Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
[openssl-users] SSL_F_SSL3_GET_MESSAGE and SSL_R_UNEXPECTED_MESSAGE
88 views
Skip to first unread message
Jeffrey Walton
Jan 18, 2015, 3:03:32 PM1/18/15
to
In the code below from s3_both.c, what would cause the
SSLerr(SSL_F_SSL3_GET_MESSAGE,SSL_R_UNEXPECTED_MESSAGE)?
I'm having trouble understanding the 'reuse_message', and what
satisfies the condition 'tmp.message_type != mt' (i.e., what causes
the failure).
Jeff
==========
long ssl3_get_message(SSL *s, int st1, int stn, int mt, long max, int *ok)
{
unsigned char *p;
unsigned long l;
long n;
int i,al;
if (s->s3->tmp.reuse_message)
{
s->s3->tmp.reuse_message=0;
if ((mt >= 0) && (s->s3->tmp.message_type != mt))
{
al=SSL_AD_UNEXPECTED_MESSAGE;
SSLerr(SSL_F_SSL3_GET_MESSAGE,SSL_R_UNEXPECTED_MESSAGE);
goto f_err;
}
*ok=1;
s->init_msg = s->init_buf->data + 4;
s->init_num = (int)s->s3->tmp.message_size;
return s->init_num;
}
...
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
SSLerr(SSL_F_SSL3_GET_MESSAGE,SSL_R_UNEXPECTED_MESSAGE)?
I'm having trouble understanding the 'reuse_message', and what
satisfies the condition 'tmp.message_type != mt' (i.e., what causes
the failure).
Jeff
==========
long ssl3_get_message(SSL *s, int st1, int stn, int mt, long max, int *ok)
{
unsigned char *p;
unsigned long l;
long n;
int i,al;
if (s->s3->tmp.reuse_message)
{
s->s3->tmp.reuse_message=0;
if ((mt >= 0) && (s->s3->tmp.message_type != mt))
{
al=SSL_AD_UNEXPECTED_MESSAGE;
SSLerr(SSL_F_SSL3_GET_MESSAGE,SSL_R_UNEXPECTED_MESSAGE);
goto f_err;
}
*ok=1;
s->init_msg = s->init_buf->data + 4;
s->init_num = (int)s->s3->tmp.message_size;
return s->init_num;
}
...
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Jeffrey Walton
Jan 18, 2015, 3:16:00 PM1/18/15
to
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?
On Sun, Jan 18, 2015 at 3:00 PM, Jeffrey Walton <nolo...@gmail.com> wrote:
> In the code below from s3_both.c, what would cause the
> SSLerr(SSL_F_SSL3_GET_MESSAGE,SSL_R_UNEXPECTED_MESSAGE)?
>
> I'm having trouble understanding the 'reuse_message', and what
> satisfies the condition 'tmp.message_type != mt' (i.e., what causes
> the failure).
>
/* 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?
On Sun, Jan 18, 2015 at 3:00 PM, Jeffrey Walton <nolo...@gmail.com> wrote:
> In the code below from s3_both.c, what would cause the
> SSLerr(SSL_F_SSL3_GET_MESSAGE,SSL_R_UNEXPECTED_MESSAGE)?
>
> I'm having trouble understanding the 'reuse_message', and what
> satisfies the condition 'tmp.message_type != mt' (i.e., what causes
> the failure).
>
Matt Caswell
Jan 18, 2015, 3:28:18 PM1/18/15
to
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?
>
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.
Matt
Jeffrey Walton
Jan 18, 2015, 5:01:52 PM1/18/15
to
On Sun, Jan 18, 2015 at 3:25 PM, Matt Caswell <ma...@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.
>
>
> 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.
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?
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.
Jeff
Matt Caswell
Jan 18, 2015, 6:16:23 PM1/18/15
to
On 18/01/15 21:58, Jeffrey Walton wrote:
> On Sun, Jan 18, 2015 at 3:25 PM, Matt Caswell <ma...@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?
>
> 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.
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.
Are you able to capture the handshake packets?
Matt
Jeffrey Walton
Jan 18, 2015, 7:39:16 PM1/18/15
to
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?
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
Jeffrey Walton
Jan 18, 2015, 8:33:15 PM1/18/15
to
> * 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.
> * 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
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.
Jeffrey Walton
Jan 18, 2015, 11:21:44 PM1/18/15
to
On Sun, Jan 18, 2015 at 3:25 PM, Matt Caswell <ma...@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 again Matt.
>
>
> 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.
>
So it appears the Android client is using OpenSSL 1.0.0. It also
appears the client advertizes the curve zoo, and the server selects
secp521r1.
I'd like to test with the server using only secp256r1.
Is there a way to disable curves through a configuration file? I'd
like to have the server only use the one curve.
0 new messages