On Thursday, August 20, 2015 12:33 AM, Petr Pisar <petr.pisar_at_atlas.cz> wrote:
   

 On Wed, Aug 19, 2015 at 05:05:17PM +0000, Lenny Markus via curl-users wrote:
> This is a continuation of the thread I started
> here:https://github.com/bagder/curl/issues/390#issuecomment-132464361
> TL;DR:I'm unable to establish a TLSv1.2 connection from a specific machine,
> and I'm trying to troubleshoot why.
> Per the suggestions on that thread, I upgraded to the latest
> curl/libcurl/openssl,  when that failed, I proceeded to do wireshark
> captures.
> I don't want to blame firewall issues right away, since I can manually
> connect from the same box using openssl s_client
>
> I have two captures here, 1) Failed with curl, 2) Success with openssl
> s_client.

The failed capture shows immediate TCP reset from server just after client's
hello. This is hardly "Unknown SSL protocol error" as reported in your log.

This is TCP error simply. Obviously the server is not content with client's
hello and terminates the TCP connection instead of sending SSL error and then
closing the TCP connection.

Moreover it's TCP reset. Not TCP FIN as one could see if an application
shuts down a TCP connection. Normal BSD socket API does not allow a process to
send TCP reset packet. Such packet is produced by kernel's TCP stack if
something is terribly wrong with the TCP regardless of transported payload.
Either it's a very special server with a user-space TCP stack, or there is a
firewall blocking some TLS requests by resetting TCP connections.

Comparing the two clien's hellos, one can see the successful client offers
more ciphersuites, namely:

TLS_ECDHE_RSA_WITH_RC4_128_SHA
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
TLS_ECDH_RSA_WITH_RC4_128_SHA
TLS_ECDH_ECDSA_WITH_RC4_128_SHA
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_RC4_128_MD5
TLS_DHE_RSA_WITH_DES_CBC_SHA
TLS_DHE_DSS_WITH_DES_CBC_SHA
TLS_DH_RSA_WITH_DES_CBC_SHA
TLS_DH_DSS_WITH_DES_CBC_SHA
TLS_RSA_WITH_DES_CBC_SHA

And then there are some other data which my TLS decoder does not understand,
but I believe these are eliptic curve parameters. Then the satisfied server offers
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 cipher suite.

Definitively your curl configures TLS more strictly than your openssl
application.

For example my curl-7.43.0 with openssl-1.0.1p works with the server.
Suprisingly my curl offers even less ciphersuites than your curl. My curl does
not offer the data which my TLS decoder does not understand. For comparison,
these ciphersuites are missing from my client:

TLS_DH_DSS_WITH_AES_128_CBC_SHA
TLS_DH_DSS_WITH_AES_128_CBC_SHA256
TLS_DH_DSS_WITH_AES_128_GCM_SHA256
TLS_DH_DSS_WITH_AES_256_CBC_SHA
TLS_DH_DSS_WITH_AES_256_CBC_SHA256
TLS_DH_DSS_WITH_AES_256_GCM_SHA384
TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA
TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA
TLS_DH_DSS_WITH_SEED_CBC_SHA
TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA
TLS_DH_RSA_WITH_AES_128_CBC_SHA
TLS_DH_RSA_WITH_AES_128_CBC_SHA256
TLS_DH_RSA_WITH_AES_128_GCM_SHA256
TLS_DH_RSA_WITH_AES_256_CBC_SHA
TLS_DH_RSA_WITH_AES_256_CBC_SHA256
TLS_DH_RSA_WITH_AES_256_GCM_SHA384
TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA
TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_DH_RSA_WITH_SEED_CBC_SHA
TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA

My client does not offer any additional ciphersuites than your curl client.
The difference looks like my client disabled CBC mode. Then the server accepts
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384.

Thanks.  How could I force curl to use a specify cipher in this case?(I thought curl relied on the underlying openSSL library to establish the crypto/ssl handshake)
  

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-users
FAQ: http://curl.haxx.se/docs/faq.html
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2015-08-22