RFC7465: Prohibiting RC4 Cipher Suites

[oherrala]

From RFC7465:

This document requires that Transport Layer Security (TLS) clients and servers never negotiate the use of RC4 cipher suites when they establish connections. This applies to all TLS versions.

And section 2, changes to TLS:

Because of the RC4 deficiencies noted in Section 1, the following apply:

• TLS clients MUST NOT include RC4 cipher suites in the ClientHello message.
• TLS servers MUST NOT select an RC4 cipher suite when a TLS client sends such a cipher suite in the ClientHello message.
• If the TLS client only offers RC4 cipher suites, the TLS server MUST terminate the handshake. The TLS server MAY send the insufficient_security fatal alert in this case.

Removing RC4 from ciphersuite_all probably fixes quite a few other packages depending on safe set of defaults provided by ciphersuite_all. RFC is so strict that maybe removing RC4 from ciphersuite_medium is also worth doing.

[kazu-yamamoto]

@vincenthz @ocheron The next version would be major. We should think this again.

[ocheron]

To me the policy is already addressed with the addition of ciphersuite_default.
"default" is the list users should use, and if we start securing "all" too, that may simply never happen.

With what we have now, I don't see any use for ciphersuite_medium.
What about just deleting it?

[vincenthz]

to clarify, I called the "policy" a way to dynamically set the tls capability we allow/deny/use-by-default related to various criterion.

For example I expect to be able to create a file in my home directory, or a service's working directory that contains policy statements, similar to this non-exhaustive list of example:

• For host foo, on port X, I want to allow RC4
• For service bar, I want to only allow RSA key >= 2K and DDH >= 1534 bits
• For all my connection, don't allow AES
• For this service, allow the SSL3 version
• For this host, contact using TLS10 without signature hash above SHA256

Once every policy choice are override-able, we can tighten the core to be more secure by default (not allow RC4 by default, not allow DH under < 1000 bits, etc.), without having a massive amount of users creating issues like "I can't access my private network SSL3 service from 2003 using triple DES"

[ocheron]

For a general-purpose library like connection that makes sense.
Reverse dependencies like smtps-gmail or push-notify-ccs can probably make a compile-time decision more easily.

push-notify-ccs has the only reference to ciphersuite_medium.
If I exclude connection and tls-debug, we have 12 packages referencing ciphersuite_all, and 0 with ciphersuite_default (unsurprisingly).
We also have 1 package referencing RC4 ciphers directly...

(for simplicity I excluded packages with outdated tls dependencies)

[kazu-yamamoto]

To me the policy is already addressed with the addition of ciphersuite_default.

OK. I agree.

[kazu-yamamoto]

With what we have now, I don't see any use for ciphersuite_medium.
What about just deleting it?

No objection.

[kazu-yamamoto]

If I exclude connection and tls-debug, we have 12 packages referencing ciphersuite_all, and 0 with ciphersuite_default (unsurprisingly).

Since nobody uses ciphersuite_default, the current ciphersuite_default with RC4 already removed does not solve this issue, right?

What should we do?

[kazu-yamamoto]

Just FYI. Our company, IIJ, had kept RC4 on www.iij.ad.jp for a loooong time because a very few clients use RC4. But we finally threw RC4 away.

[vincenthz]

I'm not usually a big fan about this argument, but consider that not all packages are public. I don't want to worry too much about stuff I don't know (for obvious reason), but it's hard to have real numbers about what is being used and where. it's only when you take things away that people manifest their unhappiness.

I agree that the different categories of cipher is not really useful, and also slightly arbitrary, but until we have a real dynamic policy capability, I worry about doing this kind of changes.

If we had the policy configuration, then we can get rid of all those cipher/versioning/hashing/certificates choices and instead just "hardcode" some reasonable secure choices with the assumption that anyone can have the configuration they need by editing couple of text file.

[vincenthz]

adding to @kazu-yamamoto comment, I've seen private services still use SSL3/TLS10 with real and scary known openssl holes in them. There's an argument to be made for sure to not help them support this kind of thing (and the browser ecosystem actively throwing old stuff away has really helped us for the last few years), but haskell tls is a minor player, we really can't impose to only have a good secure behavior only on our level.

[ocheron]

I think we have consensus that the library can stay agnostic and should provide what is necessary to make a choice at compile-time and runtime.

We have recommandations for those who wish to be "secure" (default) and "very secure" (strong). It's just a matter of maintaining the lists and communicating over. Up until very recently #168 was not even in the CHANGELOG...

The problem I have with ciphersuite_medium is that it's only cipher_RC4_128_SHA1+cipher_AES128_SHA1, so not terribly useful.

For completeness I should also add that 4 public packages use ciphersuite_strong.

[kazu-yamamoto]

I would like to propose:

• adding the deprecated pragma to ciphersuite_medium and deleting it someday
• adding the deprecated pragma to ciphersuite_all but keeping it
• telling known users of ciphersuite_medium and/or ciphersuite_all to switch to ciphersuite_default or ciphersuite_strong via their github issues or somthing

[vincenthz]

I think here, this is the right thing to do, first a weak signal of future incoming removal, then .. profits