Subject: [TLS] SCSVs and SSLv3 fallback

From: Trevor Perrin <[email-masked]>
Date: Thu, 4 Apr 2013 14:02:27 -0700

Hi,

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.

I believe TLS Extensions are generally not sent in the SSLv3
ClientHello (?).  This isn't a major problem for TLS Extensions as
optimizations (e.g. session tickets or OCSP stapling).

However, there are proposals that *require* a TLS Extension response,
for security:
 - TACK's "TackExtension" [1]
 - Certificate Transparency's "SignedCertificateTimestampList" [2]
 - OCSP stapling in the presence of an X.509 "must-staple" extension [3]

How should these work in the case of a network-triggered SSLv3 fallback?

One proposal would note that some browsers do, I think, send the
RFC5746 TLS_EMPTY_RENEGOTIATION_INFO_SCSV ciphersuite in an SSLv3
ClientHello, and receive a "renegotiation_info" ServerHello extension
in return.

So there's evidence that this idiom of a "special ciphersuite value"
in an SSLv3 ClientHello, and a TLS Extension in ServerHello, is
"compatible-enough" with the horrible middleboxes triggering these
fallbacks.

This idiom wouldn't work with a proposal that sends data in
ClientHello, but both the TACK and CT proposals use empty
extension_data, and OCSP stapling seems like it would work as a binary
signal, as well (?).

So, is it reasonable for things like TACK to consider an SCSV value
that could be used instead of (or in combination with) a ClientHello
Extension, to request the corresponding ServerHello extension?

Trevor

---

From: Hanno Böck <[email-masked]>
Date: Thu, 4 Apr 2013 23:34:02 +0200

On Thu, 4 Apr 2013 14:02:27 -0700

> 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.

-- 
Hanno Böck		mail/jabber: [email-masked]
GPG: BBB51E42		http://www.hboeck.de/

---

From: Geoffrey Keating <[email-masked]>
Date: 04 Apr 2013 14:54:25 -0700

> handshake, causing browsers to retry an SSLv3 handshake.

The name of one firewall which is confirmed to do this would make it a
lot more convincing...  It's likely that some TLS connections failed
due to packet loss or a busy server and so the 'fallback' was a
mistake.

> How should these work in the case of a network-triggered SSLv3 fallback?

I would phrase this as "how should these work when under attack and
the attacker is blocking extensions".

In the case of TACK, I think it should work by saying that if
you've previously negotiated TACK, therefore the server must
previously have supported at least TLSv1+extensions, so you SHOULD NOT
fall back to a SSLv3 ClientHello for that server, and if you do, you
MUST continue to apply any active pin.

> ClientHello, and receive a "renegotiation_info" ServerHello extension

I don't believe sending the ServerHello extension is the important
part of that protocol, the key part is that the server rejects
any renegotiation where the ciphersuite is included.

> "compatible-enough" with the horrible middleboxes triggering these

For counter-evidence, see
<https://bugzilla.mozilla.org/show_bug.cgi?id=672749>.

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Fri, 05 Apr 2013 00:43:32 +0200

> handshake, causing browsers to retry an SSLv3 handshake.

There are several types of problem, both concerning network problems  
(Google have been detecting and tracking some of those) and what appears  
to be server problems with certain extensions.

Regarding the latter, I have observed two specific issues: intolerance for  
Server Name Indication and for Certificate Status.

The affected number of connections and servers appear to be very small.

> ClientHello (?).  This isn't a major problem for TLS Extensions as

That is correct; Opera 12 also have a fallback mode that uses TLS 1.0  
without extensions.

> How should these work in the case of a network-triggered SSLv3 fallback?

For the servers/networks that will not accept a connection from a full TLS  
client with extensions, these features will not work, and strictly  
deployed (which they should be) the site will break.

> "compatible-enough" with the horrible middleboxes triggering these

In my opinion, using SCSVs should never be used. They were used once for  
Renego to accommodate SSL v3 only servers that could not be upgraded to  
TLS 1.x.

That seems to have opened up a slippery slope where "every" problem can be  
"solved" by using those values, rather than standing firm and forcing the  
problematic servers/infrastructure to be updated.

Bending over backwards will only ensure that the problem never disappear  
or take much longer than necessary to be removed.

Also: using SCSVs from the client might "fix" the client->server  
information. What if some of the responsible infrastructure also affect  
the server->client communication, and break sending of extensions back to  
the client?

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

-- 
Sincerely,
Yngve N. Pettersen

Using Opera's mail client: http://www.opera.com/mail/

---

From: Trevor Perrin <[email-masked]>
Date: Fri, 5 Apr 2013 12:46:28 -0700

Hi Hanno, Geoffrey, Yngve,

Thanks for the info and thoughts, really helpful!

It would get complicated to respond to every point individually, let
me try to summarize:

(1) I've heard anecdotal evidence that something like 1/1000
connections between TLS-capable (clients *and* servers) end up in an
SSLv3 fallback.  Hanno and Geoffrey point out this is often due to
general network problems (e.g. packet loss) rather than middlebox
TLS-intolerance.  However I have heard, and Yngve seems to agree, that
middlebox TLS-intolerance also contributes.

Does anyone know more about this?  Like: what portion of the above
fallbacks are due to general network problems vs. TLS-intolerant
middleboxes?

(2) I suggested that TLS Extensions which do not require data in the
ClientHello, and which are required for security, could follow the
5746 idiom of an SCSV alternative to the ClientHello extension for use
in SSLv3 fallback.

Geoffrey and Yngve suggest a different approach, where browsers
disable SSLv3 fallback when talking to a hostname for which they
expect one of these TLS Extensions.  With a flakey network, browsers
would retry TLS until they get through or give up.  With
TLS-intolerant middleboxes, Yngve suggests "standing firm and forcing
the problematic servers/infrastructure to be updated".

I see some problems with this:
 (a) With current proposals for CT or OCSP stapling, the requirement
for an OCSP or CT response via TLS Extensions is signalled by the
server's certificate, so is not known until *after* an SSLv3 fallback.
 Presumably the browser could cancel the SSL handshake and restart a
TLS handshake at that point, but that wastes multiple round trips.
 (b) With TLS-layer pinning (like TACK), this proposal would prevent
"active pins" from causing problems, but pin creation would still be
impeded:  Connections to not-yet-pinned sites could still suffer from
SSLv3 fallbacks due to flakey networks or intolerant middleboxes, and
not receive the pin assertion.
 (c) This proposal is guaranteed to fail with TLS-intolerant
middleboxes, whereas the SCSV proposal has a good chance of working.
 (d) As far as "standing firm" and trying to drive these middleboxes
off the Internet.  I'm all for someone else trying that (CT? :-).  But
for TACK:  If there's any significant number of these middleboxes, and
we cause anything close to a 1/1000 failure rate, we simply won't be
deployed.

I'd be interested in hearing more about why people oppose the SCSV
approach.  We're nowhere close to exhaustion of the ciphersuite (or
extension) registries.  Is there some real problem with SCSVs, or does
it just offend people's sense of the "proper way" to do things?

Trevor

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 05 Apr 2013 23:30:54 +0200

> middleboxes, whereas the SCSV proposal has a good chance of working.

[...]
> it just offend people's sense of the "proper way" to do things?

I wouldn't expect the problem of failed TLS connections due to middle
boxes or bad implementations to disappear by making a complex protocol
even more complex.

By having a protocol that offers more than a way to do things I'd expect
an increase to the interoperability and failed connection issues we see
today. More options for the same thing pretty much guarantees that there
will be at least one implementation that will ship the non mainstream
options untested.

regards,
Nikos

---

From: Trevor Perrin <[email-masked]>
Date: Fri, 5 Apr 2013 15:11:32 -0700

> boxes or bad implementations to disappear by making a complex protocol

If the problem is TLS-intolerant middleboxes, then allowing necessary
handshake data to flow via SSLv3, using a mechanism that has worked
for other extension data, should make the problem better.  No?

> will be at least one implementation that will ship the non mainstream

This is pretty easy to test, the logic is simple:
 - client sends SCSV and/or empty ClientHello extension
 - on receiving SCSV and/or empty ClientHello extension, server sends
ServerHello extension.

This is even simpler than RFC5746, since for (CT, TACK, OCSP
"must-staple") the ClientHello Extension could just be an empty
signal, and the ServerHello contains a static response.

This idiom is so simple it could be handled by an "extender file"
interface:  The site administrator could specify an "extender file"
containing PEM-encoded TLS Extensions in the server config.  Each
PEM-encoded blob would contain a prefix specifying the TLS extension
number and (optional) SCSV number.  This would avoid the need for
server-side code changes for any Extension that follows this idiom.

So, we would only need to deploy this once into (OpenSSL, Apache,
nginx, etc.).  Does that alleviate your concern?

I've discussed this with Ben Laurie and begun an OpenSSL patch, which
at least CT and TACK could take advantage of.  It doesn't allow SCSV
specification yet, but I'm wondering if it should:

https://github.com/trevp/openssl_extender

Trevor

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 5 Apr 2013 15:19:04 -0700

> for other extension data, should make the problem better.  No?

No. You assume that the "TLS-intolerant middleboxes" actually understand real SSLv3, not some very limited and old picture of it. You might fix the problem for *some* middleboxes, at the cost of making the protocol even more fragile.

--Paul Hoffman

---

From: Trevor Perrin <[email-masked]>
Date: Fri, 5 Apr 2013 15:47:16 -0700

> No. You assume that the "TLS-intolerant middleboxes" actually understand real SSLv3, not some very limited and old picture of it. You might fix the problem for *some* middleboxes, at the cost of ma…

Well, we're agreed this might fix the problem for some middleboxes. :-)

The alternative, in the TLS-intolerant middlebox case, is... what,
exactly?  Fail to connect?

Trevor

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Sat, 06 Apr 2013 01:18:19 +0200

On Sat, 06 Apr 2013 00:47:16 +0200, Trevor Perrin <[email-masked]> wrote:

>> No. You assume that the "TLS-intolerant middleboxes" actually  
>> understand real SSLv3, not some very limited and old picture of it. You  
>> might fix the problem for *some* middleboxes, at the cost of making the  
>> protocol even more fragile.
>

Given that we don't know what these middleboxes react to, using SCSVs  
might work for some, but not others, because those could be checking for  
"known" cipher suites; some might even consider a unknown cipher suite to  
be an "attack". (Note: There are apparently middleboxes that do not allow  
TLS 1.1 or TLS 1.2 connections to be established, so if these middleboxes  
block on "unknown" protocol versions, I would not be surprised if some  
don't fail to pass "unknown" cipher suites, as well)

That the Renego SCSV *seem* to have worked, does not mean that a new SCSV  
will work equally well.

As Paul says, adding an SCSV system will add complexity, which might cause  
other problems, including differences between how implementations behave  
when seeing them. Example: There are a number of servers, F5 BigIP among  
them, that does not tolerate a combination of the Renego Information  
Extension and the Renego SCSV in the same handshake.

The danger is that by using an SCSV we might "fix" the problem for one  
group of users, and completely break SSL/TLS for another group of users,  
the size of which might conceivably be substantially larger than the other  
group, and there is no way to find out which it is going to be before the  
system is deployed.

For that matter, using an SCSV to indicate an extension and to bypass an  
interfering middlebox assumes that the middlebox will permit the  
associated handshake extension to be passed back to the client. I don't  
think that is a certainty, even if it seems to have worked for Renego (but  
worst case: that might be due to the middle boxes being updated to handle  
that particular extension, since it was a security protocol patch)

Bottom line: Assume that Murphy's Law applies; if something can be done  
wrong, then somebody will do it wrong. And in terms of these middleboxes,  
somebody have, but we don't know how many ways they have done it wrong.

-- 
Sincerely,
Yngve N. Pettersen

---

From: Trevor Perrin <[email-masked]>
Date: Fri, 5 Apr 2013 21:41:33 -0700

On Fri, Apr 5, 2013 at 4:18 PM, Yngve N. Pettersen <[email-masked]> wrote:
>>> No. You assume that the "TLS-intolerant middleboxes" actually understand
>>> real SSLv3, not some very limited and old picture of it. You might fix the
>>> problem for *some* middleboxes, at the cost of making the protocol even more
>>> fragile.
>>
>>
> Given that we don't know what these middleboxes react to, using SCSVs might
> work for some, but not others,

Agreed.

> The danger is that by using an SCSV we might "fix" the problem for one group
> of users, and completely break SSL/TLS for another group of users

Suppose the SCSV is only allowed in the specific case of an SSLv3
fallback where an extension response is required or the connection
will fail (due to a requirement for TACK, CT, or OCSP).

In this case, it can't break anything because the connection is
already going to be broken.  It's not guaranteed to work, but there's
evidence it might.

Does that address this concern?

> somebody have, but we don't know how many ways they have done it wrong.

Sure.  What data do we have?

Does the estimate of 1/1000 connections between (TLS-capable clients
and servers) getting an SSL3 fallback seem right to you?

Do you have any idea how much of that is general network problems vs.
middlebox problems?

Trevor

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sat, 06 Apr 2013 11:22:55 +0200

> for other extension data, should make the problem better.  No?

It may reduce the error failures in some middle-boxes. We cannot be sure
about that because we don't know the actual reason for failure, we just
speculate.

Nevertheless your focus on SSL 3.0 is also wrong. Given the number of
security flaws known to that protocol it may be more productive for the
WG to work towards phasing it out.

>  - on receiving SCSV and/or empty ClientHello extension, server sends

What would you do at the case a middle box only accepts extension A
using SCSV but extension B is only accepted as ClientHello extension?

Since what are you countering of is bugs, you can never be sure what the
next bug would be. Bugs should be treated as bugs.

> This idiom is so simple it could be handled by an "extender file"

The previous extension mechanism was even simpler but still there were
several middle-boxes that got it wrong.

regards,
Nikos

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Sat, 06 Apr 2013 14:14:06 +0200

On Sat, 06 Apr 2013 06:41:33 +0200, Trevor Perrin <[email-masked]> wrote:

>> group

No, it does not.

The reason it does not, is that once the client have fallen back to SSL v3  
due to version and/or extension intolerance in the server and/or the  
middleboxes you can either use a plain SSL v3 or a SSL v3 with the  
proposed SCSVs.

Assuming a plain SSLv3 does not work, then the SCSV will not work either.

OTOH, if the the plain SSLv3 works OK, we do not at present know if the  
SCSV variant will work in all cases. even if the SCSV is passed through,  
we do not know if the Server Hello extension will be passed through on the  
way back.

So, using an SCSV in the SSL v3 handshake do risk breaking a handshake  
that would otherwise have completed.

I have no idea how likely that problem is, but as Nikos pointed out, this  
is trying to accommodate bugs in implementations, but we don't have a  
complete list of the bugs that have been created in these implementations.

> and servers) getting an SSL3 fallback seem right to you?

Actually, the numbers I have been informed of is that the number of  
completed connections forced to SSLv3 is less than half that.

The number of affected renego patched *servers* in my sample is in the  
0.2% range IIRC, but number of server does not translate to actual usage  
in number of connection by users. The much lower fraction of downgraded  
connections indicate that the servers I've detected are not frequently  
accessed. (BTW, the total number of intolerant servers is about 1.5%, most  
of them not renego patched).

> Do you have any idea how much of that is general network problems vs.

All the discoveries about this problem have been made by Google.

I know Google was considering doing some tests to try to ferret out how  
much of the problem was due to middleboxes or the servers, but I do not  
know if they have done so yet, or what the results were, if they did.

-- 
Sincerely,
Yngve N. Pettersen

---

From: Trevor Perrin <[email-masked]>
Date: Sat, 6 Apr 2013 09:59:06 -0700

[...]
> we do not at present know if the SCSV
> variant will work in all cases.
[...]
> So, using an SCSV in the SSL v3 handshake do risk breaking a handshake that
> would otherwise have completed.

No, you missed my point.

I was proposing using SCSVs only in the case that an SSLv3 fallback is
necessary, and the browser *REQUIRES* some data from the server (TACK,
CT, OCSP), or the browser will refuse the connection.

Example:  Suppose a browser has an active TACK pin for a domain, but
sending a TLS ClientHello to that domain results in a TCP reset.

Since the TACK pin exists, the browser can assume it is not contacting
a TLS-intolerant server.  But a TLS-intolerant middlebox seems like a
possibility (though we still need more data on prevalence).  I believe
current browsers would want to try an SSLv3 fallback in this case, to
attempt to work around the interference.

However!  SSLv3 fallback is pointless here unless the browser has some
chance of signalling that it requires a tack, and receiving it.

I am proposing giving this a chance of working, by using the same SCSV
/ ServerHello Extension idiom that has worked for RFC 5746.

Of course, this might not work for any specific middlebox!  But if the
middlebox allows unknown ciphersuites and data at the end of the SSL
ServerHello, then it will.  And if the middlebox has been patched to
whitelist the specific 5746 SCSV and ServerHello extension, that
implies it could be upgraded for new uses of this idiom as well.

Trevor

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Sat, 06 Apr 2013 21:04:45 +0200

On Sat, 06 Apr 2013 18:59:06 +0200, Trevor Perrin <[email-masked]> wrote:

> a TLS-intolerant server.

In which case the client knows what the highest supported version, and the  
extension tolerance, for the server, as you say.

In any such case the client should IMNSHO assume that it is being  
subjected to a Man In the Middle attack, using a version rollback attack,  
and abort the connection. The client should in such a situation not permit  
itself to downgrade the security of the connection, which includes _not_  
attempting to set up the connection using SSL v3, or any TLS version lower  
than what was used the last time it had a successful connection.

That is BTW, the principle embedded in my version rollback removal draft  
<http://datatracker.ietf.org/doc/draft-pettersen-tls-version-rollback-removal/>,  
which uses the server's support of the Renego extension as a proxy  
indication to determine full version and extension tolerance, and then use  
that information to assume that any failure to negotiate a connection,  
when signaling the client's highest supported version with full extension  
support in the handshake, means that the connection is being subjected to  
a version rollback attack, and terminate the connection attempt rather  
than roll back to an older version.

> But a TLS-intolerant middlebox seems like a

It could be that they have been patched, if there was a problem, but the  
Renego issue was a high profile security issue, and its solution was one  
that was being deployed in all clients within a very short period of time.  
Failure to patch any troublesome middleboxes would have caused severe  
problems for users.

I doubt any such incentive to patch will be present for most other  
extensions of TLS, particularly if the usage of the SCSV depends on the  
server being known to support the new feature.

In other words: If there is a problem in this area, you should not assume  
that it will be quickly fixed, at least not before general server support  
is past 50% or an even higher percentage of high traffic sites use it,  
which might take several years to be achieved.

-- 
Sincerely,
Yngve N. Pettersen

---

From: Adam Langley <[email-masked]>
Date: Mon, 8 Apr 2013 11:10:43 -0400

> due to packet loss or a busy server and so the 'fallback' was a

NetASQ devices certainly did do it, at least in some configurations.
Hopefully that has been fixed since I contacted them about it, but I'm
sure that not every customer has updated etc.

At the moment Chrome has a two-step fallback: TLS 1.1 -> TLS 1.0 and
then to SSLv3. From Chrome to Google (i.e. TLS 1.1 capable endpoints)
we see 0.1% of connections doing both fallbacks and then connecting
successfully. Of course, it is possible that this is due to transient
networking issues, but it seems like a rather high number for that.
(In contrast we see 0.3% doing just the first fallback)

Cheers

AGL

---

From: Trevor Perrin <[email-masked]>
Date: Mon, 8 Apr 2013 11:34:59 -0700

Hi Yngve,

Thanks for the reference to your rollback prevention draft [1].  I've
also seen the Eric Rescorla and Adam Langley proposals [2,3].

These all seem practical ways to enable a TLS-capable party suffering
an SSLv3 fallback to detect that the other party is TLS-capable.

I'd love to see any of them deployed, so such connections could be
rejected.  Browser makers could aso preload their browser with a list
of TLS-capable sites (such as their own), and disable SSLv3 fallback
for them.

Hopefully these actions would force TLS-intolerant middleboxes to be
replaced, so browsers could stop having to work-around them and this
problem would disappear.

However!  Until this happens, I  think new TLS enhancements must
unfortunately try to be compatible with browser workaround behavior.

So I'm proposing TACK (and similar proposals) could make use of SSLv3
SCSVS in a narrowly-scoped context:
 - Only in case of SSLv3 fallback
 - Only when additional data is required from the server or the
connection will fail

In the long-term, if TLS-intolerant middleboxes can be eliminated to
the point that browsers *don't* need to support them, this case will
cease to exist.  At that point this mechanism will be unused and
unneeded.

As you and Nikos have pointed out, there is no guarantee that this
mechanism will always work.  However if deployed, we could gather
statistics on it.

Anyways, I'd love to hear a better proposal for handling this
difficult and unfortunate case.  But it's seeming like the best option
for TACK (which is my immediate concern) would be to specify an SCSV
mechanism.

Does that seem reasonable?

Trevor

[1] http://datatracker.ietf.org/doc/draft-pettersen-tls-version-rollback-removal/
[2] http://www.ietf.org/mail-archive/web/tls/current/msg08099.html
[3] http://www.ietf.org/mail-archive/web/tls/current/msg08861.html

On Sat, Apr 6, 2013 at 12:04 PM, Yngve N. Pettersen <[email-masked]> wrote:
> In any such case the client should IMNSHO assume that it is being subjected
> to a Man In the Middle attack, using a version rollback attack, and abort
> the connection. The client should in such a situation not permit itself to
> downgrade the security of the connection, which includes _not_ attempting to
> set up the connection using SSL v3, or any TLS version lower than what was
> used the last time it had a successful connection.
>
> that information to assume that any failure to negotiate a connection, when
> signaling the client's highest supported version with full extension support
> in the handshake, means that the connection is being subjected to a version
> rollback attack, and terminate the connection attempt rather than roll back
> to an older version.
>
>
> that it will be quickly fixed, at least not before general server support is
> past 50% or an even higher percentage of high traffic sites use it, which
> might take several years to be achieved.
>
>
> --
> Sincerely,
> Yngve N. Pettersen
>

---

From: [email-masked] (Martin Rex)
Date: Mon, 8 Apr 2013 21:00:26 +0200 (CEST)

> 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

---

From: [email-masked] (Martin Rex)
Date: Mon, 8 Apr 2013 21:33:02 +0200 (CEST)

> than roll back to an older version.

But you do realize that this idea has been killed by Microsoft shipping
its goofed RSA premaster secret version (check) in Windows7 SChannel --
and Win7 SChannel with rfc5746 support has been in such a state of misery
for almost 3 years now.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Mon, 8 Apr 2013 21:40:08 +0200 (CEST)

> due to packet loss or a busy server and so the 'fallback' was a

In a different discussion I heard the name of one such middleboxes,
one that seems to be popular in enterprises:

  https://kb.bluecoat.com/index?page=content&id=KB5493

that appears to be incompatible with _at_least_ the silly Windows SChannel
and (former?) iPhone behaviour to use TLSv1.2 at the record layer.

I don't know whether this affected middlebox will is hostile towards
TLSv1.2 in general, or would let pass a more reasonable record version
"{03,01}" for a "{03,03}" ClientHello, such as is used by openssl-1.0.1.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Mon, 8 Apr 2013 21:49:29 +0200 (CEST)

Following up to myself.

That middlebox vendors knowledgebase article says
"Cannot access some HTTPS sites in Internet Explorer with Windows 7",
so it seems to affect connections established with TLSv1.2, not just
initial TLSv1.2 ClientHellos with TLSv1.2 at the record layer.

Sorry for the confusion.

-Martin

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Mon, 08 Apr 2013 21:51:51 +0200

> of TLS-capable sites (such as their own), and disable SSLv3 fallback

Opera 12.x already deploy the one I've described (It was also deployed in  
Opera 10.50 to 11.0x).

There are basically two main categories of Renego patched servers causing  
issues, one does not tolerate the Server Name extension (e.g  
<https://secure.avis.com>), the other does not tolerate the Certificate  
Status extension (e.g. <https://www.bigskybank.com/> which is part of a  
cluster of 90+ servers on the same /24 segment)

> replaced, so browsers could stop having to work-around them and this

I hope my proposal might manage that, but I don't think EKR and Adam's  
proposals will, since they try to work around the broken servers and  
middleboxes, and do not confront them.

Still, there have been little activity on this topic in the WG, no matter  
which direction one would like to take on this topic.

> cease to exist.  At that point this mechanism will be unused and

The problem, from my point of view, is that as long as standards and  
clients *capitulates* to (or maybe a better description is: allows  
themselves to be *blackmailed* by) those middleboxes (and servers), they  
will *never* go away, because the visited websites do not break; "if it  
ain't broken, don't fix it". (I suspect some would make references to  
"Danegeld" in similar situations.)

Case in point: Servers are still version intolerant 13+ years after TLS  
1.0 started being deployed, because clients allowed themselves to fall  
back to SSL v3. The situation is even worse regarding extension  
intolerance.

Even with the reminder about tolerance in RFC 5746 0.15% of renego patched  
servers are extension (88%) and/or version intolerant (24%) in the TLS 1.0  
to TLS 1.2 range, and the reason they are still around is that the other  
clients have not enforced a no-rollback policy for renego patched servers.  
Overall, 14.7% are intolerant for those in the 3.x and/or 4.x range.

> mechanism will always work.  However if deployed, we could gather

Which will not mean that the problem will get fixed. It will just mean  
that clients implement more and  more complex recovery methods in an  
attempt to get past what they think breaks the connection in those cases.

Quite the opposite of what my "removal" draft attempt to accomplish

Also: How long until a serious security vulnerability rears its head out  
of that mess of workarounds and iterative fallbacks?

> [1]  
> http://datatracker.ietf.org/doc/draft-pettersen-tls-version-rollback-removal/
>>> On Sat, Apr 6, 2013 at 5:14 AM, Yngve N. Pettersen  
>>> <[email-masked]>
>>> wrote:
>>>>
>> subjected
>> when

-- 
Sincerely,
Yngve N. Pettersen

---

From: [email-masked] (Martin Rex)
Date: Mon, 8 Apr 2013 22:41:13 +0200 (CEST)

> Overall, 14.7% are intolerant for those in the 3.x and/or 4.x range.

Huh? -------------------------------------------------------^^^

Why would you ever check for 4.xx version numbers?

Rejecting 4.x version numbers is perfectly OK for TLS servers!

rfc5246 says:
                                                          TLS servers
   compliant with this specification MUST accept any value {03,XX} as
   the record layer version number for ClientHello.

   TLS clients that wish to negotiate with older servers MAY send any
   value {03,XX} as the record layer version number.

A TLS client that uses a version {04,00} at the record layer or in
ClientHello.client_version is squarely in undefined territory,
and every conceivable server behaviour is perfectly compliant
with the TLSv1.2 spec.  (Personally, however, I believe that
crashing is never a valid option for the server).

-Martin

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Mon, 08 Apr 2013 22:54:46 +0200

> crashing is never a valid option for the server).

The keywords are "forward compatibility".

And your quote concerns the *record* layer version, which is 3.1 in my  
testcase.

The 4.1 that I am using in my test, is set in the  
*ClientHello.client_version* field.

IMO a SSL/TLS server MUST tolerate ANY ClientHello.client_version larger  
than its own highest supported version, and when returning the Server  
Hello will reply with whatever its highest supported version is.

-- 
Sincerely,
Yngve N. Pettersen

---

From: [email-masked] (Martin Rex)
Date: Mon, 8 Apr 2013 23:31:21 +0200 (CEST)

Yngve N. Pettersen wrote:
> Martin Rex <[email-masked]> wrote:
> >

Quoting from rfc4346 (TLS v1.1 Record Protocol PDU):

       http://tools.ietf.org/html/rfc4346#page-18

       struct {
           uint8 major, minor;
       } ProtocolVersion;

       struct {
           ContentType type;
           ProtocolVersion version;
           uint16 length;
           opaque fragment[TLSPlaintext.length];
       } TLSPlaintext;

A TLS client that sends a ClientHello.client_version with major=4,minor=1 and
expecting interop on SSLv3,TLSv1.0,TLSv1.1 or TLSv1.2 is just as misguided
as a client that sends a ClientHello.client_version with major=254, minor=255
and expecting interop on SSLv3,TLSv1.0,TLSv1.1 or TLSv1.2.

The meaning of the latter protocol version is defined here:
  http://tools.ietf.org/html/rfc4347

and there is *NO* reservation or requirement in rfc5246 that would could be
interpreted to make "major=4" any less invalid than "major=254".

-Martin

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Tue, 09 Apr 2013 01:19:46 +0200

> interpreted to make "major=4" any less invalid than "major=254".

The version field is defined as (major, minor), the version negotiation  
logic (See RFC 5246 Sec E.1) is defined as lowest version of the clients  
signaled version and the highest supported by the server. There is AFAIK  
nothing in RFC 5246 that says that the major version must match, at least  
implying that the operation is min((major_client, minor_client),  
(major_server, minor_server)).

I think is is quite reasonable to assume that *if* TLS should ever need a  
significant upgrade, one large enough that the major version number is  
changed, then we would (unless we were dealing with a complete protocol  
collapse) still want clients to be able to work with 3.x servers, which  
means that as long as the client does not know the supported version of  
the server it would use a 3.x handshake (similar to SSL v2 backwards  
compatibility), but indicate a 4.x (or whatever is assigned) version as  
its highest supported version instead of a 3.x.

In order for that to work, current servers will have to tolerate such a  
new version scheme.

If we ever get into such a situation, my guess is that we would want to  
prevent a version rollback; if we still trust the older version I think we  
also still trust the hashmethod, at least barely, to detect a modified  
handshake, but not enough to allow a rollback due to connection failure  
(unless we have some other way to signal, like we did to prevent rollback  
to SSLv2 from SSLv3).

At present, a no rollback policy like that would break 15% of all renego  
patched websites.

As I said 3 years ago, this is a forward compatibility time bomb  
<http://my.opera.com/yngve/blog/2010/06/02/renego-patched-servers-a-long-term-interoperability-time-bomb-brewing>  
(for reference, the version intolerance numbers for v4.x are, as of Dec.  
2012, 27% for all, 12% for renego patched)

-- 
Sincerely,
Yngve N. Pettersen

---

From: Trevor Perrin <[email-masked]>
Date: Mon, 8 Apr 2013 16:21:56 -0700

> Opera 12.x already deploy the one I've described (It was also deployed in

Interesting!

To make sure I understand:
 - You're saying Opera 12.x will refuse to connect to RFC
5746-supporting sites if there's a TLS-intolerant middlebox in the
way?
 - According to [1,2], about half of all TLS servers are RFC
5746-supporting?  Could I infer that Opera is providing
rollback/MITM/middlebox protection to roughly half of all TLS
connections made by its users?

If so, that's an impressive step, and great news!  Do you think other
browsers will follow suit?

> middleboxes, and do not confront them.

Not sure that's true.  From Eric's draft [3]:
"""
If the SCSV value is present and is not equal to
ClientHello.client_version, then the server MUST terminate the
handshake with a fatal "handshake_failure" alert.
"""

>From Adam's post [4]:
"""
the semantics of TLS_CAPABLE_SCSV would be that servers would reject
any SSLv3 handshakes that included this ciphersuite with a fatal
error.
"""

They have the client explicitly signal TLS capability via an SCSV,
whereas you have the client infer the server's TLS capability from
presence of renegotiation_info.

So their mechanism only works if both clients and servers support it.
Your mechanism can be rolled out unilaterally in a browser, at the
cost of a higher connection-failure rate (as you've said, ~1/700
servers return renegotiation_info while being TLS intolerant; whether
rejecting these servers is a "feature" or "bug" is another question
:-)

> The problem, from my point of view, is that as long as standards and clients
> *capitulates* to (or maybe a better description is: allows themselves to be
> *blackmailed* by) those middleboxes (and servers), they will *never* go
> away, because the visited websites do not break; "if it ain't broken, don't
> fix it". (I suspect some would make references to "Danegeld" in similar
> situations.)

I agree these middleboxes will not get fixed unless browsers and
servers break compatibility with them.

But TACK/CT/etc aren't needed for this:
 - Browsers could refuse SSLv3 fallback for sites that signal
renegotiation_info (Opera)
 - Browsers could be preloaded with lists of sites to refuse SSLv3 fallback for
 - Browsers could stop doing SSLv3 fallback entirely
 - Servers could refuse SSLv3 handshakes
 - Servers could refuse SSLv3 handshakes with a TLS_CAPABLE_SCSV (per
Eric and Adam)

They are mostly not doing so.

So in the face of the widespread middlebox "capitulation" which is a
current fact-of-life on the web, I question whether it's fair to force
the cost of breaking these middleboxes on young protocol efforts that
are already facing huge challenges to deployment.

I think doing so will simply make potential adopters unwilling to
experiment with these new enhancements, while having no impact on bad
middleboxes.

> Which will not mean that the problem will get fixed.

It means we will learn how successful this approach is in creating
TACK/CT/OCSP-must-staple connections through TLS-intolerant
middleboxes.

> It will just mean that
> clients implement more and  more complex recovery methods in an attempt to
> get past what they think breaks the connection in those cases.
>

I support your rollback removal draft, and other methods.  But
unless/until they've been effective, I don't agree that new TLS
enhancements should be prevented from trying widely-deployed
compatibility fallbacks.

> Also: How long until a serious security vulnerability rears its head out of
> that mess of workarounds and iterative fallbacks?

I support removal of all these fallbacks.  I hope we can get there.
But that is not the present reality TACK etc. have to contend with.

(And do note that TACK / CT / OCSP must-staple etc. are attempting to
address *existing* serious security vulnerabilities related to the CA
system, revocation, and so on.)

Trevor

[1] http://my.opera.com/securitygroup/blog/2011/05/19/renego-popular-unpatched-and-vulnerable-sites
[2] http://www.acsac.org/2012/openconf/modules/request.php?module=oc_program&action=view.php&a=&id=163&type=4&OPENCONF=75799905b2bb79c800ddf7ade3caad00
[3] http://www.ietf.org/mail-archive/web/tls/current/msg08099.html
[4] http://www.ietf.org/mail-archive/web/tls/current/msg08861.html

---

From: [email-masked] (Martin Rex)
Date: Tue, 9 Apr 2013 01:56:03 +0200 (CEST)

> (major_server, minor_server)).

I'm sorry, but that is a non-seqitur.

from the conceivable version numbers:

   {1.x}    undefined
   {2,x}    undefined (reserved/blocked)
   {3,x}    SSLv3 and TLS
   {4,x}    undefined
   {127,x}  undefined
   {128,x}  undefined
   {129,x}  undefined
   {253,x}  undefined
   {254,x}  DTLS
   {255,x}  undefined

and only the behaviour for {3,x} for x>3 is covered in rfc5246 Appendix E.

> changed,

This is silly and unnecessary.

The IETF could easily assign the marketing term "TLSv2.0"
for ProtocolVersion {3,4}, so there is no reason to use a major version
other than 3 for the forseeable future.

-Martin

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Wed, 24 Apr 2013 01:13:35 +0200

[Resending since it was originally not sent to the group]

> 5746-supporting sites if there's a TLS-intolerant middlebox in the

Opera will roll back all the way to SSL v3 when it does not know the
server's capabilities.

If it detect that the server support RFC 5746 it will, restart the
handshake using its highest enabled/supported version plus extensions. If
the handshake then fails it will report a handshake failure to the user;
it will not roll back.

Opera caches this result (the highest startable version) for 30 days.

> connections made by its users?

The patch coverage in my sample according to my last numbers (from
December 24, 2012) is 75% of servers are patched for renego. That number
does not necessarily translate into the same percentage of connections or
actively used servers.

Essentially, the scheme establishes a connection with one attempt for
98.5% of servers; the remaining servers might require 1-4 more connections
to establish a connection or detect a renego "protected" rollback attempt
(the sequence for TLS 1.2, if enabled is TLS 1.2+ext->TLS 1.0+ext->TLS
1.0->SSLv3)

> browsers will follow suit?

No idea, but I know Google is a bit concerned about those middleboxes.

> presence of renegotiation_info.

It seems I misremembered how their system worked, but I am still concerned
about how well it will scale as new versions of TLS are added.

However, I am also concerned about the timeframe for deploying their
system. we are currently 3 years into deploying a significant protocol
security fix (the renego patch), with 75% of servers patched, and a growth
of 8.5 percentage points in the preceeding 12 months, which indicates we
have at least 3 more years before closing in on 100% coverage (unless
clients start putting on the squeeze by removing padlocks, displaying
warnings messages, etc.)

After 4-5 years of Certificate Status Extension deployment, coverage is
still just 7.6%.  After 13 years the SSL v3-only server coverage is still
0.88%, but falling. How long do you think it will take to deploy an SCSV
based rollback protection? My guess: not less than it will take to get rid
of SSL v3.

> rejecting these servers is a "feature" or "bug" is another question

I do think, if all clients were to deploy my method, that the actively
used servers with the problem would be gone in weeks; the middleboxes
would take longer, but probably not very long.

-- 
Sincerely,
Yngve N. Pettersen

---

From: [email-masked] (Martin Rex)
Date: Wed, 24 Apr 2013 01:33:31 +0200 (CEST)

> > any SSLv3 handshakes that included this ciphersuite with a fatal

What I extremely dislike about both of these ideas is

(a) they both try to actively increase the interop failures,
    rather than decrease it

(b) they both ignore the various kinds of breakage out there
    in the installed base that may require ClientHello.client_version
    to have a specific value to make broken servers happy, rather than
    the value actually desired by the client.

(c) Keep in mind that there is not just old breakage out there,
    e.g. Microsoft shipped new breakage with Win7/Win2008R2 where
    they goofed the RSA premaster protocol version check on the
    renegotiation handshake.

For any kind of alternative TLS version negotiation, the server ought to
entirely ignore the existing ClientHello.client_version, and use the
new version signaling alone for determining the highest common protocol
version.

-Martin

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Wed, 24 Apr 2013 02:24:11 +0200

> new version signaling alone for determining the highest common protocol

Martin, how do you propose to get *rid* of the broken servers, if clients  
are not allowed to demonstrate their brokenness?

My point is that the old broken server will "never" go away as long as  
clients allow them to function, and new servers will be released in broken  
condition because clients are not telling them that they are broken during  
whatever interoperability testing the vendor did before they released the  
product. As a result, the problem will never go away.

Please note that my proposal allow clients to roll back the version with  
*non*-Renego patched servers, as before, while requiring clients to never  
roll back the version and extensions with Renego patched servers. As  
indicated earlier, 75% of all servers are now patched for Renego, but they  
make up only ~10% of of the version/extension intolerant servers (which in  
total make up about 1.5% of all servers, a number that is gradually  
decreasing as more servers are Renego patched). Thus my proposal aims to  
reduce the breakage, except with the small percentage of servers that are  
recently upgraded to a versions that ought to have been fixed for the  
intolerance issue. The number of such servers is also so low that it  
should not be an insurmountable task to get them quickly fixed. (the  
intermediate networks boxes is a different issue)

-- 
Sincerely,
Yngve N. Pettersen

---

From: [email-masked] (Martin Rex)
Date: Wed, 24 Apr 2013 03:59:23 +0200 (CEST)

> condition because clients are not telling them that they are broken during  

... writes the one who has been shipping a multi-stage reconnect fallback
for years.

The Engineering part of IETF is about creating and maintaining interop,
the IETF is no manufacturer cartel for enforcing planned obsolescense!

A non-marginal fraction of the problematic servers are not really broken,
primarily they're old and based on an old version of the specification.

What concerns me *MUCH* more is the reconnect fallback hacks in several
recent TLS clients (primarily Web Browsers), because that is what is
causing most of the interop problems (=failed TLS handshakes).

That negotiating TLSv1.2 by sending ClientHello.client_version = {03,03}
is an EXTREMELY dumb idea given the installed base should have been
(and still is) painfully obvious for everyone who cared to check, so
I really fail to understand why such ostrich behaviour was published
as rfc5246 in the first place.

Actually the problem already existed in 2006, when rfc4346 was published.
Surprise, surprise, ignoring the problem didn't make it go away.

When revising a protocol, it is a bad idea to perform it in a fashion
that only works in a fantasy fairy-tale, but instead take into account
what is going to be interoperable with the real world.

What is really needed, is a negotiation of TLSv1.2 protocol&features
that does not need ClientHello.client_version = {03,03}, but instead
can use ClientHello.client_version = {03,01}.  This would get rid
of most of the TLS handshake failures and obviate the TLS reconnect
fallback hacks in clients.  Now _that_ would be really an improvement!

But while doing that, we also SHOULD REALLY fix the semantics that are
currently specified in rfc5246 for the SignatureAlgorithm TLS extension:
strip all the crap between the contents of that extension and
signature algorithms in the certificates.

-Martin

---

From: Yoav Nir <[email-masked]>
Date: Wed, 24 Apr 2013 08:47:24 +0000

> ... writes the one who has been shipping a multi-stage reconnect fallback

What else can Opera do? Ship a browser that works on only 90% of the web? I think they're doing as much as they can to combat new kinds of brokenness. If Microsoft had had this attitude when they had a 98% of the browser market, we would be seeing a lot less brokenness today.

> the IETF is no manufacturer cartel for enforcing planned obsolescense!

The IETF is not a manufacturer's cartel. But if people want to change the way TLS clients behave (for whatever reason), this is the place to discuss it, and maybe document it.

> primarily they're old and based on an old version of the specification.

What old version of the specification had renegotiation info, but didn't have proper version negotiation?  Going strictly by the RFCs a lot more handshakes would be dropped.

> fallback hacks in clients.  Now _that_ would be really an improvement!

Are you proposing a TLS 1.2 SCSV? If Mozilla hadn't made the decisions to include Camelia in the list of ciphersuites, we would probably have quite a few servers out there that didn't tolerate unknown ciphersuites. As it is, ClientHello.client_version = {03,03} works quite well for the vast, vast majority of web sites. The ostrich wins, and they lived happily ever after.