tls_wrap: parse tls session ticket extension #5882
Conversation
// Parse known extensions | ||
while (ext_off < avail) { | ||
// Extension OOB | ||
if (avail - ext_off < 3) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are reading 4 bytes below, I would expect the condition to be avail - ext_off < 4
.
Thanks, again! All fixed. /cc @isaacs @bnoordhuis |
For what it's worth, the change LGTM. Can it be back-ported to v0.10 too? |
@bajtos no way for backporting it, I promised to not touch clienthello parser in node_crypto.cc in any version. |
I saw this coming after Ben's comment in the other issue :) If we can disable TLS session tickets in cluster workers, then these extra resumeSession calls at least won't cause slowdowns, since the session lookup is fast in single-process case. |
And, if present and non-empty, don't invoke `resumeSession` callback. fix nodejs#5872
return ParseFinish(); | ||
|
||
uint16_t cipher_len = (data[cipher_offset] << 8) + | ||
data[cipher_offset + 1]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Style?
uint16_t cipher_len =
(data[cipher_offset] << 8) + data[cipher_offset + 1];
Is a little more idiomatic. For that matter, you could write it like this:
uint16_t cipher_len =
data[cipher_offset] * 256 + data[cipher_offset + 1];
Then you don't have to use parentheses everywhere. Just food for thought. :-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, its mostly style issues :) I like having powers of two in code, though I know value of 2^8, 2^16 and 2^24.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, data[cipher_offset + 1]
looks like it could be an out-of-bounds read.
Some comments, mostly LGTM. |
One more comment (I also mentioned this on IRC): the parser is calling ParseFinish() in a lot of places when the input is malformed. Shouldn't that be (the currently non-existent) ParseError()? |
Thanks, landed with fixes in dda22a5. |
About |
And, if present and non-empty, don't invoke
resumeSession
callback.fix #5872