1

Full disclosure, I have very little idea what I'm doing.

I'm doing some troubleshooting with Curl and encryption, and I don't understand why this works for a certain website I'm testing against:

curl -v https://website

but none of these options work:

curl -v -1 https://website
curl -v -2 https://website
curl -v -3 https://website

The error I get back with all three options is: 

error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure

I've Googl'd the heck out of this error, and it seems like there are a millions reasons for Curl to return this.

I know that the -2 option uses super old and busted SSL, -3 uses less old (but still busted) SSL and that -1 uses TLS. The version of Curl I'm using doesn't seem to work if I try to get granular with --tlsv1.0, etc. I don't have permission to install a newer version of Curl on the machines I'm testing on.

So, my question is this: How do I know what method Curl is using to connect to https:// sites if I don't explicitly tell it what to use?

Paul Springer
  • 293
  • 1
  • 2
  • 9

1 Answers1

1

It depends entirely on what is negotiated with the peer. You would need to examine the handshake trace in each specific case.

user207421
  • 305,947
  • 44
  • 307
  • 483
  • I figured as such. What's the best way to examine that handshake? Something like Wireshark? – Paul Springer Feb 26 '16 at 01:23
  • Maybe this can help: http://stackoverflow.com/questions/17742003/debugging-ssl-handshake – Alex Tartan Feb 26 '16 at 09:41
  • I did a packet capture, and found that on two (presumably) identical servers, Curl uses TLS 1.2 on one and 1.1 on the other. I'm assuming the 1.1 is rejected by the destination server. Why is Curl using a different default TLS version on one but not the other? Both version of Curl report the exact same details: curl 7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3 I don't get it. – Paul Springer Feb 26 '16 at 21:10