From: owner-openssl-users On Behalf Of Ben Arnold
Sent: Friday, November 08, 2013 10:45
snip
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
snip: server cert
Yes, the server has a custom root cert that isn't installed on this
machine. I
am happy that the server cert is correct.
For testing that's okay, but I hope in real use you are verifying.
Otherwise an active attacker may be able to MITM your connections.
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
Yes. More exactly, on the initial negotiation the server does not request
client auth
(and thus openssl doesn't obtain and send it). After curl or s_client/you
sends
the GET request, the server initiates renegotiation and does request client
auth
except in the case using 1.0.1 where it fails before getting to that point.
Renegotiation is a standard capability of SSL/TLS and can be initiated by
either
client or server. Whether and when it is used depends on the applications
using SSL/TLS. *For HTTPS*, it is not uncommon for webservers to allow
connection without client auth that can access public resources but
require
renegotiation with client auth for private resources, and it certainly
appears
this particular webserver is doing that.
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.
To be exact it reports *secure* renegotiation is not supported. There
are two slightly different renegotiation protocols, the original one
(now usually called legacy or unsafe) which was found to be somewhat
vulnerable to a MITM-splicing attack, and the updated RFC5746 one
(sometimes called by the RFC#, but often just called secure).
Client can detect from ServerHello whether the server supports RFC5746
(or at least claims to) and the display tells you that. The client can't
determine if legacy renegotiation is supported except by trying it, and
even then can't be 100% certain because it could fail for another reason.
The ServerHello does indeed contain the secure-renegotiation extension
in one pcap and not the other. Assuming there isn't some really weird
logic on the server that supports 5746 only sometimes, this might be
due to the (much) larger cipherlist -- OpenSSL puts ERI-SCSV at the end
of the cipherlist, so if the server can only handle maybe 32 or 50 or so
entries
in the cipherlist it might not see ERI in the default-ciphers case.
You could experiment with intermediate size cipherlists -- my suggestion
of forcing -tls1 by itself takes you down from 80 to 52 (because it
implicitly
disables the TLSv1.2-only SHA2 and GCM suites), or so does explicit -cipher
DEFAULT:!TLSv1.2 . Removing more things you shouldn't want anyway
goes lower e.g. DEFAULT:!TLSv1.2:!EXPORT:!LOW:!SRP:!kECDH should be 30.
Or you could try writing a Java SSL client, which allows you to position
ERI-SCSV
anywhere you want in the list (i.e. end of 80, end of 40, 40th of 80, etc,
etc).
The renegotiation ClientHello is longer than the initial one because of the
session-id and
