Value of DEFAULT cipher suite

[Salz, Rich]

We are considering removing weak cryptography from the value of DEFAULT. That is, append ":!LOW:!EXPORT"

It is currently defined as this in include/openssl/ssl.h:
#define SSL_DEFAULT_CIPHER_LIST "ALL:!aNULL:!eNULL:!SSLv2"

Please let us know if you have strong objections to this.
--
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: rsalz-dbVaDHFsUTizQB+***@public.gmane.org Twitter: RichSalz


______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Benny Baumann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi Rich,

Post by Salz, Rich
We are considering removing weak cryptography from the value of
DEFAULT. That is, append ":!LOW:!EXPORT"
It is currently defined as this in include/openssl/ssl.h: #define
SSL_DEFAULT_CIPHER_LIST "ALL:!aNULL:!eNULL:!SSLv2"
Please let us know if you have strong objections to this.

Please consider also adding !SSLv3 and !RC4 to this list.

Regards,
BenBE.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCgAGBQJUDsI0AAoJEPHTXLno4S6t9FIP/0U0GxY3LyyULMPFGc+AVGmV
BfgR5WZOd1+VsWudCfhpOS9OGAMBdmjxzI2TQvm1osUnSyRI8k8642eCF8v1Gqtf
QIGtUp/A0UghKygoo9XzNCLfu2WL6DOa9HYWpURDEVanM+ZGImwNh02zv8b9jXcM
REFi7rkr8gIje7O7z9SVb3RkKqp/QBwR9s7w1i2bzdEyKi4pbsGhX0s2zclALTgU
6Gn5SMh0o3LeIoNjvfhxe4KyDY/u97omkgOmThERkgZEILrzcj2lgZZ+sI6W2qpa
E/QUNKrStQJXereOp2iAO7uEXPe3Md+VhqsSjP8pxpiTb1U6o74FITeyEggBSWS9
u8i/2sCpXZPRqUGe1OTbxzu3BjFXHOEQ6kc7pZahPAX3M9spY5WMglnFJODCn5F3
QIps8pZ1CJuXm1UhVJ3LvTKsbIsQ3C7egbPrK6zAZwCWRDUmYOya6YUUTA+gu3xs
6Tv6FHoI+r/yyiff4BfhdU7ECHlqw7+pqIgwyIWJQeNRxzOzUquuaQDy2bLnWMX5
+NGQEmgfzIPQhD5rzNI3TUrzutJB+4cyVnaIGjcjzc79gcQYRaLgkGXOg2D5nFgj
KGeUbls7kft+48Junrap/2q1ozblQt+D1j9czQPdeFWCnnt+uG6yCtnnPYqtp/GJ
3EOir+BPawK99iMGjUYy
=TFs7
-----END PGP SIGNATURE-----
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Salz, Rich]

Post by Benny Baumann
Please consider also adding !SSLv3 and !RC4 to this list.

My plan is to move RC4 and MD5 to LOW; see RT3518. As for SSLv3, the issue is that you really mean the protocol, not the ciphers (there's overlap with SSL and TLS), which is configured separately, and only via code. So I think I have to leave that as-is, unfortunately.

Thanks for the feedback.
--
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: rsalz-dbVaDHFsUTizQB+***@public.gmane.org Twitter: RichSalz

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Viktor Dukhovni]

Post by Salz, Rich

Post by Benny Baumann
Please consider also adding !SSLv3 and !RC4 to this list.

My plan is to move RC4 and MD5 to LOW; see RT3518.

Moving RC4 to "LOW" is also premature. It is already at the bottom
of the medium cipherlist, that should be enough.

Opportunistic security is degraded when TLS handshakes fail, and
applications resort to cleartext. Instead of additional security
such changes often lead to reduced security.

[Salz, Rich]

Moving RC4 to "LOW" is also premature. It is already at the bottom of the
medium cipherlist, that should be enough.

I am planning on doing it for master, not 1.0.2 That means it won't be in an official release until... what, at least six months.


______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Viktor Dukhovni]

Post by Salz, Rich

Moving RC4 to "LOW" is also premature. It is already at the bottom of the
medium cipherlist, that should be enough.

I am planning on doing it for master, not 1.0.2 That means it
won't be in an official release until... what, at least six months.

Master has "security levels", which still need some work, but are
a less crude mechanism for such tweaks. Disabling RC4 at security
level 2 or some such, is better than incompatibly reclassifying it
as "LOW". We can discuss the details later.

[Salz, Rich]

Master has "security levels", which still need some work, but are a less crude
mechanism for such tweaks. Disabling RC4 at security level 2 or some such, is
better than incompatibly reclassifying it as "LOW". We can discuss the details
later.

That should probably also be done. But things like HIGH LOW, etc are point-in-time statements and raising the bar so that existing applications just get more secure without having to change anything is also worth doing.


--
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: rsalz-dbVaDHFsUTizQB+***@public.gmane.org Twitter: RichSalz
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Viktor Dukhovni]

Post by Salz, Rich
That should probably also be done. But things like HIGH LOW,
etc are point-in-time statements and raising the bar so that existing
applications just get more secure without having to change anything
is also worth doing.

This is often a misconception. There are two "bars" that can be
raised. The "floor" and the "ceiling".

Raising the ceiling (strength of most preferred algorithms) improves
security. For example implement ChaCha with Poly1305, and prefer
it to RC4.

Raising the floor often breaks interoperability, and leads to people
disabling security or automatically failing over to cleartext, ...

https://www.ietf.org/mail-archive/web/perpass/current/msg00654.html

While there are minor inaccuracies in that post, the core points
stand.

Far more productive than disabling RC4 would be ensuring that it
is not the preferred cipher suite when better options are enabled.

To improve security, raise the ceiling. ChaCha, new EC curves,
extensions to negotiate DH parameters, ... Raising the floor can
do more harm than good.

[Salz, Rich]

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. This follows the current thinking of the IETF. 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?

--
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: rsalz-dbVaDHFsUTizQB+***@public.gmane.org Twitter: RichSalz

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Viktor Dukhovni]

Post by Salz, Rich

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.

Post by Salz, Rich
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.

Post by Salz, Rich
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.

[Salz, Rich]

We disagree. I've got two IETF WG's coming to the same conclusion so making post-1.0.2 follow IETF practices seems pretty inarguable.

Post by Viktor Dukhovni
The IETF is sadly also prone to knee-jerk reactions.

True. Some would put perpass in that category.
--
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: rsalz-dbVaDHFsUTizQB+***@public.gmane.org Twitter: RichSalz
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Jeroen de Neef]

I can see RC4 going in the list of low security ciphers within a couple of
years anyways, so we can better discourage the usage right now.

Post by Salz, Rich
We disagree. I've got two IETF WG's coming to the same conclusion so
making post-1.0.2 follow IETF practices seems pretty inarguable.

Post by Viktor Dukhovni
The IETF is sadly also prone to knee-jerk reactions.

True. Some would put perpass in that category.
--
Principal Security Engineer
Akamai Technologies, Cambridge MA
______________________________________________________________________
OpenSSL Project http://www.openssl.org

[Viktor Dukhovni]

Post by Jeroen de Neef
I can see RC4 going in the list of low security ciphers within a couple of
years anyways, so we can better discourage the usage right now.

Note that RC4 is essentially the only widely used MEDIUM cipher,
and is by default last on that list. There is little reason at
present to demote it to LOW. Folks who want strong BCP crypto,
can disable MEDIUM.

$ openssl ciphers -v 'MEDIUM:!aNULL:@STRENGTH'
DHE-RSA-SEED-SHA SSLv3 Kx=DH Au=RSA Enc=SEED(128) Mac=SHA1
DHE-DSS-SEED-SHA SSLv3 Kx=DH Au=DSS Enc=SEED(128) Mac=SHA1
SEED-SHA SSLv3 Kx=RSA Au=RSA Enc=SEED(128) Mac=SHA1
IDEA-CBC-SHA SSLv3 Kx=RSA Au=RSA Enc=IDEA(128) Mac=SHA1
IDEA-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=IDEA(128) Mac=MD5
RC2-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC2(128) Mac=MD5
ECDHE-RSA-RC4-SHA SSLv3 Kx=ECDH Au=RSA Enc=RC4(128) Mac=SHA1
ECDHE-ECDSA-RC4-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=RC4(128) Mac=SHA1
ECDH-RSA-RC4-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=RC4(128) Mac=SHA1
ECDH-ECDSA-RC4-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=RC4(128) Mac=SHA1
RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1
RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5
RC4-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5
PSK-RC4-SHA SSLv3 Kx=PSK Au=PSK Enc=RC4(128) Mac=SHA1

Once RC4 use is negligible (my guess is in ~5 years), then OpenSSL
can demote it in the library, rather than leave the choice to
applications.

[Salz, Rich]

Folks who want strong BCP crypto, can disable MEDIUM.

Folks who want weak non-BCP crypto can enable LOW.

I'm putting this on hold to see where we are 6-9 months from now.

--
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: rsalz-dbVaDHFsUTizQB+***@public.gmane.org Twitter: RichSalz
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Viktor Dukhovni]

Post by Salz, Rich
We disagree. I've got two IETF WG's coming to the same conclusion
so making post-1.0.2 follow IETF practices seems pretty inarguable.

Post by Viktor Dukhovni
The IETF is sadly also prone to knee-jerk reactions.

True. Some would put perpass in that category.

Which is why I cautioned against overly hasty counter-measures.

I don't disagree that applications and operators should generally
disable RC4. Howerver, OpenSSL is not the right place to do so.
In opportunistic TLS, disabling RC4 is often worse than leaving it
enabled.

The library should provide a sensible default preference order,
and a sensible choice of DEFAULT cipher suites, these can be updated
from time to time. Dropping cipher suites nobody is using is fine.
Dropping cipher suites that are in wide use, and making the choice
in code below the application layer is I think unwise.

We could introduce a new cipher suite class name "BCP", to complement
"DEFAULT". The latter is broadly interoperable with sensible
ordering but inclusive cipher choices, the former would be more
restrictive, offering only the BCP cipher suites, sensibly ordered.

Applications that want "BCP", could have it. Applications that
emphasize interoperability would use "DEFAULT". Then you would
be free to tweak "BCP" more aggressively than "DEFAULT".

[Michael Wojcik]

Sent: Tuesday, 09 September, 2014 11:35
Subject: RE: Value of DEFAULT cipher suite

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.

Which is tantamount to disabling it, for any applications that:

- Link OpenSSL dynamically and don't set a non-default cipher suite list
- Are rebuilt with the new OpenSSL but aren't changed to set a non-default cipher suite list

You're talking about violating the Principle of Least Surprise, which is rarely a good idea.

This follows the current thinking of the IETF.

Glossing "what's currently in an I-D" as "the current thinking of the IETF" is quite a stretch.

And UTA applies to *applications*, not to libraries.

And personally I think UTA is somewhat misguided, particularly in its excessive use of RFC 2119 conditional-compliance ("MUST") requirements in sections that the text refers to as "recommendations"; and I'm not convinced the authors have done a good job of considering the ramifications.

As for the PRC4 I-D: It too applies to applications; and unless OpenSSL is going to enforce the final requirement of part 2 ("the TLS server MUST terminate the handshake"), I can't see how you can claim your proposed change is "following" the I-D. Without that final requirement, the other two are potentially more dangerous than allowing RC4.

It's just being standards-compliant.

Which standard are we talking about? In your other message you cited to I-Ds, which are NOT standards.
--
Michael Wojcik
Technology Specialist, Micro Focus




This message has been scanned for malware by Websense. www.websense.com
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Salz, Rich]

Yes, I'm jumping the gun claiming that the I-D are standards. They're not. They're just drafts.
I'm willing to wait and see what happens for a few months.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Michael Wojcik]

Sent: Tuesday, 09 September, 2014 09:01
Subject: Re: Value of DEFAULT cipher suite

Post by Salz, Rich

Moving RC4 to "LOW" is also premature. It is already at the bottom of

the

Post by Salz, Rich

medium cipherlist, that should be enough.

I am planning on doing it for master, not 1.0.2 That means it
won't be in an official release until... what, at least six months.

Master has "security levels", which still need some work, but are
a less crude mechanism for such tweaks. Disabling RC4 at security
level 2 or some such, is better than incompatibly reclassifying it
as "LOW". We can discuss the details later.

For what it's worth, I'm with Victor on this. RC4 as cipher of last resort in the default set is better than not having it there at all.

The work factor and conditions for the best attacks on RC4 (around 2**24 largely-similar plaintexts, unless I've missed more-recent improvements, which is certainly possible) are potentially dangerous for some applications - particularly HTTPS against server clusters that will handle the load, where a client (generally a browser) can be tricked into making the requests (generally via malicious scripting). But for other applications it could be much more difficult, in practice, to mount the attack.

I think it's fair to say that RC4 is strictly weaker than the other medium ciphers (SEED and RC2), since the best published attacks against RC4 are definitely considerably more feasible than those against the other two. But as Victor said, it's better than plaintext; and it's still very widely used (often preferentially), so there's a decent chance that an OpenSSL-based application using the default suite list will encounter a peer that only supports RC4.
--
Michael Wojcik
Technology Specialist, Micro Focus




This message has been scanned for malware by Websense. www.websense.com
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Salz, Rich]

Post by Michael Wojcik
For what it's worth, I'm with Victor on this. RC4 as cipher of last resort in the
default set is better than not having it there at all.

Take it up with the IETF which has two working groups advocating against it. UTA (use of TLS in applications) and the TLS group itself:

https://tools.ietf.org/html/draft-ietf-uta-tls-bcp-02
Implementations MUST NOT negotiate RC4 cipher suites
https://tools.ietf.org/html/draft-ietf-tls-prohibiting-rc4-00
As a result, RC4 can no longer be seen as providing a sufficient level of security for TLS sessions.

"To improve security, raise the ceiling." An equal number of experienced people are equally firm that the only way to raise the standard of practice is to remove bad ciphers.

--
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: rsalz-dbVaDHFsUTizQB+***@public.gmane.org Twitter: RichSalz
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Viktor Dukhovni]

Post by Benny Baumann
Please consider also adding !SSLv3 and !RC4 to this list.

No. That would be unwise at this time.

[Jakob Bohm]

Post by Salz, Rich
We are considering removing weak cryptography from the value of DEFAULT. That is, append ":!LOW:!EXPORT"
#define SSL_DEFAULT_CIPHER_LIST "ALL:!aNULL:!eNULL:!SSLv2"
Please let us know if you have strong objections to this.

In addition to removing the very-weak (less than 70 bits security)
ciphers from the default list,this would be a good opportunity to
reorder the default list (either via the define, or bettervia whatever
internal priorities guide the interpretation of a similar user-provided
list), tomaximize security, similar to what is checked e.g. by the
online "ssllabs" checker.

Basically: Prefer PFS suites to non-PFS suites (i.e. prefer EDH/ECDH to
bare RSA) at each nominalsecurity level (256 bits, 192 bits, 128 bits,
...), also enable 0/n splitting (and/or prefer a stream cipher)for CBC
encryption with older TLS protocol versions whenever the send timing
makes them otherwise subject to BEAST.

The latter is, by the way, the reason many systems have *recently* been
configured to explicitly prefer RC4 as the only unbroken cipher
compatible with servers or clients that don't protect against BEAST in
other ways.

To protect from the known RC4 repeated-plaintext vulnerability, one
might consider adding rate limiting to some SSL/TLS protocol steps
whenever RC4 is actually used.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct [phone]
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Salz, Rich]

In addition to removing the very-weak (less than 70 bits security) ciphers
from the default list,this would be a good opportunity to reorder the default

I'd prefer to wait until TLS 1.3 is implemented, which has some definite (and rather strong :) feelings on the subject. Doing things like putting PFS first would greatly increase the computation load on servers and doesn't seem like the right thing to do as a quiet change. (But yes, moving RC4 down to LOW does seem to me like the right thing to do. :)

To protect from the known RC4 repeated-plaintext vulnerability, one might
consider adding rate limiting to some SSL/TLS protocol steps whenever RC4 is
actually used.

The TLS WG looked at adding arbitrary padding as a record type. I hope it comes back. Maybe the fact that the next TLS WG interim meeting will be at INRIA, home of the triple-handshake attack and the padding proposal, will have some effect :)

--
Principal Security Engineer, Akamai Technologies
IM: rsalz-dbVaDHFsUTizQB+***@public.gmane.org Twitter: RichSalz
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Jakob Bohm]

Post by Salz, Rich

In addition to removing the very-weak (less than 70 bits security) ciphers
from the default list,this would be a good opportunity to reorder the default

I'd prefer to wait until TLS 1.3 is implemented, which has some definite (and rather strong :) feelings on the subject. Doing things like putting PFS first would greatly increase the computation load on servers and doesn't seem like the right thing to do as a quiet change. (But yes, moving RC4 down to LOW does seem to me like the right thing to do. :)

You conveniently snipped the part of my post which explained why RC4 is
currently the*strongest* available cipher when talking to some clients,
being (in those situations)effectively stronger than AES-256 CBC, despite
its known weaknesses.

Post by Salz, Rich

To protect from the known RC4 repeated-plaintext vulnerability, one might
consider adding rate limiting to some SSL/TLS protocol steps whenever RC4 is
actually used.

The TLS WG looked at adding arbitrary padding as a record type. I hope it comes back. Maybe the fact that the next TLS WG interim meeting will be at INRIA, home of the triple-handshake attack and the padding proposal, will have some effect :)

That arbitrary padding (or any other future TLS feature) will do nothing
to mitigate the problem that interoperating with some widely deployed real
world clients leaves the choice between CBC with no mitigation and RC4 with
limitedkey lifespan (e.g. max 2**?? bytes encrypted with any given key).

You really should look at the extensive research done by SSL Labsbefore
blindly deprecating stuff.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct [phone]
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Salz, Rich]

Post by Jakob Bohm
You really should look at the extensive research done by SSL Labsbefore
blindly deprecating stuff.

Sorry you think I'm doing that. I'm raising an issue six months before it will affect people.

--
Principal Security Engineer, Akamai Technologies
IM: rsalz-dbVaDHFsUTizQB+***@public.gmane.org Twitter: RichSalz
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Viktor Dukhovni]

Post by Jakob Bohm
In addition to removing the very-weak (less than 70 bits security)
ciphers from the default list,this would be a good opportunity to
reorder the default list (either via the define, or bettervia whatever
internal priorities guide the interpretation of a similar user-provided
list), tomaximize security, similar to what is checked e.g. by the
online "ssllabs" checker.
Basically: Prefer PFS suites to non-PFS suites (i.e. prefer EDH/ECDH to
bare RSA) at each nominalsecurity level (256 bits, 192 bits, 128 bits,
...)

This is already the case starting 1.0.0.