Increasing the minimum TLS DH group size to 1024 bits.

[Adam Langley]

Earlier today a group from INRIA, Microsoft Research, John’s Hopkin’s,
the University of Michigan and the University of Pennsylvania
published work (https://weakdh.org) that they have done on exploiting
TLS (i.e. HTTPS) servers configured with weak Diffie-Hellman groups.

We would like to thank them for this work and for briefing us
beforehand. Based on their work, we disabled TLS False-Start with
Diffie-Hellman in Chrome 42, which has been the stable version for
many weeks now. This will make their attack on vulnerable servers
slightly harder.

Many years ago, Chrome was the first browser to make 512 bits the
minimum Diffie-Hellman group size because several sites were using
256-bit groups at the time. Although the issues raised in today’s
paper are fundamentally server configuration issues, we do believe
that we should try to improve the TLS ecosystem where we can. Because
of that, we will shortly[1] be changing the trunk build of Chrome to
make 1024 bits the new minimum DH size. Although this will cause
problems for some sites, today’s work shows that we shouldn’t be
treating such sites as secure anyway.

This change is on track to be included in Chrome 45, although we may
backport it to earlier release branches depending on how bad any
breakage is.

The 1024-bit minimum isn’t sufficient for the long-term.
Unfortunately, because some existing clients don’t support DH groups
larger than 1024 bits, and because TLS doesn’t negotiate specific
groups, it would be very problematic to push this limit above 1024.
Since we are nearing the elimination of 1024-bit RSA, we are looking
questioningly at the whole notion of supporting non-elliptic-curve DHE
in TLS.

Thus servers that are currently using DHE should update to support
ECDHE. If that’s not possible then at least use 1024-bit DHE and don’t
be too surprised if Chrome starts using plain RSA with your site in
the future.

(There does exist a draft specification for negotiating DHE groups in
TLS[2] and, if adopted, that would solve the problem. However, that’s
still a draft while ECDHE support is already widely implemented.)

On the server side, Google products like Search, Gmail etc have never
supported DHE and use ECDHE for forward security.


Cheers

AGL


[1] https://boringssl-review.googlesource.com/#/c/4813
[2] https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-08

[yuhong...@hotmail.com]

I suggest a 768-bit minimum for now, because of Java. As a side note, the latest IcedTea 6/7 release allow 1024-bit DHE but it is not enabled by default.

[Ryan Sleevi]

On May 19, 2015 10:46 PM, <zlb...@gmail.com> wrote:
>
> I suggest a 768-bit minimum for now, because of Java. As a side note, the latest IcedTea 6/7 release allow 1024-bit DHE but it is not enabled by default.

We are aware, but as Adam said in original message:

"Although this will cause problems for some sites, today’s work shows that we shouldn’t be treating such sites as secure anyway."

"The 1024-bit minimum isn’t sufficient for the long-term."

Ultimately, even 1024-bit is questionable in the face of nation-state adversaries, as demonstrated by the paper and related research. However, it is the minimum most browsers are moving to in the short-term.

Ultimately, if you run one if these Java 6/7 servers, your users are at an unacceptably high security risk, and it would be misleading to suggest to users that things are OK.

[Yuhong Bao]

Yea, I know that 768-bit DHE will need to be killed eventually.

[rajkris...@gmail.com]

[shafe...@gmail.com]

dear why sites is very week not support high web sites that is beg problems for support me thnx

[snagen...@gmail.com]

[sriman...@gmail.com]

THE SERVES HAS WEEK PLEASE PROVIDE STRONG NETWORK

[rupesh.m...@gmail.com]

On Wednesday, May 20, 2015 at 8:42:11 AM UTC+5:30, Adam Langley wrote:

what slow network

[rongobbm...@gmail.com]

Please would I be guided to do away with this error in our machines? Server has a weak ephemeral Diffie-Hellman public key

[David Benjamin]

On Tue, Jul 28, 2015 at 1:27 AM <rongobbm...@gmail.com> wrote:

Please would I be guided to do away with this error in our machines? Server has a weak ephemeral Diffie-Hellman public key

 This is a problem with the server, so you need to fix your server's configuration. That depends on the software your server is running.

The best option is to disable DHE cipher suites. They're really not worth salvaging, so you should configure ECDHE ciphers. If that isn't an option, you need to configure a larger group size.

[kocma...@gmail.com]

This is amazing, but Chrome still supports weak DH subgroups:
https://dh-small-subgroup.badssl.com/

[PhistucK]

Chrome 45 (currently in beta) deprecates it. Soon, it will not be supported

☆PhistucK

On Tue, Jul 28, 2015 at 6:42 PM, <kocma...@gmail.com> wrote:

This is amazing, but Chrome still supports weak DH subgroups:
https://dh-small-subgroup.badssl.com/

To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.

[David Benjamin]

On Tue, Jul 28, 2015 at 11:45 AM PhistucK <phis...@gmail.com> wrote:

Chrome 45 (currently in beta) deprecates it. Soon, it will not be supported

No it doesn't. This is something else.
 

On Tue, Jul 28, 2015 at 6:42 PM, <kocma...@gmail.com> wrote:

This is amazing, but Chrome still supports weak DH subgroups:
https://dh-small-subgroup.badssl.com/

DHE in TLS is fundamentally flawed because the server picks the group by fiat (signed, of course). They may pick a small subgroup, they may even select a non-prime.

Any problem with the server's choice of group, be it a small subgroup or even Logjam, is a server problem. The client is not in a position to perform arbitrary checks on the group. We enforce minimum prime size because using tiny primes turns out to be common and we can try to weed out the egregiously bad configurations. Adding random extra checks in hopes of covering everything is futile. (Even a primality check is too expensive.)

The right way to do this is for the client to offer a list of known groups that it accepts. ECDHE in TLS works this way. As Adam noted in his mail, servers should switch to that. There is really no reason to deploy DHE at this point.

David

[PhistucK]

Oh, sorry - what is the difference between -

"Increasing the minimum TLS DH group size to 1024 bits"

And -

"deprecating the use of keys smaller than 1024 bits in Diffie-Hellman key exchange"

(And -

"weak DH subgroups")?

Everything but "1025 bits" and "DH"? ;)

☆PhistucK

[David Benjamin]

Diffie-Hellman is performed on a group and an element of the group. In the case of DHE, the group is multiplication over integers modulo some prime. Your security depends, among other things, on the size of the subgroup generated by that element. If you're actively trying to misconfigure your server, you can pick a dumb base that gives a small subgroup, despite the prime being large. (For instance, a base of p-1 will give you a subgroup of size two, and so DHE will only ever generate one of two keys. A base of 1 is even more comical.)

Again, this all falls under the "the server is misconfigured" category. The only reason to check any of these is if some misconfiguration is common enough that it's worth weeding it out. The DHE construct in TLS makes it impractical to do any better, and servers should be using ECDHE anyway.

Some relevant Wikipedia articles:
https://en.wikipedia.org/wiki/Group_(mathematics)
https://en.wikipedia.org/wiki/Generating_set_of_a_group
https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange#Security

David

[kaushal...@gmail.com]

ihave the same problem please rectify it

[monik...@gmail.com]

i have same problem pls rectfy

[om.kam...@gmail.com]

[woosl...@gmail.com]

Having same problem, please fix it

[Yuhong Bao]

Can you provide more detail?

[lalucha...@gmail.com]

https://mfin.chhimekbank.org:8080/mfin/faces/collectionSheet/List.xhtml

[gioth...@gmail.com]

MI STATE COSTRINGENDO A CAMBIARE BROWSER!!!!!!!!!!!!!
Poichè:

Il server ha una chiave pubblica Diffie-Hellman effimera e vulnerabile
ERR_SSL_WEAK_SERVER_EPHEMERAL_DH_KEY

Ed io per lavoro utilizzo questo server. Volete proprio perdere i vostri clienti e i vostri usuali utilizzatori. Vi prego di permettere di abilitare SINGOLARMENTE ogni permissione su qualsiasi sito web che il client desidera visitare. Bloccare alla fonte è inaccettabile, ok siete bravi che avete trovato la chiave Diffie-Hellman? Ok io voglio procedere ugualmente e devo poterlo fare.

In alternativa mi dovrò rivolgere ad altri servizi che mi permettono di raggiungere il sito web desiderato

[Georg]

Il giorno giovedì 3 settembre 2015 12:20:03 UTC+2, gioth...@gmail.com ha scritto:
> MI STATE COSTRINGENDO A CAMBIARE BROWSER!!!!!!!!!!!!!
> Poichè:

It's better to use mozilla, they are more professionals . Mozilla settings can be changed without problem. From config:flags change from true to false security.ssl3.dhe_rsa_aes_128_sha and security.ssl3.dhe_rsa_aes_256_sha

[bespaent...@gmail.com]

The problem is pathetic

[Giorgia Antonellini]

@Georg: Chrome è il migliore, ne sono sempre stata convinta, Firefox non è di mio gradimento e io vorrei lavorare con quello che ritengo il meglio. Btw ho già rimpiazzato utilizzando un altro browser, poichè necessariamente devo raggiungere quel server per motivi lavorativi. 

@bespaenterprises: "Pathetic" è la tua risposta da chi si sente tre gradini più in alto degli altri. Scendi dal trono e cammina come le altre persone perchè quando la stessa problematica succederà a te, si faranno tutti delle belle risate. 

Il mio messaggio di stamattina era palesemente guidato da sconforto e rabbia, sono una pasionaria e mi dispiace che i tuoi toni di fronte alle problematiche si riducano a giudizi sentenziosi e calati da chissà quale virtù. 

Ringrazio per l'attenzione

Buon lavoro

2015-09-03 14:52 GMT+02:00 <bespaent...@gmail.com>:

The problem is pathetic

[Georg]

Chrome è solo il più veloce .... quanto a completezza mozilla è imbattibile, sempre tenendo presente che nella maggior parte dei siti governativi (che per chi ci lavora sono i più importanti) internet explorer è lo standard ufficiale (su alcuni di questi siti è impossibile navigare con gli altri due). Comunque le problematiche generate da chi rilascia le nuove versioni di Chrome (dove non è possibile disattivare l'update) rilevano una superficialità e un modo dilettantesco di lavorare. Forse il target dei clienti di Google Chrome sono gli sfaccendati che utilizzano il computer per motivi ludici. La prossima volta inseriranno un web filtering incorporato in maniera da selezionare i siti web che possono essere consultati.

Come diceva un mio ex-capo .... dilettanti e neanche di buon livello.

Un saluto

[kumarnav...@gmail.com]

> eyedhedyeyy

> AGL
>
>
> [1] https://boringssl-review.googlesource.com/#/c/4813
> [2] https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-08

he

[mohamm...@optit.co]

> AGL
>
>
> [1] https://boringssl-review.googlesource.com/#/c/4813
> [2] https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-08

Am Not able to open the page

[Georg]

I've found a workaround to bypass the problem:

add to the command line in the icon property, the following string:

--cipher-suite-blacklist=0x0001,0x0002,0x0004,0x0005,0x0017,0x0018,0xc002,0xc007,0xc00c,0xc011,0xc016,0xff80,0xff81,0xff82,0xff83,0x0033,0x0039,0x0067,0x006b,0x009e

It's clear that security will be lower but works!!!