Fwd: Broken ChangeCipherspec record in TLS 1.2 with OpenSSL 1.0.2d?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 11/11/15 15:32, Paul Hebert wrote:
> Hello,
> 
> After long delays with the client vendor (rhymes with 'Big Red'), I
> finally have a packet capture detailing the failing two-way
> authentication TLS 1.2 protocol exchanges - our handshake begins at
> packet 199 and proceeds with packet 214 being sent from the Apache
> 2.2.29/OpenSSL 1.0.2d server at 136.223.23.16 sending a bad
> ChangeCipherSpec record (I've attached packet excerpts from a failing
> two-way client and server auth session).  It looks like our server is
> sending a {ChangeCipherSpec, Finished} record - but the ChangeCipherSpec
> shows a length of 25 (19 hex) which causes the client to respond with an
> Alert (97).
> 
> Any suggestions you can provide would be appreciated?

The key point here is that this is a *renegotiation* handshake. You can
see this from the "Hello Request" coming from the server at the start of
your handshake. TLS record headers are always sent in the clear, but the
payload will be encrypted for all records after the CCS in the first
handshake. Whilst in an initial handshake you would expect a CCS length
of 1 the encrypted length in a renegotiation will be dependant on the
ciphersuite selected (e.g. MAC sizes, IVs, padding etc). In fact I just
had a look at a default s_server->s_client connection (which negotiated
ECDHE-RSA-AES256-GCM-SHA384), and the CCS length was indeed 25 (correctly).

You can see this in some of the other records in your trace. For example
the alert coming from the client has a length of 26 instead of 2 for an
unencrypted alert.

The client is failing with an alert of "Illegal Parameter". You need to
find out what parameter it is choking on, although my guess is, given
where it is in the handshake, that the client doesn't like the verify
data provided in the Finished message. That's quite tricky to pin down
because it essentially means that the handshake hashes differ for some
reason.

Does this happen for all handshakes or only some? Does it only ever
happen with a reneg handshakes (an initial handshake will be easier to
diagnose)? Are you only ever talking to one type of client or are there
others (and do the others work)? What ciphersuite is being negotiated?
Does it work with other ciphersuites?

Matt


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux