On Sun, Jan 18, 2015 at 7:35 PM, Jeffrey Walton <noloader at gmail.com> wrote:
> On Sun, Jan 18, 2015 at 6:13 PM, Matt Caswell <matt at openssl.org> wrote:
>>
>>
>> On 18/01/15 21:58, Jeffrey Walton wrote:
>>> On Sun, Jan 18, 2015 at 3:25 PM, Matt Caswell <matt at openssl.org> wrote:
>>>>
>>>>
>>>> On 18/01/15 20:13, Jeffrey Walton wrote:
>>>>> My bad... I think this is the code (from around line 500 in s3_both.c):
>>>>>
>>>>> /* s->init_num == 4 */
>>>>> if ((mt >= 0) && (*p != mt))
>>>>> {
>>>>> al=SSL_AD_UNEXPECTED_MESSAGE;
>>>>> SSLerr(SSL_F_SSL3_GET_MESSAGE,SSL_R_UNEXPECTED_MESSAGE);
>>>>> goto f_err;
>>>>> }
>>>>>
>>>>> What would cause this error on a client?
>>>>>
>>>>
>>>> The client has an internal state machine which tells it what message it
>>>> should expect next from the server based on its current state. Only
>>>> certain messages are legal at any one time. The variable mt holds the
>>>> message type of the message it is expecting to receive. The variable p
>>>> points into the message buffer for the message that it has actually
>>>> received. If the message sent from the server doesn't match the one the
>>>> client was expecting then you get this error.
>>>
>>> Thanks Matt.
>>>
>>> Have you guys (the devs) seen this failure in the field during
>>> testing? If so, what's a typical configuration to cause it? Or what's
>>> the offending server message?
>>
>> No - I've not seen it.
>>
>>>
>>> The server is using OpenSSL 1.0.1e-fips 11 Feb 2013, Thu Nov 6
>>> 12:33:36 UTC 2014. The client is Android 5.0. Down level Android
>>> versions are OK. s_client is OK.
>>
>> So - just to clarify: Is the client openssl too? Which side is sending
>> the alert? Having just reread your earlier comment I'm not clear if you
>> meant the client sent the alert, or the client received the alert.
>
> My bad... The Android 5.0 client uses OpenSSL too (but I'm not sure
> what version). Client and server are trying to negotiate TLS 1.2 with
> EC.
> * Three way handshake
> * ClientHello
> * Server ACK of previous client messages (1 each ACK, three different segments)
> * ServerHello
> * Client ACK of previous server messages (4 each ACK, four different segments)
> * Server closes connection
My bad again. The client closes the connection, not the server.
The "4 each ACKs" cover up to bytes 5719 (Seq 195, ACK 5719). That's
the `ServerHello`.
Then the client performs an ACK, FIN on the same (Seq 195, ACK 5719).
That's when the client begins processing the `ServerHello`.
Looking at a "good" exchange (TLS 1.0 client with the server) and the
"bad" exchange (TLS 1.2 client with the server), they look the same to
me (modulo the different cipher suite). The Record Layer looks well
formed, and the Handshake Protocol messages look well formed. And I
don't see any extra bytes.
The Server's Hello does have a renegotiation_info extension for TLS
1.2 that's missing from TLS 1.0. Is RI supposed to be empty? If it is,
then I am seeing a length of 1 - the NULL byte.
Jeff
