We plan to end support for DHE-based cipher suites in a future release of Chrome. To begin the process and measure the impact, Chrome 49 will temporarily move DHE to a fallback.
Earlier this year, Chrome
raised the minimum TLS Diffie-Hellman group size from 512-bit to 1024-bit. As mentioned then, 1024-bit is insufficient for the long-term. However, metrics report that around 95% of DHE connections seen by Chrome use 1024-bit DHE. This, compounded with how DHE is negotiated in TLS, makes it difficult to move past 1024-bit.
Although there is a
draft specification to solve the negotiation issues, it is still a draft, while ECDHE is already widely implemented and deployed. Indeed DHE today is only negotiated for 2% of connections by Chrome. With these numbers, we do not feel it is practical to continue supporting DHE.
We do not expect to break all 2% of connections using DHE. We expect most servers also support plain RSA cipher suites and will continue working. To predict more accurately, we will temporarily use a fallback, as was done for RC4. Starting in Chrome 49, Chrome will not offer any DHE-based ciphers in the initial ClientHello. If that fails, we will retry with our current offering, so sites relying solely on DHE will not break at this time. (This is not a long-term solution as connections are only as secure as the weaker of the two configurations.)
This, however, means servers currently negotiating DHE will lose
forward secrecy in Chrome 49. Servers should upgrade to ECDHE-based cipher suites. We recommend TLS 1.2 with TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 for most deployments. If ECDHE is unavailable, ensure a plain RSA cipher suite is supported. Servers should also disable DHE ciphers. Even if ECDHE is preferred, merely supporting a weak group leaves DHE-capable clients vulnerable.
We will determine the exact removal schedule based on what we learn from this fallback.
David