3 ms·

> When the HTTP response is done, we get these bytes: []byte{48, 13, 10, 13, 10, 23}. I don’t know what this is supposed to mean exactly but it seems to signal

> When the HTTP response is done, we get these bytes: []byte{48, 13, 10, 13, 10, 23}. I don’t know what this is supposed to mean exactly but it seems to signal the end of the connection. HTTP headers include Content-Length, so you should know when you get a truncated response, but TLS is supposed to be more general purpose, so it includes its own crypto secure end of connection indicator.

tialaramex 5y ago
These bytes are an ASCII zero, then two carriage-return/linefeed pairs and then the byte with value 23, so that 0\r\n\r\n might just be HTTP saying we're done sending you this chunked HTTP response. I think that 23 byte is the TLS content type, meaning "This is the actual application data you were transporting over TLS". In TLS 1.3 the original content type byte (from previous TLS versions) just always says 23 regardless so that middle boxes leave us alone, "Huh I guess everything is encrypted application data, I'm just a dumb middlebox so this isn't suspicious" This new, inner content type, safely encrypted and thus invisible to the middleboxes, is at the end of the data because it allows a clever trick with zero padding. See, content type zero isn't a thing. So if we get some data and the last byte is zero, that's not the content type it must be padding, remove it, try again. Still zero? Still padding, remove that and so on. Because the zeroes were encrypted, an adversary can't tell they're padding, but because they're zero the real recipient can discard them safely, yet if we don't need padding we aren't wasting space for a "no padding" indicator, we just don't add any of those zeroes. However, if 23 here is a content type, this means our intrepid TLS implementer got things a little wrong and all their HTTP data has stray 0x17 bytes at the end of each record received. I don't see code to handle that, but I may have missed it. It seems plausible that in terminal output you wouldn't notice?
- userbinator 5y ago
  For those who want to see the details of this explanation expressed in a more... struct-ured fashion, this section of the spec describes that: https://datatracker.ietf.org/doc/html/rfc8446#section-5.2 https://datatracker.ietf.org/doc/html/rfc8446#section-5.2
- tedunangst 5y ago
  Oh, I should have looked a little closer at the specific bytes. Does seem to be chopping off the http response.
deleted 5y ago
[deleted]

tialaramex 5y ago

These bytes are an ASCII zero, then two carriage-return/linefeed pairs and then the byte with value 23, so that 0\r\n\r\n might just be HTTP saying we're done sending you this chunked HTTP response. I think that 23 byte is the TLS content type, meaning "This is the actual application data you were transporting over TLS". In TLS 1.3 the original content type byte (from previous TLS versions) just always says 23 regardless so that middle boxes leave us alone, "Huh I guess everything is encrypted application data, I'm just a dumb middlebox so this isn't suspicious" This new, inner content type, safely encrypted and thus invisible to the middleboxes, is at the end of the data because it allows a clever trick with zero padding. See, content type zero isn't a thing. So if we get some data and the last byte is zero, that's not the content type it must be padding, remove it, try again. Still zero? Still padding, remove that and so on. Because the zeroes were encrypted, an adversary can't tell they're padding, but because they're zero the real recipient can discard them safely, yet if we don't need padding we aren't wasting space for a "no padding" indicator, we just don't add any of those zeroes. However, if 23 here is a content type, this means our intrepid TLS implementer got things a little wrong and all their HTTP data has stray 0x17 bytes at the end of each record received. I don't see code to handle that, but I may have missed it. It seems plausible that in terminal output you wouldn't notice?

userbinator 5y ago
For those who want to see the details of this explanation expressed in a more... struct-ured fashion, this section of the spec describes that: https://datatracker.ietf.org/doc/html/rfc8446#section-5.2 https://datatracker.ietf.org/doc/html/rfc8446#section-5.2
tedunangst 5y ago
Oh, I should have looked a little closer at the specific bytes. Does seem to be chopping off the http response.

deleted 5y ago

[deleted]