0
votes

We are using openssl 1.0.2k for our TLS related functionalities. In one of our deployment the client is able to complete the TLS handshakes using TLSv1.2 and was able to send application data towards server.After some requests the TLS connections closed from the server side with the below error "error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number"

TLS handshake steps:

1. Client hello
2. Server Hello
3. Certificate,Certificate Request, Server hello done
4. Certificate,Client Key Exchange,Change Cipher spec,Encrypted handshake message
5. Change Cipher spec,Encrypted handshake message
6. Application data exchanges between client and server
7. Encrypted Alert(server to client)
8. Encrypted Alert( client to server

The error logs from server side says "error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number"

Can you please let us know the cause for this issue. If the ssl version is mismatching then the handshake phase should not succeed right? But in our case handshake is successful and after some application data transfer our server is failing with this error.

2

2 Answers

0
votes

If the ssl version is mismatching then the handshake phase should not succeed right?

No. Any TLS packet have header, and header has TLS version inside:

(
    byte - record_type
    byte[2] - version
    byte[2] - length
) header
byte[length] - encrypted or raw data

Header is always in raw, it is never encrypted. Even if during handshake client sent TLS 1.2 version in all TLS packets, he can send another version after handshake is finished. Or someone in between can modify network traffic. In this case OpenSSL throws described error.

0
votes

In my case, I was using OpenSSL for client functionality.

I was calling SSL_set_connect_state after SSL_connect. It should be called before.

SSL_set_connect_state (for client only) cleans up all the state!

snippet:

void SSL_set_connect_state(SSL *s)
{
    s->server = 0;
    s->shutdown = 0;
    ossl_statem_clear(s);
    s->handshake_func = s->method->ssl_connect;
    clear_ciphers(s);
}

In my case:

1) Client <-> Server handshake succeeded. 2) SSL_write from client side (client sending message to server) lead to exact same error as mentioned in question (on server side)

I looked at pkt dump on server side.

read from 0x2651570 [0x2656c63] (5 bytes => 5 (0x5)) .
0000 - 16 03 01 01 e2 .....

ERROR 139688140752544:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong >version number:s3_pkt.c:337:

1) 5 Bytes read in the above snipped is the size of SSL record. Server received data, and it attempted reading SSL record.

2) 1'st byte of the record is the SSL record type In this case ===> x16 => '22'

This itself is wrong, as far as server is concerned, handshake was successful and it was expecting application data. Instead it received data with SSL record for handshake, hence it was throwing the error.

A correct snippet of application data is as follows: 'x17' ==> 23

read from 0x2664f80 [0x2656c63] (5 bytes => 5 (0x5)) .
0000 - 17 03 03 00 1c

Since SSL_set_connect_state was called after connecting, client state was lost and SSL_write will attempt handshake if handshake wasnt performed before (client thought so as its state was lost!)

More data on these SSL records can be found here: https://www.ibm.com/support/knowledgecenter/SSB23S_1.1.0.12/gtps7/s5rcd.html