[openssl-users] SSL_F_SSL3_GET_MESSAGE and SSL_R_UNEXPECTED_MESSAGE

[Jeffrey Walton]

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.

The server closes the connection after it sends it ServerHello. The
server selects TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA in its ServerHello.

> Are you able to capture the handshake packets?

Yes.

Here's what's happening on the wire:

* 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

I think what I'm seeing is artifacts of:

  * http://rt.openssl.org/Ticket/Display.html?id=3022&user=guest&password=guest
  * https://bugzilla.redhat.com/show_bug.cgi?id=1045363

I don't really know where to post a PCAP and not torture you with the
download from file sharing gimmicks, so I'll defer. I'm open to
non-gimmicky file sharing sites if you have a suggestion.

Jeff