2

I'm playing around with openssl s_client and I tried sending various payloads with/without padding and analysing the stack trace output. One case I don't understand is when I send empty bytes without padding I see the following output:

New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256
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)
---
write to 0x107ede0 [0x109a7f3] (24 bytes => 24 (0x18))
0000 - 17 03 03 00 13 a2 03 0c-67 c0 aa 77 08 7d 37 cb   ........g..w.}7.
0010 - 39 82 68 19 ba a2 39 bd-

I used a 16-byte aead tag cipher and since the content type field is 1 byte I would expect the total payload size to be 16 + 1 = 17 bytes. However, as evident in the stack trace openssl wrote a record with header 17 03 03 00 13 or 0x13 = 19 bytes. Why was 19 bytes sent instead of the expected 17 bytes? What are these two bytes?

Kiwi breeder
  • 459
  • 4
  • 11
  • How did you send these bytes? I was thinking padding, but that does not make sense. It would make more sense if that "emtpy data" consists of a single end-of-line or maybe a Unicode BOM. – Maarten Bodewes Jan 04 '23 at 18:47
  • To determine if it is padding, then please look [here](https://www.openssl.org/docs/man1.1.1/man3/SSL_CONF_cmd.html). – Maarten Bodewes Jan 04 '23 at 21:11
  • I was able to verify it's not padding... I even added `-record_padding 0` just to be sure. It seems that this record is always sent... – Kiwi breeder Jan 10 '23 at 23:18
  • I've asked Thomas, the creator of BearSSL. He said it should be 17 bytes. So very likely you did something like `echo` without `-n` or something similar. Please show us what you tried because otherwise we are not be able to answer. – Maarten Bodewes Jan 12 '23 at 00:18

0 Answers0