

Null-prefix certificate for paypal - bensummers
http://seclists.org/fulldisclosure/2009/Oct/87

======
hapless
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.

~~~
ComputerGuru
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.

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

------
markpercival
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...](http://daniel.haxx.se/blog/2009/08/12/curl-fooled-by-null-prefix/)

------
wizard_2
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.

~~~
holdenk
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.

~~~
thwarted
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.

~~~
tptacek
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.

~~~
thwarted
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).

------
agl
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.

~~~
tptacek
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.

------
alexkon
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.

