1

Some years ago, there was a bug with host name checking in ssl so that connection towww.paypal.com%00.thoughtcrime.orgwould look aswww.paypal.comat the certificate level.

The issue seems to be over for web browsers. But some tools and popular libraries still useconst char *without associated size internally for representing domain names.

Aswww.paypal.com%00.thoughtcrime.orgseems to no longer be available, are there still some public server already set up servers for testing ?

user2284570
  • 1,402
  • 1
  • 14
  • 33
  • I understand that but it's not overly clear what's happening, or where the null byte is placed. Also, this is a fairly old known vulnerability that involves not only browser's incorrectly validating, but creating bogus certificates that are also incorrectly validated by the certificate authorities. Clients are affected by this vulnerability via phishing, not the servers. – RoraΖ Oct 13 '15 at 13:54
  • @RoraΖ : Yes, such servers are difficult to set up *(that’s why I would like to avoid doing it myself)*. If you use an old version of Internet Explorer, the nul byte will be correctly rendered using the specified place in the font. – user2284570 Oct 13 '15 at 13:55
  • It's a good question, but I don't know how relevant it will be with modern browsers. – RoraΖ Oct 13 '15 at 13:57
  • @RoraΖ : It has nothing to do with web browsers, as stated in my question : “The issue seems to be over for web browsers, however, some tools and popular libraries still use`const char *`without associated size internally for representing domain names” So they can pass a stripped domain name to openssl or gnutls. – user2284570 Oct 13 '15 at 14:00
  • user2284570 - I'm not sure what the massive series of edits are supposed to achieve. Please use standard fonts - do not assume unicode is ok. The community has let you know in no uncertain terms. If we/search engines cannot easily read it, it's not good. In fact, please don't use unicode chars in your comments either - it's entirely unnecessary. – Rory Alsop Oct 13 '15 at 18:33

1 Answers1

4

There is no such thing as an "SSL domain".

There is no NUL-handling bug in SSL, which is a specification. Only bugs in implementations. Lots of bugs. In these bugs, there never was a NUL character in the hostname at all, only in the certificate.

Widely used implementations such as OpenSSL now protect against this, but testing is surely still worthwhile.

However, testing doesn't require connecting to a website. You can run tests by asking your implementation to validate a locally stored certificate. Instructions and example certificates have been available since 2009

Ben Voigt
  • 760
  • 1
  • 10
  • 17
  • I never stated it was the standard as I thought my question was implying implementations. The security library doesn’t matter if you pass an already stripped domain for checking *(passing www.paypal.com for the current public key to openssl)* they are many CVE where the security library was correct but used incorrectly. Considering the local test, this won’t work for all of them as some tools have non modifiable trust store. – user2284570 Oct 13 '15 at 17:28
  • @user2284570: I don't think you understand the actual mechanism of the failure. The NUL character isn't in the hostname you lookup with DNS (your question also confuses this), it is embedded in the certificate. The certificate decoding logic is supposed to outright reject it if there's an ASN.1-encoded NUL, because that character is illegal in a hostname. If your tool has a fixed certificate store and doesn't accept any others, then there is no risk, just make sure none of the certificates fixed in the pinned list are invalid in this way. – Ben Voigt Oct 13 '15 at 17:30
  • Ok, looks like I was confused. CVE should really be more descriptive about errors. – user2284570 Oct 13 '15 at 17:43
  • : By the way, is there an e‑mail service that would accept an ascii nul in the address name ? – user2284570 Oct 14 '15 at 14:49