Support for TLSv1.2 w/ 256-bit forward secrecy cipher suites

[Michał Staruch]

I think it would be very nice if Pale Moon supported TLSv1.2 with 256-bit forward secrecy cipher suites that are standardized under IETF:
- ECDHE-RSA-AES256-GCM-SHA384,
- DHE-RSA-AES256-GCM-SHA384,
- ECDHE-RSA-AES256-SHA384,
- DHE-RSA-AES256-SHA256.

Without that it's not possible to connect to servers aiming 4x100 in Qualys SSL Server Test like thundr.eu (full test report here).

[Moonchild]

Pale Moon supports TLS 1.2 with cipher suites having 256-bit encryption and forward secrecy already, just not the specific ones listed there.

Also, Pale Moon builds on the nss library (which can either be internal or system-installed) and I'm pretty sure these suites are not currently part of the RTM versions of nss; as such, support will have to be added to nss first before Pale Moon can practically support them.

[Michał Staruch]

Moonchild Existing suites rely on HMAC-SHA-1, so they're not fully 256-bit grade cipher suites. I know NSS is the main limitation here, but maybe you'll be able to help pushing things forward .

[Moonchild]

Please don't confuse the hashing algorithm with the actual encryption algorithm. For certificates, SHA-1 is problematic because it is the only method involved in verifying authenticity of the certificate, and the (theoretical!) attack on SHA-1 would be a concern there because certificates could be forged (which is a completely different part of SSL than the actual encryption). If you want to talk about the security bits, then SHA-256 is also not "fully 256-bit grade" despite the name, because it only has 128 security bits. SHA-384 only has 192 security bits, as well; it is effectively half of the bits of the output size.

For cipher suites, especially FS ones, the hashing algorithm won't be a first concern unless it is completely broken. SHA-1 (as a pure hashing algorithm) is resistant against preimage attacks, and the collision resistance of SHA-1 still requires ~2^60 to 2^65 hash attempts which is potentially feasible with current technology if you can take a year to hash away at it (as opposed to MD5 which takes mere seconds to find a collision). For dynamically created SSL connections, both the computation power and time frame involved makes it completely impractical. This is why there has been no urgency to implement these suites in the major browsers.

As for moving things along... I don't think my voice would carry much weight in the Mozilla realm.

EDIT: As a side note, in case you aren't too intimately familiar with it: any HMAC-SHA2-based cipher suite is very computationally inefficient and doesn't offer any significant security advantage* over the HMAC-SHA1-based cipher suites. Also note that HMAC-SHA1 is much stronger than plain SHA1.

* See also: https://en.wikipedia.org/wiki/Hash-based_message_authentication_code#Security

[Michał Staruch]

Moonchild I know what's encryption, and what's hashing . But you're right about SHA-256 having 128-bit strength .

But my main concern remains the same - using the SHA-1 for anything related to crypto is not a good idea, even in context of HMAC. In my opinion we should just stop using hashing algorithms for which collisions can be generated fo moderate amount of money (see the When Will We See Collisions for SHA-1? article from Bruce Schneier), as it happened years ago with MD5.

[Moonchild]

I'm sorry, but you don't seem to understand understand that for HMAC collisions don't matter. And that in the context of encryption and using it as a MAC generator (as opposed to using it for actual hashing), HMAC-SHA1 is perfectly fine to verify the integrity and authenticity of encrypted data. Even HMAC-MD5 would still be (albeit marginally) acceptable, which is a reason why RSA-AES-MD5 is still in the list of usable ciphers, although you would be increasing the attack surface massively for potential breakage so it's strongly discouraged. See also RFC6151 specifically 2.3 about HMAC-MD5.

[Michał Staruch]

Moonchild But IF someone figured out lower complexity pre-image attack on HMAC-MD5 or HMAC-SHA1 (and I have to assume it's possible), then they wouldn't be so secure, anymore. And some organizations might have strict security policy simply disallowing usage of both MD5 and SHA-1 for hashing in any cryptographic context.

Also mind both TLSv1.2 and TLSv1.3 draft define only cipher suites using PRF with SHA-256 (or stronger), both HMAC-MD5 and HMAC-SHA-1 are gone. This alone should be enough to start supporting PRF based on SHA-256 (or stronger).

[Moonchild]

There is no urgency in this matter. Pale Moon already supports perfectly secure ciphers using TLS1.2 with SHA256. If you wonder "why not AES256" then you should read up on why it is not significantly more secure than AES128, and understand the cost involved once again for implementing it.
TLS1.2 also does not enforce the use of ciphers with SHA256, it merely extends the range with them. TLS1.2 is a protocol. The issue you have is that the website owners don't agree with using a perfectly usable suite just because numbers.

The question in cryptography also is not "is it possible" because theoretically, any encryption can be broken. The question is: is it feasible to do so. If you need all the computers in the world to work together for thousands or millions of years to break a single key... then it's not feasible
As said before, SHA-1 is not known to be vulnerable to pre-image. MD5 is potentially, but has not been demonstrated in practice (hence the depreciation). And once again... And I hate to start repeating myself, I agree that for hashing you should not rely on on SHA-1 if it is used for authentication of a static key. But for HMAC, you are using it for integrity and authentication of individual messages. Did you actually read and understand what I pointed you to? I'll lift out the key sections here:

The cryptographic strength of the HMAC depends upon the size of the secret key that is used. The most common attack against HMACs is brute force to uncover the secret key. HMACs are substantially less affected by collisions than their underlying hashing algorithms alone.

... although the security of the MD5 hash function itself is severely compromised - the currently known " attacks on HMAC-MD5 do not seem to indicate a practical vulnerability when used as a message authentication code."

A EUROCRYPT 2009 paper presented a distinguishing attack on HMAC-MD5 [WYWZZ2009] without using related keys. It can distinguish an instantiation of HMAC with MD5 from an instantiation with a random function with 2^97 queries with probability 0.87. This is called distinguishing-H. Using the distinguishing attack, it can recover some bits of the intermediate status of the second block. However, as it is pointed out in [WYWZZ2009], it cannot be used to recover the (partial) inner key H(K Xor ipad). It is not obvious how the attack can be used to form a forgery attack either.

Now if you translate this obvious roadblock for HMAC on a severely compromised MD5 hashing function to a SHA-1 hash function that for pure hashing is barely breakable after a year of computation and big investment, then you should understand that there is no reason to immediately deprecate this as a HMAC hashing function. If organizations are enforcing this, then they are obviously not familiar enough with cryptography to make such calls.

[Michał Staruch]

Moonchild So in your opinion folks at IETF WG responsible for TLS specifications and recommending SHA-256 PRF are "not familiar enough with cryptography", too?

If organizations planning security ahead for internal systems will choose to make strict requirements from such as recommendation I see nothing wrong with that. If some people want to follow IETF recommendations on the server side - why can't we simply support it in browsers?

I understand that HMAC-SHA-1 is safe to use today (no serious attack known against it), but as it was said multiple times "Attacks always get better; they never get worse.", so if I had a choice I'd still prefer PRF using hashing function without any serious flaws (like SHA-256 or SHA-384) over ones with known weaknesses (like MD5 or SHA-1). Just in case.

About the AES-256 security. Only weakness I know against it is the related-key attack, which requires 2^99 data processed with 4 related keys to be performed. If you don't know relation between those keys and don't have that amount of data processed by them (which is far more than all data stored on the earth, as we're currently producing about 2^70 bytes each year SFAIK) then you're back on the 2^256 time complexity level attacks. Especially when we take into account that symmetric keys in TLS context are pretty short-living. If I had to choose best 256-bit cipher for protecting internal communication via TLS it would be either ChaCha20-Poly1305 or Camellia-256-GCM, both being AEAD ciphers (as required in TLSv1.3 draft) and have no known weaknesses at all. But those are not yet widely supported in TLS libraries, so getting back to reality best we could have today is the AES-256-GCM.

[Moonchild]

Moonchild So in your opinion folks at IETF WG responsible for TLS specifications and recommending SHA-256 PRF are "not familiar enough with cryptography", too?

That's not at all what I said; please don't twist my words.

There's also a difference between "preferring something" or "exclusively using it".

If some people want to follow IETF recommendations on the server side - why can't we simply support it in browsers?

See above about the reliance of Pale Moon on NSS. I'll be more than happy to make our internal NSS extended with additional security options (which I have done in some situations already) if patches are offered to that effect. In the case of Pale Moon this has to be a community effort; so if people want to follow IETF recommendations on the server side and want to push these cipher suites so they can be used exclusively by them with no fallback, then they should help make this happen.

Don't get me wrong: I'm all for implementing these cipher suites, but it's at most a "nice to have" right now since the internet as a whole doesn't use these ciphers while there are less expensive and just as secure alternatives in practical use. Heck, we're having plenty of trouble getting people off of RC4 already

[Michał Staruch]

Moonchild Guess we just misunderstand each other a bit on the beginning . I absolutely don't mind servers using AES-128-GCM or HMAC-SHA-1, and I agree that for most non-paranoid folks 128-bit crypto is pretty much fine. But NSA hires lots of mathematicians and has huge research budget, so it is possible that they know attacks other cryptanalysts don't. Another Snowden giving that knowledge to the public might happen, too. That's why I'd rather pick 256-bit crypto over 128-bit, and safe curves over those from NSA Suite B. TBH I'd also pick SIDH key exchange over both ECDHE and DHE, but let's keep something for 2020+ times .

About the RC4 I liked the official ban from IETF this year (RFC 7465) . In e-commerce world very nice move to strengthen the security was made in PCI DSS v3.1, requesting dropping support for TLSv1 after 30th June 2016, pointing TLSv1.1 as minimum and strongly recommending moving to TLSv1.2. Slowly, but we're moving forward .

[Moonchild]

The maths involved are actually pretty well-defined, and most universities in the world with people from all backgrounds are always cracking away at cryptanalysis of various commonly-used ciphers and mathematical curves, so you can bet that with the NSA under scrutiny, that people have been looking very closely at NSA-approved/promoted methods. Also, the NSA has good reason to make sure their own encryption is solid for their own use. If it was broken, I'm sure they wouldn't be using it themselves