Re: A mighty fortress is our PKI
On Tue, 27 Jul 2010 05:40:07 +0300 (EEST) Sampo Syreeni wrote: > On 2010-07-26, Perry E. Metzger wrote: > > > I think that you may be right -- the entire TLS PKI model may be > > so horribly broken that, once you no longer have any real > > security to speak of, simply sharing a cert among hundreds of > > trust domains hardly harms anything further. > > I agree. But do we then have any quantitative research on how bad > this sort of sharing really is, in excess of the basic > cryptographic vulnerability? I am not sure what quantitative measurement of vulnerability would even mean. What units would said quantity be measured in? Perry -- Perry E. Metzgerpe...@piermont.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: A mighty fortress is our PKI
On 2010-07-26, Perry E. Metzger wrote: I think that you may be right -- the entire TLS PKI model may be so horribly broken that, once you no longer have any real security to speak of, simply sharing a cert among hundreds of trust domains hardly harms anything further. I agree. But do we then have any quantitative research on how bad this sort of sharing really is, in excess of the basic cryptographic vulnerability? Does the social network research of recent years yield any numbers, for instance? -- Sampo Syreeni, aka decoy - de...@iki.fi, http://decoy.iki.fi/front +358-50-5756111, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: MITM attack against WPA2-Enterprise?
On Jul 26, 2010, at 10:30 19PM, Perry E. Metzger wrote: > On Mon, 26 Jul 2010 21:42:53 -0400 Steven Bellovin > wrote: >>> >>> I don't know, if it is truly only a ten line change to a common >>> WPA2 driver to read, intercept and alter practically any traffic >>> on the network even in enterprise mode, that would seem like a >>> serious issue to me. Setting up the enterprise mode stuff to work >>> is a lot of time and effort. If it provides essentially no >>> security over WPA2 in shared key mode, one wonders what the point >>> of doing that work is. This doesn't seem like a mere engineering >>> compromise. >> >> If I understand the problem correctly, it doesn't strike me as >> particularly serious. Fundamentally, it's a way for people in the >> same enterprise and on the same LAN to see each other's traffic. A >> simple ARP-spoofing attack will do the same thing; no crypto >> needed. Yes, that's a more active attack, and in theory is >> somewhat more noticeable. In practice, I suspect the actual risk >> is about the same. > > I think the issue is that people have been given the impression that > WPA2 provides enough security that people can feel reasonably secure > that others will not be reading their traffic over the air the way > that they might in a pure shared key scenario, and that this justified > the extra complexity of deployment. While what you say is perfectly > true, it does lead one to ask if WPA2 enterprise has not been > significantly oversold. > Probably... To me, access link crypto is about access control. WEP -- apart from the failings in RC4 and how it was used -- got that badly wrong, because it was impossible to change keys in any rational way. WPA2 was supposed to fix that; I'd have been happy if that were all it did. As others have noted, end-to-end crypto is the proper approach. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: MITM attack against WPA2-Enterprise?
On Mon, 26 Jul 2010 21:42:53 -0400 Steven Bellovin wrote: > > > > I don't know, if it is truly only a ten line change to a common > > WPA2 driver to read, intercept and alter practically any traffic > > on the network even in enterprise mode, that would seem like a > > serious issue to me. Setting up the enterprise mode stuff to work > > is a lot of time and effort. If it provides essentially no > > security over WPA2 in shared key mode, one wonders what the point > > of doing that work is. This doesn't seem like a mere engineering > > compromise. > > If I understand the problem correctly, it doesn't strike me as > particularly serious. Fundamentally, it's a way for people in the > same enterprise and on the same LAN to see each other's traffic. A > simple ARP-spoofing attack will do the same thing; no crypto > needed. Yes, that's a more active attack, and in theory is > somewhat more noticeable. In practice, I suspect the actual risk > is about the same. I think the issue is that people have been given the impression that WPA2 provides enough security that people can feel reasonably secure that others will not be reading their traffic over the air the way that they might in a pure shared key scenario, and that this justified the extra complexity of deployment. While what you say is perfectly true, it does lead one to ask if WPA2 enterprise has not been significantly oversold. -- Perry E. Metzgerpe...@piermont.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: A mighty fortress is our PKI
On Tue, 27 Jul 2010 01:14:21 + (UTC) Jay Sakata wrote: > I was very interested to read Peter's analysis of shared SAN > certificates. While we offer dedicated certificates, the shared > certificates we offer enable us to conserve IPv4 space while > helping customers lower costs. We've tested and analyzed these > shared certificates extensively and in a wide variety of scenarios, > and we believe they are just as secure as dedicated certificates. I think that you may be right -- the entire TLS PKI model may be so horribly broken that, once you no longer have any real security to speak of, simply sharing a cert among hundreds of trust domains hardly harms anything further. All major browsers already trust CAs that have virtually no security to speak of, and for the most part a certificate only indicates that the CA had reason to believe that someone was in possession of sufficient funds to pay it for it. However, I suspect this is not what you meant here. > And helping our customers manage costs is good corporate > citizenship. But we will absolutely not compromise security in the > pursuit of either of these goals; our customers' security is > paramount. > > Of course, security is a journey and not a destination, and we are > constantly striving to further improve ours. [...] > A more secure Internet is in everyone's best interest, and I always > stand ready to make sure we are doing our part. [rest elided] I find it gratifying that my mailing list has gained sufficient public importance that not one but two technology executives have made the effort within 48 hours to join it so that they can state their opinion on the issue that Peter Gutmann raised. I find it less gratifying, however, when those messages do not focus on clear discussion of technical merits. This is, after all, a technical mailing list, intended for technologists to speak clearly, openly and precisely with each other. In reading your note, I was reminded of George Orwell's excellent essay "Politics and the English Language": http://www.mtholyoke.edu/acad/intrel/orwell46.htm If you have not read it, I strongly urge that you do so. Perry -- Perry E. Metzgerpe...@piermont.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: MITM attack against WPA2-Enterprise?
> > I don't know, if it is truly only a ten line change to a common WPA2 > driver to read, intercept and alter practically any traffic on the > network even in enterprise mode, that would seem like a serious issue > to me. Setting up the enterprise mode stuff to work is a lot of time > and effort. If it provides essentially no security over WPA2 in shared > key mode, one wonders what the point of doing that work is. This > doesn't seem like a mere engineering compromise. If I understand the problem correctly, it doesn't strike me as particularly serious. Fundamentally, it's a way for people in the same enterprise and on the same LAN to see each other's traffic. A simple ARP-spoofing attack will do the same thing; no crypto needed. Yes, that's a more active attack, and in theory is somewhat more noticeable. In practice, I suspect the actual risk is about the same. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: A mighty fortress is our PKI
I was very interested to read Peter's analysis of shared SAN certificates. While we offer dedicated certificates, the shared certificates we offer enable us to conserve IPv4 space while helping customers lower costs. We've tested and analyzed these shared certificates extensively and in a wide variety of scenarios, and we believe they are just as secure as dedicated certificates. It's also important to note that we operate edge proxies that merely sit between our customers' origin servers (which have an SSL certificate of their choosing) and the end users. We do not run programs or scripts on our edge servers on behalf of customers; when end users are posting content back to the origin, we are merely a gateway. Conserving IPv4 space is very important to us - it is responsible 'net citizenship. And helping our customers manage costs is good corporate citizenship. But we will absolutely not compromise security in the pursuit of either of these goals; our customers' security is paramount. Of course, security is a journey and not a destination, and we are constantly striving to further improve ours. A significant part of that process means learning from communities like this one. Therefore, if anyone is aware of any specific vulnerability - whether with our network or with these shared certificates - I hope you will notify us immediately at security+at+edgecast.com so we can take whatever actions necessary to protect our customers, their customers, and the network as a whole. You are also welcome to contact me directly at +1 310 396 7400. A more secure Internet is in everyone's best interest, and I always stand ready to make sure we are doing our part. Jay Sakata CTO EdgeCast Networks - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: MITM attack against WPA2-Enterprise?
* Donald Eastlake: > It's always possible to make protocols more secure at higher cost. On the other hand, group key vulnerabilities are nothing new. It's just that many protocol designers seem to not understand them. Back when Cisco proposed XAUTH for IPsec, there was a heated discussion about password strength and other irrelevancies, but as far as I could later reconstruct the discussion, no one objected to the group key concept as such. It was only much later, when people used XAUTH in large deployments for providing general Internet access over insecure media, that the group key was recognized as a vulnerability. It's amazing that people still fail for this group key thing. There is quite a simple rule: If you choose the secret bits without constraints (except length and formatting), and proceed to share those bits, there can be no protection from those with whom you share, no matter what cryptographic algorithms you use. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: MITM attack against WPA2-Enterprise?
Perry, On Sun, Jul 25, 2010 at 9:23 PM, Perry E. Metzger wrote: > On Sun, 25 Jul 2010 18:48:56 -0400 Donald Eastlake > wrote: > > It's always possible to make protocols more secure at higher cost. > > Should 802.11i have required one-time pads to be couriered to all > > mobile stations involved? Probably not, since it would kind of > > negate some of the benefits of Wi-Fi. For group keys, should it > > have added another layer of security where, say, a public was > > transmitted by the AP to each station using pairwise security and > > the AP signed and all stations verified every multicast/broadcast > > frame? Possible, but public key cryptography is a pretty big burden > > if you are, for example, streaming video to multiple stations using > > multicast. Seems like it would need significant hardware support. > > I think the fact that the protocol appears to allow people to > impersonate the base station, order clients to use new keys, and then > man in the middle all subsequent communications with little effort > makes the per-endpoint keying largely moot. This does not seem like a > minor defect. > As far as I know, a new group key is delivered serially by the AP to each station using the pairwise security between them. Sure, you can impersonate the MAC address of the AP and, since it's all in the Ether, you can eavesdrop on the exchange between a station and the AP to generate a new pairwise key or to deliver a new group key to the station and inject messages into those conversations. But if you can break the security by such eavesdropping or injection, that would be a big deal, and have nothing to do with the fact that a shared key is used for group security. Donald
