[openssl-users] Ubuntu Xenial + Postgresql v9.5 == SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177:

Thu Nov 9 11:17:30 UTC 2017

On 09 Nov 2017, at 4:17 AM, Michael Wojcik <Michael.Wojcik at microfocus.com> wrote:

>> New, (NONE), Cipher is (NONE)
>> SSL-Session:
>>    Protocol  : TLSv1.2
>>    Cipher    : 0000
> 
> Yeah. TLSv1.2, no cipher. My guess is the server is allowing the 1.2 protocol level but not supporting any of the 1.2 suites.

Does this definitely mean no cipher, or could it mean “I failed earlier in the process before I took note of the cipher, like with the no peer certificate available"?

>> 42 2  0.0056 (0.0017)  S>CV3.3(62)  Handshake
>>      ServerHello
>>        Version 3.3
>>        random[32]=
>>          f9 4d fa 63 ee d5 65 6d ba dd 58 de 51 00 8e ac
>>          9f 45 24 43 e2 17 88 07 41 9a 8d aa 7f 95 2a 13
>>        session_id[0]=
>> 
>>        cipherSuite         Unknown value 0xc030
> 
> Hmm. This claims they agreed on TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. Maybe no ECC curves in common for ECDHE Kx?

This is openssl v1.0.1f (ubuntu xenial) talking to openssl v1.0.1f (ubuntu xenial), although trying openssl as shipped by MacOS Sierra on the client side gives the same result.

I set the ciphers explicitly on the server side to DEFAULT and got the same result (eliminating whatever weird settings postgresql-on-ubuntu might have as a default).

Next step was to bring openssl up onto a debugger and see what openssl was doing internally. I created a debug build of v1.0.2m, and I now have different behaviour:

When openssl v1.0.2m tries to connect to postgresql running openssl v1.0.1f (ubuntu xenial), I get different behaviour:

New TCP connection #2: localhost(61009) <-> localhost(15432)
2 1  0.0002 (0.0002)  C>S  Handshake
      ClientHello
        Version 3.3 
        cipher suites
        Unknown value 0xc030
        Unknown value 0xc02c
        Unknown value 0xc028
        Unknown value 0xc024
        Unknown value 0xc014
        Unknown value 0xc00a
        Unknown value 0xa5
        Unknown value 0xa3
        Unknown value 0xa1
        Unknown value 0x9f
        Unknown value 0x6b
        Unknown value 0x6a
        Unknown value 0x69
        Unknown value 0x68
        TLS_DHE_RSA_WITH_AES_256_CBC_SHA
        TLS_DHE_DSS_WITH_AES_256_CBC_SHA
        TLS_DH_RSA_WITH_AES_256_CBC_SHA
        TLS_DH_DSS_WITH_AES_256_CBC_SHA
        Unknown value 0x88
        Unknown value 0x87
        Unknown value 0x86
        Unknown value 0x85
        Unknown value 0xc032
        Unknown value 0xc02e
        Unknown value 0xc02a
        Unknown value 0xc026
        Unknown value 0xc00f
        Unknown value 0xc005
        Unknown value 0x9d
        Unknown value 0x3d
        TLS_RSA_WITH_AES_256_CBC_SHA
        Unknown value 0x84
        Unknown value 0xc02f
        Unknown value 0xc02b
        Unknown value 0xc027
        Unknown value 0xc023
        Unknown value 0xc013
        Unknown value 0xc009
        Unknown value 0xa4
        Unknown value 0xa2
        Unknown value 0xa0
        Unknown value 0x9e
        TLS_DHE_DSS_WITH_NULL_SHA
        Unknown value 0x40
        Unknown value 0x3f
        Unknown value 0x3e
        TLS_DHE_RSA_WITH_AES_128_CBC_SHA
        TLS_DHE_DSS_WITH_AES_128_CBC_SHA
        TLS_DH_RSA_WITH_AES_128_CBC_SHA
        TLS_DH_DSS_WITH_AES_128_CBC_SHA
        Unknown value 0x9a
        Unknown value 0x99
        Unknown value 0x98
        Unknown value 0x97
        Unknown value 0x45
        Unknown value 0x44
        Unknown value 0x43
        Unknown value 0x42
        Unknown value 0xc031
        Unknown value 0xc02d
        Unknown value 0xc029
        Unknown value 0xc025
        Unknown value 0xc00e
        Unknown value 0xc004
        Unknown value 0x9c
        Unknown value 0x3c
        TLS_RSA_WITH_AES_128_CBC_SHA
        Unknown value 0x96
        Unknown value 0x41
        TLS_RSA_WITH_IDEA_CBC_SHA
        Unknown value 0xc011
        Unknown value 0xc007
        Unknown value 0xc00c
        Unknown value 0xc002
        TLS_RSA_WITH_RC4_128_SHA
        TLS_RSA_WITH_RC4_128_MD5
        Unknown value 0xc012
        Unknown value 0xc008
        TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
        TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
        TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA
        TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA
        Unknown value 0xc00d
        Unknown value 0xc003
        TLS_RSA_WITH_3DES_EDE_CBC_SHA
        Unknown value 0xff
        compression methods
                unknown value
                  NULL
2    0.0151 (0.0148)  S>C  TCP FIN
2    0.0161 (0.0009)  C>S  TCP FIN

The server side logs the following and slams the phone down:

2017-11-09 11:01:19 UTC [12025-1] [unknown]@[unknown] LOG:  invalid length of startup packet

The client side logs the following hint:

SSL handshake has read 0 bytes and written 382 bytes

Why would 382 bytes be an invalid length for an SSL startup packet?

I did see old bug reports from around 2012 where Ubuntu shipped an openssl that broke on many sites, and there were references that buggy SSL implementations were limited to 255 bytes only. Was openssl ever such a buggy implementation?

Regards,
Graham
—

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171109/1f386cb5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3240 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171109/1f386cb5/attachment-0001.bin>