> From: Viktor Dukhovni > > You can test with s_client(1) and compare results. Is your client > certificate an > RSA certificate? How many bits of public key? Is its signature SHA1 or > SHA256?
It's a 2048 bit RSA SHA1 certificate, but I think Dave Thompson's right and it's not getting that far. I have tried using s_client and it fails with the same handshake failure. Please see below. > Attaching a PCAP file of the traffic is much more useful than hex packet > dumps. You're right of course, that is much more sensible. I have attached two pcap traces from s_connect, one success and one failure. > From: Dave Thompson > > To OP: is the logged server cert info true? I note the log shows the client > verification of the server failed; did this website give you a "custom" root > to > trust and did you simply not set that up (or perhaps not in the environment > you're testing in)? > Yes, the server has a custom root cert that isn't installed on this machine. I am happy that the server cert is correct. > To OP: If you can try to reproduce with s_client default (which is > TLSv1.2 or less) and again specifying -tls1 (or -no_tls1_2 -no_tls1_1). > That might narrow it down pretty close. I can reproduce the failure with s_client in the same manner. It looks (to me) like the server only asks for the client certificate once the GET command has been issued, the initial negotiation doesn't ask for it. I don't know the TLS protocol so that might be normal. Once I send the GET ... command it tries to renegotiate but fails. Looking at the output from s_client -state I see this during the first negotiation... --- No client certificate CA names sent --- SSL handshake has read 2884 bytes and written 639 bytes --- New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA Server public key is 2048 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE And then I send GET /directory HTTP/1.1 and see... SSL_connect:SSL renegotiate ciphers SSL_connect:unknown state SSL_connect:failed in unknown state 16444:error:140940E5:SSL routines:SSL3_READ_BYTES:ssl handshake failure:.\ssl\s3_pkt.c:1156: > From: Krzysztof Kwiatkowski > > Do you still see an error if you specify one cipher? f.e. AES256-SHA? I do get an error when using AES256-SHA, in fact a much earlier error as the server does not support that cipher, nor does it support AES-128-SHA. However I took the idea and if I add -cipher "DES-CBC3-SHA" (as selected by the server in the previous run) to s_connect then everything works OK, and if I add the same cipher selection to my program that that works too. When I do specify DES-CBC3-SHA, s_client also reports Secure Renegotiation IS supported This sounds important to me! :) Notice that the failure case reports renegotiation is NOT supported. So the question now is, how come negotiation *is* supported when I manually specify DES-CBC3-SHA and *not* supported when I leave default ciphers, when the server ends up picking DES-CBC3-SHA anyway. I have attached two pcap files, both captured using s_client - one with the default ciphers and one with -cipher "DES_CBC3-SHA". I notice that the Client Hello is slightly different, when using all ciphers there are two extra extensions: ec_point_formats and elliptic_curves. Whether or not this is relevant I have no idea, I imagine not as they are likely omitted because DES isn't ECC. For now all the servers I need to talk to support DES-CBC3-SHA, this may not always be the case. Any idea how likely it is I will find a server that doesn't? Or is there something else I can set to make renegotiation supported without specifying the cipher. Thanks for all your suggestions so far, Ben
s_client_default.pcap
Description: s_client_default.pcap
s_client_des_cbc3_sha.pcap
Description: s_client_des_cbc3_sha.pcap
