8 ms·

Proposal to Change the Default TLS Ciphersuites Offered by Browsers

132 points by fejr 13y ago

sillysaurus2 13y ago
Prefer faster over slower. Would any security expert give a critique of this section of the article? That line seems counterintuitive: faster sometimes means easier to break. Shouldn't the goal to be as slow as possible (but no slower than a user will tolerate)? Also, who is Brian Smith? His personal page doesn't give any info, just an email address. Searching for "brian smith cryptographer" yields a stackoverflow user page, some comments by Brian Smith on various security-related newsgroups, and a linkedin profile[1] with very strange job history -- overlapping timelines, and no entries after 2004 ... I'm assuming that's the same Brian Smith because of his interest in "Cryptography and Information Security." If that is him, I wonder who he's worked for since 2004? (Should we even be asking these kinds of intrusive questions about people who are proposing new security standards?) While I'm at it, I may as well ask: who is the submitter, fejr? His account is 5 days old with just one comment but 11 submissions, all related to the NSA or security. I'm curious how they came across this Brian Smith proposal in the first place, because that would give us some information about his background at least. This proposal seems new, because Wayback Machine has no record of that Brian Smith proposal URL[2] so fejr seems to be the first one to post this to any news website. [1] http://www.linkedin.com/pub/brian-smith/6/6b3/9a7 http://www.linkedin.com/pub/brian-smith/6/6b3/9a7 [2] http://web.archive.org/liveweb/https://briansmith.org/browser-ciphersuites-01.html http://web.archive.org/liveweb/https://briansmith.org/browse... EDIT: This article deserves a better top comment than mine. When I wrote this, the submission had zero comments and raised a whole lot of questions: Who is this person? Can we trust them? Why haven't we heard about this proposal till now? The answers came swiftly: Brian Smith works for Mozilla. Yes, we can trust that this proposal has no hidden agenda. We hadn't heard about it because it was originally posted to the Mozilla Crypto list two days ago. Now that those questions are settled, I find myself in the top comment spot and entirely undeserving of the honor. It may have been necessary to at least consider the questions I raised (trust and identity of the author), but my comment addressed none of the substance of the article. I wrote it in order to get some discussion started until tptacek comes in and writes a thorough critique of the proposal's strengths and any possible weaknesses. So please, someone, write up a good topcomment analysis of the proposal so we can upvote you. :)
- sp332 13y ago
  I think "as slow as possible" is good for the initial key exchange, or for storing keys at rest. The point is to make offline key recovery (by guessing) more difficult. But once you have a good key, the ciphertext is already completely scrambled. Slowing down won't make that part any harder.
- dtf 13y ago
  Here's some discussion on mozilla's crypto list: http://www.mail-archive.com/dev-tech-crypto@lists.mozilla.org/msg11247.html http://www.mail-archive.com/dev-tech-crypto@lists.mozilla.or...
  - sillysaurus2 13y ago
    Thanks! I also found a presentation from the Stanford Real World Cryptography event in Jan 2013 which cites Brian's work. It's an interesting read: https://crypto.stanford.edu/RealWorldCrypto/slides/gueron.pdf https://crypto.stanford.edu/RealWorldCrypto/slides/gueron.pd...
- lvh 13y ago
  No, slower doesn't mean more secure. 3DES is a lot slower than, say, AES, but nobody's suggesting 3DES is more secure than AES.
- dochtman 13y ago
  I'm pretty sure Brian currently works for Mozilla.
- tptacek 13y ago
  No, faster does not mean easier to break. Fast is a problem when brute force attacks are viable, as in with password hashes. There are no viable brute force attacks on 128 bit keys; that's why we use 128 bit keys.
  - Achshar 13y ago
    As a noob in encryption, why is it not possible to guess the 128 bit private key by brute force?
ott2 13y ago
So, Mr Smith wants to add a bunch of elliptic curve options (using the NIST curves, weakest P-256 first), while removing the widely used TLS_RSA_WITH_AES_256_CBC_SHA256 due to "concerns" about "performance" and an unsubstantiated argument that ephemeral key exchange is somehow always better. Hmm.
- bsullivan01 13y ago
  Beware of random cryptographers bearing suggestions? #HUMINT
  - ott2 13y ago
    Some of the OpenSSH and IETF mailing list archives about SSH also make interesting reading. Exactly why does RFC 4253 mandate Group 1 and Group 14 as the only required key exchange mechanisms? (They were defined by RFC 2412, written by someone who was "assigned to the DARPA Information Technology Office".) However, perhaps it would be better to fork a separate thread for such speculations.
  - jwr 13y ago
    I really hope TLS crypto standards won't be set (or changes rejected) based on who proposed a particular change. Changes should stand on their own merits. I don't see why we should trust anyone, random or not. It's not about trusting people, it's about trusting algorithms. So it doesn't really matter who in particular proposes changes.
    - bsullivan01 13y ago
      In a ideal world, but if you get a lot of "contributions" some might slip through. Remember, no one can match NSA's budget, manpower and maybe brainpower.
- hnolable 13y ago
  TLS_RSA_WITH_AES_256_CBC_SHA256 is not forward secret (if you have the certificate private key you can passively decrypt all past/future sessions) so removing it is a great idea. I'm only responding to what you said and not making a judgement about the rest of the guy's suggestions.
chmike 13y ago
Does ephemeral key exchange protect against MITM ? I don't think so. Checking for that would be difficult I think for a standrad protocol.
- hnolable 13y ago
  No, the DHE/ECDHE (ephemeral key exchanges) don't protect against MITM, it protects against passive dragnet decryption. But the RSA/ECDSA/DSS part (certificate signing) does. All TLS ciphersuites include certificate signing to protect against MITM, but not all include ephemeral key exchange.
devx 13y ago
Is (NIST) P-256 secure enough? I might be wrong, but I think DJB is suggesting it's not, and that Curve25519 is preferable because it meets all the needed security requirements: http://cr.yp.to/talks/2013.05.31/slides-dan+tanja-20130531-4x3.pdf http://cr.yp.to/talks/2013.05.31/slides-dan+tanja-20130531-4... And why just 128-bit AES? AES-256 is not much slower, is it? I think I read it's only 30 percent slower than 128-bit encryption. Either way PFS should become the default for all encrypted communications. Companies need to start setting their own minimums years ahead of what NIST is recommending. NIST recommended the use of RSA 1024-bit until 2010, so that probably means companies should've moved away from RSA 1024-bit at least 3-5 years earlier. Yet here we are, with most companies today still using RSA 1024-bit 3 years after what even NIST recommended. Time to put security over profits first. Also, as Ptacek is saying, it's time to implement TACK for certificate pinning: https://twitter.com/tqbf/status/375742847485358081 https://twitter.com/tqbf/status/375742847485358081
- hnolable 13y ago
  All the supported curves in TLS are most likely influenced by the US government (NIST, ANSI, and SECG). So we don't really have an option to use curves with a non-US provenance. http://tools.ietf.org/html/rfc4492#appendix-A http://tools.ietf.org/html/rfc4492#appendix-A or list all openssl curves: $ openssl ecparam -list_curves
  - tptacek 13y ago
    The NIST curves weren't influenced by the US government so much as they were defined by one NSA cryptographer, Jerry Solinas. On the other hand, the rationale behind their generation is pretty straightforward.
- tptacek 13y ago
  Bernstein's big problems with the NIST curves are that they turn out to be difficult to write fast constant-time point multiplication for them (bear in mind that they were chosen before this was a well-known concern), and that they're easy to screw up in implementations. Those are real concerns, but so to would be fresh implementations of Curve25519 in all new software. If one good thing comes of this most recent debacle, though, it'll be an industry reconsideration of the concepts that didn't manage to become NIST standards, like modern stream ciphers and faster curves.
herf 13y ago
This proposal is too aggressive at deprecating ciphers that are the only option for some browsers (e.g., IE8). It would be useful to add an icon to the address bar that indicates the security level of the crypto used (PFS or not, etc.)
- sanxiyn 13y ago
  Removing ciphers is aggressive, but what's wrong with deprecating ciphers?
devx 13y ago
The author seems to worry a lot about ARM performance. If this "proposal" is going to take 2-3 years to be implemented in browsers, then I wouldn't worry too much about it. The ARMv8 architecture is supposed to come with hardware optimized AES and SHA-1/SHA-2 encryption, and be "up to 10x" faster than on ARMv7. ARMv8 chips should start coming out next year. So if we're planning "for the future" here, then I'd start with ARMv8 in mind, rather than ARMv7 or even ARMv6 (which really should stop being supported already). If better and more optimal security means that older phones and lower-end ones will experience a setback in performance on some sites for the next few years (until they get upgraded), so be it.
- tptacek 13y ago
  How many years until ARMv8 represents the majority of phones? I think writing off ARMv7 is a bad idea.
- ape4 13y ago
  Just changing the order of the suites could be done quickly. Of course committees won't let that happen.
- mook 13y ago
  The author works for Mozilla (he's their security module peer), and is therefore focused on Firefox OS - which aims for low-end smartphones. Hence the reason for focusing on older ARM. Hope that helps.
  - devx 13y ago
    I know that's one of the reasons he's saying it, but that's not really everyone else' concern, too, and as I said security should come first. Firefox OS is coming to ARMv6 phones right now, so at the very least they shouldn't start with that in mind when establishing the minimum of performance for encryption. There's the ARMv7 Cortex A7 chip for low-end now, and ARMv6 chips are terrible for performance anyway. They should not be used as a starting point for very low-end phones anymore.
    - 13y ago
sanxiyn 13y ago
This proposal prefers AES-GCM. Interestingly, Adam Langley (Chrome) is against AES-GCM. https://www.imperialviolet.org/2013/01/13/rwc03.html https://www.imperialviolet.org/2013/01/13/rwc03.html
- Titanous 13y ago
  agl recently committed AES-GCM to Go. http://code.google.com/p/go/source/detail?r=01d672e76b57028a7f437527e6e0dd8c2e753af0 http://code.google.com/p/go/source/detail?r=01d672e76b57028a... http://code.google.com/p/go/source/detail?r=52670d783ec3490dfaf161747d944e7376acbfc5 http://code.google.com/p/go/source/detail?r=52670d783ec3490d...
- moonboots 13y ago
  My understanding is that Adam Langley prefers AES-GCM to all the other mac-then-encrypt cipher suites in tls 1.2. He's working on AES-GCM support in NSS [1]. [1] https://news.ycombinator.com/item?id=5365601 https://news.ycombinator.com/item?id=5365601
- tptacek 13y ago
  I think Adam Langley doesn't like GCM because its normal software implementation requires secret-dependent table lookups for speed. It's thus thought to be easy to produce a naive GCM implementation that will suffer from side channel attacks. That concern is rapidly being mitigated by newer CPUs which can do the multiplications for GCM in hardware. From a theoretical perspective, the polynomial MACs (like GHASH) are very well understood. But, much more importantly, the TLS GCM construction is the only modern stream encryption standardized and widely available to TLS. The block constructions in TLS suffer from being created before Encrypt-then-MAC was proven secure; they do the operations the other way around, and thus require extremely fiddly code to quash side channels that have (unlike GCM) already been shown to admit plausible attacks. The author of this proposal probably isn't so much making a statement about GCM so much as he is suggesting that we need to deprecate the 90's-crypto parts of TLS, which is something that is hard to argue with.
taway2012 13y ago
This site uses the 'Globalsign Organization Validation CA - G2' certificate, which I've removed from my trust list. It's is a certificate that can be theoretically used to sign any domain (i.e., it's MITM-capable). I semi-regularly see it on Cloudflare sites because their customers haven't bothered to send their own keys to Cloudflare. I thought it was ironic than article about SSL security was doing something that is less secure than possible (from the end user's point-of-view). Just to be clear, yes, I understand that the operator of brainsmith.org isn't gaining any more security by sending CF the private key to their own cert vs. using CF's G2 cert. With the first approach the end user of brainsmith.org has better security since he can view the site without having to trust an MITM-capable certificate.
- geraldcombs 13y ago
  In Cloudflare's case "haven't bothered to send their own keys" implies "haven't seen the need to pay Cloudflare $200/month or $3000/month for the ability to upload a certificate+key". AFAICT only the Business and Enterprise plans allow custom certificates.
  - harrytuttle 13y ago
    Why the fuck would anyone want to use them then? Even the shittiest shared host or VPS offer that for pittance.
    - rgbrenner 13y ago
      It's a CDN... comparing to a VPS is not even close to being fair. I've never seen a CDN that will let you load an ssl cert for less than a few hundred dollars. SNI isn't supported widely enough yet, so they have to dedicate an IP to you.
devx 13y ago
So far I haven't seen anyone question the SHA algorithms. Both SHA-1 and SHA-2 were designed by the NSA. Is everyone okay with that? SHA-3 wasn't designed by the NSA. http://en.wikipedia.org/wiki/Secure_Hash_Algorithm http://en.wikipedia.org/wiki/Secure_Hash_Algorithm
- apendleton 13y ago
  SHA is just used for verification in TLS, so the security considerations are different from those when it's used to, say, hash passwords. There's not much in the way of attacks that could take advantage of SHA being broken, and most that would would involve things like MITM-replacing packets in real-time with different ones with colliding hashes. It's probably true that for some classes of crypto problems, the NSA has incrementally-better cryptanalytical capabilities than the public does, but being able to find collisions in real-time, even for SHA1, seems like a very tall order.
- tptacek 13y ago
  Probably. The SHA-1 and SHA-2 hashes are straightforward extensions of hash designs from academia, and the constants in the hashes are derived from the first N prime numbers; they aren't mysterious in any way.
- duskwuff 13y ago
  SHA3 isn't available in browsers yet. Perhaps it should be, eventually, but until it is, SHA1/SHA2 are the best available options.
arthuredelstein 13y ago
Why not adopt the goal of deprecating all ciphersuites but one? Let's have a debate about the best ciphersuite and settle on a single one. That would decrease the attack surface and would allow the crypto community to focus on getting the implementation bug free. It would also give attackers a tighter focus, so we'd better pick the right ciphersuite! To Brian Smith's list of criteria, I would add implementation simplicity as a very important requirement.
- tptacek 13y ago
  For the past 5 years or so, we've managed to take good advantage of the fact that we had a diversity of ciphersuites, even though each of the pre-1.1 ciphersuites had problems. Trying to lock down a single known good ciphersuite would be drawing exactly the wrong lesson from recent history.
  - arthuredelstein 13y ago
    If the latest Greenwald/Schneier revelations are true, then the past 5 years of TLS have underwhelming to say the least, so I don't see what advantage has been obtained from diversity. Going forward, how are site admins to know what ciphersuite to use? This needs to be made very clear. And how are web users to know what the green lock in their browser means, if it can mean anything at all? The current state of affairs is incomprehensible to all but a very few. There needs to be a big public debate about what ciphersuite is the best. And there should be very careful scrutiny of the implementation. Choosing ciphersuite(s) is a political as well as a technical problem -- the goals should be as clear and simple as possible.
    - tptacek 13y ago
      That's what this post was about.
SchizoDuckie 13y ago
And... Why would Google ánd Microsoft do this? They are the biggest assets on the NSA list remember?

132 points by fejr 13y ago

Prefer faster over slower. Would any security expert give a critique of this section of the article? That line seems counterintuitive: faster sometimes means easier to break. Shouldn't the goal to be as slow as possible (but no slower than a user will tolerate)? Also, who is Brian Smith? His personal page doesn't give any info, just an email address. Searching for "brian smith cryptographer" yields a stackoverflow user page, some comments by Brian Smith on various security-related newsgroups, and a linkedin profile[1] with very strange job history -- overlapping timelines, and no entries after 2004 ... I'm assuming that's the same Brian Smith because of his interest in "Cryptography and Information Security." If that is him, I wonder who he's worked for since 2004? (Should we even be asking these kinds of intrusive questions about people who are proposing new security standards?) While I'm at it, I may as well ask: who is the submitter, fejr? His account is 5 days old with just one comment but 11 submissions, all related to the NSA or security. I'm curious how they came across this Brian Smith proposal in the first place, because that would give us some information about his background at least. This proposal seems new, because Wayback Machine has no record of that Brian Smith proposal URL[2] so fejr seems to be the first one to post this to any news website. [1] http://www.linkedin.com/pub/brian-smith/6/6b3/9a7 http://www.linkedin.com/pub/brian-smith/6/6b3/9a7 [2] http://web.archive.org/liveweb/https://briansmith.org/browser-ciphersuites-01.html http://web.archive.org/liveweb/https://briansmith.org/browse... EDIT: This article deserves a better top comment than mine. When I wrote this, the submission had zero comments and raised a whole lot of questions: Who is this person? Can we trust them? Why haven't we heard about this proposal till now? The answers came swiftly: Brian Smith works for Mozilla. Yes, we can trust that this proposal has no hidden agenda. We hadn't heard about it because it was originally posted to the Mozilla Crypto list two days ago. Now that those questions are settled, I find myself in the top comment spot and entirely undeserving of the honor. It may have been necessary to at least consider the questions I raised (trust and identity of the author), but my comment addressed none of the substance of the article. I wrote it in order to get some discussion started until tptacek comes in and writes a thorough critique of the proposal's strengths and any possible weaknesses. So please, someone, write up a good topcomment analysis of the proposal so we can upvote you. :)

sp332 13y ago
I think "as slow as possible" is good for the initial key exchange, or for storing keys at rest. The point is to make offline key recovery (by guessing) more difficult. But once you have a good key, the ciphertext is already completely scrambled. Slowing down won't make that part any harder.
dtf 13y ago
Here's some discussion on mozilla's crypto list: http://www.mail-archive.com/dev-tech-crypto@lists.mozilla.org/msg11247.html http://www.mail-archive.com/dev-tech-crypto@lists.mozilla.or...
- sillysaurus2 13y ago
  Thanks! I also found a presentation from the Stanford Real World Cryptography event in Jan 2013 which cites Brian's work. It's an interesting read: https://crypto.stanford.edu/RealWorldCrypto/slides/gueron.pdf https://crypto.stanford.edu/RealWorldCrypto/slides/gueron.pd...
lvh 13y ago
No, slower doesn't mean more secure. 3DES is a lot slower than, say, AES, but nobody's suggesting 3DES is more secure than AES.
dochtman 13y ago
I'm pretty sure Brian currently works for Mozilla.
tptacek 13y ago
No, faster does not mean easier to break. Fast is a problem when brute force attacks are viable, as in with password hashes. There are no viable brute force attacks on 128 bit keys; that's why we use 128 bit keys.
- Achshar 13y ago
  As a noob in encryption, why is it not possible to guess the 128 bit private key by brute force?

ott2 13y ago

So, Mr Smith wants to add a bunch of elliptic curve options (using the NIST curves, weakest P-256 first), while removing the widely used TLS_RSA_WITH_AES_256_CBC_SHA256 due to "concerns" about "performance" and an unsubstantiated argument that ephemeral key exchange is somehow always better. Hmm.

bsullivan01 13y ago
Beware of random cryptographers bearing suggestions? #HUMINT
- ott2 13y ago
  Some of the OpenSSH and IETF mailing list archives about SSH also make interesting reading. Exactly why does RFC 4253 mandate Group 1 and Group 14 as the only required key exchange mechanisms? (They were defined by RFC 2412, written by someone who was "assigned to the DARPA Information Technology Office".) However, perhaps it would be better to fork a separate thread for such speculations.
- jwr 13y ago
  I really hope TLS crypto standards won't be set (or changes rejected) based on who proposed a particular change. Changes should stand on their own merits. I don't see why we should trust anyone, random or not. It's not about trusting people, it's about trusting algorithms. So it doesn't really matter who in particular proposes changes.
  - bsullivan01 13y ago
    In a ideal world, but if you get a lot of "contributions" some might slip through. Remember, no one can match NSA's budget, manpower and maybe brainpower.
hnolable 13y ago
TLS_RSA_WITH_AES_256_CBC_SHA256 is not forward secret (if you have the certificate private key you can passively decrypt all past/future sessions) so removing it is a great idea. I'm only responding to what you said and not making a judgement about the rest of the guy's suggestions.

chmike 13y ago

Does ephemeral key exchange protect against MITM ? I don't think so. Checking for that would be difficult I think for a standrad protocol.

hnolable 13y ago
No, the DHE/ECDHE (ephemeral key exchanges) don't protect against MITM, it protects against passive dragnet decryption. But the RSA/ECDSA/DSS part (certificate signing) does. All TLS ciphersuites include certificate signing to protect against MITM, but not all include ephemeral key exchange.

devx 13y ago

Is (NIST) P-256 secure enough? I might be wrong, but I think DJB is suggesting it's not, and that Curve25519 is preferable because it meets all the needed security requirements: http://cr.yp.to/talks/2013.05.31/slides-dan+tanja-20130531-4x3.pdf http://cr.yp.to/talks/2013.05.31/slides-dan+tanja-20130531-4... And why just 128-bit AES? AES-256 is not much slower, is it? I think I read it's only 30 percent slower than 128-bit encryption. Either way PFS should become the default for all encrypted communications. Companies need to start setting their own minimums years ahead of what NIST is recommending. NIST recommended the use of RSA 1024-bit until 2010, so that probably means companies should've moved away from RSA 1024-bit at least 3-5 years earlier. Yet here we are, with most companies today still using RSA 1024-bit 3 years after what even NIST recommended. Time to put security over profits first. Also, as Ptacek is saying, it's time to implement TACK for certificate pinning: https://twitter.com/tqbf/status/375742847485358081 https://twitter.com/tqbf/status/375742847485358081

hnolable 13y ago
All the supported curves in TLS are most likely influenced by the US government (NIST, ANSI, and SECG). So we don't really have an option to use curves with a non-US provenance. http://tools.ietf.org/html/rfc4492#appendix-A http://tools.ietf.org/html/rfc4492#appendix-A or list all openssl curves: $ openssl ecparam -list_curves
- tptacek 13y ago
  The NIST curves weren't influenced by the US government so much as they were defined by one NSA cryptographer, Jerry Solinas. On the other hand, the rationale behind their generation is pretty straightforward.
tptacek 13y ago
Bernstein's big problems with the NIST curves are that they turn out to be difficult to write fast constant-time point multiplication for them (bear in mind that they were chosen before this was a well-known concern), and that they're easy to screw up in implementations. Those are real concerns, but so to would be fresh implementations of Curve25519 in all new software. If one good thing comes of this most recent debacle, though, it'll be an industry reconsideration of the concepts that didn't manage to become NIST standards, like modern stream ciphers and faster curves.

herf 13y ago

This proposal is too aggressive at deprecating ciphers that are the only option for some browsers (e.g., IE8). It would be useful to add an icon to the address bar that indicates the security level of the crypto used (PFS or not, etc.)

sanxiyn 13y ago
Removing ciphers is aggressive, but what's wrong with deprecating ciphers?

devx 13y ago

The author seems to worry a lot about ARM performance. If this "proposal" is going to take 2-3 years to be implemented in browsers, then I wouldn't worry too much about it. The ARMv8 architecture is supposed to come with hardware optimized AES and SHA-1/SHA-2 encryption, and be "up to 10x" faster than on ARMv7. ARMv8 chips should start coming out next year. So if we're planning "for the future" here, then I'd start with ARMv8 in mind, rather than ARMv7 or even ARMv6 (which really should stop being supported already). If better and more optimal security means that older phones and lower-end ones will experience a setback in performance on some sites for the next few years (until they get upgraded), so be it.

tptacek 13y ago
How many years until ARMv8 represents the majority of phones? I think writing off ARMv7 is a bad idea.
ape4 13y ago
Just changing the order of the suites could be done quickly. Of course committees won't let that happen.
mook 13y ago
The author works for Mozilla (he's their security module peer), and is therefore focused on Firefox OS - which aims for low-end smartphones. Hence the reason for focusing on older ARM. Hope that helps.
- devx 13y ago
  I know that's one of the reasons he's saying it, but that's not really everyone else' concern, too, and as I said security should come first. Firefox OS is coming to ARMv6 phones right now, so at the very least they shouldn't start with that in mind when establishing the minimum of performance for encryption. There's the ARMv7 Cortex A7 chip for low-end now, and ARMv6 chips are terrible for performance anyway. They should not be used as a starting point for very low-end phones anymore.
  - 13y ago

sanxiyn 13y ago

This proposal prefers AES-GCM. Interestingly, Adam Langley (Chrome) is against AES-GCM. https://www.imperialviolet.org/2013/01/13/rwc03.html https://www.imperialviolet.org/2013/01/13/rwc03.html

Titanous 13y ago
agl recently committed AES-GCM to Go. http://code.google.com/p/go/source/detail?r=01d672e76b57028a7f437527e6e0dd8c2e753af0 http://code.google.com/p/go/source/detail?r=01d672e76b57028a... http://code.google.com/p/go/source/detail?r=52670d783ec3490dfaf161747d944e7376acbfc5 http://code.google.com/p/go/source/detail?r=52670d783ec3490d...
moonboots 13y ago
My understanding is that Adam Langley prefers AES-GCM to all the other mac-then-encrypt cipher suites in tls 1.2. He's working on AES-GCM support in NSS [1]. [1] https://news.ycombinator.com/item?id=5365601 https://news.ycombinator.com/item?id=5365601
tptacek 13y ago
I think Adam Langley doesn't like GCM because its normal software implementation requires secret-dependent table lookups for speed. It's thus thought to be easy to produce a naive GCM implementation that will suffer from side channel attacks. That concern is rapidly being mitigated by newer CPUs which can do the multiplications for GCM in hardware. From a theoretical perspective, the polynomial MACs (like GHASH) are very well understood. But, much more importantly, the TLS GCM construction is the only modern stream encryption standardized and widely available to TLS. The block constructions in TLS suffer from being created before Encrypt-then-MAC was proven secure; they do the operations the other way around, and thus require extremely fiddly code to quash side channels that have (unlike GCM) already been shown to admit plausible attacks. The author of this proposal probably isn't so much making a statement about GCM so much as he is suggesting that we need to deprecate the 90's-crypto parts of TLS, which is something that is hard to argue with.

taway2012 13y ago

This site uses the 'Globalsign Organization Validation CA - G2' certificate, which I've removed from my trust list. It's is a certificate that can be theoretically used to sign any domain (i.e., it's MITM-capable). I semi-regularly see it on Cloudflare sites because their customers haven't bothered to send their own keys to Cloudflare. I thought it was ironic than article about SSL security was doing something that is less secure than possible (from the end user's point-of-view). Just to be clear, yes, I understand that the operator of brainsmith.org isn't gaining any more security by sending CF the private key to their own cert vs. using CF's G2 cert. With the first approach the end user of brainsmith.org has better security since he can view the site without having to trust an MITM-capable certificate.

geraldcombs 13y ago
In Cloudflare's case "haven't bothered to send their own keys" implies "haven't seen the need to pay Cloudflare $200/month or $3000/month for the ability to upload a certificate+key". AFAICT only the Business and Enterprise plans allow custom certificates.
- harrytuttle 13y ago
  Why the fuck would anyone want to use them then? Even the shittiest shared host or VPS offer that for pittance.
  - rgbrenner 13y ago
    It's a CDN... comparing to a VPS is not even close to being fair. I've never seen a CDN that will let you load an ssl cert for less than a few hundred dollars. SNI isn't supported widely enough yet, so they have to dedicate an IP to you.

devx 13y ago

So far I haven't seen anyone question the SHA algorithms. Both SHA-1 and SHA-2 were designed by the NSA. Is everyone okay with that? SHA-3 wasn't designed by the NSA. http://en.wikipedia.org/wiki/Secure_Hash_Algorithm http://en.wikipedia.org/wiki/Secure_Hash_Algorithm

apendleton 13y ago
SHA is just used for verification in TLS, so the security considerations are different from those when it's used to, say, hash passwords. There's not much in the way of attacks that could take advantage of SHA being broken, and most that would would involve things like MITM-replacing packets in real-time with different ones with colliding hashes. It's probably true that for some classes of crypto problems, the NSA has incrementally-better cryptanalytical capabilities than the public does, but being able to find collisions in real-time, even for SHA1, seems like a very tall order.
tptacek 13y ago
Probably. The SHA-1 and SHA-2 hashes are straightforward extensions of hash designs from academia, and the constants in the hashes are derived from the first N prime numbers; they aren't mysterious in any way.
duskwuff 13y ago
SHA3 isn't available in browsers yet. Perhaps it should be, eventually, but until it is, SHA1/SHA2 are the best available options.

arthuredelstein 13y ago

Why not adopt the goal of deprecating all ciphersuites but one? Let's have a debate about the best ciphersuite and settle on a single one. That would decrease the attack surface and would allow the crypto community to focus on getting the implementation bug free. It would also give attackers a tighter focus, so we'd better pick the right ciphersuite! To Brian Smith's list of criteria, I would add implementation simplicity as a very important requirement.

tptacek 13y ago
For the past 5 years or so, we've managed to take good advantage of the fact that we had a diversity of ciphersuites, even though each of the pre-1.1 ciphersuites had problems. Trying to lock down a single known good ciphersuite would be drawing exactly the wrong lesson from recent history.
- arthuredelstein 13y ago
  If the latest Greenwald/Schneier revelations are true, then the past 5 years of TLS have underwhelming to say the least, so I don't see what advantage has been obtained from diversity. Going forward, how are site admins to know what ciphersuite to use? This needs to be made very clear. And how are web users to know what the green lock in their browser means, if it can mean anything at all? The current state of affairs is incomprehensible to all but a very few. There needs to be a big public debate about what ciphersuite is the best. And there should be very careful scrutiny of the implementation. Choosing ciphersuite(s) is a political as well as a technical problem -- the goals should be as clear and simple as possible.
  - tptacek 13y ago
    That's what this post was about.

SchizoDuckie 13y ago

And... Why would Google ánd Microsoft do this? They are the biggest assets on the NSA list remember?