Re: New Research Suggests That Governments May Fake SSL Certificates
On Mar 25, 2010, at 8:05 AM, Dave Kleiman wrote: March 24th, 2010 New Research Suggests That Governments May Fake SSL Certificates Technical Analysis by Seth Schoen http://www.eff.org/deeplinks/2010/03/researchers-reveal-likelihood-governments-fake-ssl Today two computer security researchers, Christopher Soghoian and Sid Stamm, released a draft of a forthcoming research paper in which theypresent evidence that certificate authorities (CAs) may be cooperating with government agencies to help them spy undetected on secure encrypted communications While the paper provides a nice analysis and description of the situation, what surprises me most about it is ... that anyone was surprised. Hardware to support man-in-the-middle splicing of HTTPS sessions has been available in the marketplace for several years. They are sold by companies like Bluecoat who build appliances to monitor incoming and outgoing traffic at the interconnection points between corporate networks and the greater Internet. They're sold as means to monitor and control what sites can be accessed (they block things like gambling sites, pornography - whatever the corporation doesn't want its employees browsing from work) and also inspect the data for auditing/information leakage control purposes. In the corporate environment, where desktops/laptops are managed, the way such a device is given the ability to do MitM attacks is straightforward: The corporation simply pushes a new root CA - for a CA that actually lives inside the intercept device - into the browser's pool. The device can then generate and sign any certs it needs to to wedge into any HTTPS session invisibly. Even when the corporation allows personal machines onto the network, it will often require users to accept a corporate CA for access to internal sites. Of course, since browsers only have one pool of CA's, once you've accepted that CA, you've accepted invisible MitM attacks by the monitoring device. Since the techniques and hardware for doing this has been around for a while, it should come as no surprise that someone would notice that governments are another good market - in fact, one that tends to be fairly price-insensitive. It's distressing how much government intrusion technology is basically relabeled corporate security/ compliance technology. Governments may or may not be in a position to force CA's onto a machine, so it would be natural for them to compel existing CA's, as the paper rightly points out. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Against Rekeying
Also manually forwarded on behalf of Peter Gutmann. As before, if you reply, don't credit me with the text, it is his. From pgut001 Fri Mar 26 14:44:54 2010 To: b...@links.org, nicolas.willi...@sun.com Subject: Re: Against Rekeying Cc: cryptography@metzdowd.com, pe...@piermont.com, si...@josefsson.org In-Reply-To: 20100325160755.gf21...@sun.com Nicolas Williams nicolas.willi...@sun.com writes: I suspect that what happened, ultimately, is that TLS re-negotiation was an afterthought, barely mentioned in the TLS 1.2 RFC and barely used, therefore many experts were simply not conscious enough of its existence to care. I think that was a significant problem with noticing this, that many implementors may have looked at it, decided it was a nightmare to implement, served no really obvious purpose once 40-bit keys had gone the way of the dodo, and was a significant source of future problems (see my previous message), and so never bothered with it. As a result it never got much attention, as do significant chunks of other security protocols. I think the real skill in security protocol implementation isn't knowing what to implement, but knowing what not to implement (I've had an attack-surface- reduced SSH draft in preparation for awhile now, I really must get back to the some time). One nice thing about being the author of a crypto toolkit is that you can experiment with this, either skipping features or turning existing features off in new releases, to see if anyone notices. If no-one does, you leave them turned off. You can turn off an awful lot of security-protocol features before people start to notice, leading me to believe that a scary portion of many protocols actually consist of attack surface and not features. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
high speed password cracking on GPUs
This is from ten days ago but I just ran across it. Nothing very deep -- just higher speed brute force attacks via GPUs. http://www.net-security.org/secworld.php?id=9021 -- Perry E. Metzgerpe...@piermont.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Against Rekeying
On Fri, Mar 26, 2010 at 10:22:06AM -0400, Peter Gutmann wrote: I missed that in his blog post as well. An equally big one is the SSHv2 rekeying fiasco, where for a long time an attempt to rekey across two different implementations typically meant drop the connection, and it still does for the dozens(?) of SSH implementations outside the mainstream of OpenSSH, Putty, ssh.com and a few others, because the procedure is so complex and ambiguous that only a few implementations get it right (at one point the ssh.com and OpenSSH implementations would detect each other and turn off rekeying because of this, for example). Unfortunately in SSH you're not even allowed to ignore rekey requests like you can in TLS, so you're damned if you do and damned if you don't [0]. I made much the same point, but just so we're clear, SSHv2 re-keying has been interoperating widely since 2005. (I was at Connectathon, and while the details of Cthon testing are proprietary, I can generalize and tell you that interop in this area was very good.) Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Against Rekeying
Nicolas Williams nicolas.willi...@sun.com writes: I made much the same point, but just so we're clear, SSHv2 re-keying has been interoperating widely since 2005. (I was at Connectathon, and while the details of Cthon testing are proprietary, I can generalize and tell you that interop in this area was very good.) Whose SSH rekeying though? I follow the support forums for a range of non- mainstream (i.e. not the usual suspects of OpenSSH, ssh.com, or Putty) SSH implementations and why does my connection die after an hour with [decryption error/invalid packet/unrecognised message type/whatever] (all signs of rekeying issues) is still pretty much an FAQ across them at the current time. (There's also the mass of ancient copies of the usual suspects, principally the ssh.com implementation dating back up to ten years, baked into networking devices and whatnot that will never be updated, or at least if significant security holes present in the older versions haven't convinced the vendors using them to update them then I don't think the fact that they drop the connection after an hour will). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Against Rekeying
On Sat, Mar 27, 2010 at 12:31:45PM +1300, Peter Gutmann (alt) wrote: Nicolas Williams nicolas.willi...@sun.com writes: I made much the same point, but just so we're clear, SSHv2 re-keying has been interoperating widely since 2005. (I was at Connectathon, and while the details of Cthon testing are proprietary, I can generalize and tell you that interop in this area was very good.) Whose SSH rekeying though? I follow the support forums for a range of non- mainstream (i.e. not the usual suspects of OpenSSH, ssh.com, or Putty) SSH implementations and why does my connection die after an hour with [decryption error/invalid packet/unrecognised message type/whatever] (all signs of rekeying issues) is still pretty much an FAQ across them at the current time. Several key ones, including SunSSH. I'd have to go ask permission in order to disclose, since Connectathon results are private, IIRC. Also, it's been five years, so some of the information has fallen off my cache. Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
