openssl: Openssl not sending unexpected_message alert

Description:

The client sends an alert message as the first message to OpenSSL server. The server doesn’t respond with alert. But I observed that it prints ssl3_get_record:wrong version number in the terminal.

The client message is an alert (type \x15) and the version is \x83\x01. The server is configured to use TLS1.3. As per RFC8446, the version should be ignored. Thus, the message should be parsed as a well-formed alert message. Since the server is expecting a client hello, unexpected_message should be sent to client.

legacy_record_version: MUST be set to 0x0303 for all records generated by a TLS 1.3 implementation other than an initial ClientHello (i.e., one not generated after a HelloRetryRequest), where it MAY also be 0x0301 for compatibility purposes. This field is deprecated and MUST be ignored for all purposes.

Environment:

Ubuntu 18.04

Openssl 1.1.1j

How reproducible:

Steps to Reproduce:

openssl s_server -key /path/to/key.pem -cert /path/to/cert.pem -accept 44330 -tls1_3 -www -no_ticket

echo -n -e "\x15\x83\x01\x00\x02\x02\x50" | nc 127.0.0.1 44330

Actual results:

Openssl doesn’t respond to client.

Expected results:

Send unexpected_message alert to client.

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 20 (12 by maintainers)

Most upvoted comments

Can I just check that I’ve understood you correctly? The requirement on legacy_record_version can be split to these three parts above. Do you mean by combining the first two requirements: “MUST be set to 0x0303” and “MAY also be 0x0301”, it’s ok for server to assume the first byte shall always be “03” and thus perform check on it?

Generally if no one is allowed to check compliance, we don’t write MUST and MAY in the specification. Some people want to check and there was not WG consensus to forbid such checking.

I feel like such interpretation somewhat contradicts the third requirement: “MUST be ignored”.

You can go back to the mail thread to confirm, but the sense here is: the contents of this field have no semantic value in the TLS protocol. Specifically, in previous versions of TLS it was used to indicate a minimum supported version, but this specification explicitly disclaims such usage.

However, if you are trying to decide whether or not you are receiving a TLS packet, you need not be bound by RFC 8446.

kaduk on May 25, 2021

However, in TLS1.3, the legacy_record_version is required as “MUST be ignored for all purposes”. Therefore, any record version should be accepted

This is incomplete. You are ignoring the first sentence which says it “MUST be set to 0x303…”

So the client is not conforming, and the server can do what it wants.

richsalz on May 13, 2021