TLS-RFC Compliance

[mmaehren]

Hi, we (@jurajsomorovsky @ic0ns @mmaehren @XoMEX @Kavakuo) are performing an analysis of the RFC-compliance of open-source TLS implementations. Below we list our findings for this implementation. We admit that some are rather nit-picky, but we added them for the sake of completeness. We tried to keep the descriptions brief and didn’t want to spam the issues section so feel free to split up the list into individual issues as you see fit. If you disagree with our interpretation of certain RFC statements, please leave feedback as we’re interested in your view.

Our results apply to the default configuration of version 3.2.3. We used the example implementations for client and server.

[S] = Applies to server [C] = Applies to client [C+S] = Applies to both

Misc

• [S] LibreSSL can't process a SignatureAlgorithms extension if it contains more than 32 algorithms and sends a 'decode error' alert

• [C+S] LibreSSL by default offers and negotiates RC4 cipher suites which are deprecated by RFC 7465

• [C] LibreSSL sends both a fatal alert ('bad record mac') and a warning alert ('close notify') upon

  • receiving an AEAD protected record with an invalid authentication tag/ciphertext in a TLS 1.2 session
  • receiving a CBC-mode protected record with invalid MAC/ciphertext or padding
  • receiving an empty application data record (length 0)
  • upon detecting a record overflow
  • RFC 8446 - 6.2 Error Alerts

    Upon transmission or receipt of a fatal alert message, both parties MUST immediately close the connection.

• [C] LibreSSL does not verify if the cipher suite selected in a HelloRetryRequest is the same as in the subsequent ServerHello

  • RFC 8446 - 4.1.4 Hello Retry Request

    Upon receiving the ServerHello, clients MUST check that the cipher suite supplied in the ServerHello is the same as that in the HelloRetryRequest and otherwise abort the handshake with an "illegal_parameter" alert.

• [C] LibreSSL does not ignore the legacy version field in a ServerHello that negotiates TLS 1.3 and aborts the handshake for invalid values like 0x0304 or 0x0505

  • RFC 8446 - 4.2.1 Supported Versions

    If this extension is present, clients MUST ignore the ServerHello.legacy_version value and MUST use only the "supported_versions" extension to determine the selected version.

  • Note that the RFC also defines that a server MUST use 0x0303 as the legacy version but specifically says that the client MUST ignore the field when SupportedVersions has been received

Session not aborted

• [S] upon receiving a ChangeCipherSpec message after a completed TLS 1.2 handshake

  • This seems to affect the session keys in some way as additional encrypted messages sent afterwards trigger a 'bad record mac'

• [C] upon receiving a ServerHello that contains an extension that was not offered by the client

  • We specifically tested this with encrypt-then-MAC, MaximumFragmentLength and GREASE extensions
  • RFC 5246 - 7.4.1.4. Hello Extensions

    If a client receives an extension type in ServerHello that it did not request in the associated ClientHello, it MUST abort the handshake with an unsupported_extension fatal alert.

  • Please note the exception of the Cookie extension in TLS 1.3

• [C] upon receiving an EncryptedExtensions message with a forbidden extension in it

  • Specifically tested with Padding and GREASE extensions
  • RFC 8446 - 4.3.1. Encrypted Extensions

    The client MUST check EncryptedExtensions for the presence of any forbidden extensions and if any are found MUST abort the handshake with an "illegal_parameter" alert.

• [C] upon receiving interleaved handshake messages.

  • Our tests interleave a Hello message with a warning alert with varying alert descriptions
  • LibreSSL accepted interleaved records for all descriptions except 'close notify' if a HelloRetry request had not been sent
  • LibreSSL also accepted interleaved records after an HRR if the specific alert 'user canceled' was used

• [C+S] upon receiving an emtpy ChangeCipherSpec record before the actual ChangeCipherSpec message

  • RFC 5246 - 6.2.1 Fragmentation

    Implementations MUST NOT send zero-length fragments of Handshake, Alert, or ChangeCipherSpec content types.

• [S] upon receiving a ClientHello that contains elliptic curve extensions but no ECC cipher suite

  • 8422 - 4. TLS Extensions for ECC

    The client MUST NOT include these extensions in the ClientHello message if it does not propose any ECC cipher suites.

• [S] upon receiving a Padding extension that contains bytes other than 0x00

  • Please leave a comment if your implementation does not support this extension and hence ignores the content
  • RFC 7685 - 3. Padding Extension

    The client MUST fill the padding extension completely with zero bytes, although the padding extension_data field may be empty.

Only session closed but no alert sent

• [C+S] upon a parsing error due to an invalid lengthfield. Our tests reduce the lengthfield by one, which results in an incomplete message with an unprocessed trailing byte. An alert was not sent for specific cases:
  • length of a Certificate message
  • length of a ServerHello (alert is only missing when a HelloRetryRequest has been sent before)
  • length of the session ID field in a ServerHello (alert is only missing when a HelloRetryRequest has been sent before)
  • length of a KeyShare extension (alert is only missing when a HelloRetryRequest has been sent before)
  • length of a SupportedVersions extension (alert is only missing when a HelloRetryRequest has been sent before)
  • length of a CertificateRequestContext (here, the length is set to one without any context inserted)
  • length of a ClientKeyExchangeMessage except for RSA cipher suites
• [C] upon receiving a finite field DH share that is out of bounds
  • RFC 7919 - 3. Client Behavior

    [...] the client MUST verify that dh_Ys is in the range 1 < dh_Ys < dh_p - 1. If dh_Ys is not in this range, the client MUST terminate the connection with a fatal handshake_failure(40) alert.

• [C + S] upon receiving a TLS 1.3 record with an invalid AEAD authentication tag/ciphertext
  • RFC 8446 - 5. Record Protocol

    If the decryption fails, the receiver MUST terminate the connection with a "bad_record_mac" alert.

• [C] upon receiving a ServerKeyExchange message when no Certificate message has been received
• [C] upon receiving a TLS 1.3 HelloRetryRequest that does not result in any changes for the subsequent ClientHello
  • RFC 8446 - 4.1.4 Hello Retry Request

    Clients MUST abort the handshake with an "illegal_parameter" alert if the HelloRetryRequest would not result in any change in the ClientHello.

• [C] upon receiving a TLS 1.3 HelloRetryRequest that requests an unproposed group
  • RFC 8446 - 4.2.8 Key Share

    Upon receipt of this extension in a HelloRetryRequest, the client MUST verify that (1) the selected_group field corresponds to a group which was provided in the "supported_groups" extension in the original ClientHello [...] If either of these checks fails, then the client MUST abort the handshake with an "illegal_parameter" alert.

• [C] upon receiving a second TLS 1.3 HelloRetryRequest
  • RFC 8446 - 4.1.4 Hello Retry Request

    If a client receives a second HelloRetryRequest in the same connection (i.e., where the ClientHello was itself in response to a HelloRetryRequest), it MUST abort the handshake with an "unexpected_message" alert.

• [C] upon receiving a ServerHello with a SupportedVersions extension that negotiates a version below TLS 1.3
  • RFC 8446 - 4.2.1 Supported Versions

    If the "supported_versions" extension in the ServerHello contains a version not offered by the client or contains a version prior to TLS 1.3, the client MUST abort the handshake with an "illegal_parameter" alert.

• [C+S] upon receiving a 'close notify' alert during the handshake
• [S] upon receiving a ClientHello after a completed TLS 1.3 handshake
• [S] when the capabilities of a TLS 1.3 client and LibreSSL server do not allow for a successful handshake
  • RFC 8446 - 4.1.1 Cryptographic Negotiation

    If the server is unable to negotiate a supported set of parameters (i.e., there is no overlap between the client and server parameters), it MUST abort the handshake with either a "handshake_failure" or "insufficient_security" fatal alert (see Section 6).

• [S] upon receiving an SSL2 Hello message

Different alert sent than defined by the RFC

• [S] upon receiving a ClientHello with an EcPointFormats extension that only offers compressed or undefined point formats. LibreSSL sends a 'decode error'.
  • RFC 8422 - 5.1. Client Hello Extensions

    If the client sends the extension and the extension does not contain the uncompressed point format, and the client has used the Supported Groups extension to indicate support for any of the curves defined in this specification, then the server MUST abort the handshake and return an illegal_parameter alert.

[kinichiro]

I had checked the RFC quotes above.

• "8422 - 4. TLS Extensions for ECC" the word "RFC" is missing, but no problem.
• "RFC 8446 - 5. Record Protocol" I thought "5.2. Record Payload Protection" would be more accurate since the sentence quoted is there.
• "[C] upon receiving a second TLS 1.3 HelloRetryRequest" excuse me, but I added single space between ">" and "RFC 8446" to show quotes correctly with markdown.
• "RFC 8422 - 5.1. Client Hello Extensions" I thought "5.1.2. Supported Point Formats Extension" would be more accurate since the sentence quoted is there.

[mmaehren]

Thank you, we will try to be more specific with the RFC chapters in the future.

[botovq]

On Thu, Jun 03, 2021 at 11:30:38PM -0700, mmaehren wrote:

Hi, we @.*** @ic0ns @mmaehren @XoMEX @Kavakuo) are performing an analysis of the RFC-compliance of open-source TLS implementations. Below we list our findings for this implementation. We admit that some are rather nit-picky, but we added them for the sake of completeness. We tried to keep the descriptions brief and didn’t want to spam the issues section so feel free to split up the list into individual issues as you see fit. If you disagree with our interpretation of certain RFC statements, please leave feedback as we’re interested in your view.

Thanks for the detailed report!

We are aware of a few of the issues you raised, in particular a number of the issues with closing the connection without sending an alert are known. Most others seem outright bugs - at least none of them stands out as obviously incorrect reading of the RFCs after a first glance.

A detailed assessment will need a bit of time.

Since you asked: we do not support the padding extension (we also don't support the GREASE, MaximumFragmentLength, or encrypt-then-MAC extensions - this is related to the missing abort when these are sent unexpectedly).

How did you test all this? I assume that your group developed a certain test suite. Would it be possible to have access to that so we can avoid redoing the work that was already done by you (for reproducing, testing and regression testing)?

Our results apply to the default configuration of version 3.2.3. We used the example implementations for client and server.

Did you test 3.2.3 or 3.3.3? If it was 3.2.3, this would be a bit unfortunate, this is about 8 months old with only a small security fix from 6 months ago. There has been quite a bit of development since - although it's unlikely that many of these issues would be addressed.

What does "we used the example implementations for the client and server" mean?

[mmaehren]

Yes, we developed an automated tool for this which we plan to release in the coming months. By 'example implementations' we meant the s_client and s_server equivalent of libressl.

[mmaehren]

Hey, based on the feedback we received from other developers, we split up the reports to separate cases where the RFC imposes restrictions on a sender but does not require the receiver to enforce these restrictions. You find these at the bottom of the comment. We removed reports of missing alerts in TLS 1.3 as sending alerts is explicitly stated as optional in RFC 8446. We didn't edit the initial report to avoid confusion.

Misc

• [S] LibreSSL can't process a SignatureAlgorithms extension if it contains more than 32 algorithms and sends a 'decode error' alert

• [C+S] LibreSSL by default offers and negotiates RC4 cipher suites which are deprecated by RFC 7465

• [C] LibreSSL sends both a fatal alert ('bad record mac') and a warning alert ('close notify') upon

  • receiving an AEAD protected record with an invalid authentication tag/ciphertext in a TLS 1.2 session
  • receiving a CBC-mode protected record with invalid MAC/ciphertext or padding
  • receiving an empty application data record (length 0)
  • upon detecting a record overflow
  • RFC 8446 - 6.2 Error Alerts

    Upon transmission or receipt of a fatal alert message, both parties MUST immediately close the connection.

• [C] LibreSSL does not verify if the cipher suite selected in a HelloRetryRequest is the same as in the subsequent ServerHello

  • RFC 8446 - 4.1.4 Hello Retry Request

    Upon receiving the ServerHello, clients MUST check that the cipher suite supplied in the ServerHello is the same as that in the HelloRetryRequest and otherwise abort the handshake with an "illegal_parameter" alert.

• [C] LibreSSL does not ignore the legacy version field in a ServerHello that negotiates TLS 1.3 and aborts the handshake for invalid values like 0x0304 or 0x0505

  • RFC 8446 - 4.2.1 Supported Versions

    If this extension is present, clients MUST ignore the ServerHello.legacy_version value and MUST use only the "supported_versions" extension to determine the selected version.

  • Note that the RFC also defines that a server MUST use 0x0303 as the legacy version but specifically says that the client MUST ignore the field when SupportedVersions has been received

Session not aborted

• [S] upon receiving a ChangeCipherSpec message after a completed TLS 1.2 handshake

  • This seems to affect the session keys in some way as additional encrypted messages sent afterwards trigger a 'bad record mac'

• [C] upon receiving a ServerHello that contains an extension that was not offered by the client

  • We specifically tested this with encrypt-then-MAC, MaximumFragmentLength and GREASE extensions
  • RFC 5246 - 7.4.1.4. Hello Extensions

    If a client receives an extension type in ServerHello that it did not request in the associated ClientHello, it MUST abort the handshake with an unsupported_extension fatal alert.

  • Please note the exception of the Cookie extension in TLS 1.3

• [C] upon receiving an EncryptedExtensions message with a forbidden extension in it

  • Specifically tested with Padding and GREASE extensions
  • RFC 8446 - 4.3.1. Encrypted Extensions

    The client MUST check EncryptedExtensions for the presence of any forbidden extensions and if any are found MUST abort the handshake with an "illegal_parameter" alert.

Only session closed but no alert sent

• [C+S] upon a parsing error due to an invalid lengthfield. Our tests reduce the lengthfield by one, which results in an incomplete message with an unprocessed trailing byte. An alert was not sent for specific cases:

  • length of a Certificate message
  • length of a ServerHello (alert is only missing when a HelloRetryRequest has been sent before)
  • length of the session ID field in a ServerHello (alert is only missing when a HelloRetryRequest has been sent before)
  • length of a SupportedVersions extension (alert is only missing when a HelloRetryRequest has been sent before)
  • length of a ClientKeyExchangeMessage except for RSA cipher suites

• [C] upon receiving a finite field DH share that is out of bounds

  • RFC 7919 - 3. Client Behavior

    [...] the client MUST verify that dh_Ys is in the range 1 < dh_Ys < dh_p - 1. If dh_Ys is not in this range, the client MUST terminate the connection with a fatal handshake_failure(40) alert.

• [C] upon receiving a ServerKeyExchange message when no Certificate message has been received

• [C+S] upon receiving a 'close notify' alert during the handshake

  • This is not mandatory in TLS 1.3 but it was in 1.2

• [S] upon receiving an SSL2 Hello message

Different alert sent than defined by the RFC

• [S] upon receiving a ClientHello with an EcPointFormats extension that only offers compressed or undefined point formats. LibreSSL sends a 'decode error'.
  • RFC 8422 - 5.1. Client Hello Extensions

    If the client sends the extension and the extension does not contain the uncompressed point format, and the client has used the Supported Groups extension to indicate support for any of the curves defined in this specification, then the server MUST abort the handshake and return an illegal_parameter alert.

Unenforced sender restrictions

In the following cases, the receiver is not explicitly required to terminate the connection upon detecting a misbehavior of the peer.

• [C] upon receiving interleaved handshake messages.

  • Our tests interleave a Hello message with a warning alert with varying alert descriptions
  • LibreSSL accepted interleaved records for all descriptions except 'close notify' if a HelloRetry request had not been sent
  • LibreSSL also accepted interleaved records after an HRR if the specific alert 'user canceled' was used

• [C+S] upon receiving an emtpy ChangeCipherSpec record before the actual ChangeCipherSpec message

  • RFC 5246 - 6.2.1 Fragmentation

    Implementations MUST NOT send zero-length fragments of Handshake, Alert, or ChangeCipherSpec content types.

• [S] upon receiving a Padding extension that contains bytes other than 0x00

  • Please leave a comment if your implementation does not support this extension and hence ignores the content
  • RFC 7685 - 3. Padding Extension

    The client MUST fill the padding extension completely with zero bytes, although the padding extension_data field may be empty.

Based on the feedback we received from @tomato42, we removed the reported issue where a client sends an elliptic curve extension but does not offer an elliptic curve cipher suite as terminating the connection may cause interoperability issues.