Re: [Cryptography] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)
At a stretch, one can imagine circumstances in which trying multiple seeds to choose a curve would lead to an attack that we would not easily replicate. I don't suggest that this is really what happened; I'm just trying to work out whether it's possible. Suppose you can easily break an elliptic curve with the right "attack string". Attack strings are very expensive to generate, at say 2^80 operations. Moreover, you can't tell what curves they break until they are generated, but it's cheap to test whether a given string breaks a given curve. Each string breaks about one curve in 2^80. Thus the NSA generate an attack string, then generate 2^80 curves looking for one that is broken by the string they generated. They can safely publish this curve, knowing that unless a new attack is developed it will take 2^160 effort for anyone else to generate an attack string that breaks the curve they have chosen. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)
On Sep 10, 2013, at 3:56 PM, Bill Stewart wrote:
>> One point which has been mentioned, but perhaps not emphasised enough - if
>> NSA have a secret backdoor into the main NIST ECC curves, then even if the
>> fact of the backdoor was exposed - the method is pretty well known - without
>> the secret constants no-one _else_ could break ECC.
>> So NSA could advocate the widespread use of ECC while still fulfilling their
>> mission of protecting US gubbmint communications from enemies foreign and
>> domestic. Just not from themselves.
I think this is completely wrong.
First, there aren't any secret constants to those curves, are there? The
complaint Dan Bermstein has about the NIST curves is that they (some of them)
were generated using a verifiably random method, but that the seeds looked
pretty random. The idea here, if I understand it correctly, is that if the
guys doing the generation knew of some property that made some of the choices
of curves weak, they could have tried a huge number of seeds till they happened
upon one that led to a weak curve. If they could afford to try N seeds and do
whatever examination of the curve was needed to check it for weakness, then the
weak property they were looking for couldn't have had a probability much lower
than about 1/N.
I think the curves were generated in 1999 (that's the date on the document I
could find), so we are probably talking about less than 2^{80} operations
total. Unlike the case with the Dual EC generator, where a backdoor could have
been installed with no risk that anyone else could discover it, in this case,
they would have to generate curves until one fell in some weak curve class that
they knew about, and they would have to hope nobody else ever discovered that
weak curve class, lest all the federal users of ECC get broken at once.
The situation you are describing works for dual ec drbg, but not for the NIST
curves, as best I understand things.
--John
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)
On Tue, Sep 10, 2013 at 3:56 PM, Bill Stewart wrote: > At 11:33 AM 9/6/2013, Peter Fairbrother wrote: > >> However, while the case for forward secrecy is easy to make, implementing >> it may be a little dangerous - if NSA have broken ECDH then >> using it only gives them plaintext they maybe didn't have before. >> > > I thought the normal operating mode for PFS is that there's an initial > session key exchange (typically RSA) and authentication, > which is used to set up an encrypted session, and within that session > there's a DH or ECDH key exchange to set up an ephemeral session key, > and then that session key is used for the rest of the session. > If so, even if the NSA has broken ECDH, they presumably need to see both > Alice and Bob's keyparts to use their break, > which they can only do if they've cracked the outer session (possibly > after the fact.) > So you're not going to leak any additional plaintext by doing ECDH > compared to sending the same plaintext without it. One advantage of this approach is that we could use RSA for one and ECC for the other and thus avoid most consequences of an RSA2048 break (if that is possible). The problem I see reviewing the list is that ECC has suddenly become suspect and we still have doubts about the long term use of RSA. It also have the effect of pushing the ECC IPR concerns off the CA and onto the browser/server providers. I understand that many have already got licenses that allow them to do what they need in that respect. Perfect Forward Secrecy is not perfect. In fact it is no better than regular public key. The only difference is that if the public key system is cracked then with PFS the attacker has to break every single key exchange and not just the keys in the certificates and if you use an RSA outer with an ECC inner then you double the cryptanalytic cost of the attack (theory as well as computation). I think this is the way forward. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)
On Wed, Sep 11, 2013 at 2:40 PM, Bill Stewart wrote: > At 10:39 AM 9/11/2013, Phillip Hallam-Baker wrote: > >> Perfect Forward Secrecy is not perfect. In fact it is no better than >> regular public key. The only difference is that if the public key system is >> cracked then with PFS the attacker has to break every single key exchange >> and not just the keys in the certificates and if you use an RSA outer with >> an ECC inner then you double the cryptanalytic cost of the attack (theory >> as well as computation). >> > > I wouldn't mind if it had been called Pretty Good Forward Secrecy instead, > but it really is a lot better than regular public key. > My point was that the name is misleading and causes people to look for more than is there. It took me a long time to work out how PFS worked till I suddenly realized that it does not deliver what is advertised. > The main difference is that cracking PFS requires breaking every single > key exchange before the attack using cryptanalysis, while cracking the RSA > or ECC outer layer can be done by compromising the stored private key, > which is far easier to do using subpoenas or malware or rubber hoses than > cryptanalysis. > That is my point precisely. Though the way you put it, I have to ask if PFS deserves higher priority than Certificate Transparency. As in something we can deploy in weeks rather than years. I have no problem with Certificate Transparency. What I do have trouble with is Ben L.'s notion of Certificate Transparency and Automatic Audit in the End Client which I imposes a lot more in the way of costs than just transparency and moreover he wants to push out the costs to the CAs so he can hyper-tune the performance of his browser. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)
At 10:39 AM 9/11/2013, Phillip Hallam-Baker wrote: Perfect Forward Secrecy is not perfect. In fact it is no better than regular public key. The only difference is that if the public key system is cracked then with PFS the attacker has to break every single key exchange and not just the keys in the certificates and if you use an RSA outer with an ECC inner then you double the cryptanalytic cost of the attack (theory as well as computation). I wouldn't mind if it had been called Pretty Good Forward Secrecy instead, but it really is a lot better than regular public key. The main difference is that cracking PFS requires breaking every single key exchange before the attack using cryptanalysis, while cracking the RSA or ECC outer layer can be done by compromising the stored private key, which is far easier to do using subpoenas or malware or rubber hoses than cryptanalysis. (Of course, any messages that were saved by the sender or recipient can still be cracked by non-cryptanalytic techniques as well, but that's a separate problem.) ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)
On Tue, Sep 10, 2013 at 12:56:16PM -0700, Bill Stewart wrote: > I thought the normal operating mode for PFS is that there's an > initial session key exchange (typically RSA) and authentication, > which is used to set up an encrypted session, and within that > session there's a DH or ECDH key exchange to set up an ephemeral > session key, and then that session key is used for the rest of the > session. This is not the case in TLS. The EDH or EECDH key exchange is performed in the clear. The server EDH parameters are signed with the server's private key. https://tools.ietf.org/html/rfc2246#section-7.4.3 In TLS with EDH (aka PFS) breaking the public key algorithm of the server certificate enables active attackers to impersonate the server (including MITM attacks). Breaking the Diffie-Hellman or EC Diffie-Hellman algorithm used allows a passive attacker to recover the session keys (break must be repeated for each target session), this holds even if the certificate public-key algorithm remains secure. -- Viktor. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)
At 11:33 AM 9/6/2013, Peter Fairbrother wrote: However, while the case for forward secrecy is easy to make, implementing it may be a little dangerous - if NSA have broken ECDH then using it only gives them plaintext they maybe didn't have before. I thought the normal operating mode for PFS is that there's an initial session key exchange (typically RSA) and authentication, which is used to set up an encrypted session, and within that session there's a DH or ECDH key exchange to set up an ephemeral session key, and then that session key is used for the rest of the session. If so, even if the NSA has broken ECDH, they presumably need to see both Alice and Bob's keyparts to use their break, which they can only do if they've cracked the outer session (possibly after the fact.) So you're not going to leak any additional plaintext by doing ECDH compared to sending the same plaintext without it. One point which has been mentioned, but perhaps not emphasised enough - if NSA have a secret backdoor into the main NIST ECC curves, then even if the fact of the backdoor was exposed - the method is pretty well known - without the secret constants no-one _else_ could break ECC. So NSA could advocate the widespread use of ECC while still fulfilling their mission of protecting US gubbmint communications from enemies foreign and domestic. Just not from themselves. Yep. It's definitely the fun kind of backdoor to use. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS
On Fri, Sep 06, 2013 at 06:18:05PM +0100, Ben Laurie wrote: > On 6 September 2013 18:13, Perry E. Metzger wrote: > > > It would be good to see them abandon RC4 of course, and soon. > > > > In favour of what, exactly? We're out of good ciphersuites. Please ask your friendly neighborhood TLS implementor to move fast on http://tools.ietf.org/id/draft-josefsson-salsa20-tls-02.txt . Regards, Zooko ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS
On 10 September 2013 18:00, zooko wrote: > On Fri, Sep 06, 2013 at 06:18:05PM +0100, Ben Laurie wrote: > > On 6 September 2013 18:13, Perry E. Metzger wrote: > > > > > It would be good to see them abandon RC4 of course, and soon. > > > > > > > In favour of what, exactly? We're out of good ciphersuites. > > Please ask your friendly neighborhood TLS implementor to move fast on > http://tools.ietf.org/id/draft-josefsson-salsa20-tls-02.txt . > We prefer https://datatracker.ietf.org/doc/draft-agl-tls-chacha20poly1305/. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS
On 6/09/13 21:11 PM, Perry E. Metzger wrote: On Fri, 6 Sep 2013 18:56:51 +0100 Ben Laurie wrote: The problem is that there's nothing good [in the way of ciphers] left for TLS < 1.2. So, lets say in public that the browser vendors have no excuse left for not going to 1.2. I hate to be a conspiracy nutter, but it is that kind of week. Anyone at a browser vendor resisting the move to 1.2 should be viewed with deep suspicion. (Heck, if they're not on the government's payroll, then shame on them for retarding progress for free. They should at least be charging. And yes, I'm aware many of the people resisting are probably doing so without realizing they're harming internet security, but we can no longer presume that is the motive.) Chrome handles 1.2, there is no longer any real excuse for the others not to do the same. The sentiment I agree with. But the record of such transitions is not good. E.g., Back in September 2009 Ray & Dispensa discovered a serious bug with renegotiation in SSL. According to SSL Pulse, it took until around April of this year [0] before 80% of the SSL hosts were upgraded to cover the bug. Which gives us an OODA response loop of around 3-4 years. And, that was the best it got -- the SSL community actually cared about that bug. It gets far worse in stuff that they consider not to be a bug, such as HTTPS Everywhere, TLS/SNI, MD5, browser security fixes for phishing, HTTP-better-than-self-signed, HTTPS starting up with its own self-signed cert, etc, etc. iang [0] it depends on how you measure the 80% mark, though. PS: More here on OODA loops http://financialcryptography.com/mt/archives/001210.html http://financialcryptography.com/mt/archives/001444.html ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/06/2013 09:02 PM, Chris Palmer wrote: > First time I've heard of 128-bit symmetric called "weak"... Sure, > RC4 isn't awesome but they seem to be saying that 128-bit keys per > se are weak. calomel.org may be erring on the side of "weak" due to known vulnerabilities in RC4. > Without good server authentication, the other stuff doesn't > matter. I am inclined to agree with you. > With Chrome, you get key pinning when talking to some sites > (including Google sites, Tor, and Twtitter); I'd much rather have > that and "only" 128-bit symmetric. Also, I don't know why you > weren't getting forward secrecy; check your Firefox configuration. I did some poking around inside its configuration and it does not seem to be negotiating upward in strength, but for whatever it can get (see other post this evening). I am uncertain as to why; some investigation is in order, but slash/burn/upgrade may be safest. - -- The Doctor [412/724/301/703] [ZS] Developer, Project Byzantium: http://project-byzantium.org/ PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: https://drwho.virtadpt.net/ Too bizarre for real life, too normal to wind up on Art Bell. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIqok4ACgkQO9j/K4B7F8HX2ACZAStTl0wR/JJqI7n182jLX6mD 5i0AnAopo0YASsPGYVVntF9KKUwwrpRN =9Acb -END PGP SIGNATURE- ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS
On Fri, Sep 6, 2013 at 5:34 PM, The Doctor wrote: > Symmetric cipher RC4 (weak 10/49) > Symmetric key length 128 bits (weak 8/19) > Cert issued by Google, Inc, US SHA-1 with RSA @ 2048 bit (MODERATE 2/6) First time I've heard of 128-bit symmetric called "weak"... Sure, RC4 isn't awesome but they seem to be saying that 128-bit keys per se are weak. > Let's contrast this with ChaosPad: > Symmetric cipher Camellia (STRONG 39/39) > Symmetric key length 256 bits (STRONG 19/19) > Cert issued by CAcert, Inc. SHA-1 with RSA @ 4096 bit (MODERATE 2/6) Without good server authentication, the other stuff doesn't matter. With Chrome, you get key pinning when talking to some sites (including Google sites, Tor, and Twtitter); I'd much rather have that and "only" 128-bit symmetric. Also, I don't know why you weren't getting forward secrecy; check your Firefox configuration. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/06/2013 01:13 PM, Perry E. Metzger wrote: > Google is also now (I believe) using PFS on their connections, and > they handle more traffic than anyone. A connection I just made to > https://www.google.com/ came out as, TLS 1.2, RC4_128, SHA1, > ECDHE_RSA. Addendum: Calomel SSL Validation has an interesting set of configuration options, which may be of interest and discussion. Two noteworthy ones: - - FIPS 140-2 restricted 256 bit ciphers - - ...AND limit to Perfect Forward Secrecy ciphers Interestingly, turning this on breaks access to https://addons.mozilla.org/. Bluh. - -- The Doctor [412/724/301/703] [ZS] Developer, Project Byzantium: http://project-byzantium.org/ PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: https://drwho.virtadpt.net/ "Be the strange that you want to see in the world." --Gareth Branwyn -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIqdcYACgkQO9j/K4B7F8EKrQCguaWu9UGXABSkUwKJ7A+9n7NX KUoAn3D1AF+NW8KIu9BoIDoxllKkE2+K =GSYs -END PGP SIGNATURE- ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/06/2013 01:13 PM, Perry E. Metzger wrote: > Google is also now (I believe) using PFS on their connections, and > they handle more traffic than anyone. A connection I just made to > https://www.google.com/ came out as, TLS 1.2, RC4_128, SHA1, > ECDHE_RSA. There may be limits to how far they've deployed PFS on their user-facing services around the world at this time. I just accessed encrypted.google.com and Gmail from home, and here's what the Calomel SSL Validation add-on for Firefox (with HTTPS Finder and HTTPS-Everywhere, verified manually) and is telling me: Symmetric cipher RC4 (weak 10/49) Symmetric key length 128 bits (weak 8/19) Cert issued by Google, Inc, US SHA-1 with RSA @ 2048 bit (MODERATE 2/6) Manually keying https://www.google.com/ into my browser returned the same thing. Gmail shows me this: Symmetric cipher RC4 (weak 10/39) Symmetric key length 128 bits (weak 8/19) Cert issued by Google, Inc, US SHA-1 with RSA @ 2048 bit (MODERATE 2/6) https://www.google.com/analytics is returning the same as Gmail. Let's contrast this with ChaosPad: Symmetric cipher Camellia (STRONG 39/39) Symmetric key length 256 bits (STRONG 19/19) Cert issued by CAcert, Inc. SHA-1 with RSA @ 4096 bit (MODERATE 2/6) I'd be very interested in what other people see where they are. Alternatively, my browser's SSL/TLS configuration could be hosed, in which case I'm completely off base and probably need to torch my browser profile and start over. - -- The Doctor [412/724/301/703] [ZS] Developer, Project Byzantium: http://project-byzantium.org/ PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: https://drwho.virtadpt.net/ "Be the strange that you want to see in the world." --Gareth Branwyn -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIqdHwACgkQO9j/K4B7F8Ez8QCg0BvBhYA5EFVrTRwEqUCJFh0Y Pd8AoJGg5Zg+sKL4NdK76JxcwT1Yvcmb =T/D2 -END PGP SIGNATURE- ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS
> "PEM" == Perry E Metzger writes: PEM> Anyone at a browser vendor resisting the move to 1.2 should be PEM> viewed with deep suspicion. Is anyone? NSS has 1.2 now; it is, AIUI, in progress for ff and sm. Chromium supports it (as of version 29, it seems). Opera supports 1.2 (at least as of version 12, maybe earlier?). Arora 0.11.0 doesn't seem to provide a way to check Links and elinks only did tls 1.1. I don't see a way to get lynx or w3m (text browsers), midori, luakit or xombrero (webkit-gtk) or qupzilla (webkit-qt) to report the tls version details. So I cannot confirm what webkit can do. A bug report from 2011 for polarssl mentions that ie9 can do 1.2. I don't think there is anything else I can test. With it in openssl, gnutls, nss, polarssl, et alia support seems pretty complete. It will take some time for the current ff alpha to filter down to a "release", but otherwise things look good on the 1.2 front. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)
we were brought in as consultants to a small client/server startup that wanted to do payment transactions on their server, they had this technology they called "SSL" they wanted to use, the result is now frequently called "electronic commerce". The two people at the startup responsible for the "commerce server" we had worked with in prior life on parallel Oracle cluster scaleup. As part of mapping "SSL" technology to payment transactions we had to audit operations selling "SSL" digital certificates and also came up with recommendations on how browsers and servers would deploy and use the technology. Almost immediately several of the recommendations were violated, resulting in some number of the exploits that continue to this day. We were then tangentially involved in the Cal. data breach notification legislation, having been brought in to help wordsmith the Cal. electronic signature legislation. Many of the parties were heavily involved in privacy issues and had done numerous, indepth, public surveys. The number one issue was "identity theft" of the form involving fraudulent financial transactions ... frequently as result of data breach. The issue was nothing was being done about the problems and so it was hoped that the publicity from the notifications might motivate corrective action. Part of the issue is normally institutions take security measures in self-interests ... however, the institutions having breaches weren't at risk, it was the account holders. PCI DSS shows up some time after Cal. data breach notification and frequently the joke is that if you have a breach ... you loose your PCI DSS certification. It turns out that there was a number of Federal "data breach notification" bills introduced, preempting state legislation and effectively eliminating notification requirements ... citing PCI DSS industry effort as justification for no longer needing notification. Another problem we've frequently pointed out is current paradigm with "dual use" paradigm and even if the planet was covered in miles of information hiding encryption, it wouldn't stop data leakage. Account information is used for authenticating new transactions and so has a requirement that it be kept totally confidential and never divulged to anybody ... but at the same time, account information is needed in dozens of business processes at millions of locations around the planet. disclaimer: we were co-authors of the x9.59 financial transaction standard that slightly tweaked the current payment paradigm and eliminated the dual-use characteristic which then also eliminated the need to hide account information and as a result it also eliminated the need for SSL to hide account information in electronic commerce transactions eliminating the major requirement for SSL in the world today. -- virtualization experience starting Jan1968, online at home since Mar1970 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)
On 6 September 2013 17:20, Peter Saint-Andre wrote: > Is there a handy list of PFS-friendly > ciphersuites that I can communicate to XMPP developers and admins so > they can start upgrading their software and deployments? > Anything with EDH, DHE or ECDHE in the name... ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)
On 6/09/13 20:15 PM, Daniel Veditz wrote: On 9/6/2013 9:52 AM, Raphaël Jacquot wrote: To meet today’s PCI DSS crypto standards DHE is not required. PCI is about credit card fraud. So was SSL ;-) Sorry, couldn't resist... Mastercard/Visa aren't worried that criminals are storing all your internet purchase transactions with the hope they can crack it later; if the FBI/NSA want your CC number they can get it by asking. That's what the crims do to, they ask for all the numbers, they don't bother much with SSL. iang ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS
On 6 September 2013 18:13, Perry E. Metzger wrote: > Google is also now (I believe) using PFS on their connections, and > they handle more traffic than anyone. A connection I just made to > https://www.google.com/ came out as, TLS 1.2, RC4_128, SHA1, > ECDHE_RSA. > > It would be good to see them abandon RC4 of course, and soon. > In favour of what, exactly? We're out of good ciphersuites. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS
On Fri, 06 Sep 2013 18:52:46 +0200 Raphaël Jacquot wrote: > While I applaud this move on the part of the Nginx dev team there > is a tradeoff and that is slower performance. DHE provides stronger > encryption which in turn requires more computation but here’s where > it gets interesting. To meet today’s PCI DSS crypto standards DHE > is not required. Like many things in life there’s a balance to be > struck between the risk of compromised encryption and the > additional expense or rather the relative loss of connections per > second. As I've said earlier, I think that we no longer have the luxury of speaking in terms of higher connection establishment latency or similar considerations as a reason not to use PFS techniques. At the very least, we should presume that people will pressure technologists to overconsider such issues in an attempt to assure that stealing keys is enough to be able to read TLS connections. Certainly in a very wide variety of contexts, like XMPP, connections are so long lived that there is never a performance excuse. Google is also now (I believe) using PFS on their connections, and they handle more traffic than anyone. A connection I just made to https://www.google.com/ came out as, TLS 1.2, RC4_128, SHA1, ECDHE_RSA. It would be good to see them abandon RC4 of course, and soon. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS
On Fri, 6 Sep 2013 18:56:51 +0100 Ben Laurie wrote: > The problem is that there's nothing good [in the way of ciphers] > left for TLS < 1.2. So, lets say in public that the browser vendors have no excuse left for not going to 1.2. I hate to be a conspiracy nutter, but it is that kind of week. Anyone at a browser vendor resisting the move to 1.2 should be viewed with deep suspicion. (Heck, if they're not on the government's payroll, then shame on them for retarding progress for free. They should at least be charging. And yes, I'm aware many of the people resisting are probably doing so without realizing they're harming internet security, but we can no longer presume that is the motive.) Chrome handles 1.2, there is no longer any real excuse for the others not to do the same. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)
On 06/09/13 15:36, Perry E. Metzger wrote: One solution, preventing passive attacks, is for major browsers and websites to switch to using PFS ciphersuites (i.e. those based on ephemeral Diffie-Hellmann key exchange). It occurred to me yesterday that this seems like something all major service providers should be doing. I'm sure that some voices will say additional delay harms user experience. Such voices should be ruthlessly ignored. Any additional delay will be short - after all, if forward secrecy by ephemeral key setup (I hate the term PFS, there is nothing perfect about it) is not used then you have to use something else - usually RSA - instead. For a desktop, laptop, or even a decent mobile the difference is not noticeable in practice if the server is fast enough. However, while the case for forward secrecy is easy to make, implementing it may be a little dangerous - if NSA have broken ECDH then using it only gives them plaintext they maybe didn't have before. Personally, operating on the assumption that NSA have not made a crypto break is something I'm not prepared to do. I just don't know what that break is is. I think it's most likely RSA/DH or ECC, but could easily be wrong. I don't really care if the "break" is non-existent, irrelevant or disinformation - beefing up today's crypto is only hard in terms of getting people to choose a new updated crypto, and then getting people to implement it. This happens every so often anyway. One point which has been mentioned, but perhaps not emphasised enough - if NSA have a secret backdoor into the main NIST ECC curves, then even if the fact of the backdoor was exposed - the method is pretty well known - without the secret constants no-one _else_ could break ECC. So NSA could advocate the widespread use of ECC while still fulfilling their mission of protecting US gubbmint communications from enemies foreign and domestic. Just not from themselves. Looking at timing, the FIPS 186-3 curves were introduced in July 2009 - the first hints that NSA had made a cryptanalytic break came in early to mid 2010. I'm still leaning towards RSA, but ... -- Peter Fairbrother ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS
On 6 September 2013 18:24, Perry E. Metzger wrote: > On Fri, 6 Sep 2013 18:18:05 +0100 Ben Laurie wrote: > > On 6 September 2013 18:13, Perry E. Metzger > > wrote: > > > > > Google is also now (I believe) using PFS on their connections, and > > > they handle more traffic than anyone. A connection I just made to > > > https://www.google.com/ came out as, TLS 1.2, RC4_128, SHA1, > > > ECDHE_RSA. > > > > > > It would be good to see them abandon RC4 of course, and soon. > > > > > > > In favour of what, exactly? We're out of good ciphersuites. > > I thought AES was okay for TLS 1.2? Isn't the issue simply that > Firefox etc. still use TLS 1.0? Note that this was a TLS 1.2 > connection. > Apart from its fragility, AES-GCM is still OK, yes. The problem is that there's nothing good left for TLS < 1.2. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)
On 9/6/2013 9:52 AM, Raphaël Jacquot wrote: > To meet today’s PCI DSS crypto standards DHE is not required. PCI is about credit card fraud. Mastercard/Visa aren't worried that criminals are storing all your internet purchase transactions with the hope they can crack it later; if the FBI/NSA want your CC number they can get it by asking. -Dan Veditz smime.p7s Description: S/MIME Cryptographic Signature ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)
On 06.09.2013 18:20, Peter Saint-Andre wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/6/13 8:36 AM, Perry E. Metzger wrote: One solution, preventing passive attacks, is for major browsers and websites to switch to using PFS ciphersuites (i.e. those based on ephemeral Diffie-Hellmann key exchange). It occurred to me yesterday that this seems like something all major service providers should be doing. I'm sure that some voices will say additional delay harms user experience. Such voices should be ruthlessly ignored. +1 In practice, how do we make that happen? On the XMPP network we're pushing to make sure that all client-to-server and server-to-server hops are encrypted (yes, I know, per-hop encryption is not enough, we need end-to-end encryption too). Is there a handy list of PFS-friendly ciphersuites that I can communicate to XMPP developers and admins so they can start upgrading their software and deployments? Thanks! Peter yet, one can find this sort of thing in 3rd position when searching "nginx crypto" : http://www.hybridforge.com/blog/nginx-ssl-ciphers-and-pci-compliance quote : The developers of Nginx have recently changed the default SSL ciphers to include the very strong Diffie-Hellman Ephemeral (DHE) cipher. DHE is used to provide perfect forward secrecy in TLS. Further reading on Ephermal Diffie-Hellman, PFS and TLS at Wikipedia.org While I applaud this move on the part of the Nginx dev team there is a tradeoff and that is slower performance. DHE provides stronger encryption which in turn requires more computation but here’s where it gets interesting. To meet today’s PCI DSS crypto standards DHE is not required. Like many things in life there’s a balance to be struck between the risk of compromised encryption and the additional expense or rather the relative loss of connections per second. I’m not a lawyer nor should this be considered legal advice but I prefer things that go fast while meeting the necessary PCI compliance criteria. In order to disable DHE in the server context of the Nginx configuration add the following line: ssl_ciphers RC4:HIGH:!aNULL:!MD5:!kEDH; ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS
Hi, >>> It would be good to see them abandon RC4 of course, and soon. >> >> In favour of what, exactly? We're out of good ciphersuites. > > I thought AES was okay for TLS 1.2? Isn't the issue simply that > Firefox etc. still use TLS 1.0? Note that this was a TLS 1.2 > connection. Firefox has added TLS 1.2 two or three weeks ago, and TLS 1.2 does indeed protect against BEAST, CRIME, Lucky 13 (but not against BREACH, I recall). However, my guess would be that too many Apaches out there are linked to older openssl versions that do not yet support TLS 1.1 or TLS 1.2. I have found this a good write-up: https://www.isecpartners.com/media/106031/ssl_attacks_survey.pdf Ralph ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS
On Fri, 6 Sep 2013 18:18:05 +0100 Ben Laurie wrote: > On 6 September 2013 18:13, Perry E. Metzger > wrote: > > > Google is also now (I believe) using PFS on their connections, and > > they handle more traffic than anyone. A connection I just made to > > https://www.google.com/ came out as, TLS 1.2, RC4_128, SHA1, > > ECDHE_RSA. > > > > It would be good to see them abandon RC4 of course, and soon. > > > > In favour of what, exactly? We're out of good ciphersuites. I thought AES was okay for TLS 1.2? Isn't the issue simply that Firefox etc. still use TLS 1.0? Note that this was a TLS 1.2 connection. -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/6/13 8:36 AM, Perry E. Metzger wrote: >>> One solution, preventing passive attacks, is for major >>> browsers and websites to switch to using PFS ciphersuites (i.e. >>> those based on ephemeral Diffie-Hellmann key exchange). > > It occurred to me yesterday that this seems like something all > major service providers should be doing. I'm sure that some voices > will say additional delay harms user experience. Such voices should > be ruthlessly ignored. +1 In practice, how do we make that happen? On the XMPP network we're pushing to make sure that all client-to-server and server-to-server hops are encrypted (yes, I know, per-hop encryption is not enough, we need end-to-end encryption too). Is there a handy list of PFS-friendly ciphersuites that I can communicate to XMPP developers and admins so they can start upgrading their software and deployments? Thanks! Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSKgDaAAoJEOoGpJErxa2pMssQAKVjwZZqy0q2ogIk13rGZkym 8PnXm6H9qsw08q4w3NEXPOU41rEh/GpS4agcgVxA+huYo5hU+qeA8YuhrVXt2xS7 Jt/fUgpJup297W4ErUpzMDQegVfP8ckNizI2AXBfr631PKUs7U3ije6wdxK30Hyx 262V/SLP0uVnJpbmepWUMCfzTGMY0SAvq2blVAPJjqjulC6lshj/aiKP6RBi9hCF CW8yWO4L7Uot1mAa7j87Ywlyg9V8j6nKNEsKu81rjhSLpGvmed0GncK7U3GxLmsM z2VzZKRJ+NxwJ3MKicmEy2bNnPjSJUd8itUWKru2vYMZftGImljWv1cUsLjXkxI7 DvQQ0lrjl3W8tisN7aqmGPi2734j8AN6ilHAUCbWniJfaarfC6rU/fDuk6fGnFss N/zq9+NhYdvegmJiLvwVm42d1XdCxgoKzb27g/d8CsUWqWWXtQhxTeLL+OcKXiqh kXLDDTv9uqBgdqWDZ/uhhlFGd/PFfeakeW7QWDjAvRMyF3XWaHA+OBJpg+nE/Dsl kSfLmiCzOj4FN8aPQoM39T9IHbASpp+KYgnCl0nDweYXXBH/v5B/bCwsqz5Sy0ut SET7zglbKm6oVf9hWoXsv01Kqsrxw6xj2bdnMU6YSUQoDvDHdXlilRZ6dTP5G63v 8XfdEe3k0aa+7uPpWQ5t =SiIp -END PGP SIGNATURE- ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
