On 17 Feb 2015, at 09:52, Glyph Lefkowitz glyph@twistedmatrix.com wrote:

...

On Feb 16, 2015, at 4:53 PM, Jason J. W. Williams jasonjwwilliams@gmail.com wrote:

Hi,

I need to loosen up the default cipher list to allow RC4 (some sites our customers use like myaccounts.socalgas.com still use it).

I was going to pass the following dict into the extraCertificateOptions argument of ssl.optionsForClientTLS, but was curious if there as a better way:

{"acceptableCiphers" : <IAcceptableCiphers object>}

As the documentation for extraCertificateOptions says, if you need to use it it's a bug in the interface. As such, please file it :-). This escape-hatch was presented specifically so we could discover which features of that interface were really necessary customizations and which were just unfortunate compromises with OpenSSL's API.

In this case, no, there's no other way to get acceptable ciphers in there, and this should probably just be added to optionsForClientTLS.

Another reasonable fix might be to allow RC4, since I think the default cipher suites that we have selected might be more appropriate for servers than for clients; the major browsers will still negotiate RC4 so we might want a slightly more permissive list. Hopefully someone more cryptographically enlightened than I am can opine as to whether this is a reasonable thing to do in 2015...

-g _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Some browsers won’t — Firefox refuses to use RC4 :)

- Hawkie

On 17 February 2015 at 04:19, Jason J. W. Williams jasonjwwilliams@gmail.com wrote:

...

Some browsers won’t — Firefox refuses to use RC4 :)

I saw that on Firefox's wiki, but in reality Firefox 35 still does allow RC4: http://www.screencast.com/t/AuMRylAV

IIUC, Firefox 36 will only allow RC4 as a fallback (but not disable it completely), and I think there is talk about disabling RC4 completely for TLS 1.1/1.2.

As the documentation for extraCertificateOptions says, if you need to use it it's a bug in the interface. As such, please file it :-). This escape-hatch was presented specifically so we could discover which features of that interface were really necessary customizations and which were just unfortunate compromises with OpenSSL's API.

Will do. Saw that note but wanted to make sure I wasn't missing a better approach before filing a bug.

In this case, no, there's no other way to get acceptable ciphers in there, and this should probably just be added to optionsForClientTLS.

Another reasonable fix might be to allow RC4, since I think the default cipher suites that we have selected might be more appropriate for servers than for clients; the major browsers will still negotiate RC4 so we might want a slightly more permissive list. Hopefully someone more cryptographically enlightened than I am can opine as to whether this is a reasonable thing to do in 2015...

I'd advocate for adding the acceptableCiphers argument to optionsForClientTLS over loosening the default cipher list. I think having a secure default and making loosening that default an explicit action is a good behavior. That way a less secure cipher list is always an active choice.

-J

On 17 Feb 2015, at 2:52, Glyph Lefkowitz wrote:

...

I need to loosen up the default cipher list to allow RC4 (some sites our customers use like myaccounts.socalgas.com still use it).

I was going to pass the following dict into the extraCertificateOptions argument of ssl.optionsForClientTLS, but was curious if there as a better way:

{"acceptableCiphers" : <IAcceptableCiphers object>}

As the documentation for extraCertificateOptions says, if you need to use it it's a bug in the interface. As such, please file it :-). This escape-hatch was presented specifically so we could discover which features of that interface were really necessary customizations and which were just unfortunate compromises with OpenSSL's API.

In this case, no, there's no other way to get acceptable ciphers in there, and this should probably just be added to optionsForClientTLS.

Yes.

Another reasonable fix might be to allow RC4, since I think the default cipher suites that we have selected might be more appropriate for servers than for clients; the major browsers will still negotiate RC4 so we might want a slightly more permissive list. Hopefully someone more cryptographically enlightened than I am can opine as to whether this is a reasonable thing to do in 2015...

I’m still maintaining that watering down the defaults is an invitation to downgrade attacks that affect *everyone*. And RC4 looks worse with every month passing.