On Tue, Sep 09, 2014 at 11:34:43AM -0400, Salz, Rich wrote:
> > Far more productive than disabling RC4 would be ensuring that it is not the
> > preferred cipher suite when better options are enabled.
>
> I am not disabling RC4. I am saying that applications that want
> to use it will, after the post-1.0.2 release is adopted, need to
> take pro-active action.
Declaring "RC4" LOW is not the right answer:
$ openssl ciphers -v 'LOW:@STRENGTH'
EDH-RSA-DES-CBC-SHA SSLv3 Kx=DH Au=RSA Enc=DES(56) Mac=SHA1
EDH-DSS-DES-CBC-SHA SSLv3 Kx=DH Au=DSS Enc=DES(56) Mac=SHA1
ADH-DES-CBC-SHA SSLv3 Kx=DH Au=None Enc=DES(56) Mac=SHA1
DES-CBC-SHA SSLv3 Kx=RSA Au=RSA Enc=DES(56) Mac=SHA1
DES-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=DES(56) Mac=MD5
I've not seen a TLS connection established with one of these in
the last decade, and single DES is easily brute-forced with
off-the-shelf hardware.
Thus I'm not objecting to disabling by default "EXPORT" and "LOW"
because they at this point no longer used, and obviously much too
weak.
Though RC4 is considerably tarnished, the story is rather different,
since it is still widely used, and the attacks rather specialized.
I agree that applications and system administrators should take
measures to replace RC4 with safer choices whenever possible, but
I don't think that marking RC4 as LOW (many applications that use
RC4 disable LOW ciphers) is a positive development.
In OpenSSL there is no way to enable a cipher suite disabled with
"!blah". To enable RC4 while not allowing the remaining "LOW"
cipher suites, one would have to replace "!LOW" with the much less
obvious "!DES".
A lot of needless editing of cipherspecs which are error-prone in
the hands of non-experts. Far better to offer carrots not sticks
in the form of stronger alternatives, that are preferred by default,
and perform as well or better.
> This follows the current thinking of the IETF.
The IETF is sadly also prone to knee-jerk reactions. For example,
recent discussion of disabling session tickets, where for once
reason prevailed, but some folks are on a crusade to stamp out
crypto too weak for them and damn the unintended consequences.
> It's just being standards-compliant. If you say "security
> levels are a better way to handle this" then why don't security
> levels require RC4?
We can discuss alternative approaches in a separate thread. Security
levels still need a bit of work.
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
