ServerHello.random does not include downgrade sentinel when negotiating TLS 1.1 or earlier
Categories
(NSS :: Libraries, defect, P2)
Tracking
(Not tracked)
People
(Reporter: hkario, Assigned: kjacobs)
Details
(Keywords: csectype-other, sec-low)
Attachments
(1 file)
Updated•6 years ago
|
| Reporter | ||
Comment 1•6 years ago
|
||
one more point: it looks like when the server is set to TLS 1.2 as the highest version supported, it does set the downgrade sentinels for TLS 1.1 and TLS 1.0 connections
Comment 2•6 years ago
|
||
Comment 1 makes this sound like a non-issue.
Help me understand what is going on here. Under which conditions does the server fail to produce the downgrade sentinel?
| Reporter | ||
Comment 3•6 years ago
|
||
Situation A:
- Server: TLS 1.0, 1.1, 1.2 and 1.3 are enabled. (-V tls1.0:tls1.3)
- Client is advertising 1.2 as the highest supported version, result: TLS 1.2 is negotiated and the ServerHello.random includes downgrade sentinel (expected)
- Client is advertising 1.1 as the highest supported version, result: TLS 1.1 is negotiated and the ServerHello.random DOES NOT include downgrade sentinel (unexpected)
- Client is advertising 1.0 as the highest supported version, result: TLS 1.0 is negotiated and the ServerHello.random DOES NOT include downgrade sentinel (unexpected)
Situation B:
- Server: TLS 1.0, 1.1 and 1.2 are enabled (-V tls1.0:tls1.2)
- Client is advertising 1.2 as the highest supported version, result: TLS 1.2 is negotiated and the ServerHello.random does not include downgrade sentinel (expected)
- Client is advertising 1.1 as the highest supported version, result: TLS 1.1 is negotiated and the ServerHello.random does include downgrade sentinel (expected)
- same as above for 1.0
Comment 4•6 years ago
|
||
OK, I see what's going on.
switch (ss->vrange.max) {
case SSL_LIBRARY_VERSION_TLS_1_3:
PORT_Memcpy(downgradeSentinel,
tls13_downgrade_random, sizeof(tls13_downgrade_random));
break;
case SSL_LIBRARY_VERSION_TLS_1_2:
PORT_Memcpy(downgradeSentinel,
tls12_downgrade_random, sizeof(tls12_downgrade_random));
break;
default:
/* Do not change random. */
break;
}
We're setting the sentinel based on the max version, not on the version we negotiate, because the algorithm in the spec is kind of counterintuitive. So we are setting the sentinel
Setting this to security because it actually would stop downgrade from the client from 1.2 -> 1.1 if the server was 1.2. Note that TLS 1.3 clients would in fact do downgrade protection correctly because they are required to check for both values.
Updated•6 years ago
|
| Reporter | ||
Comment 5•6 years ago
|
||
Martin, I did link this bug (along with the description of issue) from https://github.com/tomato42/tlsfuzzer/wiki/Found-bugs
would you prefer for me to remove it for now, and keep it secret until this bug is private, or should we not put too much of a spotlight on the issue by removing it from the listing?
Comment 6•6 years ago
|
||
I will request that you remove this from the bugs list there until we fix this. Obviously, the information is out there now, but we can keep from broadcasting it for the moment.
| Reporter | ||
Comment 7•6 years ago
|
||
no problem, done
| Reporter | ||
Comment 8•6 years ago
|
||
ping? 3.44 shipped, but this is still unfixed
Comment 9•6 years ago
|
||
Sorry, this hasn't been on my radar. I'm setting this so we re-triage it at the start of the next cycle.
Updated•6 years ago
|
| Assignee | ||
Comment 10•6 years ago
|
||
Per-[[ https://tools.ietf.org/html/rfc8446#section-4.1.3 | RFC 8446 ]], the downgrade sentinel must be set by a TLS 1.3 server (and should be set by a TLS 1.2 server) that negotiates TLS 1.0 or 1.1. This patch corrects the behavior and adds a test.
| Assignee | ||
Comment 11•5 years ago
|
||
Updated•5 years ago
|
Updated•5 years ago
|
Description
•