On 09 Nov 2017, at 4:17 AM, Michael Wojcik <Michael.Wojcik@xxxxxxxxxxxxxx> wrote:
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"?
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 — |
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
