So, we start by calling the s˙client tool with the -crlf option to deal with carriage return, and -msg and -debug to see detailed information on TLS messages and print the debugging information, including a hex dump of all traffic:
root@5026f08a9173:/opt/openssl# openssl s_client -crlf -connect cr.yp.to:443 -msg -debug
CONNECTED(00000003)
>>> TLS 1.0, RecordHeader [length 0005]
16 03 01 01 31
>>> TLS 1.3, Handshake [length 0131], ClientHello
01 00 01 2d 03 03 93 24 7e 4a 6b b9 67 d0 3d dd
d5 cd cf f6 a6 da 19 a1 75 27 17 ee 26 58 cc 37
0a 5f a9 04 30 2b 20 92 23 81 9e 72 5f f9 4e 21
— snip —
After a successful TLS handshake, the s˙client tool stops and waits for user input:
— snip —
New, TLSv1.2, Cipher is ECDHE-RSA-CHACHA20-POLY1305
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-CHACHA20-POLY1305
Session-ID:
Session-ID-ctx:
Master-Key: 96260DD02E02C755C804F1EC5DC — snip —
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1683835757
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: yes
—
Now we can enter the HTTP GET request GET / HTTP/1.1 and press Enter. It will be immediately followed by the debug output:
GET / HTTP/1.1
>>> TLS 1.2, RecordHeader [length 0005]
17 03 03 00 20
write to 0x55ed1055c4b0 [0x55ed10569533] (37 bytes => 37 (0x25))
0000 – 17 03 03 00 20 48 18 81-51 1f 18 1b e8 a0 6a 97 ….
H..Q…..j.
0010 – be 90 dd 9e a6 b7 e5 8a-e8 c7 e0 80 8d 2f d3 87 …………./..
0020 – 69 a1 ef 72 9e i..r.
Next, we need to enter the request header field Host: cr.yp.to. You have to hurry up a bit, though. Otherwise, the server will terminate the TLS session due to a time-out. Also, recall that after entering Host: cr.yp.to, you have to hit Enter twice:
Host: cr.yp.to
>>> TLS 1.2, RecordHeader [length 0005]
17 03 03 00 20
write to 0x55ed1055c4b0 [0x55ed10569533] (37 bytes => 37 (0x25))
0000 – 17 03 03 00 20 1a a0 ef-19 30 fd 08 85 03 30 25
>>> TLS 1.2, RecordHeader [length 0005]
17 03 03 00 12
write to 0x55ed1055c4b0 [0x55ed10569533] (23 bytes => 23 (0x17))
0000 – 17 03 03 00 12 57 0c 8e-ae c1 dd 39 57 a8 d5 38 …..W…..9W..8
0010 – fc 91 9b 32 fb ff 59 …2..Y
read from 0x55ed1055c4b0 [0x55ed105653e3] (5 bytes => 5 (0x5))
0000 – 17 03 03 04 10 ….
After you enter the request header field Host: cr.yp.to and hit Enter twice, you will see a large amount of output with the individual TLS protocol messages and, eventually, the HTML payload:
<<< TLS 1.2, RecordHeader [length 0005]
17 03 03 04 10
read from 0x55ed1055c4b0 [0x55ed105653e8] (1040 bytes => 1040 (0x410))
0000 – 2a aa c5 5f 7e d0 4f ac-0d 4d 10 a5 11 91 d8 50 *.._~.O..M…..P
0010 – 69 9a 4e 3a 48 b6 df 2d-cb b3 96 9a fc 91 69 b5 i.N:H..-……i.
— snip —
03f0 – 70 d1 0f d4 35 0b e3 fc-fe 5e 6d e6 37 33 e8 54 p…5….^m.73.T
0400 – 6a 69 f4 a5 3c 1a 7d 6d-e5 db d7 be 88 af a3 c1 ji..<.}m……..
HTTP/1.1 200 OK
Server: publicfile
Date: Thu, 11 May 2023 20:28:43 GMT
Last-Modified: Wed, 17 Feb 2021 15:13:46 GMT
Content-Type: text/html
Transfer-Encoding: chunked
400
<html>
<head>
<meta http-equiv=”content-type” content=”text/html; charset=utf-8″>
<meta name=”viewport” content=”width=device-width, initial-scale=1″>
<meta name=”robots” content=”index,follow”>
<style type=”text/css”>
— snip —
Congratulations! You have successfully transmitted HTML data over a secure channel established using the TLS 1.3 protocol. But you might wonder what actually happens to your plaintext input and where those strange byte sequences come from. As an example, the HTTP request GET / HTTP/1.1 was transformed into the following TLS record:
GET / HTTP/1.1
>>> TLS 1.2, RecordHeader [length 0005]
17 03 03 00 20
write to 0x55ed1055c4b0 [0x55ed10569533] (37 bytes => 37 (0x25))
0000 – 17 03 03 00 20 48 18 81-51 1f 18 1b e8 a0 6a 97 ….
H..Q…..j.
0010 – be 90 dd 9e a6 b7 e5 8a-e8 c7 e0 80 8d 2f d3 87 …………./..
0020 – 69 a1 ef 72 9e i..r.
The first 5 bytes belong to the TLS record header, which is transmitted in plaintext, that is, the header is not encrypted. The first byte is 17 in hexadecimal notation. This is equivalent to 23, the number denoting a TLS record of type application˙data. The next two bytes encode the legacy˙record˙version. Recall that this field has the value 0x0303 for all TLS 1.3 records except the initial ClientHello. The last two bytes of the header store the length of the actual payload, which in our case is 20 in hexadecimal or 32 in decimal. Together with the header, the size of this TLSPlaintext is 37 bytes.