Re: [cryptography] SSL *was* broken by design
On 1/10/11 22:11 PM, William Allen Simpson wrote: I started reading this thread, and then left it alone, and am catching up. It's hard to know where to start, so changing the subject a little. :) On 9/20/11 12:51 PM, ianG wrote: On 20/09/11 01:53 AM, Andy Steingruebl wrote: SSH doesn't solve phishing either. Is it a total failure also? I don't think so. SSL is used for a lot more than HTTPS. Any proposal to fix it *must* take that into account. - Andy Irrelevant, because SSH at the architectural level and SSH at the protocol level are aligned and in balance. There is no discord because SSH was never really taken out of its intended design framework. That's arguably because the designer wasn't facing the political forces of the times, which the designers of SSL drowned in. For whatever reasons, we can skip that and look at the results: SSH was pretty much always used in accordance with its original design-assumptions, whereas SSL was pretty much never used in accordance with its original design-assumptions. Actually, SSH faced a lot of the same political pressures as SSL. SSH didn't cave! Instead, they carefully did all the work by non-US persons outside the US -- even though that meant some foreign developers of OpenSSH had to drive across the US border into Canada. Meanwhile, back when Netscape was located near the Stanford campus (an easy walk from the computing center), Paul Mockapetris got me to visit. I sat down with Taher Elgamal and others, explaining what we were doing with Photuris. To the best of my memory, we thought it would be better to: 1) Authenticate the list of supported methods/transforms. We did that in Photuris to avoid MITM attackers choosing the lowest common denominator. And not only the parameters, but the length fields of the parameters, too. Karn had insisted on cheap Photuris renegotiation from the start, and that requires protection against substitution. 2) Hide the certificates/users. We called that party privacy protection. We used the initial D-H exchange to create a temporary stream key, and masked the data with the stream (simply an MD5 hash). 3) Require Perfect Forward Secrecy. We'd not managed to get IPsec to do that. It was a big argument at the time. Even today, not all TLS suites provide PFS. 4) Authenticate outside of encryption, so we could quickly and cheaply check before doing a more computationally intensive decryption. We managed to force that into IPsec, and hoped to get Netscape to do the same for SSL (now TLS). IIRC, that's since been proven to be more secure, but we didn't know it at the time. We were mostly interested in practicality. So how was it that Netscape SSL had exactly the same faults as IPsec, ISAKMP, Oakley, IKE? Political pressure! Somebody really REALLY wanted to be able track users and intercept/substitute Do I have proof? No, it's merely circumstantial. Also, my multi-year FBI personal investigation over PPP CHAP was coincidental, too. Proof is hard. But we might see it in the future. Not now, but in a few years. Whoever that somebody is, they did too good a job. And now they get to pay the cost. It isn't as if they can cherry-pick the consequences, because the net was cast too wide: the whole infrastructure is institutionally weak, and if we triangulate the spots that should have been strong but are weak, they all seem to point one location. So now we have the cyber-war scenario. One side spikes a nuclear plant, the other side punches a hole in trust infra. Tit for tat, bring it on! I suspect if it does take off -- tit for tat in cyber warfare -- there will be some smarter people who will realise they stupidly fired the first shot. And now they can't stop the 100 shots... Not a few people in there will be examining the causes, and realise that they set themselves up for a fall. Ho to reverse this? I suspect the only way is for somebody to come clean and tell people what they did. Otherwise, all the believers out there will ... carry on, keeping our infrastructure insecure. Netscape caved, for their commercial interests. There was also the CA business model. User's own interests took last place. https://financialcryptography.com/mt/archives/000609.html I think it was inevitable. So, arguing about ease of use is a waste of time, as long as the easy to use protocol was designed to be broken. It really is time to start over. Well, yes and no, WYTM? The thing is, somebody doesn't really matter to us. Arguably, ComodoHacker doesn't really matter as much as all the press makes out. And he's fixable. What matters is phishing and breaches. And the former is impacted by SSL. If we could get more SSL it would improve things. The reason we can't is because the UI is so horrible that people prefer to avoid it. iang ___ cryptography mailing list cryptography@randombit.net
Re: [cryptography] PFS questions (was SSL *was* broken by design)
On 10/02/2011 03:38 AM, Peter Gutmann wrote: Sandy Harrissandyinch...@gmail.com writes: What on Earth were the arguments against it? I'd have thought PFS was a complete no-brainer. Two things, it's computationally very expensive, and most people have no idea what PFS is. There's been one significant improvement since the 90s: Even the typical MS Windows IT guy today will have at least played with Wireshark and may have even set up certificates for something. I find an easy way to explain PFS is someone who gets a Wireshark capture won't be able to decrypt it EVEN IF they somehow get the private key to the certificate. There's an increasing awareness of data loss issues right now. I wonder if DHE ciphersuites will become recognized as a best practice? At the risk of feeding the conspiracy angle, I note that there is only one stream cipher for SSL/TLS (RC4). All the others in common use are CBC modes, with that same predictable IV weakness as IPsec (i.e. BEAST). There are no DHE cipher suites defined for RC4. So if you want PFS, you have to accept predictable IVs. If you want resistance to BEAST, you have to give up PFS. Personally, I don't interpret this as anything more than the IETF process and some vendor biases back in the 90s. But it shows that designing for this concept of 'agility' is important, in particular for reasons you don't know at the time. - Marsh ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] PFS questions (was SSL *was* broken by design)
At the risk of feeding the conspiracy angle, I note that there is only one stream cipher for SSL/TLS (RC4). All the others in common use are CBC modes, with that same predictable IV weakness as IPsec (i.e. BEAST). There are no DHE cipher suites defined for RC4. So if you want PFS, you have to accept predictable IVs. If you want resistance to BEAST, you have to give up PFS. Personally, I don't interpret this as anything more than the IETF process and some vendor biases back in the 90s. But it shows that designing for this concept of 'agility' is important, in particular for reasons you don't know at the time. Oh, please. I'm sorry, Marsh, but this is just silly, suggesting that there are vendor biases against stream ciphers and agility. After all, if we look through the library of publicly-available, well-trusted stream ciphers there is, u, well, there's always, ur, well. Oh, I know! Counter mode! Yeah, that's it. On the agility front, most people seem to be against it. Weren't we in a huge no-choices-are-the-only-security mood a few weeks ago? Stream ciphers are hard. They're hard to build correctly, hard to use correctly, and have been the red-headed-stepchild of cipher design for really good reasons. Remember WEP? The most damning problem in it to my mind was the order-2^24 attack caused by using a stream cipher (and a 24-bit pseudo-IV). Any stream cipher that gets created has to answer this really good question: Why are you better than AES-CTR? The next question would be why it's better than Serpent-CTR, or Twofish-CTR, or heck why not use Threefish-CTR? Of course right now, the best thing to do stream-cipher-wise is to use GCM mode, with is in TLS 1.2, but hardly deployed at all, no doubt because of bias against wanting to use something that's authenticated, right? After all, wouldn't the surveillance state want us all to be vulnerable to CBC attacks like BEAST, and people who are preventing that must be in cahoots with the NSA, right? But of course, GCM mode is part of Suite B, and that's the NSA's push for using an authenticated data stream. So that means that the people who are pushing for stream ciphers are also in cahoots with the surveillance state by pushing for authenticated modes, too! In case anyone missed it, the sarcasm bits should have been showing up in the UTF-8 over the last couple of paragraphs at some point or other. Come on. This discussion has descended past whacko, which is where it went once the broken by design discussion started. Yeah, security is hard, but it's software. We know how to do that, once we understand the problems. The wrong questions have been asked for so long in this long discussion that I think the only reasonable people are the ones ignoring the whole thing. Jon ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] PFS questions (was SSL *was* broken by design)
Come on. This discussion has descended past whacko, which is where it went once the broken by design discussion started. Quite. I had to point someone at some of these threads today; when it came to this part, I alluded to black helicopters. --Steve Bellovin, https://www.cs.columbia.edu/~smb ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] PFS questions (was SSL *was* broken by design)
Come on. This discussion has descended past whacko, which is where it went once the broken by design discussion started. On 2011-10-04 9:18 AM, Steven Bellovin wrote: Quite. I had to point someone at some of these threads today; when it came to this part, I alluded to black helicopters. SSH faced political and administrative difficulties that protocols easier for the authorities to intercept did not face. That is suggestive. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
