Road to RC4-free web (the case for YouTube without RC4)

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Road to RC4-free web (the case for YouTube without RC4)

Hubert Kario
The number of sites that prefer RC4 while still supporting other ciphers are
very high (18.6% in June[1], effectively 21.3% for Firefox[6]) and not
changing much. The percent of servers that support only RC4 is steadily
dropping (1.771% in April[3], 1.194% in May[2], 0.985% in June[1]).

Because of that, disabling RC4 should be possible for many users. The big
exception for that was YouTube video servers[4] which only recently gained
support for TLS_RSA_WITH_AES_128_GCM_SHA256.

So let me be blunt. Why we can't have[5] a setting that will allow users of
over 2% of servers increase their security[6] and make youtube usable for
people that disabled RC4[7,8,9]. While we have a setting like
security.ssl3.rsa_seed_sha which as far as I can see affects no servers[6]?

Note that I'm not talking about changing the default configuration, I'm
talking only about adding optional functionality.

Full analisys is available here:
http://securitypitfalls.wordpress.com/2014/06/29/is-rc4-less


 1 - http://securitypitfalls.wordpress.com/2014/06/24/rc4-only
 2 - http://securitypitfalls.wordpress.com/2014/06/24/may-2014
 3 - http://securitypitfalls.wordpress.com/2014/05/07/cipher-scan
 4 -
https://www.ssllabs.com/ssltest/analyze.html?d=r4---sn-uxaxovg-5goz.googlevideo.
com
 5 - https://bugzilla.mozilla.org/show_bug.cgi?id=1029179
 6 - http://securitypitfalls.wordpress.com/2014/06/29/is-rc4-less
 7 - https://github.com/klemens/ff-youtube-all-html5/issues/24
 8 - https://support.mozilla.org/en-US/questions/990082
 9 -
https://productforums.google.com/forum/#!searchin/youtube/rc4/youtube/
VuVshylMDO0/EMuBNFmgQLwJ

--
Regards,
Hubert Kario
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Road to RC4-free web (the case for YouTube without RC4)

Brian Smith-19
On Sun, Jun 29, 2014 at 11:18 AM, Hubert Kario <[hidden email]> wrote:

> Because of that, disabling RC4 should be possible for many users. The big
> exception for that was YouTube video servers[4] which only recently gained
> support for TLS_RSA_WITH_AES_128_GCM_SHA256.
>

Hi,

I read your blog post at
http://securitypitfalls.wordpress.com/2014/06/29/is-rc4-less, which is
interesting. The blog post compares how enabling/disabling various cipher
suites affects the percentage of sites that end up negotiating RC4.
However, I noticed that you didn't measure how enabling/disabling various
cipher suites affects how often Firefox uses ECDHE, DHE with a strong
(>=1280 bit, at least), DHE with weak, or RSA key exchange.

Using the Firefox 30 telemetry data [0], I saw that
TLS_ECDHE_RSA_WITH_RC4_128_SHA is still the 7th most commonly negotiated
cipher suite, at ~1.1% of all full handshakes that Firefox does, and that
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA is the 12th most common cipher suite, at
0.1%. Also note that these two cipher suites are the least-preferred ECDHE
cipher suites in Firefox's ClientHello, so it seems likely that disabling
these two cipher suites will reduce the use of ECDHE by ~1.2%. IIRC, when I
analyzed this previously, I found that almost every site negotiating
ECDHE-RC4 cipher suites would do RSA key exchange if we disabled these two
cipher suites. The benefits of ECDHE outweigh the risks of using RC4, so I
think that disabling these two cipher suites or changing their
prioritization in the Firefox ClientHello would be a bad idea at this time.
So, at a minimum, it would be important to re-run your analysis with these
two cipher suites still enabled to see what the real effect of adding
RSA-AES-GCM cipher suites.

As I noted in my bug comment [1], I think that the rhetoric of us not
adding any more RSA-key-exchange-based cipher suites, even the AES-GCM
ones, is significant. Software engineers at multiple companies referenced
our positions on this as part of making the business case for raising the
priority of ECDHE support in their products. It has been slow going, but
also it has only been half a year since we shipped the new cipher suite
configuration in Firefox. The effects on other products will be more clear
soon, if what I am told is correct. In particular, I see that Red Hat [2]
and Canonical [3] are still debating whether to backport ECDHE support to
Apache 2.2. I think that by maintaining our position here, we can help the
engineers working on that make a stronger case for those backports.

By the way, I'd like to again thank Kurt Roeckx for his efforts to convince
Debian to backport ECDHE support to Debian's Apache 2.2 [4].


> So let me be blunt. Why we can't have[5] a setting that will allow users of
> over 2% of servers increase their security[6] and make youtube usable for
> people that disabled RC4[7,8,9]. While we have a setting like
> security.ssl3.rsa_seed_sha which as far as I can see affects no servers[6]?
>

I agree that we should treat the RSA-AES-GCM cipher suites the same way we
treat those other cipher suites that are disabled by default. I filed bug
1031952 [5] and wrote the patch to remove the unneeded preferences.


> Note that I'm not talking about changing the default configuration, I'm
> talking only about adding optional functionality.
>

Like I said in the bug [1], in PSM we only add such prefs as a last resort,
and I don't think we're that desperate yet. The prefs like
security.ssl3.rsa_seed_sha existed before we started the effort to reform
Firefox's cipher suite, and it was always intended to remove them once we'd
verified that we hadn't caused any significant compatibility issues with
the new configuration.

Cheers,
Brian

[0]
http://telemetry.mozilla.org/#filter=release%2F30%2FSSL_CIPHER_SUITE_FULL&aggregates=multiselect-all!Submissions&evoOver=Builds&locked=true&sanitize=false&renderhistogram=Table
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1029179#c3
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1035818
[3] https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1197884
[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733564
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=1031952
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Road to RC4-free web (the case for YouTube without RC4)

Hubert Kario
----- Original Message -----

> From: "Brian Smith" <[hidden email]>
> To: "mozilla's crypto code discussion list" <[hidden email]>
> Sent: Monday, June 30, 2014 12:23:41 AM
> Subject: Re: Road to RC4-free web (the case for YouTube without RC4)
>
> On Sun, Jun 29, 2014 at 11:18 AM, Hubert Kario <[hidden email]> wrote:
>
> > Because of that, disabling RC4 should be possible for many users. The big
> > exception for that was YouTube video servers[4] which only recently gained
> > support for TLS_RSA_WITH_AES_128_GCM_SHA256.
> >
>
> Hi,
>
> I read your blog post at
> http://securitypitfalls.wordpress.com/2014/06/29/is-rc4-less, which is
> interesting. The blog post compares how enabling/disabling various cipher
> suites affects the percentage of sites that end up negotiating RC4.
> However, I noticed that you didn't measure how enabling/disabling various
> cipher suites affects how often Firefox uses ECDHE, DHE with a strong
> (>=1280 bit, at least), DHE with weak, or RSA key exchange.

This data is in the full scan results at:
http://securitypitfalls.wordpress.com/2014/06/24/rc4-only-servers-fall-below-1-june-2014-scan-results/
Basically, for DHE there exist 2 sizes: 1024 bit (93% of DHE) and 2048 bit
(6% of DHE servers).

> Using the Firefox 30 telemetry data [0], I saw that
> TLS_ECDHE_RSA_WITH_RC4_128_SHA is still the 7th most commonly negotiated
> cipher suite, at ~1.1% of all full handshakes that Firefox does, and that
> TLS_ECDHE_ECDSA_WITH_RC4_128_SHA is the 12th most common cipher suite, at
> 0.1%. Also note that these two cipher suites are the least-preferred ECDHE
> cipher suites in Firefox's ClientHello, so it seems likely that disabling
> these two cipher suites will reduce the use of ECDHE by ~1.2%.

That's true only if we don't enable any other ECDHE suites.

Enabling just ECDHE-RSA-AES128-SHA256 causes Firefox to negotiate RC4 with 2%
less servers, without disabling or changing order of any RC4 cipher.
The "Firefox 29 and one more cipher" section at the blog.

> IIRC, when I
> analyzed this previously, I found that almost every site negotiating
> ECDHE-RC4 cipher suites would do RSA key exchange if we disabled these two
> cipher suites.

That's assuming we don't enable any other suites.

> The benefits of ECDHE outweigh the risks of using RC4,

I have to disagree here. Even 1024 bit DHE requires a targeted attack at ~80 bit
complexity. Currently we see RC4 at around 56 bit, with a completely unoptimized
attack...

> so I
> think that disabling these two cipher suites or changing their
> prioritization in the Firefox ClientHello would be a bad idea at this time.
> So, at a minimum, it would be important to re-run your analysis with these
> two cipher suites still enabled to see what the real effect of adding
> RSA-AES-GCM cipher suites.

I'm assuming that you want to see the effect with regards to selected cipher
suite and key exchange (ECDHE vs DHE vs RSA).

Please say which cipher lists you want simulated.
 
> As I noted in my bug comment [1], I think that the rhetoric of us not
> adding any more RSA-key-exchange-based cipher suites, even the AES-GCM
> ones, is significant. Software engineers at multiple companies referenced
> our positions on this as part of making the business case for raising the
> priority of ECDHE support in their products.

I fail to see how changing /non default/ settings affects that.

I mean, I've been surfing with disallowed pictures for mixed content
(security.mixed_content.block_display_content). You'd be surprised at amount
of sites that break because of that. Disabled JavaScript is similar.
Webmasters make sites and configure servers against the lowest common
denominator: it works, then the work is done. They don't check what happens if
the user is running non standard configuration. I've never seen a website
that said to the user to modify the settings in about:config to make the
site work as intended.

It's not like you plan to remove support for those ciphers from NSS, do you?

Disabling access to just under 1% of servers is too much, so we can't remove
RC4 from default. Adding additional ciphers may bring the amount of sites that
use RC4 from 20% to 18% but it will not bring it below 18% as long as RC4
ciphers are enabled.

I want a setting for early adopters.

So that statistics for servers start showing that the clients don't advertise
support for RC4 ciphers, so that server side stats show that support for other
ciphers is important for interoperability.

> It has been slow going, but
> also it has only been half a year since we shipped the new cipher suite
> configuration in Firefox. The effects on other products will be more clear
> soon, if what I am told is correct. In particular, I see that Red Hat [2]
> and Canonical [3] are still debating whether to backport ECDHE support to
> Apache 2.2. I think that by maintaining our position here, we can help the
> engineers working on that make a stronger case for those backports.
>
> By the way, I'd like to again thank Kurt Roeckx for his efforts to convince
> Debian to backport ECDHE support to Debian's Apache 2.2 [4].

I'm glad to hear that there are similar initiatives to the one we have in RedHat.

> > Note that I'm not talking about changing the default configuration, I'm
> > talking only about adding optional functionality.
> >
>
> Like I said in the bug [1], in PSM we only add such prefs as a last resort,
> and I don't think we're that desperate yet.

20% of Internet servers negotiating suboptimal ciphers is not *really bad*?
How much do we have to reach for that to be a problem?

--
Regards,
Hubert Kario
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Road to RC4-free web (the case for YouTube without RC4)

Kurt Roeckx
In reply to this post by Brian Smith-19
On 2014-06-30 02:35, Hubert Kario wrote:
>> The benefits of ECDHE outweigh the risks of using RC4,
>
> I have to disagree here. Even 1024 bit DHE requires a targeted attack at ~80 bit
> complexity. Currently we see RC4 at around 56 bit, with a completely unoptimized
> attack...

Do you have a reference for those 56 bit?  You're not talking about the
old export ciphers I hope?  I haven't seen anything saying that the 128
bit RC4 has a complexity of 56 bit.  If it's really at 56 bit, we should
disable it everywhere now, no matter if it breaks things or not.

I think we should do all that's possible to avoid RC4.  I think that for
now we should follow Microsoft in not having RC4 in the initial
handshake and if fails retry with RC4 enabled.  It's my understanding
that that should reduce RC4 usage from 20% of the sites to 1%.


Kurt

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Road to RC4-free web (the case for YouTube without RC4)

Hubert Kario
----- Original Message -----

> From: "Kurt Roeckx" <[hidden email]>
> To: [hidden email]
> Sent: Monday, 30 June, 2014 10:56:13 AM
> Subject: Re: Road to RC4-free web (the case for YouTube without RC4)
>
> On 2014-06-30 02:35, Hubert Kario wrote:
> >> The benefits of ECDHE outweigh the risks of using RC4,
> >
> > I have to disagree here. Even 1024 bit DHE requires a targeted attack at
> > ~80 bit
> > complexity. Currently we see RC4 at around 56 bit, with a completely
> > unoptimized
> > attack...
>
> Do you have a reference for those 56 bit?

My estimation.

http://www.isg.rhul.ac.uk/tls/
requires 2^30 sessions with 2^8 computations to recover full text.
And it requires 2^24 sessions and 2^8 computations to recover some bytes.

I assumed two to one data-to-computation equivalence and added 8 bits from
the original attack.

Even if the equivalence is higher, capturing 2^10 of sessions won't
require extended monitoring. If we then say that this then requires 2^67
computations (over 3 to 1 equivalence) the cost of that is around $250000
using EC2. That's mafia kind of money, not NSA.

I trust RC4 as much as single DES - good against script kiddies.

> I think we should do all that's possible to avoid RC4.  I think that for
> now we should follow Microsoft in not having RC4 in the initial
> handshake and if fails retry with RC4 enabled.

yes, that would certainly help

>  It's my understanding
> that that should reduce RC4 usage from 20% of the sites to 1%.

that's correct

--
Regards,
Hubert Kario
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Road to RC4-free web (the case for YouTube without RC4)

Kurt Roeckx
In reply to this post by Kurt Roeckx
On 2014-06-30 12:20, Hubert Kario wrote:

>> From: "Kurt Roeckx" <[hidden email]>
>> On 2014-06-30 02:35, Hubert Kario wrote:
>>>
>>> I have to disagree here. Even 1024 bit DHE requires a targeted attack at
>>> ~80 bit
>>> complexity. Currently we see RC4 at around 56 bit, with a completely
>>> unoptimized
>>> attack...
>>
>> Do you have a reference for those 56 bit?
>
> My estimation.
>
> http://www.isg.rhul.ac.uk/tls/
> requires 2^30 sessions with 2^8 computations to recover full text.
> And it requires 2^24 sessions and 2^8 computations to recover some bytes.

Please note that those are 2^30 sessions with the same plain text.  That
is hopefully not done by just monitoring.

> Even if the equivalence is higher, capturing 2^10 of sessions won't
> require extended monitoring. If we then say that this then requires 2^67
> computations (over 3 to 1 equivalence) the cost of that is around $250000
> using EC2. That's mafia kind of money, not NSA.

As far as I know the attack is purely based on statistics.  Throwing
more CPU time at it won't suddenly change the statistics.  For the
attack to work you need more data not more CPU time.


Kurt

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Road to RC4-free web (the case for YouTube without RC4)

Hubert Kario
In reply to this post by Brian Smith-19
----- Original Message -----

> From: "Brian Smith" <[hidden email]>
> To: "mozilla's crypto code discussion list" <[hidden email]>
> Sent: Monday, 30 June, 2014 12:23:41 AM
> Subject: Re: Road to RC4-free web (the case for YouTube without RC4)
>
> On Sun, Jun 29, 2014 at 11:18 AM, Hubert Kario <[hidden email]> wrote:
>
> > Because of that, disabling RC4 should be possible for many users. The big
> > exception for that was YouTube video servers[4] which only recently gained
> > support for TLS_RSA_WITH_AES_128_GCM_SHA256.
> >
>
> Hi,
>
> I read your blog post at
> http://securitypitfalls.wordpress.com/2014/06/29/is-rc4-less, which is
> interesting. The blog post compares how enabling/disabling various cipher
> suites affects the percentage of sites that end up negotiating RC4.
> However, I noticed that you didn't measure how enabling/disabling various
> cipher suites affects how often Firefox uses ECDHE, DHE with a strong
> (>=1280 bit, at least), DHE with weak, or RSA key exchange.

If the question is, "does removing RC4 with adding extra ciphers gives up
PFS?", the answer is likely* yes, by 2%. But adding or removing ciphers
has small impact on PFS compared to the 20% elephant in the room.

 * - those are simulated handshakes using OpenSSL
     cipher order, so while AES to RC4 relation is
     maintained, the relation between AES128 and
     AES256 is not as well as relation between
     DHE-AES128 and AES256, so in reality connection
     using Firefox would likely end up with AES128
     cipher while the below order shows AES256 ciphers.
     Next month's data will include information
     if the server appears to use server cipher
     order or not so the simulations will match
     reality more closely.

If we use following cipher order:
        'ECDHE-ECDSA-AES128-GCM-SHA256',
        'ECDHE-RSA-AES128-GCM-SHA256',
        'ECDHE-ECDSA-AES256-SHA',
        'ECDHE-ECDSA-AES128-SHA',
        'ECDHE-RSA-AES128-SHA',
        'ECDHE-RSA-AES256-SHA',
        'ECDHE-RSA-DES-CBC3-SHA',
        'ECDHE-ECDSA-RC4-SHA',
        'ECDHE-RSA-RC4-SHA',
        'DHE-RSA-AES128-SHA',
        'DHE-DSS-AES128-SHA',
        'DHE-RSA-CAMELLIA128-SHA',
        'DHE-RSA-AES256-SHA',
        'DHE-DSS-AES256-SHA',
        'DHE-RSA-CAMELLIA256-SHA',
        'EDH-RSA-DES-CBC3-SHA',
        'AES128-SHA',
        'CAMELLIA128-SHA',
        'AES256-SHA',
        'CAMELLIA256-SHA',
        'DES-CBC3-SHA',
        'RC4-SHA',
        'RC4-MD5'

Then simulated handshakes end with:

Selected ciphers              Count    Percent
-----------------------------+---------+------
AES128-SHA                     23354     6.6545
AES256-SHA                     48262     13.7519
CAMELLIA128-SHA                2         0.0006
CAMELLIA256-SHA                188       0.0536
DES-CBC3-SHA                   996       0.2838
DHE-RSA-AES128-SHA             704       0.2006
DHE-RSA-AES256-SHA             105819    30.1522
DHE-RSA-CAMELLIA256-SHA        336       0.0957
ECDHE-ECDSA-AES128-GCM-SHA256  9192      2.6192
ECDHE-ECDSA-AES128-SHA         12        0.0034
ECDHE-ECDSA-RC4-SHA            1         0.0003
ECDHE-RSA-AES128-GCM-SHA256    40876     11.6473
ECDHE-RSA-AES128-SHA           172       0.049
ECDHE-RSA-AES256-SHA           45331     12.9167
ECDHE-RSA-DES-CBC3-SHA         252       0.0718
ECDHE-RSA-RC4-SHA              27726     7.9003
EDH-RSA-DES-CBC3-SHA           652       0.1858
RC4-MD5                        9344      2.6625
RC4-SHA                        37699     10.742
x:DHE                          107511    30.6344
x:ECDHE                        123562    35.208
x:kRSA                         119845    34.1488



Removing
        'ECDHE-ECDSA-RC4-SHA',
        'ECDHE-RSA-RC4-SHA',
Doesn't change the compatibility:

x:FF 29 incompatible      39        0.0111

causes the servers to select following ciphers:

Selected ciphers              Count    Percent
-----------------------------+---------+------
AES128-SHA                     23354     6.6545
AES256-SHA                     48262     13.7519
CAMELLIA128-SHA                2         0.0006
CAMELLIA256-SHA                188       0.0536
DES-CBC3-SHA                   996       0.2838
DHE-RSA-AES128-SHA             704       0.2006
DHE-RSA-AES256-SHA             105821    30.1528
DHE-RSA-CAMELLIA256-SHA        336       0.0957
ECDHE-ECDSA-AES128-GCM-SHA256  9192      2.6192
ECDHE-ECDSA-AES128-SHA         13        0.0037
ECDHE-RSA-AES128-GCM-SHA256    40878     11.6478
ECDHE-RSA-AES128-SHA           200       0.057
ECDHE-RSA-AES256-SHA           46972     13.3843
ECDHE-RSA-DES-CBC3-SHA         252       0.0718
EDH-RSA-DES-CBC3-SHA           652       0.1858
RC4-MD5                        9344      2.6625
RC4-SHA                        63744     18.1633
x:DHE                          107513    30.6349
x:ECDHE                        97507     27.7838
x:kRSA                         145890    41.5701

So about 0.5% servers did select better cipher,
mostly ECDHE-RSA-AES256-SHA*. But at the "cost"
of selecting non PFS suites (by 7.4%)



leaving RC4 in place but adding ECDHE-RSA-AES128-SHA256
causes the negotiated ciphers to look like this:

Selected ciphers              Count    Percent
-----------------------------+---------+------
AES128-SHA                     23347     6.6525
AES256-SHA                     48261     13.7516
CAMELLIA128-SHA                2         0.0006
CAMELLIA256-SHA                188       0.0536
DES-CBC3-SHA                   996       0.2838
DHE-RSA-AES128-SHA             703       0.2003
DHE-RSA-AES256-SHA             105815    30.1511
DHE-RSA-CAMELLIA256-SHA        336       0.0957
ECDHE-ECDSA-AES128-GCM-SHA256  9192      2.6192
ECDHE-ECDSA-AES128-SHA         12        0.0034
ECDHE-ECDSA-RC4-SHA            1         0.0003
ECDHE-RSA-AES128-GCM-SHA256    40839     11.6367
ECDHE-RSA-AES128-SHA           117       0.0333
ECDHE-RSA-AES128-SHA256        7456      2.1245
ECDHE-RSA-AES256-SHA           44696     12.7358
ECDHE-RSA-DES-CBC3-SHA         252       0.0718
ECDHE-RSA-RC4-SHA              21407     6.0997
EDH-RSA-DES-CBC3-SHA           652       0.1858
RC4-MD5                        9344      2.6625
RC4-SHA                        37302     10.6289
x:DHE                          107506    30.6329
x:ECDHE                        123972    35.3248
x:kRSA                         119440    34.0334

That not only makes the servers select more secure
cipher, it also decreases the number of non-PFS
connections by small amount.

If we add the rest of SHA256 ciphers we get the
following listing:

Selected ciphers              Count    Percent
-----------------------------+---------+------
AES128-GCM-SHA256              1540      0.4388
AES128-SHA                     18898     5.3848
AES128-SHA256                  4436      1.264
AES256-SHA                     42657     12.1548
AES256-SHA256                  10724     3.0557
CAMELLIA128-SHA                1         0.0003
CAMELLIA256-SHA                173       0.0493
DES-CBC3-SHA                   988       0.2815
DHE-RSA-AES128-GCM-SHA256      1482      0.4223
DHE-RSA-AES128-SHA             314       0.0895
DHE-RSA-AES128-SHA256          3         0.0009
DHE-RSA-AES256-SHA             75470     21.5045
DHE-RSA-AES256-SHA256          30620     8.7249
DHE-RSA-CAMELLIA256-SHA        295       0.0841
ECDHE-ECDSA-AES128-GCM-SHA256  9192      2.6192
ECDHE-ECDSA-AES128-SHA         12        0.0034
ECDHE-ECDSA-RC4-SHA            1         0.0003
ECDHE-RSA-AES128-GCM-SHA256    36095     10.285
ECDHE-RSA-AES128-SHA           117       0.0333
ECDHE-RSA-AES128-SHA256        6795      1.9362
ECDHE-RSA-AES256-SHA           44608     12.7107
ECDHE-RSA-DES-CBC3-SHA         252       0.0718
ECDHE-RSA-RC4-SHA              21109     6.0148
EDH-RSA-DES-CBC3-SHA           651       0.1855
RC4-MD5                        8890      2.5331
RC4-SHA                        35597     10.1431
x:DHE                          108835    31.0116
x:ECDHE                        118181    33.6747
x:kRSA                         123904    35.3054

So while we don't gain on PFS front, we gain on RC4.



Disabling ECDHE+RC4 with SHA256 enabled paints
following picture:

Selected ciphers              Count    Percent
-----------------------------+---------+------
AES128-GCM-SHA256              1540      0.4388
AES128-SHA                     18898     5.3848
AES128-SHA256                  4436      1.264
AES256-SHA                     42657     12.1548
AES256-SHA256                  10724     3.0557
CAMELLIA128-SHA                1         0.0003
CAMELLIA256-SHA                173       0.0493
DES-CBC3-SHA                   988       0.2815
DHE-RSA-AES128-GCM-SHA256      1482      0.4223
DHE-RSA-AES128-SHA             314       0.0895
DHE-RSA-AES128-SHA256          3         0.0009
DHE-RSA-AES256-SHA             75472     21.5051
DHE-RSA-AES256-SHA256          30620     8.7249
DHE-RSA-CAMELLIA256-SHA        295       0.0841
ECDHE-ECDSA-AES128-GCM-SHA256  9192      2.6192
ECDHE-ECDSA-AES128-SHA         13        0.0037
ECDHE-RSA-AES128-GCM-SHA256    36097     10.2855
ECDHE-RSA-AES128-SHA           140       0.0399
ECDHE-RSA-AES128-SHA256        6797      1.9367
ECDHE-RSA-AES256-SHA           46247     13.1777
ECDHE-RSA-DES-CBC3-SHA         252       0.0718
EDH-RSA-DES-CBC3-SHA           651       0.1855
RC4-MD5                        8890      2.5331
RC4-SHA                        55031     15.6806
x:DHE                          108837    31.0122
x:ECDHE                        98738     28.1346
x:kRSA                         143338    40.843


Disabling RC4 completely with SHA256 enabled gives
following statistics:

Selected ciphers              Count    Percent
-----------------------------+---------+------
AES128-GCM-SHA256              1549      0.4414
AES128-SHA                     37431     10.6657
AES128-SHA256                  6244      1.7792
AES256-SHA                     47065     13.4108
AES256-SHA256                  12504     3.5629
CAMELLIA128-SHA                2         0.0006
CAMELLIA256-SHA                14917     4.2505
DES-CBC3-SHA                   8558      2.4385
DHE-RSA-AES128-GCM-SHA256      1482      0.4223
DHE-RSA-AES128-SHA             329       0.0937
DHE-RSA-AES128-SHA256          3         0.0009
DHE-RSA-AES256-SHA             79680     22.7042
DHE-RSA-AES256-SHA256          31581     8.9987
DHE-RSA-CAMELLIA256-SHA        726       0.2069
ECDHE-ECDSA-AES128-GCM-SHA256  9192      2.6192
ECDHE-ECDSA-AES128-SHA         13        0.0037
ECDHE-RSA-AES128-GCM-SHA256    36099     10.2861
ECDHE-RSA-AES128-SHA           219       0.0624
ECDHE-RSA-AES128-SHA256        6811      1.9407
ECDHE-RSA-AES256-SHA           51919     14.7939
ECDHE-RSA-DES-CBC3-SHA         312       0.0889
EDH-RSA-DES-CBC3-SHA           668       0.1903
x:DHE                          114469    32.617
x:ECDHE                        104565    29.7949
x:kRSA                         128270    36.5495

So we give up about 2% of PFS and gain 2% of DHE
for those 20% of RC4.

--
Regards,
Hubert Kario
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Road to RC4-free web (the case for YouTube without RC4)

Hubert Kario
In reply to this post by Kurt Roeckx
----- Original Message -----

> From: "Kurt Roeckx" <[hidden email]>
> To: [hidden email]
> Sent: Monday, 30 June, 2014 1:57:33 PM
> Subject: Re: Road to RC4-free web (the case for YouTube without RC4)
>
> On 2014-06-30 12:20, Hubert Kario wrote:
> >> From: "Kurt Roeckx" <[hidden email]>
> >> On 2014-06-30 02:35, Hubert Kario wrote:
> >>>
> >>> I have to disagree here. Even 1024 bit DHE requires a targeted attack at
> >>> ~80 bit
> >>> complexity. Currently we see RC4 at around 56 bit, with a completely
> >>> unoptimized
> >>> attack...
> >>
> >> Do you have a reference for those 56 bit?
> >
> > My estimation.
> >
> > http://www.isg.rhul.ac.uk/tls/
> > requires 2^30 sessions with 2^8 computations to recover full text.
> > And it requires 2^24 sessions and 2^8 computations to recover some bytes.
>
> Please note that those are 2^30 sessions with the same plain text.  That
> is hopefully not done by just monitoring.

It requires static/same plain text only at certain positions.

This is the case for at least some HTTP headers.

The attack also doesn't exploit the fact that some parts of message are
known or are easy to guess for the attacker.

"However, it is a truism that attacks only get better with time, and we
anticipate significant further improvements to our attacks."

> > Even if the equivalence is higher, capturing 2^10 of sessions won't
> > require extended monitoring. If we then say that this then requires 2^67
> > computations (over 3 to 1 equivalence) the cost of that is around $250000
> > using EC2. That's mafia kind of money, not NSA.
>
> As far as I know the attack is purely based on statistics.  Throwing
> more CPU time at it won't suddenly change the statistics.  For the
> attack to work you need more data not more CPU time.

Not entirely, the statistics provide the likely values for bytes. Then the
attack uses those 2^8 operations to guess the values. With 2^30 sessions
you get 100% recovery rate for first few hundred bytes, with 2^24 sessions
you get above 90% for few selected bytes.

In essence, the attack is an oracle aiding brute force search.
--
Regards,
Hubert Kario
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Road to RC4-free web (the case for YouTube without RC4)

Brian Smith-19
In reply to this post by Hubert Kario
On Sun, Jun 29, 2014 at 5:35 PM, Hubert Kario <[hidden email]> wrote:

>
> > As I noted in my bug comment [1], I think that the rhetoric of us not
> > adding any more RSA-key-exchange-based cipher suites, even the AES-GCM
> > ones, is significant. Software engineers at multiple companies referenced
> > our positions on this as part of making the business case for raising the
> > priority of ECDHE support in their products.
>
> I fail to see how changing /non default/ settings affects that.
>

Some Linux distros may be tempted to change their default Firefox
configuration files so that a different set of cipher suites is enabled by
default. I am very opposed to that, and that's one of the biggest reasons
why particularly in PSM I discourage preferences.


> I mean, I've been surfing with disallowed pictures for mixed content
> (security.mixed_content.block_display_content). You'd be surprised at
> amount
> of sites that break because of that. Disabled JavaScript is similar.
> Webmasters make sites and configure servers against the lowest common
> denominator: it works, then the work is done. They don't check what
> happens if
> the user is running non standard configuration. I've never seen a website
> that said to the user to modify the settings in about:config to make the
> site work as intended.
>

If it were up to me, we wouldn't have either of the block_display_content
or disable-Javascript preferences either.

Also, see Gavin's email here about adding such prefs in general. He
basically says, "Don't do it." Note that Gavin is the Firefox module owner:
https://groups.google.com/d/msg/mozilla.dev.platform/PL1tecuO0KA/e9BbmUAcRrwJ


> 20% of Internet servers negotiating suboptimal ciphers is not *really bad*?
> How much do we have to reach for that to be a problem?
>

It would be better to have less (no) RC4 usage but I don't think it is as
urgent of a problem as you seem to. Also, I feel like it is really not a
great use of time to re-open the debate about adding support for
about-to-be-deprecated cipher suites to Firefox. In the short term, things
are going to be suboptimal but we're far from disabling RC4 by default, and
the default configuration is really what we care about.

I am interested in discussing what we can do to help more server side
products get better cipher suites by default, and on deciding whether we
add support for ChaCha20-Poly1304, but otherwise I think we should table
the discussion until more server-side products and more servers have had
sufficient time to react to what we've already decided.

Cheers,
Brian
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Road to RC4-free web (the case for YouTube without RC4)

Brian Smith-19
In reply to this post by Kurt Roeckx
On Mon, Jun 30, 2014 at 1:56 AM, Kurt Roeckx <[hidden email]> wrote:

> On 2014-06-30 02:35, Hubert Kario wrote:
>
>> The benefits of ECDHE outweigh the risks of using RC4,
>>>
>>
>> I have to disagree here. Even 1024 bit DHE requires a targeted attack at
>> ~80 bit
>> complexity. Currently we see RC4 at around 56 bit, with a completely
>> unoptimized
>> attack...
>>
>
> Do you have a reference for those 56 bit?  You're not talking about the
> old export ciphers I hope?  I haven't seen anything saying that the 128 bit
> RC4 has a complexity of 56 bit.  If it's really at 56 bit, we should
> disable it everywhere now, no matter if it breaks things or not.
>
> I think we should do all that's possible to avoid RC4.  I think that for
> now we should follow Microsoft in not having RC4 in the initial handshake
> and if fails retry with RC4 enabled.  It's my understanding that that
> should reduce RC4 usage from 20% of the sites to 1%.
>

I would welcome a patch that does that. I think initially we should do it
without disabling TLS_ECDHE_*_WITH_RC4_*, instead only disabling
TLS_RSA_WITH_RC4_*, so that we don't push sites that choose
TLS_ECDHE_*_WITH_RC4_* to using non-ephemeral key exchange. I think, in
parallel with that, we can figure out why so many sites are still using
TLS_ECDHE_*_WITH_RC4_* instead of TLS_ECDHE_*_WITH_AES* and start the
technical evangelism efforts to help them.

Cheers,
Brian
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Road to RC4-free web (the case for YouTube without RC4)

Julien Pierre-3
Brian,

On 7/1/2014 14:05, Brian Smith wrote:
> I think, in parallel with that, we can figure out why so many sites
> are still using TLS_ECDHE_*_WITH_RC4_* instead of
> TLS_ECDHE_*_WITH_AES* and start the technical evangelism efforts to
> help them. Cheers, Brian
The reason for sites choosing RC4 over AES_CBC might be due to the
various vulnerabilities against CBC mode, at least for sites that
support TLS 1.0 .
I think a more useful form of evangelism would be to get sites to stop
accepting SSL 3.0 and TLS 1.0 protocols.

Julien

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Road to RC4-free web (the case for YouTube without RC4)

Hubert Kario
In reply to this post by Brian Smith-19
----- Original Message -----

> From: "Brian Smith" <[hidden email]>
> To: "mozilla's crypto code discussion list" <[hidden email]>
> Sent: Tuesday, 1 July, 2014 10:58:27 PM
> Subject: Re: Road to RC4-free web (the case for YouTube without RC4)
>
> On Sun, Jun 29, 2014 at 5:35 PM, Hubert Kario <[hidden email]> wrote:
>
> >
> > > As I noted in my bug comment [1], I think that the rhetoric of us not
> > > adding any more RSA-key-exchange-based cipher suites, even the AES-GCM
> > > ones, is significant. Software engineers at multiple companies referenced
> > > our positions on this as part of making the business case for raising the
> > > priority of ECDHE support in their products.
> >
> > I fail to see how changing /non default/ settings affects that.
> >
>
> Some Linux distros may be tempted to change their default Firefox
> configuration files so that a different set of cipher suites is enabled by
> default. I am very opposed to that, and that's one of the biggest reasons
> why particularly in PSM I discourage preferences.

One of the main reasons so many people choose Firefox over Chrome, is still
the amount of extensions that are available to them to customize the
behaviour of the browser. Removing options won't help us gain more users.

Even if some distributions do plan to change crypto policy of all the
applications[1], I don't see how this (if applied consistently against
all applications) is a bad thing.

> > I mean, I've been surfing with disallowed pictures for mixed content
> > (security.mixed_content.block_display_content). You'd be surprised at
> > amount
> > of sites that break because of that. Disabled JavaScript is similar.
> > Webmasters make sites and configure servers against the lowest common
> > denominator: it works, then the work is done. They don't check what
> > happens if
> > the user is running non standard configuration. I've never seen a website
> > that said to the user to modify the settings in about:config to make the
> > site work as intended.
> >
>
> If it were up to me, we wouldn't have either of the block_display_content
> or disable-Javascript preferences either.

Except that having such options does stop real attacks. Nearly all exploits
use JavaScript in one form or another. Bugs in JPEG parsers do happen
(CVE-2012-2806), so it's not really "safe" content.

Some people may have requirements to have higher security. Even if only
so that they can spot such errors more easily and notify webmasters.
 
> Also, see Gavin's email here about adding such prefs in general. He
> basically says, "Don't do it." Note that Gavin is the Firefox module owner:
> https://groups.google.com/d/msg/mozilla.dev.platform/PL1tecuO0KA/e9BbmUAcRrwJ

"As Benjamin notes,
an add-on is a much better way to suggest people customize these
things, and writing an add-on that sets a pref is trivial."

So you'd accept code that is able to change this preference but doesn't
expose it through about:config?

I'm more that willing to create such patchset and extension pair.

> > 20% of Internet servers negotiating suboptimal ciphers is not *really bad*?
> > How much do we have to reach for that to be a problem?
> >
>
> It would be better to have less (no) RC4 usage but I don't think it is as
> urgent of a problem as you seem to. Also, I feel like it is really not a
> great use of time to re-open the debate about adding support for
> about-to-be-deprecated cipher suites to Firefox.

deprecating a cipher/html tag/operating system doesn't make it go away

> I am interested in discussing what we can do to help more server side
> products get better cipher suites by default, and on deciding whether we
> add support for ChaCha20-Poly1304, but otherwise I think we should table
> the discussion until more server-side products and more servers have had
> sufficient time to react to what we've already decided.

if the rate of change in RC4-only servers is any indication, the percentage
of servers that effectively negotiate RC4 will remain in double digits
for next 5 years at least

 1 - https://fedoraproject.org/wiki/Changes/CryptoPolicy

--
Regards,
Hubert Kario
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Road to RC4-free web (the case for YouTube without RC4)

Hubert Kario
In reply to this post by Julien Pierre-3
----- Original Message -----

> From: "Julien Pierre" <[hidden email]>
> To: "mozilla's crypto code discussion list" <[hidden email]>
> Cc: [hidden email]
> Sent: Wednesday, 2 July, 2014 4:15:15 AM
> Subject: Re: Road to RC4-free web (the case for YouTube without RC4)
>
> Brian,
>
> On 7/1/2014 14:05, Brian Smith wrote:
> > I think, in parallel with that, we can figure out why so many sites
> > are still using TLS_ECDHE_*_WITH_RC4_* instead of
> > TLS_ECDHE_*_WITH_AES* and start the technical evangelism efforts to
> > help them. Cheers, Brian
> The reason for sites choosing RC4 over AES_CBC might be due to the
> various vulnerabilities against CBC mode, at least for sites that
> support TLS 1.0 .

problem is that to support AES-GCM and ECDHE you need the very newest
both Apache and OpenSSL.

If you have older Apache, you do get TLS 1.2 and you do get SHA-256
suites, but you can't use ECDHE.

You also can't set different cipher order for TLS1.1 and up and TLS1.0
and lower.

So a server that has order like this:
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES128-SHA256
AES128-GCM-SHA256
AES128-SHA256
RC4-SHA
DHE-RSA-AES128-SHA
AES128-SHA

will negotiate RC4 with Firefox. Such configuration has about 2% of
servers.
--
Regards,
Hubert Kario
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Road to RC4-free web (the case for YouTube without RC4)

Brian Smith-19
In reply to this post by Julien Pierre-3
On Tue, Jul 1, 2014 at 7:15 PM, Julien Pierre <[hidden email]>
wrote:

> On 7/1/2014 14:05, Brian Smith wrote:
>
>> I think, in parallel with that, we can figure out why so many sites are
>> still using TLS_ECDHE_*_WITH_RC4_* instead of TLS_ECDHE_*_WITH_AES* and
>> start the technical evangelism efforts to help them. Cheers, Brian
>>
> The reason for sites choosing RC4 over AES_CBC might be due to the various
> vulnerabilities against CBC mode, at least for sites that support TLS 1.0 .
> I think a more useful form of evangelism would be to get sites to stop
> accepting SSL 3.0 and TLS 1.0 protocols.
>

Servers that cannot, for whatever reason, support the AES-GCM cipher
suites, should be changed to prefer AES-CBC cipher suites over RC4-based
cipher suites at least for TLS 1.1 and later.

Most sites are not going to stop accepting SSL 3.0 and/or TLS 1.0 any time
soon, because they want to be compatible with Internet Explorer on Windows
XP and other software that doesn't support TLS 1.1+.

However, in the IETF, there is an effort, spearheaded by our friends at
Google, for solving the downgrade problem:
http://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00

This simple feature, if implemented by the browser and by the server,
allows the server to recognize that the browser has tried a non-secure
downgrade to a lower version of TLS. Once the server recognizes that, the
server can reject the downgraded connection. The net effect is that,
assuming modern browsers quickly add support for this mechanism, the server
can be ensure that it only uses CBC cipher suites with modern browsers over
TLS 1.1 or later and that it never uses RC4-based cipher suites with modern
browsers (in conjunction with the "prefer AES-CBC cipher suites over RC4
cipher suites" change I suggest above).

However, it is likely that crypto libraries that make the two changes above
will also have support for TLS_ECDHE_*_WITH_AES_*_GCM cipher suites too.
So, I hope that they also enable TLS_ECDHE_*_WITH_AES_*_GCM at the same
time they deploy these changes.

FWIW, I filed bugs [1][2] for adding support for
draft-ietf-tls-downgrade-scsv-00 to NSS, Gecko, and Firefox.

Cheers,
Brian

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1036737
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1036735
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Road to RC4-free web (the case for YouTube without RC4)

Brian Smith-19
In reply to this post by Hubert Kario
On Wed, Jul 2, 2014 at 5:28 AM, Hubert Kario <[hidden email]> wrote:

> > On 7/1/2014 14:05, Brian Smith wrote:
> > > I think, in parallel with that, we can figure out why so many sites
> > > are still using TLS_ECDHE_*_WITH_RC4_* instead of
> > > TLS_ECDHE_*_WITH_AES* and start the technical evangelism efforts to
> > > help them. Cheers, Brian
> > The reason for sites choosing RC4 over AES_CBC might be due to the
> > various vulnerabilities against CBC mode, at least for sites that
> > support TLS 1.0 .
>
> problem is that to support AES-GCM and ECDHE you need the very newest
> both Apache and OpenSSL.
>

> If you have older Apache, you do get TLS 1.2 and you do get SHA-256
> suites, but you can't use ECDHE.
>

It depends on what distro you are using and how old of an Apache you are
talking about. Debian has shown it is relatively straightforward to
backport ECDHE support to Apache 2.2.x, so I think other distros will also
be able to do so. I'm sure it isn't a trivial effort, but it is definitely
worthwhile to do so.


> You also can't set different cipher order for TLS1.1 and up and TLS1.0
> and lower.
>

The software can be changed to add this feature, and those changes can be
backported.


> So a server that has order like this:
> DHE-RSA-AES128-GCM-SHA256
> DHE-RSA-AES128-SHA256
> AES128-GCM-SHA256
> AES128-SHA256
> RC4-SHA
> DHE-RSA-AES128-SHA
> AES128-SHA
>
> will negotiate RC4 with Firefox. Such configuration has about 2% of
> servers.
>

I understand. But, I think the best way of accommodating those servers is
for the server software vendor to provide an (semi-)automatic update that
enables the TLS_ECDHE_*_WITH_AES*_GCM_* cipher suites.

Cheers,
Brian
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Road to RC4-free web (the case for YouTube without RC4)

Brian Smith-19
In reply to this post by Hubert Kario
On Wed, Jul 2, 2014 at 5:08 AM, Hubert Kario <[hidden email]> wrote:

> Also, see Gavin's email here about adding such prefs in general. He
> > basically says, "Don't do it." Note that Gavin is the Firefox module
> owner:
> >
> https://groups.google.com/d/msg/mozilla.dev.platform/PL1tecuO0KA/e9BbmUAcRrwJ
>
> "As Benjamin notes,
> an add-on is a much better way to suggest people customize these
> things, and writing an add-on that sets a pref is trivial."
>
> So you'd accept code that is able to change this preference but doesn't
> expose it through about:config?
>
> I'm more that willing to create such patchset and extension pair.
>

It is already possible to write such an extension without any new Firefox
APIs, because extensions can call NSS functions.

Cheers,
Brian
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Road to RC4-free web (the case for YouTube without RC4)

Kurt Roeckx
In reply to this post by Julien Pierre-3
On 2014-07-10 02:40, Brian Smith wrote:
> FWIW, I filed bugs [1][2] for adding support for
> draft-ietf-tls-downgrade-scsv-00 to NSS, Gecko, and Firefox.

Maybe you should also file such bugs with OpenSSL and GnuTLS?


Kurt


--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Road to RC4-free web (the case for YouTube without RC4)

Hubert Kario
In reply to this post by Brian Smith-19
----- Original Message -----

> From: "Brian Smith" <[hidden email]>
> To: "mozilla's crypto code discussion list" <[hidden email]>
> Sent: Thursday, 10 July, 2014 3:02:34 AM
> Subject: Re: Road to RC4-free web (the case for YouTube without RC4)
>
> On Wed, Jul 2, 2014 at 5:08 AM, Hubert Kario <[hidden email]> wrote:
>
> > Also, see Gavin's email here about adding such prefs in general. He
> > > basically says, "Don't do it." Note that Gavin is the Firefox module
> > owner:
> > >
> > https://groups.google.com/d/msg/mozilla.dev.platform/PL1tecuO0KA/e9BbmUAcRrwJ
> >
> > "As Benjamin notes,
> > an add-on is a much better way to suggest people customize these
> > things, and writing an add-on that sets a pref is trivial."
> >
> > So you'd accept code that is able to change this preference but doesn't
> > expose it through about:config?
> >
> > I'm more that willing to create such patchset and extension pair.
> >
>
> It is already possible to write such an extension without any new Firefox
> APIs, because extensions can call NSS functions.

Can you point me in the direction of how to do that?

Also, won't it require native code?

--
Regards,
Hubert Kario
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Road to RC4-free web (the case for YouTube without RC4)

Henri Sivonen-2
In reply to this post by Hubert Kario
On Tue, Jul 1, 2014 at 11:58 PM, Brian Smith <[hidden email]> wrote:
> I am interested in discussing what we can do to help more server side
> products get better cipher suites by default, and on deciding whether we
> add support for ChaCha20-Poly1304

Out of curiosity, what's holding back a decision to implement
ChaCha20-Poly1305?

--
Henri Sivonen
[hidden email]
https://hsivonen.fi/
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Road to RC4-free web (the case for YouTube without RC4)

Hubert Kario
In reply to this post by Brian Smith-19
----- Original Message -----

> From: "Brian Smith" <[hidden email]>
> To: "mozilla's crypto code discussion list" <[hidden email]>
> Cc: [hidden email]
> Sent: Thursday, 10 July, 2014 2:40:55 AM
> Subject: Re: Road to RC4-free web (the case for YouTube without RC4)
>
> On Tue, Jul 1, 2014 at 7:15 PM, Julien Pierre <[hidden email]>
> wrote:
>
> > On 7/1/2014 14:05, Brian Smith wrote:
> >
> >> I think, in parallel with that, we can figure out why so many sites are
> >> still using TLS_ECDHE_*_WITH_RC4_* instead of TLS_ECDHE_*_WITH_AES* and
> >> start the technical evangelism efforts to help them. Cheers, Brian
> >>
> > The reason for sites choosing RC4 over AES_CBC might be due to the various
> > vulnerabilities against CBC mode, at least for sites that support TLS 1.0 .
> > I think a more useful form of evangelism would be to get sites to stop
> > accepting SSL 3.0 and TLS 1.0 protocols.
> >
>
> Servers that cannot, for whatever reason, support the AES-GCM cipher
> suites, should be changed to prefer AES-CBC cipher suites over RC4-based
> cipher suites at least for TLS 1.1 and later.
>
> Most sites are not going to stop accepting SSL 3.0 and/or TLS 1.0 any time
> soon, because they want to be compatible with Internet Explorer on Windows
> XP and other software that doesn't support TLS 1.1+.
>
> However, in the IETF, there is an effort, spearheaded by our friends at
> Google, for solving the downgrade problem:
> http://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00
>
> This simple feature, if implemented by the browser and by the server,
> allows the server to recognize that the browser has tried a non-secure
> downgrade to a lower version of TLS. Once the server recognizes that, the
> server can reject the downgraded connection. The net effect is that,
> assuming modern browsers quickly add support for this mechanism, the server
> can be ensure that it only uses CBC cipher suites with modern browsers over
> TLS 1.1 or later and that it never uses RC4-based cipher suites with modern
> browsers (in conjunction with the "prefer AES-CBC cipher suites over RC4
> cipher suites" change I suggest above).
>
> However, it is likely that crypto libraries that make the two changes above
> will also have support for TLS_ECDHE_*_WITH_AES_*_GCM cipher suites too.
> So, I hope that they also enable TLS_ECDHE_*_WITH_AES_*_GCM at the same
> time they deploy these changes.
>
> FWIW, I filed bugs [1][2] for adding support for
> draft-ietf-tls-downgrade-scsv-00 to NSS, Gecko, and Firefox.

What basis do you have to assume that server administrators will actually
upgrade their Apache/nginx/lighttpd/OpenSSL/etc. installations?

There are many installation that still haven't fixed their servers after
Heartbleed (0.5%) or the CCS vulnerability (9%)[1]!
Over 1% of servers still support SSL3 only[2]!

 1 - https://www.trustworthyinternet.org/ssl-pulse/
 2 - http://wp.me/p4BPwe-x
--
Regards,
Hubert Kario
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
12