search

flightaware / piaware

Client-side package and programs for forwarding ADS-B data to FlightAware
BSD 2-Clause "Simplified" License
487 stars 69 forks source link

Adept server not compatible with OpenSSL 3.0 in standard settings #84

Closed Lalufu closed 2 years ago

Lalufu commented 2 years ago

Distributions (Like Ubuntu 22.04 and Fedora 36) have started shipping OpenSSL 3.0. Running piaware on those distributions ends up with piaware not being able to connect to the adept server:

piaware[872]: Connecting to FlightAware adept server at 206.253.84.194/1200
piaware[872]: Connection with adept server at 206.253.84.194/1200 established
piaware[872]: TLS error: unexpected eof while reading
piaware[872]: TLS handshake with adept server at 206.253.84.194/1200 failed: handshake failed: unexpected eof while reading
piaware[872]: reconnecting in 56 seconds...

The reason for this is that OpenSSL 3.0, in its default setting, does no longer support TLS servers that do not support RfC5746 (Secure renegotiations). This RfC is from 2010, as a response to a CVS from 2009.

If a server support this setting can be easily tested from the CLI:

$ openssl s_client -host 206.253.84.198 -port 1200 < /dev/null |& grep Secure
Secure Renegotiation IS NOT supported

While it is possible to configure openssl 3.0 to again talk to servers that do not support this feature, support for a security feature that is more than 10 years old should be enabled on the server side.

Lalufu commented 2 years ago

On some further investigation this doesn't seem to be triggered by the missing secure renegotiation feature (although that should probably be addressed as well).

On this F36 system, piaware connects to the adept server, and then tries to start a TLS negotiation over the socket: https://github.com/flightaware/piaware/blob/2bb5ed53a52c8271f76c109ee0d679bcda0c1722/package/fa_adept_client.tcl#L213

Looking at a packet capture, the client sends a 512 byte packet, and the server closes the connection. Wireshark doesn't seem to think that whatever is in those 512 bytes is a TLS handshake,and I don't think it is, either, but I have no idea what else it could be. The pcap file is available, but github won't let me add it to the ticket.

I don't know enough about TCL to figure out what's going on, is there a simple TLS/SSL client (like openssl s_client) in TCL?

Lalufu commented 2 years ago

It appears that tcltls on Fedora 36 is just plain broken. I'll close this.

mutability commented 2 years ago

Well, that's not great. Thanks for the report. Any idea what's broken on F36?

Re secure renegotiation, we're using a recent openssl (1.1.1c?) on the server side and not doing anything special that would disable secure renegotation, so I'm not sure what's going on there. FWIW, I get conflicting reports from openssl on the two sides of the connection if I run a s_client / s_server pair on one of the adept servers (the server site claims that renegotiation is supported) so that s_client check may be misleading.

client side:

New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 21 (unable to verify the first certificate)

server side:

ACCEPT
-----BEGIN SSL SESSION PARAMETERS-----
MH0CAQECAgMEBAITAgQgPb5XyG1TrnWjA+FKCi2jNJmgTawGZFZXrkv9mFIlB5ME
MApGQheT9akg12OVR62xA6gWK47VaR6L30mbzfuWLFwnLszGVESMrLVTHmHydFNO
w6EGAgRihxfQogQCAhwgpAYEBAEAAACuBgIEQ5epnw==
-----END SSL SESSION PARAMETERS-----
Shared ciphers:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA
Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:ECDSA+SHA1:RSA+SHA224:RSA+SHA1:DSA+SHA224:DSA+SHA1:DSA+SHA256:DSA+SHA384:DSA+SHA512
Shared Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:ECDSA+SHA1:RSA+SHA224:RSA+SHA1
Supported Elliptic Groups: X25519:P-256:X448:P-521:P-384
Shared Elliptic groups: X25519:P-256:X448:P-521:P-384
---
No server certificate CA names sent
CIPHER is TLS_AES_256_GCM_SHA384
Secure Renegotiation IS supported
Lalufu commented 2 years ago

I'm not sure what precisely is going on with tcltls in F36, but it's broken in general, and not only in conjunction with FA. I've got a ticket open on the Fedora side to look at this.

With respect to the renegotiation issue I'll have to apologize, this is slightly more complicated than it looks at first.

If SSL negotiates a TLS1.3 connection, openssl will always show "Secure Renegotiation IS NOT supported" from the client side because TLS1.3 doesn't support renegotiation at all, secure or not. Apparently this has led to enough confusion that openssl 3.1 will change the wording on that.

The FA adept servers do support TLS1.3, hence the message. If one forces the connection down to TLS1.2 (with -no_tls1_3) then secure renegotiation is supported.

There's nothing to be done from the FA side on this.

On Thu, May 19, 2022 at 09:28:07PM -0700, Oliver Jowett wrote:

Well, that's not great. Thanks for the report. Any idea what's broken on F36?

Re secure renegotiation, we're using a recent openssl (1.1.1c?) on the server side and not doing anything special that would disable secure renegotation, so I'm not sure what's going on there. FWIW, I get conflicting reports from openssl on the two sides of the connection if I run a s_client / s_server pair on one of the adept servers (the server site claims that renegotiation is supported) so that s_client check may be misleading.

client side:

New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 21 (unable to verify the first certificate)

server side:

ACCEPT
-----BEGIN SSL SESSION PARAMETERS-----
MH0CAQECAgMEBAITAgQgPb5XyG1TrnWjA+FKCi2jNJmgTawGZFZXrkv9mFIlB5ME
MApGQheT9akg12OVR62xA6gWK47VaR6L30mbzfuWLFwnLszGVESMrLVTHmHydFNO
w6EGAgRihxfQogQCAhwgpAYEBAEAAACuBgIEQ5epnw==
-----END SSL SESSION PARAMETERS-----
Shared ciphers:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA
Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:ECDSA+SHA1:RSA+SHA224:RSA+SHA1:DSA+SHA224:DSA+SHA1:DSA+SHA256:DSA+SHA384:DSA+SHA512
Shared Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:ECDSA+SHA1:RSA+SHA224:RSA+SHA1
Supported Elliptic Groups: X25519:P-256:X448:P-521:P-384
Shared Elliptic groups: X25519:P-256:X448:P-521:P-384
---
No server certificate CA names sent
CIPHER is TLS_AES_256_GCM_SHA384
Secure Renegotiation IS supported

-- Reply to this email directly or view it on GitHub: https://github.com/flightaware/piaware/issues/84#issuecomment-1132446426 You are receiving this because you modified the open/close state.

Message ID: @.***>

Lalufu commented 2 years ago

To close this off, tcltls is fixed on Fedora 36, and piaware works fine now.