3

I recently found that a library I am using (specifically Apache HTTPClient) when is configured to verify the hostname of the remote server against the certificate's CN it just seems to be doing a string comparison.
I.e. if the certificate has been issued to an IP and the user types a name instead e.g. https://secureserver/
but the IP<->secureserver (maps e.g. configured in windows host file) the verification fails complaining that 

javax.net.ssl.SSLException: hostname in certificate didn't match: 
    <secureserver> != <10.4.5.1>

Is this the way usually implemented in all libraries? I.e. am I wrong to have expected that a reverse lookup for secureserver to 10.4.5.1. that is the CN of the certificate should have occured?

Thanks

|improve this question
  • As @Hendrik says, that's the way SSL/TLS works, it's not supposed to do that check, nor would it be allowed to. However, there is another problem there: there are additional checks that should be done, to verify that the certificate is indeed valid. Many libraries (don't know specifically about apache) do not perform the full set of checks, and suffice with only checking the name. – AviD♦ Sep 5 '11 at 7:06
  • @AviD:Not sure on your last comment, that check only the name.Could you please give an example of some of the omissions of such libraries? – Jim Sep 5 '11 at 18:16
  • Trust chain, validity dates, signature... As I said, I dont know about apache, but some libraries do not perform these checks automatically (name too, for that matter), unless you explicitly tell it to. – AviD♦ Sep 5 '11 at 18:24
3

https is based on private/public key cryptography. So the client uses the public key of the server to encrypt information that only the server can decrypt.

On this simple level, the attacker may trick the client to talk to him instead of the real server, using the public key of the attacker. The attacker then decrypts the sent information using his private key and forwards it to the real server. This is called a Man in the middle attack.

To prevent this kind of attack, SSL uses certificate. A certificate is basically a public key with some identity information attached to it. Those certificates can be signed by certificate authorities to confirm the identity information.

The client has to verify that the name in the certificate matches the server it wants to talk to. In case of a normal web-browser that is the domain name displayed in the address bar. Without this verification the attacker could just send any certificate.

DNS is not secure so in many situation it can be easily manipulated. If the browser would relax the verification to accept an IP-address which belongs to the domain name in question, it would trust the insecure DNS.

Apart from that, the usage of IP addresses in SSL-certificates is invalid. So even if you type in the ip-address into the address bar, the browser must reject the certificate. But a certificate may contain a list of domain names for which it is valid.

|improve this answer
  • 3
    The browser trusts the insecure DNS in any case, as it uses it to reach the server that presents the certificate. Trojans that modify the hosts file or redirect DNS queries (like the DNSChanger trojan) can fool the browser when it thinks it's going to "name". Which is why name-to-name mapping only provides security insofar as trusted certificate authorities ensure that only Apple has signed certs for names like 'apple.com'. – gowenfawr Aug 17 '11 at 20:38
  • 2
    @gowenfawr, the browser trusts the certificate authorities and server certificates that are contained in its trust store. It will of course follow the DNS response in order to try to reach the server. But it does not trust DNS. If the DNS response is faked, there will be a warning about an invalid certificate unless there is a further compromise. – Hendrik Brummermann Aug 17 '11 at 20:46
  • My understanding from your answer and gowenfawr comment is that there is an inherent security risk to do a DNS lookup during a certificate validation.But I have noticed that an IP as part of CN in a certificate is accepted without complaint from IE and Firefox (have tried it against an IIS server sending a certificate with CN it's IP). So I am not sure what you mean that the usage of IP in certificates is invalid – Jim Aug 17 '11 at 20:48
  • 1
    Hendrik, right, I think we agree here. We're both saying DNS isn't relied upon either forward or backwards (and with good reason!) – gowenfawr Aug 17 '11 at 20:55
  • @gowenfawr:But is it valid to have an IP as CN?Please read my previous comment – Jim Aug 17 '11 at 21:18
3

Yes, I believe you were wrong to expect that the certificate name validation process would do any name resolution, reverse resolution, or other mapping for you. The matching that takes place is pretty much a literal thing performed at the application layer (sorry, bad label. I mean the SSL library code called by the application when I say "application layer"; in OSI this would probably be Session or Presentation layer, but it's all part of the application executable).

I don't believe you'll find a java library handler to add in the name mapping you're looking for, because the SSL/TLS protocol really is about matching the literal names (and then making sure the cryptographic and certification authority aspects are in place).

I believe you can use the subjectAltName tag to generate a certificate which will validly match multiple names, but that's sort of the opposite approach from what you're looking at.

|improve this answer
  • Do you mean in the specific example of the java library some kind of handler should be configured that would actually do the reverse lookup?I mean why does this belong to application level? – Jim Aug 17 '11 at 20:43
  • I understand what you are saying.But in this case it seems that a certificate should not be issued to an IP to avoid issues such as these.Is this the case?Is there some recomendation on this i.e. not issue the certificate to an IP? – Jim Aug 17 '11 at 21:26
2

The point of SSL is that the outside world is hostile (at least potentially). You cannot expect the DNS to return true, unaltered answers, because any attacker who could impact your connection (and you believe that there are such people, because that's the reason you use SSL) could also alter DNS responses. The whole exercise is about trusting a specific set of "trust anchors" (aka "root CA") and building up from that -- and only from that.

So the SSL client will require that the name of the intended server is indeed present in the server's certificate, not anything indirect like an IP address on which the said name was mapped through a potentially insecure mechanism like DNS.

Note: conceptually, any kind of "identity" could be used, as long as what the client expects is equal to what is found in the certificate. In HTTPS, it is assumed that "what the client expects" is adequately described by the URL, more precisely the server name part of the URL. Web browsers show that name proeminently (I am using Chromium right now; it displays the URL in the URL bar as some grey text, with the server name being highlighted in a darker shade). One could conceivably imagine a convention where the client "knows" the target IP address (hardcoded, or known from a trustworthy source, not from a DNS request), and expects that IP address to appear in the certificate; X.509 certificates can indeed contain IP addresses (see the iPAddress name type in the Subject Alt Name extension). However, existing implementations don't match IP addresses, they match names. So it was written, and it makes sense, because names can be verified by humans, and IP addresses can change quite a lot when migrating or expanding infrastructures.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.