As you may be aware, Moxie Marlinspike and Dan Kaminsky(working separately), at the Black Hat security conference the other week each presented similar null characters findings in separate presentations regarding SSL.
An attacker may obtain a certificate with the Null character in the domain name, say www.foo.net\0.carbonwind.net, which would make most of browsers(and not only) to see the certificate as been issued to www.foo.net.
As writing, Firefox 3.5 was confirmed not being susceptible to this.
You can find coverage about this on various web sites on the Internet:
http://www.thoughtcrime.org/software/sslsniff/, Moxie Marlinspike’s web site
http://www.wired.com/threatlevel/2009/07/kaminsky/, Wired article
https://blogs.verisign.com/ssl-blog/2009/07/busy_day_at_black_hat.php, Tim Callan's SSL Blog
BLACK HAT USA 2009 Presentations, Moxie Marlinspike’s More Tricks For Defeating SSL slides
http://www.securityfocus.com/bid/35888
Use your favorite search engine to find more info.
Now, as you may also know, outbound SSL inspection may have been incorporated into several products(bellow, for the moment, we will look at the HTTPS inspection), so that encrypted connections to be scanned for viruses, malware, protocol compliance, etc(but we’re not interested in what malware or so they are able to find right now within the encrypted connections).
This can be done at the edge(say on the firewall or web security gateway), or on the host itself with a client-side solution.
So I started to wonder, does this detect/block the NULL character certificates, as now the “security device/software” also should validate the server’s certificate since it’s actively MITM the SSL connection ?
One of the basic validation that this “security device/software”” must do, is to verify if the CA that issued the server’s certificate is trusted, the client will see the certificate as being issued by the “security device/software’s” CA, as the “security device/software” creates and signs on-the-fly the servers’ certificates with its own root certificate, root certificate which the client must trust in order to avoid any server certificate errors.
If the inspection is done on the edge, the pressure is on the “security device’s” trusted CAs certificate store, it may be meaningless if the client trusted or not the real CA. This may offer the advantage of “centralizing” the trusted CA certificate store. But if the “security device” does not do its job, then my oh my.
It will be up to the Crypto API used by “security device” and it’s implementation of the outbound SSL inspection.
So let’s do some quick tests.
First, let’s prepare a crafted certificate request for www.foo.net to be signed by an internal test CA. For example, bellow I’ve opened with Notepad++ a crafted certificate request(which is bellow in DER format)-no, I haven’t used Notepad++ to do anything to that request, just in case one asks-:
Sent this request to my internal test CA to sign it, and got the needed certificate, which Windows “buys”:
Put this certificate on a local Windows 2003 SP2 IIS test web server, and let’s try to access this secure web server and see what happens.
First let’s start with a client-side solution for SSL inspection.
As you may know Kaspersky Internet Security offers for a while the Scan encrypted connections option. It can scan HTTPS for malware and viruses.
http://support.kaspersky.com/kis2010/tech?qid=208280430
Here is a quick view of it, on KIS 2010 on Windows Vista SP2 x64:
KIS 2010 will use its own generated root CA certificate, which will be installed in the Certificates – Current User\Trusted Root Certification Authorities\Certificates store if you click the Install Certificate… button.
This will be fine for browsers which do not use their own trusted CAs store(please note that for example Firefox, Opera use their own trusted CAs store).
Already having the feeling that this won’t add anything against NULL character certificates.
But let’s proceed, and enable the needed setting on KIS 2010.
If the CA that issued the server’s certificate is not trusted(Windows trusted CAs store), KIS 2010 will issue some warnings, we can’t say for sure what seems to be the problem(playing with various browsers):
Next, the question that interests us, does KIS 2010 verify the server’s name from the certificate ?
And it appears it does not do that(unless I’ve missed a setting on it). For example I can go to a secure web site over HTTPS by IP address, and KIS 2010 just creates on the fly the needed server cert without any prompts, the server’s name from the certificate check being left to the browser(I could have used a bogus name instead of the IP address with the same result):
Let’s access the test web server with IE 8 on the Windows Vista SP2 machine with KIS 2010 on it(the local test CA was added to Windows trusted CAs store), and as expected nothing, all looks just fine:
Let’s try on the same machine with Firefox 3.5 this time. A little problem, I cannot add as a trusted CA the KIS 2010’s root certificate. It works fine on older versions of Firefox, but not on 3.5 throwing the error bellow(actually this root certificate is a “primitive” form of a root certificate, does not have any Key Usage Restrictions or any Basic Constraints). Anyway, let’s don’t waist any time with this and focus on what we want to see.
Firefox will complain about the Kaspersky’s CA not being trusted(we expected this), and unlike IE 8, it senses that something is wrong with the name from the server’s certificate:
So, we haven’t had any success with KIS 2010 on the Vista SP2 x64 machine.
Let’s move now to an edge HTTPS inspection solution, say Astaro Security Gateway 7 and its HTTPS inspection for outbound client's HTTPS connections(I’ve install it in a virtual lab as VM on ESXi 4).
I’ve enabled on it the HTTP proxy, in Standard mode, HTTPS traffic will be scanned, and the HTTP proxy is listening on port 8080(actually all the settings are pretty much default settings, I’ve just enabled HTTPS inspection):
We can manage Astaro Security Gateway 7’s trusted CAs store and download its generated root certificate used to sign on-the-fly the server’s certificates and install this certificate in the needed trusted CAs store on clients:
Let’s try to access our test web site using IE 8 from a machine behind Astaro Security Gateway 7, machine configured as web proxy client, Astaro Security Gateway 7 does not trusts our test CA yet:
Please note the CN from server’s certificate, things may look promising at this stage.
But does Astaro verify the server’s name from the certificate ?
The above error message does not say anything about a name mismatch.
Well, I did not find(yet, if it exists) a setting on Astaro Security Gateway 7 to verify the server’s name from the certificate.
For example when I access a secure web site by IP address using IE 8 from a machine behind the Astaro Security Gateway 7, machine configured as web proxy client, I do not receive any warnings from Astaro Security Gateway 7(I could have used a bogus name instead of the IP address with the same result):
Let’s make trusted the local test CA:
And now access the test web site using IE 8 from a machine behind the Astaro Security Gateway 7, machine configured as web proxy client, and nothing, everything looks fine:
Fire up Firefox 3.5(Firefox trusts Astaro’s generated root certificate) from a machine behind the Astaro Security Gateway 7, machine configured as web proxy client and, unlike with IE 8, something is wrong here with server’s name from the certificate according to Firefox:
So unless I'm rusty and missed some settings on Astaro Security Gateway 7’s SSL inspection, Astaro Security Gateway 7 won’t help either.
Let’s try with Forefront TMG Beta 3 instead of Astaro Security Gateway 7(I’ve install it in a lab as VM on ESXi 4). Expectations are low, as TMG Beta 3 was installed on Windows Server 2008 SP2. Anyway let’s try. And Forefront TMG is still in its beta stages, as opposed to Astaro Security Gateway 7 which was production ready.
HTTPS Outbound Inspection was enabled on TMG Beta 3:
Let’s test from a machine behind TMG Beta 3, machine configured as web proxy client when TMG Beta 3 does not trust our test CA. Our connection is denied:
Test with an invalid name in server’s certificate from a machine behind TMG Beta 3, machine configured as web proxy client, for example, we connect to tac.foo.net and instead the server’s certificate was issued to www.carbownind.net:
And as we can see, TMG Beta 3 does check the name from server’s certificate.
That’s cool, but it will help us against Null character certificates ?
Let’s make our internal test CA trusted(I don’t think the trusted CAs store can be managed from TMG Beta 3’s mmc currently, so I’ve used the Certificates mmc):
And access the test web site using IE 8 from a machine behind TMG Beta 3, machine configured as web proxy client and firewall client, and, as expected nothing, everything looks fine, I’m even being kindly notified by FWC while I’m p0wning myself, delightful:
If I will check the logs on TMG Beta 3 for such a request, nothing interesting will show, except maybe what the absence of DNSSec can do:
Now let’s access the test web site using Firefox 3.5 from a machine behind TMG Beta 3, machine configured as web proxy client and firewall client, and as can be seen the certificate, unlike to IE 8, does not look right to Firefox:
So, as expected TMG Beta 3 did not help either.
Also, please note that if you use SSTP, the Windows SSTP client can be fooled by such a server certificate.
Actually, there are more edge devices capable of outbound HTTPS inspection that I would have liked to test, and especially I would have liked to test Secure Computing’s Webwasher, as Secure Computing does some noise about their HTTPS inspection in one of their white papers, but unfortunately I do not have access to any of them as writing.