Re: [ANNOUNCE] NSS 3.37 Release
On 2018-05-08 22:49, Kai Engert wrote: Notable changes: * The TLS 1.3 implementation was updated to Draft 28. I find it unfortunate that you update the draft version to 28 and did not keep it at 26 like some other implementations, since the protocol did not change since draft 26. This makes it harder to actually test things. Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Security implications for TLS validation post handshake
On Wed, Oct 18, 2017 at 11:27:45AM +0200, Gregory Szorc wrote: > The way you specify the desired TLS protocol version (which is heavily > inspired by OpenSSL's API) is to pass a protocol constant along with some > more options to control ciphers, protocol options (like compression), etc. > If you want to require TLS 1.2+, you use SSLv23 and then mask out older > protocols. e.g. ssl.OP_NO_SSLv2 | ssl.OP_NO_SSLv3 | ssl.OP_NO_TLSv1 | > ssl.OP_NO_TLSv1_1. OpenSSL 1.1.0 added a new way to do this, setting a minimum and maximum supported version, and at the same time deprecated the use of the flags. I suggest you do something like that in python too. It should be easy enough to turn the mimimum the version in a list of flags for version that don't support the minimum version. > Python versions before 2.7.9 lacked controls necessary to ensure optimal > security. For example, Python didn't expose constants to force TLS versions > >1.0. Instead, you had to use PROTOCOL_TLSv1 (the latest available > constant) and force TLS 1.0. Or, you used SSLv23 (masking out SSL v2 and v3 > of course) and hoped the underlying crypto library can negotiate TLS >1.0. Python deprecated PROTOCOL_TLSv1 since version 2.7.13. (It only allowed TLS 1.0, people have been confused by the SSLv23 name which is why OpenSSL 1.1.0 deprecated that and other names.) > Again, I'm naive, but it feels like pre-filtering is better because it > eliminates surface area for e.g. downgrade attacks. However - and this is > where the problem resides - Python <2.7.9 doesn't exactly give you the > requisite tools for adequate pre-filtering. Since the constants aren't > there, you have to use PROTOCOL_SSLv23 and "hope" that a TLS >1.0 > connection is established. The flags mentioned above did move the check for the version from python to at least OpenSSL. > Question: > > Python exposes the negotiated TLS protocol version and cipher info post TLS > handshake (results of OpenSSL's SSL_get_version() and > SSL_get_current_cipher() functions). So it is possible to examine these > values to determine whether to proceed with the connection. My question is: > what are the dangers or concerns in doing so? I'm assuming there's a > surface area of downgrade-type attacks in play. But I'm not sure the > specifics. > > e.g. on Python <2.7.9, the best we can do is use PROTOCOL_SSLv23 and "hope" > the underlying crypto library is able to negotiate TLS >1.0. But this will > advertise protocols and ciphers for TLS 1.0+ in ClientHello. I don't think > this is ideal: I think I'd prefer to not advertise client support for TLS > 1.0 (and even 1.1) support at all if there is no intent on speaking these > older (and known vulnerable) protocols. With TLS up to 1.2 you just indicate the highest supported verion, you don't have a list of supported version. With TLS 1.3 you actually send a list of versions you support, and using the minimum version (and flags) will limit the versions that are send as supported. Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Java keytool certgen - Alertnative Subject Name
On 2017-05-24 02:39, Roger Dunn wrote: We are moving from OpenSSL to Java to handle CSRs for our CA. Our devices require a custom 'description' field as part of the Subject sequence. (Related link) https://linux.die.net/man/3/x509_name_get_text_by_nid The following command line fails (we are using a HSM but that's not relevant to the question) java -Dprotect=module -DignorePassphrase=true sun.security.tools.keytool.Main -certreq -alias myalias -file c:\mycerts\certs\cert23may.csr.pem -keypass 00 -dname "C=US,ST=CA,L=Cupertino,O=Apple\ Computer,OU=MyUnit,CN=MyServer,description=1495543419" -keystore c:\mycerts\private\may18_2017.ncsw -sigalg SHA256withECDSA -storepass 00 -storetype nCipher.sworld keytool error: java.io.IOException: Invalid keyword "DESCRIPTION" My guess is that it doesn't know the OID for description, which seems to be 2.5.4.13. Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Remove Legacy TLS Ciphersuites from Initial Handshake by Default
On 2015-03-14 01:23, kim.da...@safe-mail.net wrote: Is there an agreed timeline for deprecation of the technologies listed in the initial posting? We should be proactive in this field. For example, last month a plan to deploy 12000 devices to medical professionals has been finalised, despite the devices using 1024bit RSA keys - on the grounds that it works in current browsers and will likely keep working for the next 10 years. I am not happy about such outcomes. Whoever thinks that this will keep working for the next 10 years is clearly misinformed. CAs should not be issuing such certificates. If they do, please let us know which CA does that so we can talk to them about revoking them. Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Remove Legacy TLS Ciphersuites from Initial Handshake by Default
On 2015-02-28 04:15, Kosuke Kaizuka wrote: I also propose removing the following ciphersuit: 000A TLS_RSA_WITH_3DES_EDE_CBC_SHA because 3DES is a cipher that requires too much computing power compared to AES, much more computer memory, lacks hardware acceleration on servers, is rarely negotiated, has had its bitstrenght reduced below 128bits, and its removal is on track with avoiding (and eventually removing) RSA key exchange. Additionally, the servers that support (or even prefer!) 3DES always support some AES ciphersuit too. Some of old servers offer only TLS_RSA_WITH_3DES_EDE_CBC_SHA and TLS_RSA_WITH_RC4_SHA. If TLS_RSA_WITH_3DES_EDE_CBC_SHA is removed, TLS_RSA_WITH_RC4_SHA will be used. Yes, we do want to use 3DES with those servers and not RC4. Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Remove Legacy TLS Ciphersuites from Initial Handshake by Default
On 2015-03-02 13:32, Hubert Kario wrote: Not true. In Alexa top 1 million I found at least 439 servers which support only 3DES and have valid certificates. If Firefox removes RC4, I'm sure that this will make this number effectively only larger (80% of servers still support RC4, 15% prefer RC4 over any and all ciphers). Please note that since 36 (released last week) RC4 is not offered in the initial connection anymore. See: https://developer.mozilla.org/en-US/Firefox/Releases/36#Security https://bugzilla.mozilla.org/show_bug.cgi?id=1088915 Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Road to RC4-free web (the case for YouTube without RC4)
On 2014-07-10 13:53, Henri Sivonen wrote: On Tue, Jul 1, 2014 at 11:58 PM, Brian Smith br...@briansmith.org wrote: I am interested in discussing what we can do to help more server side products get better cipher suites by default, and on deciding whether we add support for ChaCha20-Poly1304 Out of curiosity, what's holding back a decision to implement ChaCha20-Poly1305? I think implementation already exist, but there currently is no standard yet on how to do it. There are various drafts: https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-04 https://tools.ietf.org/html/draft-mavrogiannopoulos-chacha-tls-02 https://tools.ietf.org/html/draft-nir-cfrg-chacha20-poly1305-01 But the states of them are currently unclear to me. There is also an old patch for NSS available at: https://bugzilla.mozilla.org/show_bug.cgi?id=917571 I'm not sure that that patch is current or not. An other alternative is using curve25519. It's also not standardized yet, but at this time it seems more likely to be standardized first. Anyway, using AES-GCM should be what you want to use now. Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Curve25519 and/or Curve41417 and/or Alternatives in Gecko/Firefox (was Re: Road to RC4-free web (the case for YouTube without RC4))
On Thu, Jul 10, 2014 at 09:57:56AM -0700, Brian Smith wrote: On Thu, Jul 10, 2014 at 5:33 AM, Kurt Roeckx k...@roeckx.be wrote: [snip] An other alternative is using curve25519. It's also not standardized yet, but at this time it seems more likely to be standardized first. Thanks for bringing up curve25519. I'd like to share a recent paper written by Daniel J. Bernstein, Chitchanok Chuengsatiansup, and Tanja Lange: Curve41417: Karatsuba revisited.'' http://cr.yp.to/papers.html#curve41417 Section 1.5, Is high security useful? is particularly interesting. I think it is likely the case that Curve25519 solves the wrong problem*: it tries to be faster than NIST P-256 but only the same strength, but I think a new standard curve should be the same speed as NIST P-256 but much stronger. My thinking is that now, when Curve25519 isn't an option, everybody is using P-256 without significant performance complaints. This shows that we don't really need something faster than P-256. Further, as the paper states in section 1.5, there are quite a few reasons to want to have a security level higher than ~125 bits, if we can get it with reasonable performance and without compromising other security goals, which we apparently can, according to this paper. By the way, an extra notable merit of this paper is that they focused on ARM performance I would like to hear what others think about this, including what people think Gecko should do. I think it looks promosing. But like the paper indicates it needs time for other people to review it before it's going to see any adoption. Curve25519 on the other hand is almost 10 years old now, and provides the security I currently think is at a good level, and is fast. So I think we should try to adopt curve25519 and later see if we should adopt Curve41417. Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Road to RC4-free web (the case for YouTube without RC4)
On 2014-06-30 02:35, Hubert Kario wrote: The benefits of ECDHE outweigh the risks of using RC4, I have to disagree here. Even 1024 bit DHE requires a targeted attack at ~80 bit complexity. Currently we see RC4 at around 56 bit, with a completely unoptimized attack... Do you have a reference for those 56 bit? You're not talking about the old export ciphers I hope? I haven't seen anything saying that the 128 bit RC4 has a complexity of 56 bit. If it's really at 56 bit, we should disable it everywhere now, no matter if it breaks things or not. I think we should do all that's possible to avoid RC4. I think that for now we should follow Microsoft in not having RC4 in the initial handshake and if fails retry with RC4 enabled. It's my understanding that that should reduce RC4 usage from 20% of the sites to 1%. Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Where are others SHA256 cipher suits in Firefox 27?
On Sun, Mar 23, 2014 at 08:43:35AM -0700, gegard4321 wrote: Another reason to enable DHE_RSA_AES_*_GCM: Mozilla's new account system only supports RSA and DHE_RSA ciphers: https://www.ssllabs.com/ssltest/analyze.html?d=accounts.firefox.com Same goes for mozilla.org and bugzilla. Firefox selects TLS_DHE_RSA_WITH_AES_128_CBC_SHA, while chrome selects TLS_DHE_RSA_WITH_AES_128_GCM_SHA256. And I would really prefer the GCM version over the CBC version. Please add support for TLS_DHE_RSA_WITH_AES_*_GCM_SHA*, which currently probably means TLS_DHE_RSA_WITH_AES_128_GCM_SHA256. Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Where are others SHA256 cipher suits in Firefox 27?
On Thu, Feb 06, 2014 at 09:57:34PM +, gegard4321-bugzi...@yahoo.co.uk wrote: Regarding the other variants of AES-GCM -TLS_RSA_WITH_AES_128_GCM_SHA256 There are some sites support AES-GCM that use only ciphers with RSA key exchange. I think it would be best not to support new standards that don't provide Forward Secrecy, but on the other hand, if this cipher is enabled then users browsing to those sites will at least have something better than RSA with AES-CBC. If I'm correct, AES-GCM is not vulnerable to some of the newer TLS attacks, in particular Lucky13. Even when used together with TLS 1.2, AES-CBC is vulnerable to Lucky13. Lucky13 is a timing attack on MAC-then-Encrypt, which CBC uses. This attack can be fixed, but it's harder to get this right than it should be. Maybe you're refering to the BEAST attack instead of Lucky 13, which TLS 1.1 fixed and can be worked around in older versions by splitting? Anyway, I see no need for adding support for ciphers that do not support forward secrecy. -TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 I'm aware that a lot of sites only use 1024 bit DH, but with the patent issues regarding ECC, there are still enough sites who don't support ECDHE. If this cipher is enabled, users can benefit both from protection against Lucky13 and Forward Secrecy. Also there are enough sites out there that do have 2048 or even 4096 bit DH key exchange. Please name a few of those sites that have 1024 DH keys. For sites that have both ECDHE and DHE ciphers enabled, ECDHE variants are usually the preferred anyway and if the server has no preference, they are also preferred by NSS. I also think that diversity should be maintained in case a vulnerability in some standard or protocol is discovered. Just like supporting ChaCha20_Poly1305 and AES with other modes like CCM to avoid the same disaster as with the BEAST attack, where AES-CBC was the only really secure protocol, found vulnerable and then having tons of sites switch back to the insecure RC4. Just in case ECC is being discovered vulnerable, there should be an alternative key exchange method that does not use EC cryptography. The only widely used are RSA and DHE, and DHE supports Forward Secrecy and is the better alternative IMO. Some of the curves using by ECDHE might have some problems which is why people are working on getting alternatives like curve25519 standardized. But DHE is so slow that people want to avoid it, and there are both clients and servers have problems with sizes of 2048 or more which really is what you want. But I can understand that some people might prefer DHE instead of ECDHE. And I've actually requested that this cipher would be enabled too. Bruce Schneier believes ECC is relatively easier to break for the NSA. Whether or not you find his advice important, the fact is that ECC is relatively new and there should at least be one older and proven method as well. I understand that RSA is expected to get broken in the next 10 years and we need alternatives. ECDSA is currently the only other standardised method for using in TLS that we should consider using as far as I know. I would also like to point out that EC isn't exactly new, it's just seeing more wide deployment now. So I'm actually concerned that in the long run all of RSA, DHE and ECC will be broken and that we don't really have alternatives. But we have to go with what we currently know. Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On 2014-01-27 02:43, ripber...@aol.com wrote: Hi, So I didn't get to the bottom of this thread because some of it is 'loading' I really recommend that you do read all the messages. All of this has been discussed in various thread both here and on other lists. Encryption: AES-256 - 256 bit AES-192 - 192 bit AES-128 - 128 bit Triple-Key Triple DES (3DES) - 112 bit (NOTICE: No Camilla, RC4, SEED, DES or 2DES). Other recommendations don't not recommend 3DES, but do recommend Camellia. The reason to have RC4 and 3DES enabled is that there are servers that do not support AES and only support either RC4 or 3DES. Actually running with RC4 disabled makes me run into some of those sites. Digital Signature Generation: DSA with p=2048, q=224 - 112 bit RSA with n=2048 - 112 bit EC-DSA with n224- 112 bit This generally affects what type of certifcates you need. Notice RSA-2048 now required (no RSA-1024). Following CA/Browser baseline requirements, everything should now be 2048 bit or more, but some CAs aren't ready for this. 1024 bits is now below 1%. I think all ECDSA are 256 bit or more, and DSA isn't used. Hash Functions: Digital Signature Generation: SHA-224: 112 bit SHA-256: 128 bit SHA-384: 192 bit SHA-512: 256 bit (NOTICE: No MD5, no SHA-1) Please note that both MD5 and SHA-1 still have a preimage resistance of = 112 bit, but their collision resistance isn't that good. That means in an HMAC they can perfectly be used. A Suite B TLS client configured at a minimum level of security of 128 bits MUST offer the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 or the We do not have a minimum level of 128. As you say yourself, 112 bit is enough. I'd suggest you follow NIST 800-131a, but if not at least give a configuration switch to drop NON-FIPS algorithms. From the above list, I'd drop the RC4, MD5 and CAMELLIA options - at least if a FIPS configuratoin switch is activated. Better - no switch and drop them. If you have to included them for some reason - put them at the bottom if the preference list. 3DES, RC4 and MD5 are actually at the bottom of the list. I think in general, you could say the shorter the key or hash, the faster it runs, so if all you are trying to get to as 112 bit security (all that is required in 2014), I'd consider preferring suites with AES_128 encryption and SHA MACs over AES_256 or SHA-256 or SHA-384. We prefer GCM, and AES128 over AES256. But GCM doesn't use a HMAC and so needs SHA256. 3DES is still acceptable for 2014. It's still in the list. The following suite is the MANDATORY suite required by TLS 1.1 (RFC 4346). If you are going to allow the browser to enable TLS 1.1, you should make sure this is enabled when TLS 1.1 is enabled. There's also no reason to take it out if the minimum security protocol is TLS 1.2 - just leave it at the bottom as you have it. 000A TLS_RSA_WITH_3DES_EDE_CBC_SHA So maybe you could argue that if we do a fall back from TLS 1.2 to 1.1 that it should be included. But RFC 4346 is obsolete, and I don't see any real problems with dropping it. The following suite is the MANDATORY suite required by TLS 1.0 (RFC 2246). If you are going to allow the browser to enable TLS 1.0, you should probably make sure this is enabled when TLS 1.0 is enabled. There's also no reason to take it out if the minimum security protocol is TLS 1.1 or TLS 1.2 - just leave it at the bottom as you have it. This is less important since I don't think DSA certrificates are much used. 0013 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA Also obsolete. I'm also not sure why you aren't supporting: C0 08 - TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA 00 13 - TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA 00 16 - TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA If the answer is no one uses them or not in NSS - that's fine. However they would be OK for NIST 800-131a. 3DES is slow, support should be removed, no point in adding support for it anymore, you should move to AES or Camellia. Might also ask why you didn't include any DH key negotiation cipher suites (e.g. C004, C003, 0031, 0030, 000D, 0010) It's OK for the server to have a static DH key provided the client uses an ephemeral DH key. If the answer is no one uses them or not in NSS - that's fine. However the above ones would be OK for NIST 800-131a. static (EC)DH keys do not offer forward security. They do cause you to spend more time on the key exchange. So what is the advantage of them? Not sure why you included C02B and C02F or why they are at the top. The SHA-256 is overkill for 2014 - I know if you want GCM - it only comes with at least SHA-256. I haven't researched GCM vs CBC. My first take would be you don't need them - but there might be some reason to include and maybe even to put first. C02B does
Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On Mon, Jan 27, 2014 at 09:26:20AM -0800, ripber...@aol.com wrote: 2) NIST is a US government standards board that drives a lot of compliance regulation. There are companies what will want to be able show that they are NIST compliant. I'm sure it is important to some. But I think it would be more important to get the server to be compliant rather than the client. The client currently has to work in a lot of different environments where it can't be sure that the other end is compliant with those standards. NIST is, like you said, a US government standard, and as such doesn't have any official status outside the US. That doesn't mean that if it has good recommendations that we shouldn't try to follow them. But we have to live in the real world, and it's more complicated. 4) I think the flaws in the TLS 1.1 CBC definition (no random IV) drove folks away from AES and to use RC4 - it was the best thing left in TLS 1.1 - or Camellia which is probably as good or better than AES though rather new and therefore risky - but better than a broken AES-CBC implementation. I think you mean TLS 1.0? 5) I'm trying to tell you what the standard says - not whether I agree with it. I don't get to pick. The standard does not allow Camellia (because it is too new). But the standard does support and justify taking away the set of suites that Marlen suggested. I was just giving a more explicit rational for dropping them. AES is from 1998, Camellia from 2000. I wouldn't call that too new. But it is used less. Digital Signature Generation: RSA with n=2048 - 112 bit This generally affects what type of certifcates you need. Notice RSA-2048 now required (no RSA-1024). Following CA/Browser baseline requirements, everything should now be 2048 bit or more, but some CAs aren't ready for this. 1024 bits is now below 1%. I think all ECDSA are 256 bit or more, and DSA isn't used. The standard is telling you what you should use, not whether anyone does or not support it. The standard is saying everyone should already be at 112 security bit strength now. Agree you might as well ignore DSA if no one implemented it which means you can forget about TLS_DH, TLS_DHE_DSS suites. I understand some sites may not use RSA-2048 keys in certificates. However using RSA-1024 bit keys has only 80 bits of security strength which is no longer secure (NIST worries about it saying secure for say another 20 years). Even worse than RSA-1024 I suspect will be the use of SHA-1 in certificate signatures. The CA/Browser requirements are good in changing the certificates being generated. It resulted in the 1024 bits keys going from 10% last year to 1% now, and with the current rate should be near 0% in a few months. I would also like to see them to change the SHA-1 requirement to SHA-2, and some CAs are working on that. But there seems to be existing software that still can't handle it. SHA-1 is known to be only providing about 60 bit of security for a collision attack, which is a problem. To make it more hard the CAB requirements state that the CA should add at least 20 bit of entropy and at least some people say that that is not enough. The client is not obligated to enforce NIST 800-131a. But I would suggest two things: 1) There should be a visible indication whenever a web site ends up with a connections that has less than 112 bit security. Perhaps even ask the user if he really wants to connect to a site with 'weak' security. This might motivate some of these sites to fix their security. 2) There should be a configuration control to block connection to a weak sites period. Weak = See description at end of post. You can actually disable things like MD5, RC4 and 3DES and set the minimum version to TLS 1.2. You will just run into many sites that just don't work. It will show you that it's weak or strong if you first click the icon and press more info. Not sure on what that is based. I think in general, you could say the shorter the key or hash, the faster it runs, so if all you are trying to get to as 112 bit security (all that is required in 2014), I'd consider preferring suites with AES_128 encryption and SHA MACs over AES_256 or SHA-256 or SHA-384. We prefer GCM, and AES128 over AES256. But GCM doesn't use a HMAC and so needs SHA256. There's not much point in having one algorithm with more security than another - the least secure algorithm determines the security level of the implementation and the higher security algorithm just burns performance. AES-128 and SHA-256 hashes are same strength. AES-192 and SHA-384 hashes are same strength. AES-256 and SHA-512 hashes are the same strength. For 112 bit security strength - AES-128 is sufficient so don't need
Re: Hashing functions in Firefox OS
On 2013-12-17 16:02, Stéphanie Ouillon wrote: Hi, I'm in the Firefox OS Security team and I'm starting working on adding support for stronger passwords in the Firefox OS lockscreen (bug 877541) [1]. At the moment, only a 4-digit password can be configured and we want to improve that for FxOS 1.4 (March 2014). Some time ago, David Dahl provided on a patch for having hashing functions in Gecko: it's a JSM living next to the SettingsManager for FxOS [2]. Supported algorithms are sha256, sha384 and sha512. But having a set of hashing functions that could be called from anywhere would definitely be best. I'm confused what passwords have to do with hashes. Do you want to store hash(pass)? This is a bad idea, please use something that is designed to store passwords instead like bcrypt, scrypt or PBKDF2. Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On Fri, Jan 10, 2014 at 08:11:02PM -0500, Julien Vehent wrote: On Thu, Jan 09, 2014 at 12:59:40PM -0500, Julien Vehent wrote: I started a scan of Alexa's top 1 million websites. It's going to take a few days to have all the results. So far, 21 out of 1396 websites scanned support neither AES or 3DES. I'm about half way through the scan, but it's unlikely that the numbers will change from now. The raw results are below, and I posted an analysis on my blog: https://jve.linuxwall.info/blog/index.php?post/TLS_Survey Thanks for doing this. There are some pretty scary numbers in there. Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On 2013-12-15 02:41, Brian Smith wrote: On Sat, Dec 14, 2013 at 4:47 PM, Kosuke Kaizuka cai.0...@gmail.com wrote: little supported, never negotiated cipher One of the largest websites which support Camellia is Yahoo!. Firefox 26 or lower use TLS_RSA_WITH_CAMELLIA_256_CBC_SHA with Yahoo!. In Firefox 27 or later, Yahoo! will choose TLS_RSA_WITH_AES_128_CBC_SHA instead, because of the cipher suite order change in Firefox 27. I'm not sure what you mean with Yahoo!, they have several sites each with their own settings. Some of them set the preferred order at the server side and prefer RC4 and so we end up with RC4. I'm considering if we should also drop support for RC4 on the client side. At least IE11 on windows 8.1 doesn't do RC4, but does do 3DES. Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On Thu, Jan 09, 2014 at 12:59:40PM -0500, Julien Vehent wrote: On 2014-01-09 06:41, Kurt Roeckx wrote: I'm considering if we should also drop support for RC4 on the client side. At least IE11 on windows 8.1 doesn't do RC4, but does do 3DES. I started a scan of Alexa's top 1 million websites. It's going to take a few days to have all the results. So far, 21 out of 1396 websites scanned support neither AES or 3DES. For all the ones I looked it, they only have RC4 enabled. So I have to wonder, do are those sites that people in general use without ssl? Or does IE11 have some fallback mechanism that it enables RC4 if it first fails to negiotate a protocol? Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: [Ach] Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On Fri, Jan 03, 2014 at 12:19:10AM +0100, Aaron Zauner wrote: 3DES isn't broken. Triple DES provides about 112bit security (We've a section on the topic in the Paper in the Keylenghts section). All ciphers that we recomend are at least at 128bit security. The document doesn't seem to say that it's trying to reach a 128 bit security level over the whole chain. It seems to be happy with 2048 bit RSA keys. They also provide 112 bit security. If you really want to go for 128 bit, you need to have the RSA keys of at least something in the order of 3072 bit. If 2048 is fine, 3DES is fine. Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: [Ach] Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On Thu, Jan 02, 2014 at 09:33:24PM +0100, Aaron Zauner wrote: I *think* they want to prefer CAMELLIA to AES, judging by the published ciphersuite. But the construction must be wrong because it returns AES first. If the intent is to prefer Camellia, then I am most interesting in the rationale. Thanks for reporting this! Yes. The intent was to prefer Camellia where possible. First off we wanted to have more diversity. Second not everybody is running a sandybridge (or newer) processor. Camellia has better performance for non-intel processors with about the same security. I know that for AES people having been putting an effort in making this constant time. Having AES-NI clearly helps with this. I can't say the same for Camellia and so think it doesn't make sense to prefer it over AES. NSS/Firefox currently still has Camellia as first non-ECDHE and as result does use it for sites supporting it. But as far as I know it's the only browser supporting it, and the next version is going to prefer AES over Camellia all the time which resulted in it's usage going from about 5% to as good as 0%. There has also been talk about either disbaling it by default or even dropping support for it but that currently didn't happen yet. Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: [Ach] Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On Thu, Jan 02, 2014 at 10:10:49PM +0100, Aaron Zauner wrote: What's the take on the ChaCha20/Poly1305 proposal by the Mozilla Sec. Team by the way? Not being part of the mozilla team myself, I at least have the impression that they want it. You might want to look at this old version: https://briansmith.org/browser-ciphersuites-01.html Lots has been discussed and changed since that, but it at least mentions it. Google is also working on getting it into NSS: https://bugzilla.mozilla.org/show_bug.cgi?id=917571 Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: [Ach] Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On Thu, Jan 02, 2014 at 02:12:47PM -0800, Ryan Sleevi wrote: What's the take on the ChaCha20/Poly1305 proposal by the Mozilla Sec. Team by the way? There are 5 security teams at Mozilla, so Mozilla Sec Team is a very large group. I think we all want a new stream cipher in TLS to replace RC4. But that's going to take years, and won't help the millions of people who don't replace their software that often. Really? If anything, Firefox and Chromium have shown that new changes can be deployed on the order of weeks-to-months, and with server opt-in (such as NPN/ALPN), the majority of *users* traffic can be protected or enhanced within a few weeks-to-months after. Google already has deployed experimental support, for example. Likewise, the adoption of SPDY - within Firefox and within a number of significant web properties - show that it's significantly quicker than it used to be to protect users. You're correct that there's going to be a long-tail of sites that don't update, sure, but rapid deployment is certainly an increasing possibility for the majority of users. Updates on the client side can be done in a few months, at least for a very large population of the clients. But things tend to break in unexpected ways making and it ussually takes a lot of testing time before it can really be deployed. But I see more problems getting the server side to change. Maybe you can convice some people to disable certain things, but I think it's going to be hard to try to convice them that they should upgrade to a new software version. I've tried and failed. When firefox 27 is released all major browsers will finally support TLS 1.1+ in their latest version. But on the server side we now see about 20% that support it, which is an increase of about 15% over last year. We also still see 25% that still supports SSLv2. At this rate it's still going to take years before you can say that the majority of the sites will support it. I think we should find a way to force them to upgrade, and trying to be as compatible as possible isn't really helping. Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On Sun, Dec 15, 2013 at 11:22:32AM -0500, Julien Vehent wrote: For the same reason, the server ciphersuite that we recommend at https://wiki.mozilla.org/Security/Server_Side_TLS does not drop Camellia, but lists it at the bottom of the ciphersuite. It's a safe choice, but not one that we recommend. You might also want to read: https://bettercrypto.org/ Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On Sat, Dec 14, 2013 at 05:41:55PM -0800, Brian Smith wrote: Fx26Fx27 Change Cipher Suite 0.00% 14.15% +14.15% TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (new) 0.00% 8.30% +8.30% TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (new) Are you sure you didn't switch those 2? At least your other mail with stats had them to other way around. Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
On Sun, Dec 15, 2013 at 11:22:32AM -0500, Julien Vehent wrote: On 2013-12-15 11:13, Kurt Roeckx wrote: On Sun, Dec 15, 2013 at 10:46:04AM -0500, Julien Vehent wrote: On 2013-12-14 19:47, Kosuke Kaizuka wrote: Camellia is widely reviewed and chosen as a recommended cipher by several independent committees. If CAMELLIA_CBC is dropped by security reason, AES_CBC should be also dropped. There is another reason to drop CAMELLIA: AES with AES-NI is 8 times faster. AES-NI is supported by the majority of server CPUs right now. Camellia is still fast in software, my laptop computes between 90 and 160 MB/s with openssl and an intel cpu. But if we want to provide the fastest response time to users, it's important to consider the server cost on the client side. It's not because it's enabled that you have to use it. The priority of Camellia is now always below AES. If the server supports AES it should pick it. Right. And by drop I really meant reduce preference of. Which is what we already did. As Brian's stats show, the reordering has already reduced Camellia's usage to about 0.03%. But some people are also considering disabling it by default, as I think all other where talking in this thread, not just reduce the preference. For the same reason, the server ciphersuite that we recommend at https://wiki.mozilla.org/Security/Server_Side_TLS does not drop Camellia, but lists it at the bottom of the ciphersuite. It's a safe choice, but not one that we recommend. As far as I know the reasons for not recommending it are: - It's slower - It probably doesn't have much constant-time implementations. So as I understand it, the reason for not recommending it don't have anything to do with the security of Camellia itself. Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: TLS 1.2 Issue with openldap 2.4.36 built on NSS 3.15.3
On Fri, Nov 29, 2013 at 04:07:35AM -0800, sameer...@gmail.com wrote: Hi, I found some new behavior with openldap server built against Mozilla NSS(3.15.3) and our requirement is to use only TLSv1.2 ciphers only. I have no idea what you really mean with this. Please note that ciphers can typically be used with more than 1 version of TLS. There ussually is a minimum version and maximum version of SSL/TLS a cipher can be used with. I'm going to guess that you're talking about ciphers that minimum require TLS 1.2. Those would be all ciphers that can use SHA-2, and GCM but you don't seem to like that. I would like to point out again that GCM is really what you want and I suggest you try to convince your user that that is what he wants. As far as I know, NSS does not have any ciphers with SHA-2 other than GCM, and so I think what you want is not currently possible with NSS. If I have following LDAP (Server+Client)configuration: Scenario 1: Openldap Server built against NSS(slap.conf) Openldap client built against NSS(pam_ldap.conf) TLSCipherSuite TLSv1.2 tls_ciphers TLSv1.2 Communication fails with LDAP server throwing following error: --TLS: could not set cipher list TLSv1.2. Any idea why LDAP server is throwing above error. Is that the case that cipher string TLSv1.2 is not recognized by Mozilla NSS. Maybe openldap doesn't know how to translate TLSv1.2 for NSS yet? Please note that you give it an openssl string and that openldap translates this to something for NSS. Scenario 2: Openldap Server built againit NSS(slap.conf) Openldap client built against NSS(pam_ldap.conf) TLSCipherSuite TLSv1.2+HIGH tls_ciphers SSLv3 Scenario 3: Openldap Server built againit NSS(slap.conf) Openldap client built against NSS(pam_ldap.conf) TLSCipherSuite SSlv3 tls_ciphers TLSv1.2+HIGH In Scenario 2 and 3, communication is successfully established. Any idea which protocol ciphers is used for establishing the communication. AFAIK SSLv3 and TLSv1.2 ciphers are different and incompatible. I suggest you monitor the network communication with something like wireshark and then look at the Server Hello. It should say which cipher the server selected. It will also tell which TLS version is used, but please note that if it says 1.2 that that doesn't mean it's a 1.2 cipher. Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: TLS 1.2 Issue with openldap 2.4.36 built on NSS 3.15.3
On Fri, Nov 29, 2013 at 01:43:11PM +0100, Kurt Roeckx wrote: As far as I know, NSS does not have any ciphers with SHA-2 other than GCM, and so I think what you want is not currently possible with NSS. It seems that some are implemented, but at least firefox with the latest version doesn't have any such enabled. You might need to do something to get them enabled. It seems there is at least support for those non-GCM ciphers: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA256 Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: TLS 1.2 Issue with openldap 2.4.36 built on NSS 3.15.3
On Fri, Nov 29, 2013 at 03:53:09PM -0800, Elio Maldonado Batiz wrote: Firefox 27 will support TLS 1.2, see https://bugzilla.mozilla.org/show_bug.cgi?id=861266 I know, and the only TLS 1.2 cipher will be GCM. Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: TLS 1.2 Issue with openldap 2.4.36 built on NSS 3.15.3
On Tue, Nov 26, 2013 at 01:14:50PM +, Sameer Stephen wrote: Hi, We have an application which uses pam_ldap.so module to connect to LDAP server. Our application( i.e. client ) uses openldap(2.4.36) which is built against mozilla NSS library(3.15.3) and as per NSS mozilla official website, it supports TLSv1.2 protocol/ciphers. Our application run on RHEL 6 and we have configured pam_ldap.conf with following parameters: === host XXX base dc=, dc= ssl on tls_ciphers TLSv1.2+HIGH:!AESGCM:!aNULL:!eNULL === That looks like an openssl string to me. That would give you the following ciphers if you use openssl 1.0.1: ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384 ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA384 DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256 DHE-DSS-AES256-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(256) Mac=SHA256 ECDH-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(256) Mac=SHA384 ECDH-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256) Mac=SHA384 AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256 ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256 ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA256 DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256 DHE-DSS-AES128-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(128) Mac=SHA256 ECDH-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(128) Mac=SHA256 ECDH-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128) Mac=SHA256 AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256 Is there a reason why you disable GCM? I can see no good reason to disable it. It really is what you want in the first place. As far as I know NSS doesn't support any of those. As far as I know the only cipher that requires TLS 1.2 and is supported by NSS is currently the GCM one. But I'm not sure which version of NSS has support for GCM. Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
On Mon, Nov 18, 2013 at 06:47:08PM -0800, Wan-Teh Chang wrote: On Mon, Nov 18, 2013 at 4:57 PM, Brian Smith br...@briansmith.org wrote: Also, AES implementations are highly optimized, well-audited, well-tested, and are more likely to be side-channel free. Camellia doesn't get used very often. Yet, some websites (most famously, Yahoo!), prefer Camellia over AES, even when we offer AES at higher priority in the handshake. There must be a misunderstanding. NSS offers Camellia at higher priority than AES in the ClientHello. Yes, in the current stable version camellia is often negiotiated if the server supports it because it's almost always above the AES ciphers in the list. The biggest exception to that is ECDHE, because there is no camellia cipher of that. I think that the new order makes more sense, and at least in aurora the order has changed now. Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removing SSL 2.0 from NSS (was Re: Removing dead code from NSS)
On Mon, Oct 07, 2013 at 11:17:46AM -0700, Brian Smith wrote: On Fri, Oct 4, 2013 at 6:52 PM, Ludovic Hirlimann ludovic+n...@mozilla.com wrote: Hi, AFAIK NSS still contains code for SSL2 , but no product uses it. SSL2 has been turned off at least 2 years ago. By removing SSL2 code we get : Smaller librarie faster compile time + test time What do you guys think ? Hi Ludovic, I do think it is time to remove SSL 2.0 support from libssl. I'm all for removing SSL 2.0 support. OpenSSL still supports SSL 2.0, but the default cipher list doesn't include any ciphers that can be used with SSL 2.0 and so thus disabling the use of SSL 2.0 by default. I assume the same goes for NSS. In Debian I decided to build openssl since 1.0.0 without SSL 2.0 support, I didn't receive any negative feedback from that. At that point it didn't support TLS 1.1 or 1.2 yet since that only got added in 1.0.1. But the 1.0.0 version wasn't part of any release. Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
On Fri, Aug 30, 2013 at 01:10:08AM +0200, Kurt Roeckx wrote: So what needs to happen so that we can move on with this? I still have the same question. Nothing seems to be happening. Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
On Mon, Sep 09, 2013 at 07:20:57PM +0100, Rob Stradling wrote: Probably worth keeping an eye on this new draft and the related discussion on the TLS list... http://tools.ietf.org/html/draft-sheffer-tls-bcp-00 Note that the recommended cipher there isn't in Brian's proposal, and I've already pointed that out. Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
On Mon, Sep 09, 2013 at 11:29:19AM -0400, Stefan Arentz wrote: On Sep 9, 2013, at 11:16 AM, Gervase Markham g...@mozilla.org wrote: On 09/08/13 03:30, Brian Smith wrote: Please see https://briansmith.org/browser-ciphersuites-01.html This proposal promotes ECC. http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance Schneier: Prefer conventional discrete-log-based systems over elliptic-curve systems; the latter have constants that the NSA influences when they can. He elaborates in the comments: I no longer trust the constants. I believe the NSA has manipulated them through their relationships with industry. Does that affect your proposal? Wasn't he talking about http://en.wikipedia.org/wiki/Dual_EC_DRBG#Controversy ? No, he actually said he doesn't trust any ECC, but on the other hand said that we should probably move to at least 500 bit ECC. Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
So what needs to happen so that we can move on with this? Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
On Mon, Aug 26, 2013 at 05:16:43PM -0700, Robert Relyea wrote: 2) It does have a significant downside speed wise. I was responsible for measuring this once from the server perspective (we were trying to convince people to use ECC. I could only get wins over RSA at the 2048 bit range with ECDH (224bit) not ECDHE... and that was ECDHE where we used a single private key generated at server startup). Note that we are using 256 bit ECC at the low end. Those figures are old, so it would be good to try to get new ones from the client perspective (not how many connections a server can use). I'm not as worried about the order for servers as servers can manage their performance by only supporting the fast algorithms. See http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html I think this is the most relevant one. Most of the others compare it to 1024 RSA keys. Only about 4% is still using 1024 keys now, while the rest is using 2048 or more. Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
On 08/09/2013 04:30 AM, Brian Smith wrote: Please see https://briansmith.org/browser-ciphersuites-01.html First, this is a proposal to change the set of sequence of ciphersuites that Firefox offers. So I think there are a whole bunch of things where we have 2 options, and it's not always clear which is more important. We have: - PFS or not - ECC or not - RSA or DSA - GCM or CBC - keysize (128 vs 256) - cipher itself - The used MAC As far as I understand things, most of those don't have a big impact on security, but do on the speed. I think it makes sense to have PFS when the other side supports it, so that part of the order looks good to me. We clearly want (EC)DHE when possible. DH should probably be avoided. I understand that ECC might be more secure and is faster, so you want to prefer ECC. But currently there aren't many servers that have ECDHE yet, so we should be careful what the order is in case it's not available and try to use DHE in that case. The current list didn't do that but this one does. I'm not sure which of RSA and DSA is better, but clearly people use RSA more. I understand that GCM is faster, but the implementations might have side channel attacks. So I'm not sure if GCM or CBC is better, but we should probably prefer GCM or CBC. I understand that for a 2048 bit public key a 128 bit symmetric key should be good enough, but for a 4096 you should have a larger key. I see that about 2% is using keys of 4096 bit. As far as I understand it, there is nothing wrong with 3DES other than that it's slower. RC4 should clearly be deprecated, but is currently popular because BEAST and that it's the only stream cipher we have. Since we know we're not vulnerable to that, it make sense to order this as late as possible. It might not be obvious, but camellia is currently used a lot when connecting to sites because it's the first non-ECDHE in the current list. And the RSA key-exchange was even before the DHE version. I understand that the MAC itself doesn't make much difference, but we should probably avoid MD5. I see no SHA256 MACs except for GCM which probably isn't a problem. So I can mostly follow the reasoning behind the proposed order, but I'm a little bit surprised that we used to have all the 256 bit before the 128 bit, and it's now the other way around. I don't really see this as a problem except for people that want to use 4096 bit public keys. They should probably disable 128 bit keys on their server. I'm not sure why you keep TLS_DHE_DSS_WITH_AES_128_CBC_SHA and drop TLS_DHE_DSS_WITH_AES_256_CBC_SHA I'm concerned that DHE_RSA_WITH_3DES_EDE_CBC_SHA is dropped, since it's the only one with PFS that some sites support. Can I suggest you add that before the ECDHE_*_RC4 ciphers? Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
On Mon, Aug 19, 2013 at 08:06:49PM +0200, Kurt Roeckx wrote: I understand that the MAC itself doesn't make much difference, but we should probably avoid MD5. I see no SHA256 MACs except for GCM which probably isn't a problem. I'm having mixed feelings about SHA1 / SHA256. I think it makes sense to move to SHA256 even when SHA1 isn't broken as used here. But since we do this already use it for GCM, and that's on top of the list, I think it's fine. I'm concerned that DHE_RSA_WITH_3DES_EDE_CBC_SHA is dropped, since it's the only one with PFS that some sites support. Can I suggest you add that before the ECDHE_*_RC4 ciphers? I also just noticed that all GCM suites we have are ECDHE versions. I would like to have a DHE version too since apache 2.2 doesn't support ECDHE but does have support for the DHE GCM ciphers. I would like to see that as first non-ECDHE cipher in the list. Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
