Re: [TLS] SCSVs and SSLv3 fallback

[[e-mail] (Martin Rex)]

Hanno Böck wrote:
>
> Trevor Perrin <[e-mail]> wrote:
>>
>> I've heard (anecdotally) that HTTPS between browsers and webservers
>> who are both TLS-capable sometimes results in SSLv3 connections.
>> Presumably this is due to firewall interference with the TLS
>> handshake, causing browsers to retry an SSLv3 handshake.
> 
> This happens pretty often if you have a unreliable (e.g. mobile)
> internet connection. Mozilla/nss-Bug about it:
> https://bugzilla.mozilla.org/show_bug.cgi?id=450280
> 
> And it's a serious problem if you're using Server Name
> Indication (SNI) for more than one SSL cert on one IP. The "solution" I
> found for our case was that I found it tolerable today to disable SSLv3
> on the server side. However, I'm not really happy with that browser
> fallback behaviour, it's a serious pitfall for the use of SNI.


Looking at the discussion under the above bugzilla URL (and how long
this has been dragging along) is quite disappointing.

I've seen vaguely similar breakage in Microsoft SChannel when used by
WinHTTP with lots of active scripting, occasionally causing white pages,
stateful apps to get out-of-sync with the frontend and users to loose
their input.

I believe, that the effect is already properly described here:
  https://bugzilla.mozilla.org/show_bug.cgi?id=450280#c3

in that it can even happen with <Ctrl-F5> (reload).

and "some" light in this response:
  https://bugzilla.mozilla.org/show_bug.cgi?id=450280#c13

mentioning that "reload" is technically a "stop+reload".


The issue that seems to affect Firefox in the same fashion that it
affects SChannel is that the fallback driving logic fails to distinguish
between locally triggered aborts of a TLS handshake and aborts caused
by the remote peer (unexpected remote connection closure, fatal TLS alert
or MAC error during the TLS handshake).  A timeout during the TLS handshake
is **seperate** and harder to deal with.

Active scripting, Users hitting <Ctrl-F5> or Reload, User navigation before
a page has completed loading of all elements, (meta-)refresh before a
page has completed loading of all elements and event-based active content
that causes replacement of page data or navigation to other locations
may all **LOCALLY** cause termination of an active TLS socket, and
in arbitrary states of the communication -- sometimes during the handshake.

When the TLS socket is locally aborted, this ought to neither invalidate
the client-side TLS session cache entry, nor ought this to cause a
fallback to a lower TLS protocol version.  From what is described in
the above bugzilla entry, it appears that FF might inappropriately
perform a fallback when the connection is locally aborted (potentially
limited to aborting during an active TLS handshake).


Depending on what the TLS client memorizes about (prior) connections,
a first change might be to make the purging of TLS sessions from the
client-side TLS session cache less agressive, and not perform a protocol
fallback to SSLv3 when there is an existing TLS session in the TLS session
cache that was successfully established with TLS extensions in the
ClientHello.


-Martin