pub struct TlsStream { /* private fields */ }Expand description
A TlsStream is generally responsible for handling the framing and decrypting of the TLS Record protocol.
Consider the following scenario
messages -> |------m1------|--------m2------|--------m3-------|
records -> |----r1----|-------r2---|-----r3------|----r4-----|
packets -> |--p1--|---p2---|---p3--|---p4--|--p5----|---p6---|Assume (without loss of generality) that each read call returns an individual, single packet.
§Packet Buffering
We won’t be able to decrypt r1 until we have received both p1 and p2.
To handle this we buffer all the reads in byte_buffer until the full record
is available.
§Record Buffering
Depending on different key logging implementations, we won’t be able to decrypt
the record immediately. We buffer complete records in record_buffer until
the decryption keys are available.
Even once we’re able to decrypt records, We won’t be able to parse m1 until
we have received both r1 and r2. We buffer the decrypted plaintext in
plaintext_content_stream
Note that the content_stream will only ever hold a single content type.
TODO: shenanigans here. We either have to “poll_decrypt” each time we have gotten a full record, or we need to poll_decrypt when we see a new content type (before we add it to the stream). I like the first option because it’s less modality.
THOUGHT: Can obfuscated records have multiple inner content types in them? I think the answer is no. And if the answer is yes then 😭.
Implementations§
Source§impl TlsStream
impl TlsStream
pub fn new(sender: Mode) -> Self
Sourcepub fn suppress_next_key_state(&mut self)
pub fn suppress_next_key_state(&mut self)
Set need_next_key_space to false
While the “sender” streams are almost entirely independent, that get’s broken in the event of a hello retry.
Normally, when the Server sends a ServerHello this means that the next message will be the EncryptedExtension (which the TLS Stream will need to decrypt).
But if it was a We need a way for the server stream to tell the client stream that there’s actually another client hello on the way.
Sourcepub fn feed_bytes(&mut self, data: &[u8])
pub fn feed_bytes(&mut self, data: &[u8])
Add bytes to a TLS stream.
In the case of a DecryptingPipe, this is the method called by the Read & Write IO methods.
This method will not do any decryption, but will try and assemble existing data into complete records.
Sourcepub fn digest_bytes(
&mut self,
state: &mut ConversationState,
key_manger: &KeyManager,
) -> Result<Vec<ContentValue>>
pub fn digest_bytes( &mut self, state: &mut ConversationState, key_manger: &KeyManager, ) -> Result<Vec<ContentValue>>
Attempt to decrypt available bytes.