Proposal: Disable SSLv3 in Firefox ESR 31

[Richard Barnes]

Hey all,

By now, you've probably heard about the POODLE attacks on SSLv3, and our decision to disable SSLv3 by default in Firefox 34 [1]. Several people have proposed that we also make this change in Firefox ESR 31.

So I wanted to propose that we also disable SSLv3 by default in ESR 31 at about the same time as we do it in 34, that is, around November 25.

If there are any objections or comments on that proposal, please raise them in this thread.

Thanks,
--Richard

[1] https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0/

[Kai Engert]

On Thu, 2014-10-16 at 10:31 -0700, Richard Barnes wrote:
> By now, you've probably heard about the POODLE attacks on SSLv3, and
> our decision to disable SSLv3 by default in Firefox 34 [1]. Several
> people have proposed that we also make this change in Firefox ESR 31.
>
> So I wanted to propose that we also disable SSLv3 by default in ESR 31
> at about the same time as we do it in 34, that is, around November 25.
>
> If there are any objections or comments on that proposal, please raise
> them in this thread.

FYI, it's actually more than a proposal.

It has been clarified in the bug, disabling it in Firefox 31.3 is
already planned:
https://bugzilla.mozilla.org/show_bug.cgi?id=1076983#c73

So, if you have any objections, please speak up.

Thanks
Kai

[Florian Weimer]

* Richard Barnes:

> If there are any objections or comments on that proposal, please
> raise them in this thread.

A lot of this has already been hashed out on the IETF TLS WG mailing
list, with a slightly different perspective.

Why is disabling SSL 3.0 acceptable, but getting rid of the broken
fallback which will keep endangering users for a long time to come is
not?

[Kai Engert]

On Thu, 2014-10-16 at 20:27 +0200, Florian Weimer wrote:
> A lot of this has already been hashed out on the IETF TLS WG mailing
> list, with a slightly different perspective.
>
> Why is disabling SSL 3.0 acceptable, but getting rid of the broken
> fallback which will keep endangering users for a long time to come is
> not?

Please let's make sure there are no misunderstandings.

Do you claim that Firefox 34 will continue to fall back to SSL 3 when
necessary?

I was hoping that Firefox 34 would completely disable SSL 3, no longer
accepting servers requesting to use that version, and no longer
initiating any SSL 3 connections, not even when falling back.

Did I understand incorrectly?

Kai

[Reed Loden]

On Thu, 16 Oct 2014 20:27:24 +0200
Florian Weimer <f...@deneb.enyo.de> wrote:

> * Richard Barnes:
>
> > If there are any objections or comments on that proposal, please
> > raise them in this thread.
>

> A lot of this has already been hashed out on the IETF TLS WG mailing
> list, with a slightly different perspective.
>
> Why is disabling SSL 3.0 acceptable, but getting rid of the broken
> fallback which will keep endangering users for a long time to come is
> not?

Are you talking about implementing TLS_FALLBACK_SCSV (bug 1036737) or
disabling the insecure TLS version fallback to SSLv3 (bug 689814)?

The former is riding the release trains and should be in Firefox 35. The
latter is no longer needed now that SSLv3 is disabled (though I guess
it could still be implemented for those people who require SSLv3 still
be enabled).

~reed

[Florian Weimer]

* Reed Loden:

> On Thu, 16 Oct 2014 20:27:24 +0200
> Florian Weimer <f...@deneb.enyo.de> wrote:
>
>> * Richard Barnes:
>>
>> > If there are any objections or comments on that proposal, please
>> > raise them in this thread.
>>
>> A lot of this has already been hashed out on the IETF TLS WG mailing
>> list, with a slightly different perspective.
>>
>> Why is disabling SSL 3.0 acceptable, but getting rid of the broken
>> fallback which will keep endangering users for a long time to come is
>> not?
>
> Are you talking about implementing TLS_FALLBACK_SCSV (bug 1036737) or
> disabling the insecure TLS version fallback to SSLv3 (bug 689814)?

Neither. I'm talking about the out-of-protocol insecure version
negotiation for TLS implemented in Firefox. That's a broader scope
than bug 689814, which is strictly about fallback to SSL 3.0.

I suspect you think it is necessary based on bogus telemetry. There
will be some breakage, but I doubt it will be more than the fallout
from disabling SSL 3.0 by default. And the long-term benefits are so
much greater.

[Julien Pierre]

Florian,

On 10/16/2014 12:50, Florian Weimer wrote:
> Neither. I'm talking about the out-of-protocol insecure version
> negotiation for TLS implemented in Firefox. That's a broader scope
> than bug 689814, which is strictly about fallback to SSL 3.0.

+1
This fallback needs to get removed, yesterday.
SSL/TLS have had a secure mechanism for preventing protocol version
downgrade attacks from day 1.
Firefox circumvents this. It's about time Firefox - and others - to
conform to the standard.

TLS_FALLBACK_SCSV is a one-time band-aid that won't do any good in the
long run.
Any server administrator that cares about security will simply disable
SSL3 in their server, rather than go through the process of upgrading
their software to support this draft.

Julien

[Kai Engert]

On Thu, 2014-10-16 at 20:51 +0200, Kai Engert wrote:
> Do you claim that Firefox 34 will continue to fall back to SSL 3 when
> necessary?

Yes. If I understand correctly, it seems that Firefox indeed still falls
back to SSL3, even with SSL3 disabled.

I found
https://bugzilla.mozilla.org/show_bug.cgi?id=1083058
which intends to implement a preference to configure the oldest allowed
protocol version to fallback to, with a propose mininum of 1 (TLS1).

Kai

[Julien Pierre]

Kai,

What is the purpose of Firefox continuing to do any fallback at all ?
IMO, making a second connection with any lower version of SSL/TLS
defeats the intent of the SSL/TLS protocol, which have built-in defenses
against protocol version downgrade.
Isn't it time this fallback gets eliminated at last ?

Julien

[Kai Engert]

On Mon, 2014-10-20 at 16:45 -0700, Julien Pierre wrote:
> What is the purpose of Firefox continuing to do any fallback at all ?
> IMO, making a second connection with any lower version of SSL/TLS
> defeats the intent of the SSL/TLS protocol, which have built-in defenses
> against protocol version downgrade.
> Isn't it time this fallback gets eliminated at last ?

I'm stating what I found, I'm not making that decision.

Kai

[Reed Loden]

On Tue, 21 Oct 2014 01:40:45 +0200
Kai Engert <ka...@kuix.de> wrote:

> On Thu, 2014-10-16 at 20:51 +0200, Kai Engert wrote:
> > Do you claim that Firefox 34 will continue to fall back to SSL 3 when
> > necessary?
>
> Yes. If I understand correctly, it seems that Firefox indeed still falls
> back to SSL3, even with SSL3 disabled.

Has that been tested, as that seems pretty wrong if that's true?...
It's not my understanding at all and would mean that those who have
been turning SSLv3 off (via security.tls.version.min) haven't actually
been protecting themselves from POODLE.

> I found
> https://bugzilla.mozilla.org/show_bug.cgi?id=1083058
> which intends to implement a preference to configure the oldest allowed
> protocol version to fallback to, with a propose mininum of 1 (TLS1).

I always took that patch to be useful for those who need SSLv3
enabled -- as in, if security.tls.version.min was 0, then that patch
would effectively protect them from downgrade attacks against sites
that support higher TLS versions.

~reed

[Julien Pierre]

Kai,

Sorry, I didn't mean to blame you for that decision - but IMO this
should be pointed out to whoever made that call.

The whole TLS_FALLBACK_SCSV would be unnecessary if not for this browser
misbehavior - and I hope the IETF will reject it.

Julien

[Kai Engert]

On Tue, 2014-10-21 at 01:40 +0200, Kai Engert wrote:
> On Thu, 2014-10-16 at 20:51 +0200, Kai Engert wrote:
> > Do you claim that Firefox 34 will continue to fall back to SSL 3 when
> > necessary?
>
> Yes. If I understand correctly, it seems that Firefox indeed still falls
> back to SSL3, even with SSL3 disabled.

I'm sorry if I got this wrong, inspired by Florian's claim (still
falling back) and my quick reading of the code. Let's get this
clarified.

My reading of the source indicated that adjustForTLSIntolerance would
fall back until it reaches SSL3.

However, trying to connect to a SSL3-only server like
https://bod.bodmillenium.com using Firefox 33 and 36 fails (with min.tls
set to 1).

So hopefully I was wrong.

Thanks
Kai

[Hubert Kario]

Yes, it's external to the TLS, and yes, it's bad that browsers do use
the manual fallback. Yes, the servers should be regularly updated and
as such bugs that cause it fixed. Yes, the configurations should be
updated to align them with current recommendations.

But it doesn't happen in real world.

So either we can push for policies which will never be implemented and
be workable in real world, or we can try to make the systems secure in
real world for people that care (both users and server admins that
do apply updates regularly).

Yes, I'd like to live in a world where it's not necessary, but we don't.
--
Regards,
Hubert Kario

[Florian Weimer]

* Julien Pierre:

> The whole TLS_FALLBACK_SCSV would be unnecessary if not for this
> browser misbehavior - and I hope the IETF will reject it.

Technically, we still need the codepoint assignments from the IETF
draft because of their widespread use, and that requires Standards
Action, which means publication of a standards-track RFC. Although
the RFC could simply say, "do not use these codepoints".

(I think TLS_FALLBACK_SCSV is a mistake, too.)

[Kai Engert]

So, let's get this clarified with test results.

I've tested Firefox 34 beta 1.

Because bug 1076983 hasn't landed on the beta branch yet, the current
Firefox 34 beta 1 still has SSL3 enabled.

With this current default configuration (SSL3 enabled), Firefox will
fall back to SSL3.

Then I used about:config and changed security.tls.version.min to 1
(which means TLSv1, thereby disabling SSL3).

With SSL3 disabled, Firefox 34 no longer falls back to SSL3.

When attempting to connect to a SSL3-only server, I see Firefox 34
attempting three connections, with TLS 1.2 {3,3}, TLS 1.1 {3,2} and TLS
1.0 {3,1}, but not SSL3.

In other words, with SSL3 disabled, Firefox 34 doesn't attempt a
fallback to use SSL3.

With these new results, it's no longer clear to me what Florian was
referring to.

On Thu, 2014-10-16 at 20:27 +0200, Florian Weimer wrote:

> Why is disabling SSL 3.0 acceptable, but getting rid of the broken
> fallback which will keep endangering users for a long time to come is
> not?

Florian, did you assume that Firefox would still fall back to SSl3?
That's not happening.
With SSL3 disabled, the intention, as I understand it, is to disable
SSL3 completely, not even using it when falling back.

On the other hand, Firefox will continue to fall back to non-disabled
versions of TLS (such as TLS 1.1 and TLS 1.0).

Is this what you're worried about?

Kai

[Florian Weimer]

* Kai Engert:

> When attempting to connect to a SSL3-only server,

Which is now treated as version-intolerant, it seems.

> I see Firefox 34 attempting three connections, with TLS 1.2 {3,3},
> TLS 1.1 {3,2} and TLS 1.0 {3,1}, but not SSL3.

This still shows the fallback attempts, to TLS 1.0 even, which isn't
exactly stellar from a CBC padding perspective, either.

> With these new results, it's no longer clear to me what Florian was
> referring to.

I still think the fallback behavior you have shown is a browser bug,
and should be fixed there, but its removal. There seems to be rather
vehement disagreement, but I don't get way.

People who desparately need to connect to old devices can keep old
browser versions around, or you could offer a per-site configuration
knob (chances are you need that for SSL 3.0 support anyway). These
old devices frequently demand old browser or Java versions, so yet
another reason to keep an old browser around does not seem
particularly cumbersome to me.

The benefit from that would be that regular users are protected even
if servers do not implement TLS_FALLBACK_SCSV.

[Julien Pierre]

Hubert,

On 10/21/2014 05:06, Hubert Kario wrote:
>
> Yes, it's external to the TLS, and yes, it's bad that browsers do use
> the manual fallback. Yes, the servers should be regularly updated and
> as such bugs that cause it fixed. Yes, the configurations should be
> updated to align them with current recommendations.
>
> But it doesn't happen in real world.
>
> So either we can push for policies which will never be implemented and
> be workable in real world, or we can try to make the systems secure in
> real world for people that care (both users and server admins that
> do apply updates regularly).
>
> Yes, I'd like to live in a world where it's not necessary, but we don't.

IMO, reasonable decisions can be made to drop support for TLS intolerant
servers.

Those who have legacy devices that can't be updated could still use
legacy browsers to connect to them, or there could be an explicit legacy
mode of operation in current browsers that preserves it.

This way, browsers won't subject the requests to 99.999% of servers that
are not TLS-intolerant to needless MITM attacks, not to mention extra
network bandwidth and round trips.

Julien

[Julien Pierre]

Florian,

On 10/21/2014 06:38, Florian Weimer wrote:
>
> I still think the fallback behavior you have shown is a browser bug,
> and should be fixed there, but its removal. There seems to be rather
> vehement disagreement, but I don't get way.

+1 , any fallback is a bug. SSL has built-in protocol version negotiation.

> People who desparately need to connect to old devices can keep old
> browser versions around, or you could offer a per-site configuration
> knob (chances are you need that for SSL 3.0 support anyway). These
> old devices frequently demand old browser or Java versions, so yet
> another reason to keep an old browser around does not seem
> particularly cumbersome to me.

We think alike....

>
> The benefit from that would be that regular users are protected even
> if servers do not implement TLS_FALLBACK_SCSV.

Indeed. Servers that care about the SSL3 issue aren't going to upgrade
software to pick up TLS_FALLBACK_SCSV . They will just disable SSL3 in
the configuration, which is much simpler and much quicker to do . Some
servers may do both, but it won't be the majority.

TLS_FALLBACK_SCSV serves no purpose except to perpetuate the illusion
that the browser fallback makes some sort of sense.

Julien

[Julien Pierre]

Kai,

On 10/21/2014 05:31, Kai Engert wrote:
> So, let's get this clarified with test results.
>
> I've tested Firefox 34 beta 1.
>
> Because bug 1076983 hasn't landed on the beta branch yet, the current
> Firefox 34 beta 1 still has SSL3 enabled.
>
> With this current default configuration (SSL3 enabled), Firefox will
> fall back to SSL3.
>
> Then I used about:config and changed security.tls.version.min to 1
> (which means TLSv1, thereby disabling SSL3).
>
> With SSL3 disabled, Firefox 34 no longer falls back to SSL3.
>

> When attempting to connect to a SSL3-only server, I see Firefox 34

> attempting three connections, with TLS 1.2 {3,3}, TLS 1.1 {3,2} and TLS
> 1.0 {3,1}, but not SSL3.
>

That's a lot of fallbacks.
Do we know of TLS 1.0 servers that reject connections with TLS 1.2 or
1.1 in ClientHello instead of falling back to 1.0 ?
Or TLS 1.1 servers that reject connections with 1.2 in ClientHello
instead of falling back to 1.1 ?

Just how many broken servers are there out there ?

Julien

[Julien Pierre]

Florian,

On 10/21/2014 05:24, Florian Weimer wrote:
> * Julien Pierre:
>
>> The whole TLS_FALLBACK_SCSV would be unnecessary if not for this
>> browser misbehavior - and I hope the IETF will reject it.
> Technically, we still need the codepoint assignments from the IETF
> draft because of their widespread use, and that requires Standards
> Action, which means publication of a standards-track RFC. Although
> the RFC could simply say, "do not use these codepoints".

Sorry I misspoke - I'm not that familiar with the intricacies of the
IETF RFC process.

Julien

[Hubert Kario]

On Tuesday 21 October 2014 16:10:52 Julien Pierre wrote:
> Hubert,
>
> On 10/21/2014 05:06, Hubert Kario wrote:
> > Yes, it's external to the TLS, and yes, it's bad that browsers do use
> > the manual fallback. Yes, the servers should be regularly updated and
> > as such bugs that cause it fixed. Yes, the configurations should be
> > updated to align them with current recommendations.
> >
> > But it doesn't happen in real world.
> >
> > So either we can push for policies which will never be implemented and
> > be workable in real world, or we can try to make the systems secure in
> > real world for people that care (both users and server admins that
> > do apply updates regularly).
> >
> > Yes, I'd like to live in a world where it's not necessary, but we don't.
>
> IMO, reasonable decisions can be made to drop support for TLS intolerant
> servers.
>
> Those who have legacy devices that can't be updated could still use
> legacy browsers to connect to them, or there could be an explicit legacy
> mode of operation in current browsers that preserves it.

Problem is that if something doesn't work in one browser and does in another
users blame the browser. Even if the browser that doesn't work does the right
thing.

Recommending the use of obsolete browsers is also a bad idea - they have well
known vulnerabilities. It also may simply be not possible in walled gardens
(phones/tablets).

> This way, browsers won't subject the requests to 99.999% of servers that
> are not TLS-intolerant to needless MITM attacks, not to mention extra
> network bandwidth and round trips.

It's closer to below 99% or 89%, depending on which TLS version you look at.
It's rare, but it's not unheard of, and that's internet facing dedicated web
servers. I'm afraid what the statistics would be for devices where the TLS
part is secondary (routers/automation systems/smart devices/etc.) which we
can't really probe.
--
Regards,
Hubert Kario

[Julien Pierre]

Hubert,

On 10/22/2014 05:27, Hubert Kario wrote:
>
> Problem is that if something doesn't work in one browser and does in another
> users blame the browser. Even if the browser that doesn't work does the right
> thing.

What if all browsers started doing the right thing ?

>
> Recommending the use of obsolete browsers is also a bad idea - they have well
> known vulnerabilities. It also may simply be not possible in walled gardens
> (phones/tablets).

Are there phone/tablets which can't install any 3rd party browsers at all ?

Anyway, the very fallback we are talking about here is a known
vulnerability.
It sounds like we want a browser that is current on vulnerability fixes,
except for this one.
That would seem to make the case for some sort of "legacy mode" in
current browsers.

>
>> This way, browsers won't subject the requests to 99.999% of servers that
>> are not TLS-intolerant to needless MITM attacks, not to mention extra
>> network bandwidth and round trips.
> It's closer to below 99% or 89%, depending on which TLS version you look at.

Do you have any pointer to the versions and data for this 99% / 89% ?

> It's rare, but it's not unheard of, and that's internet facing dedicated web
> servers. I'm afraid what the statistics would be for devices where the TLS
> part is secondary (routers/automation systems/smart devices/etc.) which we
> can't really probe.

For legacy devices, a "legacy mode" in the browser seems most appropriate.

Julien

[Hubert Kario]

On Wednesday 22 October 2014 15:54:57 Julien Pierre wrote:
> Hubert,
>
> On 10/22/2014 05:27, Hubert Kario wrote:
> > Problem is that if something doesn't work in one browser and does in
> > another users blame the browser. Even if the browser that doesn't work
> > does the right thing.
>
> What if all browsers started doing the right thing ?

That's a very hypothetical question...

"What if all servers deployed TLS1.2 and refused connections with anything
older?" That would also fix the problem...

> > Recommending the use of obsolete browsers is also a bad idea - they have
> > well known vulnerabilities. It also may simply be not possible in walled
> > gardens (phones/tablets).
>
> Are there phone/tablets which can't install any 3rd party browsers at all ?

AFAIK, iOS devices require you to use the system TLS stack.

> Anyway, the very fallback we are talking about here is a known
> vulnerability.
> It sounds like we want a browser that is current on vulnerability fixes,
> except for this one.

I'm not saying it isn't. But it is behaviour that is expected by users. Just
like users expect to not see "this connection is untrusted, you may be subject
to MITM attack" when connecting over plain HTTP.

> >> This way, browsers won't subject the requests to 99.999% of servers that
> >> are not TLS-intolerant to needless MITM attacks, not to mention extra
> >> network bandwidth and round trips.
> >
> > It's closer to below 99% or 89%, depending on which TLS version you look
> > at.
> Do you have any pointer to the versions and data for this 99% / 89% ?

http://www.ietf.org/proceedings/90/slides/slides-90-tls-0.pdf

--
Regards,
Hubert Kario

[Julien Pierre]

Hubert,

On 10/23/2014 07:53, Hubert Kario wrote:
>> Are there phone/tablets which can't install any 3rd party browsers at all ?
> AFAIK, iOS devices require you to use the system TLS stack.

I see, I didn't know.
But it still would seem that any second connection (fallback) would be
dictated by the browser implementation itself, and not the stack.

>
>> Anyway, the very fallback we are talking about here is a known
>> vulnerability.
>> It sounds like we want a browser that is current on vulnerability fixes,
>> except for this one.
> I'm not saying it isn't. But it is behaviour that is expected by users.

I think most users are woefully unaware of any TLS connection retry /
fallback being done by the browser.
I think you meant to say that users expect the browser to continue to
work with all their legacy TLS-intolerant devices somehow.
That doesn't mean that a legacy mode of operation in the browser
wouldn't be an acceptable solution to them.

> Do you have any pointer to the versions and data for this 99% / 89% ?
> http://www.ietf.org/proceedings/90/slides/slides-90-tls-0.pdf
>

Thank you. The 11% of TLS 1.3 intolerant servers is scary indeed. Do we
have any idea which SSL stacks / server vendors are affected ?

Julien