3

I started a TLS1.3-server via openSSL (version 1.1.1-pre4 (beta) 3 Apr 2018 )

$ openssl s_server -key key.pem -cert cert.pem -accept 44330 -www -tls1_3

and a TLS1.3 client

$ openssl s_client -connect 127.0.0.1:44330 -tls1_3

I captured the traffic via wirehark (version: 2.9.0-55):

TLS1_3 Wireshark pcap-data

Why is version 1.2 concerning the handshake protocol and even 1.0 for the record layer detected/defined?

While reading the rfc-draft, I found this:

In order to maximize backwards compatibility, records containing an initial ClientHello SHOULD have version 0x0301 and a record containing a second ClientHello or a ServerHello MUST have version 0x0303, reflecting TLS 1.0 and TLS 1.2 respectively.

Looking at my pcap, this record containing a second ClientHello can not be found. And the following ServerHello is indeed version 0x0303.

But it seems, that client and server do speak TLS1.3 after all: enter image description here

I do not understand this. Can you help me?

Community
  • 1
user1511417
  • 131
  • 3
  • 6

2 Answers2

2

Because poor implementations broke when presented with 1.3.

Cloudflare: Why TLS 1.3 isn't in browsers yet

When presented with a client hello with version 3.4, a large percentage of TLS 1.2-capable servers would disconnect instead of replying with 3.3. Internet scans by Hanno Böck, David Benjamin, SSL Labs, and others confirmed that the failure rate for TLS 1.3 was very high, over 3% in many measurements.

The controversial choice was to accept a proposal from David Benjamin to make the first TLS 1.3 message (the client hello) look like it TLS 1.2. The version number from the client was changed back to (3, 3) and a new “version” extension was introduced with the list of supported versions inside. The server would return a server hello starting with (3, 4) if TLS 1.3 was supported and (3, 3) or earlier otherwise. Draft 16 of TLS 1.3 contained this new and “improved” protocol negotiation logic.

The original protocol negotiation mechanism is unrecoverably burnt. That means it likely can’t be used in a future version of TLS without significant breakage.

John Mahowald
  • 32,050
  • 2
  • 19
  • 34
  • Which has nothing to do with the OP as it does not use a webserver but starts a server directly with OpenSSL... He already found out about the 2 ClientHello... – Patrick Mevzek Apr 13 '18 at 05:48
  • The client is standard compliant, which implies the question why is the version number intended to be strange. I linked a CDN provider's blog because it had reasons why to not downgrade TLS versions and data from the real world to show the challenges. The fact that their business is delivering web pages to browsers is almost irrelevant - that was a post about TLS. – John Mahowald Apr 16 '18 at 01:26
  • Do you see that the OP is testing a TLS connection between basically the same software, operating as both client and server? Hence it has nothing to do with how TLS is implemented in browsers. – Patrick Mevzek Apr 16 '18 at 01:28
1

Second ClientHello is sent only in case the server asks for it – it is sent as a response to the HelloRetryRequest message.

If the DH key shares in the key_shares extension are acceptable to the server, it will not ask client for second ClientHello, if they aren't, but client advertised support for other groups (in the supported_groups extension) that are acceptable, the server will ask the client for second ClientHello by sending HelloRetryRequest with the group that the client should send. If none of the groups in the supported_groups extension are acceptable to server, it will reject the connection with handshake_failure alert (if it is RFC compliant).

side note: the real protocol version advertised and negotiated lives in the supported_versions extension (that's how Wireshark knows it's a TLS 1.3 connection even though ServerHello.version has value 0x0303 in it).

Hubert Kario
  • 6,361
  • 6
  • 36
  • 65