Null-prefix certificate for paypal | Hacker News Reader

Null-prefix certificate for paypal

seclists.org

63 pointsbensummers12 comments

To be clear: this is a two-part hack.

Part 1: The null-prefix cert bug is still in the Windows SSL stack. Any browser that uses the Windows SSL libs will take this cert, issued to CN=www.paypal.com\0someoneelse.es, and use it for CN=www.paypal.com.

Part 2: The certificate has already been revoked by its issuer, but a man-in-the-middle attack will prevent the client from discovering that. Moxie Marlinspike's sslsniff + arp spoofing can be run anywhere within the layer 2 broadcast domain in order to deceive the client when it tries to verify the cert.

If I'm not mistaken, the same trick you mention in "Part 2" can be used to deceive the client for any false certificate, not just a null-prefix certificate.

But you need to have a cert signed by an authority the browser trusts, which is why you need the null-prefix attack.

For anyone that wants to know more about what a null-prefix cert is:

http://daniel.haxx.se/blog/2009/08/12/curl-fooled-by-null-pr...

I'm going to have to write an article about "no public wifi" and setup a proper vpn for everyone I know. I just finished reading about hijacking google analytics's js and setting the cache expiration for a year in the future. This means someone can hijack every page that uses tracking in your browser until you clear your cache. The thing that kills me is that there's just no need for it, lets move vpn's into common practice and lets update our ssl libraries (microsoft!)

That caching trick also means, if you get your paypal "jacked" once, it can persist when you're back on a secure connection.

VPNs however add considerable latency as well as cost and complexity. Its not like there is no down side to using VPNs. If your using SSH and a web browser which isn't susceptible to the current SSL exploits, I don't see why I would want to use a VPN over Wi-Fi.

DNS lookups are not currently signed nor authenticated, neither of which go through ssh or the browser's SSL stack, which is a major attack vector for MITM.

SSL was designed not to care that DNS is insecure.

Heading off one likely response to this comment: it is silly to look at a bug in probably the best-tested piece of security code on the planet (Microsoft's CryptoAPI/schannel code) and arrive at the conclusion that DNSSEC, a protocol nobody has ever deployed successful at scale, isn't hiding many worse bugs.

The same obviously goes for SSH, which uses key continuity so as not to care that DNS is insecure.

While all that's true, it's not the design of SSL that is at issue, but rather bugs in the SSL stack, such as this null-prefix certificates issue. While I don't know the state of Microsoft's stack for this bug, ubuntu just released a patch for wget yesterday for it (USN-842-1, CVE-2009-3490). No one is really talking about DNSSEC, but if you were using a wifi connection (the original use case in this thread of using a VPN over wifi) and thought you were secure because you were using SSL, MITM via DNS is still a possible attack vector, as hapless points out elsewhere in these comments. Obviously a VPN over wifi wouldn't secure you for accessing paypal.com via SSL (which is a public resource), but other, private resources secured with only SSL but resolved via public DNS are at risk (wifi or not).

Also, a more correct ASN.1 parser (at the CA, or in the client) could have saved them. The CN field is a PrintableString type which has a limited character set specified. NUL is not an allowed character in a PrintableString.

I've tested a lot of ASN.1 implementations and I've never seen a BER or DER parser that even managed to check lengths or parse pathological OID arcs properly, let alone handling restricted character sets in strings.

You might as well say they'd have been better served with a unicorn.

If you're using Firefox, set security.OCSP.require to true. There is also UI for it under Preferences -> Advanced -> Encryption -> Validation -> When an OCSP connection fails, treat the certificate as invalid.

I don't know whether it protects against all OCSP attacks but it's obviously better than the default option.

Reply on news.ycombinator.com