RC4 is dyning - Githubissues

kazu-yamamoto commented 9 years ago

Now RFC 7465: "Prohibiting RC4 Cipher Suites" is published. We need to consider when we should remove RC4 from WarpTLS.

snoyberg commented 9 years ago

I'm OK removing it now. @vincenthz any thoughts on the matter?

kazu-yamamoto commented 9 years ago

FYI: http://www.rc4nomore.com/

meteficha commented 9 years ago

Thanks for the pointer. +1 on removing.

kazu-yamamoto commented 9 years ago

If we agree to remove RC4, we need to decide when we do it: WarpTLS 3.1.0 or 3.2.0? I will release WarpTLS 3.1.0 in this week.

snoyberg commented 9 years ago

I'd say 3.1. This is just changing the default, not removing the capability entirely, right?

On Mon, Jul 20, 2015 at 8:16 PM Kazu Yamamoto notifications@github.com wrote:

If we agree to remove RC4, we need to decide when we do it: WarpTLS 3.1.0 or 3.2.0? I will release WarpTLS 3.1.0 in this week.

— Reply to this email directly or view it on GitHub https://github.com/yesodweb/wai/issues/400#issuecomment-123138940.

kazu-yamamoto commented 9 years ago

Right.

So, what about providingdefaultTraditionalTlsSettings which includes RC4?

snoyberg commented 9 years ago

Shrug. I'm fine with it, though I'm not convinced it's necessary. If you want to go that route, feel free

On Mon, Jul 20, 2015, 8:44 PM Kazu Yamamoto notifications@github.com wrote:

Right.

So, what about providingdefaultTraditionalTlsSettings which includes RC4?

— Reply to this email directly or view it on GitHub https://github.com/yesodweb/wai/issues/400#issuecomment-123142622.

kazu-yamamoto commented 9 years ago

Please see the commit above to know what I want to do exactly.

kazu-yamamoto commented 9 years ago

If we have defaultTlsSettings and traditionalTlsSettings, we can be more active to make defautlTlsSettings more modern. I would like to discuss to remove re-negociation from defaultTlsSettings, too.

erikd commented 9 years ago

+1 on removing RC4 +1 on removing re-negociation from defaultTlsSettings

kazu-yamamoto commented 9 years ago

I was wrong. The smart constructors (e.g. tlsSettings) modifiy defaultTlsSettings. chainCertFiles etc are not exported. So, we cannot modify chainCertFiles in traditionalTlsSettings.

@snoyberg What is the intention to hide chainCertFiles etc? Can we export them?

snoyberg commented 9 years ago

It's a backwards compatibility hack. A better approach would be to export setters like setChainCertFiles that will ensure that internal invariants are kept about in-memory vs in-file storage.

kazu-yamamoto commented 9 years ago

@snoyberg OK. We should not export these field names.

kazu-yamamoto commented 9 years ago

Now, things are clear to me.

traditionalTlsSettings:

There is no way to control renegotiation of the "tls" lib so to satisfy the tests provided by https://www.ssllabs.com/ssltest/. I will bring this issue to the "tls" lib itself.
There is no smart constructors which can modify traditionalTlsSettings.
So, let's not define traditionalTlsSettings.

RC4:

Let's remove RC4 now.
The current doc is misleading. We should move the smart constructor part first, field names second. This leads users to use smart constructors first, then modify tlsCiphers if necessay.

I implemented this all and am satisfied. Please review the current code, everyone.

kazu-yamamoto commented 9 years ago

The renego issue now goes to https://github.com/vincenthz/hs-tls/issues/112.

snoyberg commented 9 years ago

LGTM

kazu-yamamoto commented 9 years ago

Let's close this.

yesodweb / wai

RC4 is dyning #400