Remove PSKs with incompatible hashes after HRR
Categories
(NSS :: Libraries, enhancement, P4)
Tracking
(firefox111 fixed)
Tracking | Status | |
---|---|---|
firefox111 | --- | fixed |
People
(Reporter: mt, Assigned: lschwarz)
Details
(Keywords: sec-audit, Whiteboard: [post-critsmash-triage][adv-main111-])
Attachments
(1 file)
When we receive a TLS HelloRetryRequest, that fixes the choice of cipher suite. That means that the PSK we have might not be valid if it uses a different hash.
Rather than include the PSK in this case, we can save a bunch of effort by dropping it. This is permitted by the protocol.
Saving effort also means that we don't need to think too hard about how the transcript for the PSK binder is constructed with mismatched hash functions (one for the ClientHello compression, another for the binder). It looks like our code is correct in this regard, but it would need careful validation to be sure. As this is a nonsensical situation it is better to avoid the question entirely.
Updated•3 years ago
|
Comment 1•3 years ago
|
||
Marking security until Benjamin has a chance to take a look, just to be sure.
Updated•3 years ago
|
Comment 2•3 years ago
|
||
Dennis, when you have a few mins could you look at this bug please? : ) Thanks!
Updated•3 years ago
|
Comment 3•3 years ago
|
||
In addition, in its updated ClientHello, the client SHOULD NOT offer any pre-shared keys associated with a hash other than that of the selected cipher suite. This allows the client to avoid having to compute partial hash transcripts for multiple hashes in the second ClientHello.
If I have understood correctly, dropping PSKs with the wrong hash function is required by the spec, so we should definitely do this.
Reporter | ||
Comment 4•3 years ago
|
||
Right. We don't have to drop them and it was easier to keep them at the time. There are lots of reasons to do the work though.
Separately, if you can work out whether we have any concrete problems in existing code, we can work out whether to keep this as a security bug. We were cautious initially, but I haven't seen any cause for concern. Confirmation that it is not a security bug would be helpful.
Assignee | ||
Comment 5•2 years ago
|
||
Comment 6•2 years ago
|
||
There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:djackson, could you have a look please?
If you still have some work to do, you can add an action "Plan Changes" in Phabricator.
For more information, please visit auto_nag documentation.
Updated•2 years ago
|
Updated•2 years ago
|
Comment 7•2 years ago
|
||
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•1 year ago
|
Description
•