Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Stitching multiple readable buffers together #1060
In TLS there is two layers of framing. The Record frame and the protocol frame. A record frame is wrapped inside the protocol frame. However the record frame can be much larger than the record frame. Therefore I need to be able to unwrap and decrypt the record fragments in place.
I then need to slice off the headers, and trailers to get the actual record data. At this point if I don't have the complete frame I will need to preserve and check multiple of these. It would be nice if at this point I didn't need to construct a collection or my own linked list but instead could append the start cursor of the second list to the end cursor of the first.
I am not sure if this is possible today but as I believe they are linked lists of buffers internally this should be possible.
Code samples would help me understand better here. Is this across multiple calls to ReadAsync?
[ header | payload ] -> [ header | payload ]
Is that what it looks like? You want to string multiple payloads together into a single readable buffer?
Yeah but it's even more complex.
ReadAsync ReadAsync ReadAsync ReadAsync
Payload1.1 + Payload1.2 == Payload1
The "Header" record can be max 2^16-1 long (16k) but the internal message can be 2^24-1 long (again go figure?) Each of Payload1.1 and Payload1.2 is independently encrypted so will be decrypted at that layer, however they need to be combined to make a single message to process.... the only way I can currently think of doing this is to have a listener internally that does the decryption, and then puts them with another custom header injected and put them back on another pipeline, which seems a bit over the top.
Instead I want something like
AsyncRead, AsyncRead (until I have a whole frame according to [Header])
Then decrypt, Preserve the decrypted chunk, and save that as state in the reading loop, then go back for another frame, once I have another frame, preserve that and append it to the other readable buffer and process the completed [Payload]
The other problem with the internal channel is that the process needs to be synchronised. Async won't work because the current payload may change the encryption state which will change the way the next [header] frame will be handled (encrypted or not, renegotiated keys etc)
One way to solve it but seems unclean is to hold a list of buffers that makes up the current payload. Obviously then I have to enumerate that and the readables which is a mess.
I have got past this by making an internal channel for now. It's really a sync operation so it's a bit over kill but it works…
On 22 Dec 2016 2:23 a.m., "David Fowler" ***@***.***> wrote: (P.S. don't mention spacing, var it's mock code) My eyes — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1060 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/APpZub9u1d6ZY6KgBSvQcSV3Wc9gPtnsks5rKd8HgaJpZM4LK6f_> .