412834 - TLS intolerant retry attempted after successful TLS handshake

Status: RESOLVED WORKSFORME

(Core :: Security: PSM, defect)

Description

[Nelson Bolyard (seldom reads bugmail)]

It has been reported that FF sometimes goes into TLS intolerant behavior mode
AFTER it has successfully done a TLS handshake with a server.  That is, FF 
does a successful TLS handshake, then sometime later experiences a handshake failure with that same server, resulting in marking the server as TLS 
intolerant, even though PSM's immediate experience has demonstrated that the 
server is NOT TLS intolerant.  

I think it would be desirable to remember (for the lifetime of the process) 
that a server is capable of doing TLS, and NEVER attempting TLS intolerant 
retries on that server after we've successfully done a TLS handshake with it.

Comment 1

[Marcin Cieślak (:saper)]

TLS intolerance logic, maybe bug 460419 is related.

Comment 2

[Honza Bambas (:mayhemer)]

Will be fixed with in bug 412833.

Comment 3

[Honza Bambas (:mayhemer)]

Fixed in bug 412833.

Marcin: I'll take a look at bug 460419 later.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

Hhow can this bug be considered fixed if bug 498311 persists?

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

I hope this really is fixed, because this is going to be VITAL to the 
success of the new TLS renegotiation fix.  False SSL3 fallbacks will be 
harmful to renegotiation, I think.

Comment 6

[Honza Bambas (:mayhemer)]

(In reply to comment #5)
> False SSL3 fallbacks will be harmful to renegotiation, I think.

Nelson, can you please be more specific in what way it could be?

Comment 7

[Honza Bambas (:mayhemer)]

(In reply to comment #0 and comment #5)
> I think it would be desirable to remember (for the lifetime of the process) 
> that a server is capable of doing TLS, and NEVER attempting TLS intolerant 
> retries on that server after we've successfully done a TLS handshake with it.

This is exactly what the patch for bug 412833 does.

As I understand you are worried about a case when an active attacker discards TLS handshake making the victim's UA believe the server in incapable of TLS handshake and would fallback to SSLv3 that is vulnerable, right?

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

I don't see how this bug can be fixed, and bug 498311 can remain unfixed.
AFAICT, as long as bug 498311 remains demonstrable, that is an existence 
proof that this bug is unfixed.

Comment 9

[Honza Bambas (:mayhemer)]

Got it. When user presses stop load button before it firsts connect a secure server, the server is marked as TLS intolerant and we never more have a chance to mark it as TLS tolerant (that has a priority over the TLS intolerant mark).

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

In answer to comment 6, at the time that I wrote comment 5, the TLS/SSL 
renegotiation vulnerability was known, but the final solution had not yet
been agreed.  The first proposed solution for that problem would have 
effectively made "safe renegotiation" impossible (going forward) for SSL 3.0, 
and only possible for TLS (SSL 3.1 and above).  I wrote comment 5 thinking 
that that proposal would be accepted.  (It was not.)  If it had been, then
it would certainly have been true that false (undeserved) fallbacks to 
SSL 3.0 would indeed have been detrimental to renegotiation.  However, the 
solution that was finally adopted includes a hack that allows SSL 3.0 to 
continue to have "safe renegotiation", so false fallbacks do not prevent 
renegotiation, although they are still undesirable.

Comment 11

[Honza Bambas (:mayhemer)]

For now releasing, but left on my radar.

Comment 12

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

I don't believe this bug is relevant anymore.