Ubuntu Xenial + Postgresql v9.5 == SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177:

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Ubuntu Xenial + Postgresql v9.5 == SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177:

Graham Leggett
Hi all,

I am having quite a time trying to get postgresql v9.5 to talk over SSL on Ubuntu Xenial, running openssl v1.0.1f. Previously my setup was Ubuntu Trusty, and this works fine.

The questions I have based on the info below:

- It is the openssl s_client side that is triggering the handshake failure. Is there a way to get openssl to log why the handshake failed in the returned error message? Verification depth issue? No path to requested target? Something else?

- What is the significance of "no peer certificate available”? A tcpdump and the ssldump shows that three certificates are sent by the postgresql server, why would openssl claim no certificates were sent?

- The same certificates work fine in Ubuntu Trusty, they don’t work in Ubuntu Xenial. The certs are SHA256 certs, and consist of a root, two intermediates and a leaf cert. The postgresql server provides the two intermediates and the leaf cert, and the root as passed in -CAfile.

- Are there any known incompatibility issues with openssl on Xenial?

When I attempt to connect to postgresql using openssl s_client, I get this:

postgres@sql02:~$ openssl s_client -verify 10 -CAfile .postgresql/root.crt -key .postgresql/postgresql.key -cert .postgresql/postgresql.crt -connect sql01:5432 -servername sql01
verify depth is 10
CONNECTED(00000003)
139930468939416:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 379 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1510188432
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)


ssldump confirms that it is the client side - that’s openssl - that’s rejecting the handshake and returning unknown ca:

New TCP connection #42: 172.29.231.43(33116) <-> 172.29.228.240(5432)
42 1  0.0038 (0.0038)  C>SV3.1(300)  Handshake
      ClientHello
        Version 3.3
        random[32]=
          80 cf 99 66 b3 07 55 c2 3f cf b2 61 13 39 89 c1
          33 37 f4 77 21 a3 fd 2e f9 fa 9b 65 4e b5 bd 24
        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
        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
                  NULL
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
        compressionMethod                   NULL
42 3  0.0056 (0.0000)  S>CV3.3(3345)  Handshake
      Certificate
        certificate[1329]=[snip]
        certificate[1010]=[snip]
        certificate[990]=[snip]
42 4  0.0056 (0.0000)  S>CV3.3(333)  Handshake
      ServerKeyExchange
42 5  0.0056 (0.0000)  S>CV3.3(179)  Handshake
      CertificateRequest
        certificate_types                   rsa_sign
        certificate_types                   dss_sign
        certificate_types                 unknown value
Not enough data. Found 163 bytes (expecting 32767)
      ServerHelloDone
42 6  0.0061 (0.0004)  C>SV3.3(2)  Alert
    level           fatal
    value           unknown_ca
42    0.0062 (0.0001)  C>S  TCP RST

Regards,
Graham



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Ubuntu Xenial + Postgresql v9.5 == SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177:

Michael Wojcik
> From: openssl-users [mailto:[hidden email]] On Behalf
> Of Graham Leggett
> Sent: Wednesday, November 08, 2017 20:11
> To: [hidden email]
> Subject: [openssl-users] Ubuntu Xenial + Postgresql v9.5 == SSL
> routines:ssl23_write:ssl handshake failure:s23_lib.c:177:
>
> - What is the significance of "no peer certificate available”?

You can get this message from s_client even if the handshake failed for other reasons. I've seen it when there are no common cipher suites, for example. One case I recently observed: A stock OpenSSL 1.0.2j s_client talking to an older IIS. IIS negotiated TLSv1.2 but didn't actually support any of the TLSv1.2 suites. s_client reported the negotiated suite was 0 (i.e. none), but it also gave me the "no peer certificate" diagnostic. (In this case, forcing TLSv1.1 got the connection working, and since this was for an internal demo I didn't bother beating IIS into submission.)

> 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.

> ssldump confirms that it is the client side - that’s openssl - that’s rejecting the
> handshake and returning unknown ca:
>
> New TCP connection #42: 172.29.231.43(33116) <-> 172.29.228.240(5432)
> 42 1  0.0038 (0.0038)  C>SV3.1(300)  Handshake
>       ClientHello
>         Version 3.3
>         random[32]=
>           80 cf 99 66 b3 07 55 c2 3f cf b2 61 13 39 89 c1
>           33 37 f4 77 21 a3 fd 2e f9 fa 9b 65 4e b5 bd 24
>         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
>         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
>                   NULL
> 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?

>         compressionMethod                   NULL
> 42 3  0.0056 (0.0000)  S>CV3.3(3345)  Handshake
>       Certificate
>         certificate[1329]=[snip]
>         certificate[1010]=[snip]
>         certificate[990]=[snip]
> 42 4  0.0056 (0.0000)  S>CV3.3(333)  Handshake
>       ServerKeyExchange
> 42 5  0.0056 (0.0000)  S>CV3.3(179)  Handshake
>       CertificateRequest
>         certificate_types                   rsa_sign
>         certificate_types                   dss_sign
>         certificate_types                 unknown value
> Not enough data. Found 163 bytes (expecting 32767)
>       ServerHelloDone

Not seeing any curve agreement there. There should be a ServerKeyExchange before the ServerHelloDone, if memory serves. (Someone may correct me on this - it's been some time since I looked at the details of ECDHE key exchange.)

> 42 6  0.0061 (0.0004)  C>SV3.3(2)  Alert
>     level           fatal
>     value           unknown_ca

This looks to me like the wrong Alert value, but again maybe someone can correct me on that.

Anyway, my suggestion is try setting a cipher list that doesn't include the ECC suites, to confirm that's the problem.

--
Michael Wojcik
Distinguished Engineer, Micro Focus



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Ubuntu Xenial + Postgresql v9.5 == SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177:

Graham Leggett
On 09 Nov 2017, at 4:17 AM, Michael Wojcik <[hidden email]> 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


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Ubuntu Xenial + Postgresql v9.5 == SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177:

Michael Wojcik
> From: openssl-users [mailto:[hidden email]] On Behalf Of Graham Leggett
> Sent: Thursday, November 09, 2017 06:18
> To: [hidden email]
> Subject: Re: [openssl-users] Ubuntu Xenial + Postgresql v9.5 == SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177:

> On 09 Nov 2017, at 4:17 AM, Michael Wojcik <[hidden email]> wrote:

> > 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"?

Well, in this case it seems to mean "the server and I agreed on a cipher suite, but the server didn't do the thing it needed to do to make that suite usable".

> > 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.

At least prior to 1.1.0, to use ECC in OpenSSL the application has to make some additional calls. (I don't remember offhand how much of this goes away in the 1.1.0 API.) So it's quite possible for two applications using stock OpenSSL 1.0.x to fail to use an ECC suite.

> 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).

DEFAULT includes ECC suites. You should try something like DEFAULT:!ECDHE:!ECDH to eliminate the ECC Kx suites.

> When openssl v1.0.2m tries to connect to postgresql running openssl v1.0.1f (ubuntu xenial), I get different behaviour:
> ...
> 2017-11-09 11:01:19 UTC [12025-1] [unknown]@[unknown] LOG:  invalid length of startup packet

Offhand, I don't know what the problem is here.

--
Michael Wojcik
Distinguished Engineer, Micro Focus
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Ubuntu Xenial + Postgresql v9.5 == SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177:

Graham Leggett
On 09 Nov 2017, at 2:57 PM, Michael Wojcik <[hidden email]> wrote:

>> 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.
>
> At least prior to 1.1.0, to use ECC in OpenSSL the application has to make some additional calls. (I don't remember offhand how much of this goes away in the 1.1.0 API.) So it's quite possible for two applications using stock OpenSSL 1.0.x to fail to use an ECC suite.
>
>> 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).
>
> DEFAULT includes ECC suites. You should try something like DEFAULT:!ECDHE:!ECDH to eliminate the ECC Kx suites.

I just tried that - no change in behaviour, apart from the negotiation of a different cipher before the connection fails (0x9f).

>> When openssl v1.0.2m tries to connect to postgresql running openssl v1.0.1f (ubuntu xenial), I get different behaviour:
>> ...
>> 2017-11-09 11:01:19 UTC [12025-1] [unknown]@[unknown] LOG:  invalid length of startup packet
>
> Offhand, I don't know what the problem is here.

Does or did openssl server have any known bugs with respect to the length of a ClientHello packet being in excess of 255 bytes?

This is what a tcpdump looks like when psql linked to openssl v1.0.1f attempts to connect to postgresql linked to openssl v1.0.1f, the client side sends 8 bytes, then 1 byte, then 305 bytes in my case:

listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
11:51:45.113996 IP 172.29.231.43.40454 > 172.29.228.240.5432: Flags [S], seq 3580373978, win 26883, options [mss 8961,sackOK,TS val 12226525 ecr 0,nop,wscale 7], length 0
11:51:45.114035 IP 172.29.228.240.5432 > 172.29.231.43.40454: Flags [S.], seq 3310545722, ack 3580373979, win 26847, options [mss 8961,sackOK,TS val 12327573 ecr 12226525,nop,wscale 7], length 0
11:51:45.114243 IP 172.29.231.43.40454 > 172.29.228.240.5432: Flags [.], ack 1, win 211, options [nop,nop,TS val 12226525 ecr 12327573], length 0
11:51:45.114271 IP 172.29.231.43.40454 > 172.29.228.240.5432: Flags [P.], seq 1:9, ack 1, win 211, options [nop,nop,TS val 12226525 ecr 12327573], length 8
11:51:45.114277 IP 172.29.228.240.5432 > 172.29.231.43.40454: Flags [.], ack 9, win 210, options [nop,nop,TS val 12327573 ecr 12226525], length 0
11:51:45.114934 IP 172.29.228.240.5432 > 172.29.231.43.40454: Flags [P.], seq 1:2, ack 9, win 210, options [nop,nop,TS val 12327574 ecr 12226525], length 1
11:51:45.115132 IP 172.29.231.43.40454 > 172.29.228.240.5432: Flags [.], ack 2, win 211, options [nop,nop,TS val 12226525 ecr 12327574], length 0
11:51:45.117703 IP 172.29.231.43.40454 > 172.29.228.240.5432: Flags [P.], seq 9:314, ack 2, win 211, options [nop,nop,TS val 12226526 ecr 12327574], length 305
11:51:45.119459 IP 172.29.228.240.5432 > 172.29.231.43.40454: Flags [P.], seq 2:3941, ack 314, win 219, options [nop,nop,TS val 12327575 ecr 12226526], length 3939
11:51:45.120234 IP 172.29.231.43.40454 > 172.29.228.240.5432: Flags [P.], seq 314:321, ack 3941, win 350, options [nop,nop,TS val 12226526 ecr 12327575], length 7
11:51:45.120324 IP 172.29.231.43.40454 > 172.29.228.240.5432: Flags [R.], seq 321, ack 3941, win 350, options [nop,nop,TS val 12226526 ecr 12327575], length 0

The openssl v1.0.1f server side responds with a ServerHello, however the client side rejects the ServerHello saying "unknown ca", even though this same set of certificates works fine in Ubuntu Trusty.

In a second test, if I use openssl v1.0.2m compiled from source to connect to the same server, the client side sends 308 bytes in one go:

listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
11:53:02.032126 IP 172.29.228.7.54912 > 172.29.228.240.5432: Flags [S], seq 1471313029, win 26883, options [mss 8961,sackOK,TS val 645036074 ecr 0,nop,wscale 7], length 0
11:53:02.032165 IP 172.29.228.240.5432 > 172.29.228.7.54912: Flags [S.], seq 126514461, ack 1471313030, win 26847, options [mss 8961,sackOK,TS val 12346803 ecr 645036074,nop,wscale 7], length 0
11:53:02.032490 IP 172.29.228.7.54912 > 172.29.228.240.5432: Flags [.], ack 1, win 211, options [nop,nop,TS val 645036074 ecr 12346803], length 0
11:53:02.039507 IP 172.29.228.7.54912 > 172.29.228.240.5432: Flags [P.], seq 1:309, ack 1, win 211, options [nop,nop,TS val 645036076 ecr 12346803], length 308
11:53:02.039521 IP 172.29.228.240.5432 > 172.29.228.7.54912: Flags [.], ack 309, win 219, options [nop,nop,TS val 12346805 ecr 645036076], length 0
11:53:02.040625 IP 172.29.228.240.5432 > 172.29.228.7.54912: Flags [F.], seq 1, ack 309, win 219, options [nop,nop,TS val 12346805 ecr 645036076], length 0
11:53:02.041682 IP 172.29.228.7.54912 > 172.29.228.240.5432: Flags [.], ack 2, win 211, options [nop,nop,TS val 645036077 ecr 12346805], length 0
11:53:02.049476 IP 172.29.228.7.54912 > 172.29.228.240.5432: Flags [F.], seq 309, ack 2, win 211, options [nop,nop,TS val 645036078 ecr 12346805], length 0
11:53:02.049492 IP 172.29.228.240.5432 > 172.29.228.7.54912: Flags [.], ack 310, win 219, options [nop,nop,TS val 12346807 ecr 645036078], length 0

In this case the postgresql linked to openssl v1.0.1f immediately slams the phone down after the initial ClientHello, leading to the "SSL handshake has read 0 bytes" in the openssl client side.

In my case I have an SNI header with a long DNS name in it, and a very long list of ciphers on the client side that postgresql does not appear to give me control over.

Is this is known problem, does it ring any bells?

Regards,
Graham



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Ubuntu Xenial + Postgresql v9.5 == SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177:

Michael Wojcik
> From: openssl-users [mailto:[hidden email]] On Behalf
> Of Graham Leggett
> Sent: Thursday, November 09, 2017 08:30
> To: [hidden email]
> Subject: Re: [openssl-users] Ubuntu Xenial + Postgresql v9.5 == SSL
> routines:ssl23_write:ssl handshake failure:s23_lib.c:177:
>
> On 09 Nov 2017, at 2:57 PM, Michael Wojcik
> <[hidden email]> wrote:
>
> > DEFAULT includes ECC suites. You should try something like
> > DEFAULT:!ECDHE:!ECDH to eliminate the ECC Kx suites.
>
> I just tried that - no change in behaviour, apart from the negotiation of a
> different cipher before the connection fails (0x9f).

OK. 9f is TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, so it's not an ECC issue after all. At least not with this client. It's not clear to me if you've gone back to the 1.0.1f client, or if you were still using 1.0.2m here.

> Does or did openssl server have any known bugs with respect to the length
> of a ClientHello packet being in excess of 255 bytes?

Someone else will have to answer this. As far as I know, it was only the F5 TLS implementation that had this issue.

--
Michael Wojcik
Distinguished Engineer, Micro Focus



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users