Hello, For the purposes of the Crypto Policies change proposal [0], I think I've settled to the following three policy levels (inspired by the ENISA levels but with a rename of the good LEGACY level to DEFAULT). Any comments or suggestions are appreciated.
As these levels will be a moving target across releases (will provide defaults that reflect the current state of the art), levels of previous fedora releases will be referenced as LEVELNAME-F21.
[0]. https://fedoraproject.org/wiki/Changes/CryptoPolicy
regards, Nikos
The levels and their current settings:
=====LEGACY===== A level that may include algorithms with known weaknesses (but not completely broken) which will ensure maximum compatibility with legacy systems. It should provide at least 64-bit security and include RC4, but not MD5 as signature algorithm.
MACs: MD5, SHA1+ Curves: All supported Signature algorithms: must use SHA-1 hash or better Ciphers: AES-GCM, AES-CBC, CAMELLIA-GCM, CAMELLIA-CBC, 3DES-CBC, RC4 Key exchange: ECDHE, RSA, DHE DH params size: 768+ RSA params size: 768+ SSL Protocols: All supported (SSL3.0+)
=====DEFAULT====== A reasonable default for today's standards. For F21 it should provide 80-bit security and no broken ciphers like RC4.
MACs: SHA1+ Curves: All supported Signature algorithms: must use SHA-1 hash or better Ciphers: AES-GCM, AES-CBC, CAMELLIA-GCM, CAMELLIA-CBC, 3DES-CBC Key exchange: ECDHE, RSA, DHE DH params size: 1024+ RSA params size: 1024+ SSL Protocols: All supported (SSL3.0+)
=====FUTURE====== A level that will provide security on a conservative level that is believed to withstand any near-term future attacks. That will be an 128-bit security level, without including protocols with known attacks available (e.g. SSL 3.0/TLS 1.0). This level may prevent communication with commonly used systems that provide weaker security levels (e.g., systems that use SHA-1 as signature algorithm).
MACs: SHA1+ Curves: All supported Signature algorithms: must use SHA-256 hash or better Ciphers: AES-GCM, AES-CBC, CAMELLIA-GCM, CAMELLIA-CBC Key exchange: ECDHE, RSA, DHE DH params size: 2048+ RSA params size: 2048+ SSL Protocols: TLS1.1+
On 03/27/2014 12:13 PM, Nikos Mavrogiannopoulos wrote:
For the purposes of the Crypto Policies change proposal [0], I think I've settled to the following three policy levels (inspired by the ENISA levels but with a rename of the good LEGACY level to DEFAULT). Any comments or suggestions are appreciated.
Do you expect that the signature algorithm restrictions will apply to the self-signatures as well?
On Thu, 2014-03-27 at 12:49 +0100, Florian Weimer wrote:
On 03/27/2014 12:13 PM, Nikos Mavrogiannopoulos wrote:
For the purposes of the Crypto Policies change proposal [0], I think I've settled to the following three policy levels (inspired by the ENISA levels but with a rename of the good LEGACY level to DEFAULT). Any comments or suggestions are appreciated.
Do you expect that the signature algorithm restrictions will apply to the self-signatures as well?
No, not really. I will make it explicit, but I don't think there are libraries that currently enforce restrictions on the self signatures.
regards, Nikos
On 03/27/2014 01:06 PM, Nikos Mavrogiannopoulos wrote:
On Thu, 2014-03-27 at 12:49 +0100, Florian Weimer wrote:
On 03/27/2014 12:13 PM, Nikos Mavrogiannopoulos wrote:
For the purposes of the Crypto Policies change proposal [0], I think I've settled to the following three policy levels (inspired by the ENISA levels but with a rename of the good LEGACY level to DEFAULT). Any comments or suggestions are appreciated.
Do you expect that the signature algorithm restrictions will apply to the self-signatures as well?
No, not really. I will make it explicit, but I don't think there are libraries that currently enforce restrictions on the self signatures.
I had this change in mind:
http://marc.info/?l=openssl-cvs&m=124508133203041&w=2
I don't know if similar changes were applied to other libraries when we removed MD2 support.
On Thu, 2014-03-27 at 13:12 +0100, Florian Weimer wrote:
I had this change in mind:
http://marc.info/?l=openssl-cvs&m=124508133203041&w=2
I don't know if similar changes were applied to other libraries when we removed MD2 support.
There was a similar issue in gnutls that was solved a few years ago, and I have not seen anything reported in NSS (which already restricts MD5 as signature algorithm). So I don't believe that there will be any issues with that.
regards, Nikos
On 03/27/2014 02:43 PM, Nikos Mavrogiannopoulos wrote:
On Thu, 2014-03-27 at 13:12 +0100, Florian Weimer wrote:
I had this change in mind:
<http://marc.info/?l=openssl-cvs&m=124508133203041&w=2>I don't know if similar changes were applied to other libraries when we removed MD2 support.
There was a similar issue in gnutls that was solved a few years ago, and I have not seen anything reported in NSS (which already restricts MD5 as signature algorithm). So I don't believe that there will be any issues with that.
Okay, great.
I'll make a note to check JCE.
----- Original Message -----
From: "Nikos Mavrogiannopoulos" nmav@redhat.com To: security@lists.fedoraproject.org Sent: Thursday, 27 March, 2014 12:13:33 PM Subject: available crypto policies
Hello, For the purposes of the Crypto Policies change proposal [0], I think I've settled to the following three policy levels (inspired by the ENISA levels but with a rename of the good LEGACY level to DEFAULT). Any comments or suggestions are appreciated.
Can you give reasons why you want to limit the number of provided policies?
Do you plan some other mechanism for people to enforce strict FIPS guidelines, 128 bit security level or Suite B crypto? In other words, implement their own policy?
As these levels will be a moving target across releases (will provide defaults that reflect the current state of the art), levels of previous fedora releases will be referenced as LEVELNAME-F21.
While "self-updating" policies are quite nice, I can see people not trusting them (either as this implies that they will change, or that they are not strict enough). That's why I think "security level" policies would be better. With probably the LEGACY, DEFAULT and FUTURE defined as aliases that will change.
Either way, the file in which the configuration is going to take place should either contain a detailed description of available policies or a reference to the appropriate man page.
The levels and their current settings:
=====LEGACY===== A level that may include algorithms with known weaknesses (but not completely broken) which will ensure maximum compatibility with legacy systems. It should provide at least 64-bit security and include RC4, but not MD5 as signature algorithm.
MACs: MD5, SHA1+ Curves: All supported Signature algorithms: must use SHA-1 hash or better Ciphers: AES-GCM, AES-CBC, CAMELLIA-GCM, CAMELLIA-CBC, 3DES-CBC, RC4 Key exchange: ECDHE, RSA, DHE DH params size: 768+ RSA params size: 768+ SSL Protocols: All supported (SSL3.0+)
I think we should do a 767, 1023 and 2047 as the values for RSA and DH, some implementations (most common being Cisco routers) regularly generate "off-by-one" RSA sizes.
=====DEFAULT====== A reasonable default for today's standards. For F21 it should provide 80-bit security and no broken ciphers like RC4.
MACs: SHA1+ Curves: All supported Signature algorithms: must use SHA-1 hash or better Ciphers: AES-GCM, AES-CBC, CAMELLIA-GCM, CAMELLIA-CBC, 3DES-CBC Key exchange: ECDHE, RSA, DHE DH params size: 1024+ RSA params size: 1024+ SSL Protocols: All supported (SSL3.0+)
=====FUTURE====== A level that will provide security on a conservative level that is believed to withstand any near-term future attacks. That will be an 128-bit security level, without including protocols with known attacks available (e.g. SSL 3.0/TLS 1.0). This level may prevent communication with commonly used systems that provide weaker security levels (e.g., systems that use SHA-1 as signature algorithm).
MACs: SHA1+ Curves: All supported Signature algorithms: must use SHA-256 hash or better Ciphers: AES-GCM, AES-CBC, CAMELLIA-GCM, CAMELLIA-CBC Key exchange: ECDHE, RSA, DHE DH params size: 2048+ RSA params size: 2048+ SSL Protocols: TLS1.1+
Shouldn't DH params and RSA params at 128 bit be 3072 bit in size? And ECDSA curves at least 256 bit in size? (While we don't ship any in Fedora now, it may change in future and it doesn't hurt to codify that in policy.)
On Thu, 2014-03-27 at 09:13 -0400, Hubert Kario wrote:
----- Original Message -----
From: "Nikos Mavrogiannopoulos" nmav@redhat.com To: security@lists.fedoraproject.org Sent: Thursday, 27 March, 2014 12:13:33 PM Subject: available crypto policies
Hello, For the purposes of the Crypto Policies change proposal [0], I think I've settled to the following three policy levels (inspired by the ENISA levels but with a rename of the good LEGACY level to DEFAULT). Any comments or suggestions are appreciated.
Can you give reasons why you want to limit the number of provided policies?
We must have a reasonable number of policies for the user to select, that address common use-cases. If I had presented a list of 2^16 policies, an administrator would need an expert to translate the various available options. I do expect though more policies to be added by time if this feature proves useful.
Do you plan some other mechanism for people to enforce strict FIPS guidelines, 128 bit security level or Suite B crypto? In other words, implement their own policy?
I have not yet decided which scripting language to use to generate the individual library settings from policies, but the idea is to allow policies to be added.
However, it is not my intention to use that framework for custom policies primarily. My goal is to be able to handle 99% percent of the common use-cases with these three policies.
As these levels will be a moving target across releases (will provide defaults that reflect the current state of the art), levels of previous fedora releases will be referenced as LEVELNAME-F21.
While "self-updating" policies are quite nice, I can see people not trusting them (either as this implies that they will change, or that they are not strict enough). That's why I think "security level" policies would be better. With probably the LEGACY, DEFAULT and FUTURE defined as aliases that will change.
In effect these will be aliases, e.g., LEGACY is an alias for LEGACY-F21 in fedora 21, and an alias for LEGACY-F22 in 22. Does this align with what you suggest?
Either way, the file in which the configuration is going to take place should either contain a detailed description of available policies or a reference to the appropriate man page.
Indeed.
I think we should do a 767, 1023 and 2047 as the values for RSA and DH, some implementations (most common being Cisco routers) regularly generate "off-by-one" RSA sizes.
ok.
=====FUTURE======
[...]
MACs: SHA1+ Curves: All supported Signature algorithms: must use SHA-256 hash or better Ciphers: AES-GCM, AES-CBC, CAMELLIA-GCM, CAMELLIA-CBC Key exchange: ECDHE, RSA, DHE DH params size: 2048+ RSA params size: 2048+ SSL Protocols: TLS1.1+
Shouldn't DH params and RSA params at 128 bit be 3072 bit in size? And ECDSA curves at least 256 bit in size? (While we don't ship any in Fedora now, it may change in future and it doesn't hurt to codify that in policy.)
Nice catch. Corrected.
regards, Nikos
----- Original Message -----
From: "Nikos Mavrogiannopoulos" nmav@redhat.com To: "Hubert Kario" hkario@redhat.com Cc: security@lists.fedoraproject.org Sent: Thursday, 27 March, 2014 2:39:37 PM Subject: Re: available crypto policies
On Thu, 2014-03-27 at 09:13 -0400, Hubert Kario wrote:
----- Original Message -----
From: "Nikos Mavrogiannopoulos" nmav@redhat.com To: security@lists.fedoraproject.org Sent: Thursday, 27 March, 2014 12:13:33 PM Subject: available crypto policies
Hello, For the purposes of the Crypto Policies change proposal [0], I think I've settled to the following three policy levels (inspired by the ENISA levels but with a rename of the good LEGACY level to DEFAULT). Any comments or suggestions are appreciated.
Can you give reasons why you want to limit the number of provided policies?
We must have a reasonable number of policies for the user to select, that address common use-cases. If I had presented a list of 2^16 policies, an administrator would need an expert to translate the various available options. I do expect though more policies to be added by time if this feature proves useful.
I was thinking more on the lies of "provide ~10 policies but strongly recommend using the DEFAULT as the policy with reasonable security and compatibility". But giving just few that are most likely going to be used and having the possibility to add more is a good starting point.
Do you plan some other mechanism for people to enforce strict FIPS guidelines, 128 bit security level or Suite B crypto? In other words, implement their own policy?
I have not yet decided which scripting language to use to generate the individual library settings from policies, but the idea is to allow policies to be added.
However, it is not my intention to use that framework for custom policies primarily. My goal is to be able to handle 99% percent of the common use-cases with these three policies.
The devil is in the details as they say, and some people may have very weird requirements (e.g. if auditors don't fully understand the intent of some recommendations) so the configurability of it may actually be the main selling point.
As far as scripting language: I don't think it will actually be necessary, the set of algorithms supported by the libraries is closed and limited, so with the exception of RSA and DH sizes, it should be possible to explicitly list the allowed algorithms at specific levels. In case of RSA and DH a set of "<=", "<", ">", ">=", "==", "&&", "||" should be enough. Specific cipher ordering may be achievable only using enumeration...
As these levels will be a moving target across releases (will provide defaults that reflect the current state of the art), levels of previous fedora releases will be referenced as LEVELNAME-F21.
While "self-updating" policies are quite nice, I can see people not trusting them (either as this implies that they will change, or that they are not strict enough). That's why I think "security level" policies would be better. With probably the LEGACY, DEFAULT and FUTURE defined as aliases that will change.
In effect these will be aliases, e.g., LEGACY is an alias for LEGACY-F21 in fedora 21, and an alias for LEGACY-F22 in 22. Does this align with what you suggest?
I meant "DEFAULT" being alias for "LEVEL-80". But yes, providing LEGACY as an alias for LEGACY-F22 *in* F22 is a very good idea.
Hi,
I went and extended the scanning script from https://jve.linuxwall.info/blog/index.php?post/TLS_Survey and performed the same scan again.
The most important change is that I captured also the information about the used certificate by server (both the key size, signature and if it links to trust anchors we distribute in F19). That makes the cohort significantly different (my 305280 valid servers vs Julien Vehent's 451470 SSL-enabled servers).
The results are both good and bad.
The bad: 1. Over 10% of servers prefer RC4 with TLS1.1 or TLS1.2 (!!) 2. 1.77% of servers support only RC4 (which is an increase from Julien scan result of 1.5%) 3. Nearly 20% of servers prefer RC4 4. There are still servers that support *only* SSLv2 5. Nearly 95% of servers have certificates signed with SHA-1 6. Over 30% of servers prefer PFS with 1024 bit DH params 7. 15% of servers enable export suites 8. 19% enable single DES suites 9. 3% of servers support only 3DES ciphers
The good: 1. There are no servers with valid certificates and <1024 bit RSA keys 2. While there are quite a few servers that use 768bit or 512bit DH (about 0.2%) very few of them actually prefer them (0.023%) 3. There are no servers with certificates with md5 signatures 4. Nearly 50% of servers support TLS1.1 or greater 5. Over 99% of servers use at least 2047 bit RSA certificates
Note that the results do not include results from SNI-only servers. Also, for some reason google servers like YouTube don't present ECDSA certificates to the script.
SSL/TLS survey of 305280 websites from Alexa's top 0.97 million Stats only from connections that did provide valid certificates (or anonymous DH from servers that do also have valid certificate installed)
Supported Ciphers Count Percent -------------------------+---------+------- 3DES 274509 89.9204 3DES Only 9642 3.1584 AES 277201 90.8022 AES Only 523 0.1713 AES-CBC Only 267 0.0875 AES-GCM 100595 32.9517 AES-GCM Only 12 0.0039 CAMELLIA 112135 36.7319 CAMELLIA Only 1 0.0003 CHACHA20 19072 6.2474 RC4 268298 87.8859 RC4 Only 5418 1.7748 RC4 Preferred 59552 19.5073 RC4 forced in TLS1.1+ 31737 10.396 z:ADH-DES-CBC-SHA 1016 0.3328 z:ADH-SEED-SHA 795 0.2604 z:AECDH-NULL-SHA 8 0.0026 z:DES-CBC-MD5 279 0.0914 z:DES-CBC-SHA 60744 19.8978 z:DHE-RSA-SEED-SHA 46262 15.154 z:ECDHE-RSA-NULL-SHA 6 0.002 z:EDH-RSA-DES-CBC-SHA 49529 16.2241 z:EXP-ADH-DES-CBC-SHA 624 0.2044 z:EXP-DES-CBC-SHA 49850 16.3293 z:EXP-EDH-RSA-DES-CBC-SHA 36180 11.8514 z:EXP-RC2-CBC-MD5 47372 15.5176 z:IDEA-CBC-MD5 28 0.0092 z:IDEA-CBC-SHA 44932 14.7183 z:NULL-MD5 322 0.1055 z:NULL-SHA 317 0.1038 z:NULL-SHA256 11 0.0036 z:RC2-CBC-MD5 307 0.1006 z:SEED-SHA 59061 19.3465
Supported Handshakes Count Percent -------------------------+---------+------- DHE 144983 47.4918 DHE and ECDHE 33828 11.081 ECDHE 113831 37.2874
Supported PFS Count Percent PFS Percent -------------------------+---------+--------+----------- DH,1024bits 138534 45.3793 61.5745 DH,2048bits 5471 1.7921 2.4317 DH,3072bits 2 0.0007 0.0009 DH,3248bits 2 0.0007 0.0009 DH,4094bits 1 0.0003 0.0004 DH,4096bits 250 0.0819 0.1111 DH,512bits 78 0.0256 0.0347 DH,768bits 651 0.2132 0.2894 ECDH,B-163,163bits 1 0.0003 0.0004 ECDH,B-571,570bits 279 0.0914 0.124 ECDH,P-224,224bits 3 0.001 0.0013 ECDH,P-256,256bits 113201 37.081 50.3147 ECDH,P-384,384bits 138 0.0452 0.0613 ECDH,P-521,521bits 266 0.0871 0.1182 Prefer DH,1024bits 99280 32.521 44.1272 Prefer DH,2048bits 1848 0.6053 0.8214 Prefer DH,4096bits 12 0.0039 0.0053 Prefer DH,512bits 1 0.0003 0.0004 Prefer DH,768bits 72 0.0236 0.032 Prefer ECDH,B-163,163bits 1 0.0003 0.0004 Prefer ECDH,B-571,570bits 226 0.074 0.1005 Prefer ECDH,P-256,256bits 80220 26.2775 35.6556 Prefer ECDH,P-384,384bits 84 0.0275 0.0373 Prefer ECDH,P-521,521bits 246 0.0806 0.1093 Prefer PFS 181990 59.6141 80.8895 Support PFS 224986 73.6982 100.0
Certificate sig alg Count Percent -------------------------+---------+-------- None 11870 3.8882 sha1WithRSAEncryption 289276 94.7576 sha256WithRSAEncryption 16033 5.2519
Certificate key size Count Percent -------------------------+---------+-------- RSA 1024 2098 0.6872 RSA 2028 1 0.0003 RSA 2047 3 0.001 RSA 2048 295413 96.7679 RSA 2049 4 0.0013 RSA 2056 3 0.001 RSA 2058 1 0.0003 RSA 2060 1 0.0003 RSA 2064 1 0.0003 RSA 2080 3 0.001 RSA 2084 2 0.0007 RSA 2345 1 0.0003 RSA 2408 1 0.0003 RSA 2432 88 0.0288 RSA 2536 1 0.0003 RSA 2612 1 0.0003 RSA 3000 1 0.0003 RSA 3050 1 0.0003 RSA 3072 18 0.0059 RSA 3248 2 0.0007 RSA 3600 1 0.0003 RSA 4042 1 0.0003 RSA 4048 1 0.0003 RSA 4069 1 0.0003 RSA 4086 1 0.0003 RSA 4092 2 0.0007 RSA 4096 7634 2.5007 RSA 4098 1 0.0003 RSA 4192 2 0.0007 RSA 8192 4 0.0013 RSA/ECDSA Dual Stack 0 0.0
Supported Protocols Count Percent -------------------------+---------+------- SSL2 644 0.211 SSL2 Only 20 0.0066 SSL3 303052 99.2702 SSL3 Only 3706 1.214 SSL3 or TLS1 Only 155876 51.06 TLS1 301098 98.6301 TLS1 Only 673 0.2205 TLS1.1 136386 44.6757 TLS1.1 Only 4 0.0013 TLS1.1 or up Only 60 0.0197 TLS1.2 144857 47.4505 TLS1.2 Only 45 0.0147 TLS1.2, 1.0 but not 1.1 12292 4.0265
(the scan was performed between 5th and 17th of April 2014, full results available on request - 34MiB xz tarball)
On Fri, 2014-04-25 at 10:34 -0400, Hubert Kario wrote:
Hi,
I went and extended the scanning script from https://jve.linuxwall.info/blog/index.php?post/TLS_Survey and performed the same scan again.
The most important change is that I captured also the information about the used certificate by server (both the key size, signature and if it links to trust anchors we distribute in F19). That makes the cohort significantly different (my 305280 valid servers vs Julien Vehent's 451470 SSL-enabled servers).
The results are both good and bad.
The bad:
- Over 10% of servers prefer RC4 with TLS1.1 or TLS1.2 (!!)
- 1.77% of servers support only RC4 (which is an increase from Julien scan result of 1.5%)
- Nearly 20% of servers prefer RC4
- There are still servers that support *only* SSLv2
- Nearly 95% of servers have certificates signed with SHA-1
- Over 30% of servers prefer PFS with 1024 bit DH params
- 15% of servers enable export suites
- 19% enable single DES suites
- 3% of servers support only 3DES ciphers
The good:
- There are no servers with valid certificates and <1024 bit RSA keys
- While there are quite a few servers that use 768bit or 512bit DH (about 0.2%) very few of them actually prefer them (0.023%)
- There are no servers with certificates with md5 signatures
- Nearly 50% of servers support TLS1.1 or greater
- Over 99% of servers use at least 2047 bit RSA certificates
Note that the results do not include results from SNI-only servers. Also, for some reason google servers like YouTube don't present ECDSA certificates to the script.
Very nice work.
SSL/TLS survey of 305280 websites from Alexa's top 0.97 million Stats only from connections that did provide valid certificates (or anonymous DH from servers that do also have valid certificate installed)
RC4 Only 5418 1.7748
That's pretty interesting. The question is now how important is that RC4 only segment. Is that percentage significant enough to revise having RC4 in the "default" crypto profile set?
btw. I've put the policy generation code in: https://git.fedorahosted.org/git/crypto-profiles.git
It currently generates policies for gnutls (in rawhide) and for openssl (which will support that in rawhide). NSS should follow, hopefully, before the F21 release (patches are available but are not upstream yet).
regards, Nikos
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Mon, May 05, 2014 at 11:50:48AM +0200, Nikos Mavrogiannopoulos wrote:
On Fri, 2014-04-25 at 10:34 -0400, Hubert Kario wrote:
SSL/TLS survey of 305280 websites from Alexa's top 0.97 million Stats only from connections that did provide valid certificates (or anonymous DH from servers that do also have valid certificate installed)
RC4 Only 5418 1.7748
That's pretty interesting. The question is now how important is that RC4 only segment. Is that percentage significant enough to revise having RC4 in the "default" crypto profile set?
Revise how? RC4 should be dropped down to EXPORT status, IMO, but somehow lives on.
I believe Hubert is having this conversation with OpenSSL devels now...
- --Eric
- -------------------------------------------------- Eric "Sparks" Christensen Red Hat, Inc - Product Security Team
sparks@redhat.com - sparks@fedoraproject.org 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - --------------------------------------------------
Eric H. Christensen wrote:
On Mon, May 05, 2014 at 11:50:48AM +0200, Nikos Mavrogiannopoulos wrote:
On Fri, 2014-04-25 at 10:34 -0400, Hubert Kario wrote:
SSL/TLS survey of 305280 websites from Alexa's top 0.97 million Stats only from connections that did provide valid certificates (or anonymous DH from servers that do also have valid certificate installed) RC4 Only 5418 1.7748
That's pretty interesting. The question is now how important is that RC4 only segment. Is that percentage significant enough to revise having RC4 in the "default" crypto profile set?
Revise how? RC4 should be dropped down to EXPORT status, IMO, but somehow lives on.
+1. Not quite sure why it's still in the TLS 1.3 draft.
Aaron
On Mon, 2014-05-05 at 16:46 +0200, Aaron Zauner wrote:
Eric H. Christensen wrote:
On Mon, May 05, 2014 at 11:50:48AM +0200, Nikos Mavrogiannopoulos wrote:
On Fri, 2014-04-25 at 10:34 -0400, Hubert Kario wrote:
SSL/TLS survey of 305280 websites from Alexa's top 0.97 million Stats only from connections that did provide valid certificates (or anonymous DH from servers that do also have valid certificate installed) RC4 Only 5418 1.7748
That's pretty interesting. The question is now how important is that RC4 only segment. Is that percentage significant enough to revise having RC4 in the "default" crypto profile set?
Revise how? RC4 should be dropped down to EXPORT status, IMO, but somehow lives on.
+1. Not quite sure why it's still in the TLS 1.3 draft.
This is not about the TLS protocol in 5 years, but about the ciphers that we will make available in Fedora 21 by default this autumn. If the default settings disallow RC4 it means that the users of Fedora will not be able to connect to the 1.7748% of this list of web servers.
That is, no HTTPS connection at all for 17215 servers; only plaintext. If that list contains some popular HTTPS servers, we'll have: 1. Users connecting with no security at all to these web sites. 2. Users relaxing the overall security level from DEFAULT -> LEGACY 3. Users switching to some other distribution that things just work.
I don't like any of these possibilities if they apply to a major part of our users. The DEFAULT setting should apply to 99% of our users.
We need to know what removing RC4 from the default list entails. Knowing which these 17215 servers are, and their ranking in that list would certainly help decide.
regards, Nikos
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Mon, May 05, 2014 at 05:11:04PM +0200, Nikos Mavrogiannopoulos wrote:
That is, no HTTPS connection at all for 17215 servers; only plaintext.
No, if your website is protected by SSL there should be no option for plaintext. None.
- Users relaxing the overall security level from DEFAULT -> LEGACY
That's what we're already doing by allowing RC4 in DEFAULT settings. It's a bad cipher. Luckily we can rearrange ciphers to use betters ones before RC4. The problem is servers who don't use HIGH or DEFAULT settings but rather cherry pick ciphers outside of their understanding and end up with bad choices.
- Users switching to some other distribution that things just work.
This is being done upstream of Fedora. Again, this is really a problem for server-side installations and less with client side installations.
We need to know what removing RC4 from the default list entails. Knowing which these 17215 servers are, and their ranking in that list would certainly help decide.
It would be very interesting to see what servers are only supporting RC4 and ask them why they don't wish to use DEFAULT.
- -- Eric
- -------------------------------------------------- Eric "Sparks" Christensen Red Hat, Inc - Product Security Team
sparks@redhat.com - sparks@fedoraproject.org 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - --------------------------------------------------
On Mon, 2014-05-05 at 11:30 -0400, Eric H. Christensen wrote:
- Users switching to some other distribution that things just work.
This is being done upstream of Fedora.
The crypto policy is about fedora, we are upstream on that. https://fedoraproject.org/wiki/Changes/CryptoPolicy
regards, Nikos
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Mon, May 05, 2014 at 06:07:31PM +0200, Nikos Mavrogiannopoulos wrote:
On Mon, 2014-05-05 at 11:30 -0400, Eric H. Christensen wrote:
- Users switching to some other distribution that things just work.
This is being done upstream of Fedora.
The crypto policy is about fedora, we are upstream on that. https://fedoraproject.org/wiki/Changes/CryptoPolicy
Yes, and this is largely going to be a server-side change. The default policy is none (meaning whatever the software wants to do).
- -- Eric
- -------------------------------------------------- Eric "Sparks" Christensen Red Hat, Inc - Product Security Team
sparks@redhat.com - sparks@fedoraproject.org 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - --------------------------------------------------
On Mon, 2014-05-05 at 12:16 -0400, Eric H. Christensen wrote:
- Users switching to some other distribution that things just work.
This is being done upstream of Fedora.
The crypto policy is about fedora, we are upstream on that. https://fedoraproject.org/wiki/Changes/CryptoPolicy
Yes, and this is largely going to be a server-side change. The default policy is none (meaning whatever the software wants to do).
Could you please elaborate on what you mean above? The default policy will not be none after the change. This is the whole purpose of the change.
regards, Nikos
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Mon, May 05, 2014 at 06:19:01PM +0200, Nikos Mavrogiannopoulos wrote:
On Mon, 2014-05-05 at 12:16 -0400, Eric H. Christensen wrote:
- Users switching to some other distribution that things just work.
This is being done upstream of Fedora.
The crypto policy is about fedora, we are upstream on that. https://fedoraproject.org/wiki/Changes/CryptoPolicy
Yes, and this is largely going to be a server-side change. The default policy is none (meaning whatever the software wants to do).
Could you please elaborate on what you mean above? The default policy will not be none after the change. This is the whole purpose of the change.
Wow, this feature has changed since the last time I looked at it. I was under the impression this would only be used to force compliance with security policies. Nonetheless, I don't disagree with DEFAULT, here. Using RC4 and MD5 is just asking for trouble. Sure, it might break some things but 1) those sites should be fixed and 2) using RC4 and MD5 is just providing a false sense of security. A line should be drawn somewhere. Again, it's 2014... stop making bad crypto decisions.
- -- Eric
- -------------------------------------------------- Eric "Sparks" Christensen Red Hat, Inc - Product Security Team
sparks@redhat.com - sparks@fedoraproject.org 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - --------------------------------------------------
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Mon, May 05, 2014 at 05:11:04PM +0200, Nikos Mavrogiannopoulos wrote:
- Users switching to some other distribution that things just work.
I should probably also point out that the other distribution shouldn't be a Microsoft product. Microsoft Windows 8.x doesn't support RC4, upcoming versions of Microsoft Windows 7 will also stop supporting RC4. I suspect those 5000 RC4-only sites will soon update their settings.
- -- Eric
- -------------------------------------------------- Eric "Sparks" Christensen Red Hat, Inc - Product Security Team
sparks@redhat.com - sparks@fedoraproject.org 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - --------------------------------------------------
----- Original Message -----
From: "Eric H. Christensen" sparks@fedoraproject.org To: "Nikos Mavrogiannopoulos" nmav@redhat.com Cc: security@lists.fedoraproject.org Sent: Monday, May 5, 2014 6:38:40 PM Subject: Re: Fedora crypto policy vs the real world Was: available crypto policies
upcoming versions of Microsoft Windows 7 will also stop supporting RC4
That sounds nearly too good to be true. Source?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Mon, May 05, 2014 at 01:20:17PM -0400, Hubert Kario wrote:
----- Original Message -----
From: "Eric H. Christensen" sparks@fedoraproject.org To: "Nikos Mavrogiannopoulos" nmav@redhat.com Cc: security@lists.fedoraproject.org Sent: Monday, May 5, 2014 6:38:40 PM Subject: Re: Fedora crypto policy vs the real world Was: available crypto policies
upcoming versions of Microsoft Windows 7 will also stop supporting RC4
That sounds nearly too good to be true. Source?
https://technet.microsoft.com/library/security/2868725?altTemplate=SecurityA...
- -- Eric
- -------------------------------------------------- Eric "Sparks" Christensen Red Hat, Inc - Product Security Team
sparks@redhat.com - sparks@fedoraproject.org 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - --------------------------------------------------
On Po, 2014-05-05 at 13:26 -0400, Eric H. Christensen wrote:
On Mon, May 05, 2014 at 01:20:17PM -0400, Hubert Kario wrote:
----- Original Message -----
From: "Eric H. Christensen" sparks@fedoraproject.org To: "Nikos Mavrogiannopoulos" nmav@redhat.com Cc: security@lists.fedoraproject.org Sent: Monday, May 5, 2014 6:38:40 PM Subject: Re: Fedora crypto policy vs the real world Was: available crypto policies
upcoming versions of Microsoft Windows 7 will also stop supporting RC4
That sounds nearly too good to be true. Source?
https://technet.microsoft.com/library/security/2868725?altTemplate=SecurityA...
Huh, but it actually does not disable RC4 support by default. The update just enables possibility to disable it through registry setting or API call.
"What does the 2868725 update do? The update supports the removal of RC4 as an available cipher on affected systems through registry settings. It also allows developers to remove RC4 in individual applications through the use of the SCH_USE_STRONG_CRYPTO flag in the SCHANNEL_CRED structure. These options are not enabled by default. Microsoft recommends that customers test any new settings for disabling RC4 prior to implementing them in their environments."
So no, Windows won't disable RC4 support by default.
----- Original Message -----
From: "Tomas Mraz" tmraz@redhat.com To: "Eric H. Christensen" sparks@fedoraproject.org Cc: "Hubert Kario" hkario@redhat.com, security@lists.fedoraproject.org Sent: Tuesday, 6 May, 2014 10:24:38 AM Subject: Re: Fedora crypto policy vs the real world Was: available crypto policies
On Po, 2014-05-05 at 13:26 -0400, Eric H. Christensen wrote:
On Mon, May 05, 2014 at 01:20:17PM -0400, Hubert Kario wrote:
----- Original Message -----
From: "Eric H. Christensen" sparks@fedoraproject.org To: "Nikos Mavrogiannopoulos" nmav@redhat.com Cc: security@lists.fedoraproject.org Sent: Monday, May 5, 2014 6:38:40 PM Subject: Re: Fedora crypto policy vs the real world Was: available crypto policies
upcoming versions of Microsoft Windows 7 will also stop supporting RC4
That sounds nearly too good to be true. Source?
https://technet.microsoft.com/library/security/2868725?altTemplate=SecurityA...
Huh, but it actually does not disable RC4 support by default. The update just enables possibility to disable it through registry setting or API call.
"What does the 2868725 update do? The update supports the removal of RC4 as an available cipher on affected systems through registry settings. It also allows developers to remove RC4 in individual applications through the use of the SCH_USE_STRONG_CRYPTO flag in the SCHANNEL_CRED structure. These options are not enabled by default. Microsoft recommends that customers test any new settings for disabling RC4 prior to implementing them in their environments."
So no, Windows won't disable RC4 support by default.
nitpick: Windows 7 doesn't disable RC4 support by default. Windows 8 does disable RC4 by default: http://blogs.msdn.com/b/ie/archive/2013/11/12/ie11-automatically-makes-over-...
On Tue, 2014-05-06 at 06:41 -0400, Hubert Kario wrote:
So no, Windows won't disable RC4 support by default.
nitpick: Windows 7 doesn't disable RC4 support by default. Windows 8 does disable RC4 by default: http://blogs.msdn.com/b/ie/archive/2013/11/12/ie11-automatically-makes-over-...
I don't think microsoft would be held as an example, but still they do negotiate RC4, as they re-try connecting using RC4 if the first handshake fails. From a security point of view, their change is useless, as if I can attack RC4, I can simply make the first attempt to connect fail, and attack the second that includes RC4.
Nevertheless, we cannot even do what they do (i.e., reconnect using RC4 as fallback). What we do is to set the bar to either allow RC4 or have a failed connection, and thus force a plaintext session, that is worse than RC4.
regards, Nikos
----- Original Message -----
From: "Nikos Mavrogiannopoulos" nmav@redhat.com To: "Hubert Kario" hkario@redhat.com Cc: "Tomas Mraz" tmraz@redhat.com, security@lists.fedoraproject.org Sent: Tuesday, 6 May, 2014 1:17:13 PM Subject: Re: Fedora crypto policy vs the real world Was: available crypto policies
On Tue, 2014-05-06 at 06:41 -0400, Hubert Kario wrote:
So no, Windows won't disable RC4 support by default.
nitpick: Windows 7 doesn't disable RC4 support by default. Windows 8 does disable RC4 by default: http://blogs.msdn.com/b/ie/archive/2013/11/12/ie11-automatically-makes-over-...
I don't think microsoft would be held as an example, but still they do negotiate RC4, as they re-try connecting using RC4 if the first handshake fails. From a security point of view, their change is useless, as if I can attack RC4, I can simply make the first attempt to connect fail, and attack the second that includes RC4.
Yes, for a dedicated attack, it does not change anything, as it is performing man in the middle anyway. It does help against passive attacker. But I agree, connection retry with different ciphers is bad idea.
Nevertheless, we cannot even do what they do (i.e., reconnect using RC4 as fallback). What we do is to set the bar to either allow RC4 or have a failed connection, and thus force a plaintext session, that is worse than RC4.
Sorry, but how does that force a plaintext session?
There's no plaintext fallback for HTTP. Over HTTP you get a redirection to HTTPS site that simply won't work, no fallback. If the attacker uses sslstrip and you won't notice lack of padlock that's not the fault of RC4.
For connections like LDAP, SMTP, POP3 or IMAP you configure it once to either use or not use SSL. So that's only configuration time attack.
And applications which use opportunistic encryption shouldn't use default cipher order anyway (as default won't ever have anonymous DH).
On Tue, 2014-05-06 at 07:42 -0400, Hubert Kario wrote:
Sorry, but how does that force a plaintext session?
You try to connect to an https site. It doesn't work and an error message is issued that no common ciphers were found. The only thing that you can try as user is fall back to http.
There's no plaintext fallback for HTTP.
I agree there is no automatic fallback, but there will be manual fallback by the users.
And applications which use opportunistic encryption shouldn't use default cipher order anyway (as default won't ever have anonymous DH).
You don't need anonymous DH for opportunistic encryption, and most likely you don't want it either. With anonymous DH (and current implementations) you cannot achieve key continuity, which is the ingredient that makes opportunistic encryption worthwhile.
regards, Nikos
----- Original Message -----
From: "Nikos Mavrogiannopoulos" nmav@redhat.com To: "Hubert Kario" hkario@redhat.com Cc: "Tomas Mraz" tmraz@redhat.com, security@lists.fedoraproject.org Sent: Tuesday, 6 May, 2014 2:31:12 PM Subject: Re: Fedora crypto policy vs the real world Was: available crypto policies
On Tue, 2014-05-06 at 07:42 -0400, Hubert Kario wrote:
Sorry, but how does that force a plaintext session?
You try to connect to an https site. It doesn't work and an error message is issued that no common ciphers were found. The only thing that you can try as user is fall back to http.
That would require the site to be available over HTTP and HTTPS. All sites that want HTTPS redirect all request given over HTTP to HTTPS site, so you can't manually downgrade them. That means the only users that use the HTTPS version are probably people that have installed HTTPS everywhere extension - not the average user.
On Tue, 2014-05-06 at 09:32 -0400, Hubert Kario wrote:
That would require the site to be available over HTTP and HTTPS. All sites that want HTTPS redirect all request given over HTTP to HTTPS site, so you can't manually downgrade them. That means the only users that use the HTTPS version are probably people that have installed HTTPS everywhere extension - not the average user.
Hubert, I believe we are discussing in vain. Yes indeed the scenario you mention could happen _if_ the http site redirects to https, but this is not universal, and even if it is, the user will be unable to connect to that web site at all with Fedora.
I have no particular interest in enabling RC4 if that's not needed; it is a cipher that has been shown to be broken. Our goal, however, is to define a conservative behavior that provides a good balance between security and usability. If we fail that we force the users to switch to using plaintext connections or (better) to the 'legacy' level. Switching all applications that use this policy to legacy level is worse than just allowing RC4 as it reduces the security of all sessions and not only the sessions that negotiate RC4.
What we need to know to decide is information about the specific servers that only require RC4. What is their ranking on the Alexa top 0.97 million list that you mentioned. Are they on the bottom or on the top 100 of the list? Do we have that information?
regards, Nikos
----- Original Message -----
From: "Nikos Mavrogiannopoulos" nmav@redhat.com To: "Hubert Kario" hkario@redhat.com Cc: "Tomas Mraz" tmraz@redhat.com, security@lists.fedoraproject.org Sent: Tuesday, May 6, 2014 4:09:25 PM Subject: Re: Fedora crypto policy vs the real world Was: available crypto policies
What we need to know to decide is information about the specific servers that only require RC4. What is their ranking on the Alexa top 0.97 million list that you mentioned. Are they on the bottom or on the top 100 of the list? Do we have that information?
the top 100 I provided is the 100 highest ranked sites (according to Alexa), their rank is the number before comma.
in other words: 396,adultfriendfinder.com means that adultfriendfinder.com is this highest ranked site that enables only RC4, its rank is 396 in the Alexa list.
----- Original Message -----
From: "Nikos Mavrogiannopoulos" nmav@redhat.com To: "Aaron Zauner" azet@azet.org Cc: "Hubert Kario" hkario@redhat.com, security@lists.fedoraproject.org Sent: Monday, May 5, 2014 5:11:04 PM Subject: Re: Fedora crypto policy vs the real world Was: available crypto policies
On Mon, 2014-05-05 at 16:46 +0200, Aaron Zauner wrote:
Eric H. Christensen wrote:
On Mon, May 05, 2014 at 11:50:48AM +0200, Nikos Mavrogiannopoulos wrote:
On Fri, 2014-04-25 at 10:34 -0400, Hubert Kario wrote:
SSL/TLS survey of 305280 websites from Alexa's top 0.97 million Stats only from connections that did provide valid certificates (or anonymous DH from servers that do also have valid certificate installed) RC4 Only 5418 1.7748
That's pretty interesting. The question is now how important is that RC4 only segment. Is that percentage significant enough to revise having RC4 in the "default" crypto profile set?
Revise how? RC4 should be dropped down to EXPORT status, IMO, but somehow lives on.
+1. Not quite sure why it's still in the TLS 1.3 draft.
This is not about the TLS protocol in 5 years, but about the ciphers that we will make available in Fedora 21 by default this autumn. If the default settings disallow RC4 it means that the users of Fedora will not be able to connect to the 1.7748% of this list of web servers.
That is, no HTTPS connection at all for 17215 servers; only plaintext. If that list contains some popular HTTPS servers, we'll have:
- Users connecting with no security at all to these web sites.
- Users relaxing the overall security level from DEFAULT -> LEGACY
- Users switching to some other distribution that things just work.
I don't like any of these possibilities if they apply to a major part of our users. The DEFAULT setting should apply to 99% of our users.
We need to know what removing RC4 from the default list entails. Knowing which these 17215 servers are, and their ranking in that list would certainly help decide.
In my opinion, Fedora, as a security concious distribution, should follow Microsoft example and remove RC4 from default too. Protecting users of 18% of web servers is worth the problems it may cause.
Note that the results are from connections that were forced to use SSL, not ones that were redirected to SSL.
We can either provide false sense of security to users of those 1.7% of sites or provide much better security to users of nearly 18% of sites that also support other cipher suites. Because of Windows 8 (both mobile and desktop), the 1.7% number will be going down, not up.
For example, the highest ranked sites that did support only RC4 were: 396,adultfriendfinder.com 499,typepad.com - now fixed 592,timeanddate.com - now fixed 791,priceline.com 853,inbox.com 975,lacaixa.es 985,squarespace.com 1204,aa.com 1434,xiaomi.com 1590,cvs.com Neither of those redirect to SSL by default.
RC4 is broken. While the latest attack against it does require few million connections (which we know that some actors already do collect) it also, for all intents and purposes, has computational complexity of 0. Researchers performed only 256 tries for their guesses - that's 8bit computational complexity for the attack.
They did use only double byte biases and assumed completely random plaintext (no "GET / HTTP/1.1" or "EHLO smtp.example.com"). So this was not entirely a detailed cryptanalysis, large parts of it were simple brute force.
Also note that a service that connects to a site every minute for a year will reach the needed threshold for the easiest attack that recovers "only" 3 bytes with 100% accuracy.
Now, unless someone has done the maths, I'm going to use conservative estimate and assume a one to one ratio for memory-time trade off. That means that RC4 has 38 bit computational complexity of attack for a capture of just few connections. That's export grade crypto level.
Top 100 sites that supported only RC4 ciphers: 396,adultfriendfinder.com 499,typepad.com 592,timeanddate.com 791,priceline.com 853,inbox.com 975,lacaixa.es 985,squarespace.com 1204,aa.com 1434,xiaomi.com 1590,cvs.com 1641,orbitz.com 1900,directv.com 1942,siteground.com 2108,warriorplus.com 2242,tharunaya.co.uk 2398,mmotraffic.com 2769,frys.com 3041,arbeitsagentur.de 3720,geico.com 3740,freelifetimefuckbook.com 3970,fancy.com 4176,readwrite.com 5495,kankanews.com 5554,o2.co.uk 5636,kaiserpermanente.org 5717,fonts.com 5997,blogs.com 6316,live365.com 6550,internations.org 6647,cheaptickets.com 6684,usc.edu 7469,fssnet.co.in 7599,trojmiasto.pl 7667,streeteasy.com 7711,geni.com 7928,softaculous.com 8035,siemens.com 8106,tim.com.br 8256,hornywife.com 8259,path.com 8299,xmatch.com 8459,xojane.com 8649,worldwinner.com 8717,tanga.com 8847,mtwebcenters.com.tw 8964,farnell.com 9461,grosbill.com 9566,boe.es 9797,westfield.com 9805,seur.com 10163,uggaustralia.com 10308,ultracart.com 10505,thetaoofbadass.com 11179,bankofthewest.com 11330,singlehop.com 11429,kay.com 11887,commonapp.org 11889,halkbank.com.tr 12008,autocarindia.com 12223,zavvi.com 12239,reachlocal.com 12283,wine.com 12426,gotprint.net 12773,bigbasket.com 13273,squarefree.com 13326,wantickets.com 13395,magicjack.com 13736,fossil.com 13760,geektyrant.com 14451,oculusvr.com 14538,nuskin.com 14646,flyaerlingus.com 14922,feelunique.com 14966,dollarshaveclub.com 15231,penthouse.com 15393,website.ws 15423,thehut.com 15807,mikrotik.com 15909,autoanything.com 16042,calguns.net 16099,elanceonline.com 16126,clixtrac.com 16276,whotrades.com 16499,centerparcs.com 16531,datingtorelating.com 16716,bnonline.fi.cr 17315,myprotein.com 17552,brownells.com 17698,htmldog.com 17862,christianitytoday.com 17891,ebookers.com 18067,bankcardservices.co.uk 18122,hotforex.com 18251,reginaldchan.net 18266,e-sixt.de 18342,mojebanka.cz 18486,help.squarespace.com 18541,bevmo.com 18578,interspire.com 18584,getiton.com
On Mon, 5 May 2014, Hubert Kario wrote:
We can either provide false sense of security to users of those 1.7% of sites or provide much better security to users of nearly 18% of sites that also support other cipher suites.
IMHO, it is a situation similar to, say, the case when you get an expired server certificate. The program should refuse to talk to such server by default but it should explain the problem to the user and make it possible to override the default policy (*).
(*) Yes, I am *painfully aware* that 99 out of 100 users are idiots who should never be trusted to make such decisions but I think we'd better leave the business of making software attempting to compensate for intellectual deficiencies of its user to, ahem, certain other vendors.
RC4 is broken. While the latest attack against it does require few million connections (which we know that some actors already do collect) it also, for all intents and purposes, has computational complexity of 0. Researchers performed only 256 tries for their guesses - that's 8bit computational complexity for the attack.
Well, you need to process those millions of collected ciphertexts too... But yes, ~10^6 ops are still close enough to zero nowadays.
Also note that a service that connects to a site every minute for a year will reach the needed threshold for the easiest attack that recovers "only" 3 bytes with 100% accuracy.
You assume the client keeps sending the same secret data for a year. This might be possible just as it might be possible to coax the client to spam the server with a rapid sequence of repeated requests but (in both cases) with the important "under certain circumstances" qualification.
Also, perfect 100% accuracy (= zero probability of error) is impossible (see below) but you can get as close as you desire.
Now, unless someone has done the maths, I'm going to use conservative estimate and assume a one to one ratio for memory-time trade off. That means that RC4 has 38 bit computational complexity of attack for a capture of just few connections. That's export grade crypto level.
I might have missed something here but I am afraid you are mistaken. As far I know the attack--or its simple single-byte variant--works as follows:
You are interested in some byte b of plaintext that its transmitted repeatedly and you know it always corresponds to n-th byte of ciphertext. You assume some prior probability distribution P(b = x) of possible values of b.
You observe the interesting byte c of ciphertext and get the probability distribution P(k_n = y) of the n-th byte of keystream, assuming a randomly chosen keys. Compute the posterior prob. distribution P' for values of b assuming ciphertext c by Bayesian inference.
The result would be the same as the original of P(b = x) if P(k_n = y) were uniform. But it is biased and this makes some values of the unknown plaintext byte b slightly more probable a posteriori than they were a priori (at the expense of other values). Repeat (with priors replaced by posteriors) with more ciphertexts until the probability of one value grows large enough.
(AlFardan et al. describe a different and possibly somewhat more efficient approach to find the maximum-likelihood choice of a plaintext byte.)
If you capture "just few" connections you do not collect enough information to distinguish between the correct value and incorrect values, and no amount of computing power will help you (that is unless you have got enough to crack the cipher directly).
----- Original Message -----
From: "Pavel Kankovsky" peak@argo.troja.mff.cuni.cz To: "Hubert Kario" hkario@redhat.com Cc: security@lists.fedoraproject.org Sent: Monday, 5 May, 2014 11:02:18 PM Subject: Re: Fedora crypto policy vs the real world Was: available crypto policies
On Mon, 5 May 2014, Hubert Kario wrote:
We can either provide false sense of security to users of those 1.7% of sites or provide much better security to users of nearly 18% of sites that also support other cipher suites.
IMHO, it is a situation similar to, say, the case when you get an expired server certificate. The program should refuse to talk to such server by default but it should explain the problem to the user and make it possible to override the default policy (*).
Firefox does say that the communication is impossible because the server does not support the same encryption algorithms as the client.
There is no option to override. The problem is that the server won't tell you which ciphers it wants (it may be RC4, it may be single DES...). Firefox does tell you that you should contact the web site owner and tell him about the problem.
Also note that a service that connects to a site every minute for a year will reach the needed threshold for the easiest attack that recovers "only" 3 bytes with 100% accuracy.
You assume the client keeps sending the same secret data for a year.
Who changes passwords for an automated service on frequency higher than once a year? It's set it and forget it (or are you trying to tell me that you and all the people you know do change email passwords every 1-3 months?).
Also, perfect 100% accuracy (= zero probability of error) is impossible (see below) but you can get as close as you desire.
Oh, sure, there is a chance that the attacker will guess AES-128 encryption key in first try. But I'd guess that the probability of that is not much lower than the probability of random bit flip occurring during password checking caused by cosmic radiation and letting you through even though you provided wrong password.
On the other hand, breaking RC4 has probability closer to winning the National Lottery than random bit flips. The former is likely, the latter unlikely.
Now, unless someone has done the maths, I'm going to use conservative estimate and assume a one to one ratio for memory-time trade off. That means that RC4 has 38 bit computational complexity of attack for a capture of just few connections. That's export grade crypto level.
I might have missed something here but I am afraid you are mistaken. As far I know the attack--or its simple single-byte variant--works as follows:
You are interested in some byte b of plaintext that its transmitted repeatedly and you know it always corresponds to n-th byte of ciphertext. You assume some prior probability distribution P(b = x) of possible values of b.
You observe the interesting byte c of ciphertext and get the probability distribution P(k_n = y) of the n-th byte of keystream, assuming a randomly chosen keys. Compute the posterior prob. distribution P' for values of b assuming ciphertext c by Bayesian inference.
The result would be the same as the original of P(b = x) if P(k_n = y) were uniform. But it is biased and this makes some values of the unknown plaintext byte b slightly more probable a posteriori than they were a priori (at the expense of other values). Repeat (with priors replaced by posteriors) with more ciphertexts until the probability of one value grows large enough.
(AlFardan et al. describe a different and possibly somewhat more efficient approach to find the maximum-likelihood choice of a plaintext byte.)
If you capture "just few" connections you do not collect enough information to distinguish between the correct value and incorrect values, and no amount of computing power will help you (that is unless you have got enough to crack the cipher directly).
That's correct for attack that uses just single byte biases, there are also double byte biases in RC4 output: http://www.mindspring.com/~dmcgrew/rc4-03.pdf
Like I said, the attacks assume random plaintext. While in reality, all plaintexts have internal structure (the protocol used, be it HTTP, SMTP or POP3). Coupled with double byte biases you are able to recover unknown, but unchanging (like passwords or pre shared keys), bytes of plaintext.
And in case of passwords, just information that a set of characters is more likely at a given position is of huge advantage.
On Tue, 6 May 2014, Hubert Kario wrote:
Firefox does say that the communication is impossible because the server does not support the same encryption algorithms as the client.
There is no option to override. The problem is that the server won't tell you which ciphers it wants (it may be RC4, it may be single DES...).
The server won't tell it explicitly but the client can play some trial-and-error. IMHO, two steps would be sufficient: First, try to connect with secure ciphersuites. If it fails, try again with, ahem, less secure ciphersuites, and warn the user.
(You may object that an encrypted connection is supposed to be simply secure, not more secure or less secure, but I am afraid that ship has already sailed with things like EV certs aboard.)
Such a feature would become useful again when it will be necessary to phase out other ciphersuites (or protocol versions) in the future.
Firefox does tell you that you should contact the web site owner and tell him about the problem.
...while the said contact is published on the site I am not allowed to access. :)
You assume the client keeps sending the same secret data for a year.
Who changes passwords for an automated service on frequency higher than once a year? It's set it and forget it (or are you trying to tell me that you and all the people you know do change email passwords every 1-3 months?).
You argue that RC4 is not secure when used in a certain manner. I agree.
But I wanted to point out that there are other applications whose modus operandi is less conductive to attacks on RC4 and that an unconditional ban on the use of RC4 might perhaps be too drastic. (In fact, I am quite familiar with one of the web apps on your list and I dare to say it is very unlikely anyone will be able to exploit (known) weaknesses in RC4 to do anything serious.)
BTW: If it's "set it and forget it" then passwords might not be the best authentication method...
That's correct for attack that uses just single byte biases, there are also double byte biases in RC4 output: http://www.mindspring.com/~dmcgrew/rc4-03.pdf
Indeed, there are double-byte biases but their nature is similar. The only important twists are: 1. they are not restricted to the initial part of the keystream and 2. pairs of bytes can overlap (see below).
Like I said, the attacks assume random plaintext. While in reality, all plaintexts have internal structure (the protocol used, be it HTTP, SMTP or POP3). Coupled with double byte biases you are able to recover unknown, but unchanging (like passwords or pre shared keys), bytes of plaintext.
Let us assume we need to collect 2^20 ciphertexts to guess a certain plaintext byte (with probability very close to 1) with no prior information about the byte (in order words: our prior probability distribution is uniform for all values from 0 to 255). This means that the average information content we can extract from one ciphertext is 8 / 2^20 = 2^-17 bits. Yes, a tiny fraction of a bit.
If you start with some nontrivial priors (e.g. an assumption that the byte is an ASCII code of an alphanumeric character), you reduce the total amount of information you need to collect but the reduction is proportional to the fraction of bits of information provided by said priors: if you assume that there are, say, only 16 = 2^4 possible values of the plaintext byte, you still need to analyze 4 / 2^-17 = 2^19 ciphertexts. 50 % of bits, 50 % of work. (BTW: compare this result to figure 8 in AlFardan et al.)
Let us look at double-byte biases now: the straightforward approach would recover individual pairs of bytes (16 bits) but if those pairs overlap (they do when you are after several consecutive bytes) you can correlate your guesses and reduce "degrees of freedom" to half (8 bits per one pair). The strength of double-byte biases (+/- 2^-8) is comparable to the strength of an average single-byte bias but they occur less frequently (cca 2^-12 vs 2^-8) therefore I do not think the use of double-byte biases would make the attack considerably easier.
The biases are a bad problem but they are not bad enough to make it possible to crack plaintext with a handful of ciphertexts.
On Mon, May 05, 2014 at 10:28:22 -0400, "Eric H. Christensen" sparks@fedoraproject.org wrote:
Revise how? RC4 should be dropped down to EXPORT status, IMO, but somehow lives on.
Didn't it regain some popularity as a mitigation for the Beast vulnerability?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Mon, May 05, 2014 at 10:08:53AM -0500, Bruno Wolff III wrote:
On Mon, May 05, 2014 at 10:28:22 -0400, "Eric H. Christensen" sparks@fedoraproject.org wrote:
Revise how? RC4 should be dropped down to EXPORT status, IMO, but somehow lives on.
Didn't it regain some popularity as a mitigation for the Beast vulnerability?
Yes, and now that Beast is mitigated elsewhere... The problem is that RC4 doesn't provide that much security, now. It's 2014, if you are still using it you don't actually care about your users.
- -- Eric
- -------------------------------------------------- Eric "Sparks" Christensen Red Hat, Inc - Product Security Team
sparks@redhat.com - sparks@fedoraproject.org 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - --------------------------------------------------
Hello, Interesting results.
2014-04-25 16:34 GMT+02:00 Hubert Kario hkario@redhat.com:
The bad:
- Over 10% of servers prefer RC4 with TLS1.1 or TLS1.2 (!!)
- 1.77% of servers support only RC4 (which is an increase from Julien scan result of 1.5%)
Just a side note: note that 1.77% of servers isn't the same as 1.77% of affected users. Looking at the list of top such servers there are quite a few where I'd guess that much more than 1.77% of users visit them at least once a year. Mirek
On Thu, Mar 27, 2014 at 12:13:33PM +0100, Nikos Mavrogiannopoulos wrote:
=====LEGACY===== systems. It should provide at least 64-bit security and include RC4, but not MD5 as signature algorithm.
DH params size: 768+ RSA params size: 768+
=====DEFAULT====== A reasonable default for today's standards. For F21 it should provide 80-bit security and no broken ciphers like RC4.
DH params size: 1024+ RSA params size: 1024+
=====FUTURE====== A level that will provide security on a conservative level that is believed to withstand any near-term future attacks. That will be an 128-bit security level, without including protocols with known
DH params size: 2048+ RSA params size: 2048+
According to http://www.keylength.com/en/compare/ the asymetric sizes do not match the symmetric size according to most sources listed on http://www.keylength.com/en/compare/.
Regards Till
----- Original Message -----
From: "Till Maas" opensource@till.name To: security@lists.fedoraproject.org Sent: Wednesday, June 4, 2014 9:46:13 AM Subject: Re: available crypto policies
On Thu, Mar 27, 2014 at 12:13:33PM +0100, Nikos Mavrogiannopoulos wrote:
=====LEGACY===== systems. It should provide at least 64-bit security and include RC4, but not MD5 as signature algorithm.
DH params size: 768+ RSA params size: 768+
=====DEFAULT====== A reasonable default for today's standards. For F21 it should provide 80-bit security and no broken ciphers like RC4.
DH params size: 1024+ RSA params size: 1024+
=====FUTURE====== A level that will provide security on a conservative level that is believed to withstand any near-term future attacks. That will be an 128-bit security level, without including protocols with known
DH params size: 2048+ RSA params size: 2048+
According to http://www.keylength.com/en/compare/ the asymetric sizes do not match the symmetric size according to most sources listed on http://www.keylength.com/en/compare/.
That's old version. New one (https://fedoraproject.org/wiki/Changes/CryptoPolicy) is: Legacy: 767+ default: 1023+ future: 3071+
that matches NIST recommendations for default (80bit) and future level(128bit)
On Wed, 2014-06-04 at 08:47 -0400, Hubert Kario wrote:
----- Original Message -----
From: "Till Maas" opensource@till.name To: security@lists.fedoraproject.org Sent: Wednesday, June 4, 2014 9:46:13 AM Subject: Re: available crypto policies
On Thu, Mar 27, 2014 at 12:13:33PM +0100, Nikos Mavrogiannopoulos wrote:
=====LEGACY===== systems. It should provide at least 64-bit security and include RC4, but not MD5 as signature algorithm.
DH params size: 768+ RSA params size: 768+
=====DEFAULT====== A reasonable default for today's standards. For F21 it should provide 80-bit security and no broken ciphers like RC4.
DH params size: 1024+ RSA params size: 1024+
=====FUTURE====== A level that will provide security on a conservative level that is believed to withstand any near-term future attacks. That will be an 128-bit security level, without including protocols with known
DH params size: 2048+ RSA params size: 2048+
According to http://www.keylength.com/en/compare/ the asymetric sizes do not match the symmetric size according to most sources listed on http://www.keylength.com/en/compare/.
That's old version. New one (https://fedoraproject.org/wiki/Changes/CryptoPolicy) is: Legacy: 767+ default: 1023+
shouldn't this be 2047+ ?
future: 3071+
that matches NIST recommendations for default (80bit) and future level(128bit)
On Wed, 2014-06-04 at 09:05 -0400, Simo Sorce wrote:
According to http://www.keylength.com/en/compare/ the asymetric sizes do not match the symmetric size according to most sources listed on http://www.keylength.com/en/compare/.
That's old version. New one (https://fedoraproject.org/wiki/Changes/CryptoPolicy) is: Legacy: 767+ default: 1023+
shouldn't this be 2047+ ?
If we do that then the applications that use these settings will be unable to talk to any servers that offer 1024 keys. Given the number of these servers that would be a good reason for applications not switching to this centrally managed configuration system. That is we'd have these settings as in a museum and no-one will be using them.
regards, Nikos
On Wed, Jun 04, 2014 at 03:15:33PM +0200, Nikos Mavrogiannopoulos wrote:
On Wed, 2014-06-04 at 09:05 -0400, Simo Sorce wrote:
That's old version. New one (https://fedoraproject.org/wiki/Changes/CryptoPolicy) is: Legacy: 767+ default: 1023+
shouldn't this be 2047+ ?
If we do that then the applications that use these settings will be unable to talk to any servers that offer 1024 keys. Given the number of these servers that would be a good reason for applications not switching to this centrally managed configuration system. That is we'd have these settings as in a museum and no-one will be using them.
IMHO it should be part of the policy to create FUTURE class keys by default even if a weaker security level is required to make future transitions easier. Otherwise the amount of servers using weak keys will not decrease.
Regards Till
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Wed, Jun 04, 2014 at 03:15:33PM +0200, Nikos Mavrogiannopoulos wrote:
On Wed, 2014-06-04 at 09:05 -0400, Simo Sorce wrote:
According to http://www.keylength.com/en/compare/ the asymetric sizes do not match the symmetric size according to most sources listed on http://www.keylength.com/en/compare/.
That's old version. New one (https://fedoraproject.org/wiki/Changes/CryptoPolicy) is: Legacy: 767+ default: 1023+
shouldn't this be 2047+ ?
If we do that then the applications that use these settings will be unable to talk to any servers that offer 1024 keys. Given the number of these servers that would be a good reason for applications not switching to this centrally managed configuration system. That is we'd have these settings as in a museum and no-one will be using them.
Who still uses 1024-bit keys? You aren't finding a CA to sign them.
- -- Eric
- -------------------------------------------------- Eric "Sparks" Christensen Red Hat, Inc - Product Security Team
sparks@redhat.com - sparks@fedoraproject.org 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - --------------------------------------------------
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/05/2014 08:41 AM, Eric H. Christensen wrote:
On Wed, Jun 04, 2014 at 03:15:33PM +0200, Nikos Mavrogiannopoulos wrote:
On Wed, 2014-06-04 at 09:05 -0400, Simo Sorce wrote:
According to http://www.keylength.com/en/compare/ the asymetric sizes do not match the symmetric size according to most sources listed on http://www.keylength.com/en/compare/.
That's old version. New one (https://fedoraproject.org/wiki/Changes/CryptoPolicy) is: Legacy: 767+ default: 1023+
shouldn't this be 2047+ ?
If we do that then the applications that use these settings will be unable to talk to any servers that offer 1024 keys. Given the number of these servers that would be a good reason for applications not switching to this centrally managed configuration system. That is we'd have these settings as in a museum and no-one will be using them.
Who still uses 1024-bit keys? You aren't finding a CA to sign them.
-- Eric
Some legacy hardware, stuff with brain dead interfaces that doesn't give an option to create longer keys. I can't name anything off hand (it's been years since I saw anything like this) but I have to assume they're still out there in production.
- -- Kurt Seifried - Red Hat - Product Security - Cloud stuff and such PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
----- Original Message -----
From: "Florian Weimer" fweimer@redhat.com To: security@lists.fedoraproject.org Sent: Friday, June 6, 2014 10:58:17 AM Subject: Re: available crypto policies
On 06/05/2014 04:41 PM, Eric H. Christensen wrote:
Who still uses 1024-bit keys? You aren't finding a CA to sign them.
By default, sshd uses 1024 bits for the protocol 1 ephemeral server key.
Isn't version 1 completely broken and you shouldn't use it at all? Just like SSLv2?
On 06/06/2014 12:30 PM, Hubert Kario wrote:
----- Original Message -----
From: "Florian Weimer" fweimer@redhat.com To: security@lists.fedoraproject.org Sent: Friday, June 6, 2014 10:58:17 AM Subject: Re: available crypto policies
On 06/05/2014 04:41 PM, Eric H. Christensen wrote:
Who still uses 1024-bit keys? You aren't finding a CA to sign them.
By default, sshd uses 1024 bits for the protocol 1 ephemeral server key.
Isn't version 1 completely broken and you shouldn't use it at all? Just like SSLv2?
Yes, it's disabled by default.
----- Original Message -----
From: "Simo Sorce" simo@redhat.com To: "Hubert Kario" hkario@redhat.com Cc: "Till Maas" opensource@till.name, security@lists.fedoraproject.org Sent: Wednesday, June 4, 2014 3:05:03 PM Subject: Re: available crypto policies
On Wed, 2014-06-04 at 08:47 -0400, Hubert Kario wrote:
----- Original Message -----
From: "Till Maas" opensource@till.name To: security@lists.fedoraproject.org Sent: Wednesday, June 4, 2014 9:46:13 AM Subject: Re: available crypto policies
That's old version. New one (https://fedoraproject.org/wiki/Changes/CryptoPolicy) is: Legacy: 767+ default: 1023+
shouldn't this be 2047+ ?
No, approx. more than 0.5% of Internet servers still use 1024 bit certificates, we also still trust 1024 bit CA roots.
It also matches accepting SHA-1 signatures in certificates.
On Wed, Jun 04, 2014 at 08:47:16AM -0400, Hubert Kario wrote:
That's old version. New one (https://fedoraproject.org/wiki/Changes/CryptoPolicy) is: Legacy: 767+ default: 1023+ future: 3071+
that matches NIST recommendations for default (80bit) and future level(128bit)
But it matches only NIST recommendations, there are other sources that claim that 1024 bit asymmetric is less than 80 bit symmetric. Therefore instead of "For F21 it should provide 80-bit security" for default it should say something like "For F21 it should provide 72-bit security" or whatever is correct.
Regards Till
----- Original Message -----
From: "Till Maas" opensource@till.name To: "Hubert Kario" hkario@redhat.com Cc: security@lists.fedoraproject.org Sent: Wednesday, June 4, 2014 4:09:07 PM Subject: Re: available crypto policies
On Wed, Jun 04, 2014 at 08:47:16AM -0400, Hubert Kario wrote:
That's old version. New one (https://fedoraproject.org/wiki/Changes/CryptoPolicy) is: Legacy: 767+ default: 1023+ future: 3071+
that matches NIST recommendations for default (80bit) and future level(128bit)
But it matches only NIST recommendations,
It also matches ENISA recommendations
there are other sources that claim that 1024 bit asymmetric is less than 80 bit symmetric. Therefore instead of "For F21 it should provide 80-bit security" for default it should say something like "For F21 it should provide 72-bit security" or whatever is correct.
There is no "correct" way to compare cracking asymmetric with symmetric. It's apples to oranges. The values (80, 112, 128, etc.) are only ballpark estimates and used as guidelines.
On Thu, Mar 27, 2014 at 12:13:33PM +0100, Nikos Mavrogiannopoulos wrote:
=====FUTURE====== A level that will provide security on a conservative level that is believed to withstand any near-term future attacks. That will be an 128-bit security level, without including protocols with known attacks available (e.g. SSL 3.0/TLS 1.0). This level may prevent communication with commonly used systems that provide weaker security levels (e.g., systems that use SHA-1 as signature algorithm).
MACs: SHA1+
^^^^^
Curves: All supported Signature algorithms: must use SHA-256 hash or better Ciphers: AES-GCM, AES-CBC, CAMELLIA-GCM, CAMELLIA-CBC Key exchange: ECDHE, RSA, DHE DH params size: 2048+ RSA params size: 2048+ SSL Protocols: TLS1.1+
Why is SHA1+ allowed as MAC here?
Regards TIll
On St, 2014-06-04 at 16:15 +0200, Till Maas wrote:
On Thu, Mar 27, 2014 at 12:13:33PM +0100, Nikos Mavrogiannopoulos wrote:
=====FUTURE====== A level that will provide security on a conservative level that is believed to withstand any near-term future attacks. That will be an 128-bit security level, without including protocols with known attacks available (e.g. SSL 3.0/TLS 1.0). This level may prevent communication with commonly used systems that provide weaker security levels (e.g., systems that use SHA-1 as signature algorithm).
MACs: SHA1+
^^^^^Curves: All supported Signature algorithms: must use SHA-256 hash or better Ciphers: AES-GCM, AES-CBC, CAMELLIA-GCM, CAMELLIA-CBC Key exchange: ECDHE, RSA, DHE DH params size: 2048+ RSA params size: 2048+ SSL Protocols: TLS1.1+
Why is SHA1+ allowed as MAC here?
SHA1 is 128 bit security level when used within HMAC for message authentication. You cannot apply birthday attack to message authentication.
On Wed, 2014-06-04 at 16:15 +0200, Till Maas wrote:
MACs: SHA1+
^^^^^Curves: All supported Signature algorithms: must use SHA-256 hash or better Ciphers: AES-GCM, AES-CBC, CAMELLIA-GCM, CAMELLIA-CBC Key exchange: ECDHE, RSA, DHE DH params size: 2048+ RSA params size: 2048+ SSL Protocols: TLS1.1+
Why is SHA1+ allowed as MAC here?
And why not? Could we please have a constructive conversation? Why do you think it shouldn't be there? Do you have any results on cryptanalysis of HMAC-SHA1 that do not make it suitable for this level?
regards, Nikos
security@lists.fedoraproject.org
-
Aaron Zauner -
Bruno Wolff III -
Eric Christensen -
Florian Weimer -
Hubert Kario -
Kurt Seifried -
Miloslav Trmač -
Nikos Mavrogiannopoulos -
Pavel Kankovsky -
Simo Sorce -
Till Maas -
Tomas Mraz