I'm going over some client code I've inherited for doing secure communication over HTTPS, and it seems that it's not checking the common name in the server certificate (eg. 'CN = "example.com"' against the actual URL that's being requested. This is probably deliberate, since our client app is required to talk to various environments, so after contacting an initial portal (eg. example.com/main) and the user choosing an environment the app gets redirected to a specific IP, so all future requests look something like "http://127.0.0.1/page".
However being an SSL newbie, I'm unsure of the implications of disabling this check. My first reaction would be that it'd be easier to perform some kind of man-in-the-middle attack, since someone else could just copy our certificate and pretend to be one of our servers. But if we were doing common name checking you'd be able to do the same thing with custom DNS settings anyway, so it doesn't seem to actually gain us anything. Are there other attacks that this leaves us open to which we wouldn't be otherwise?
Thanks
Someone else can't just copy your certificate and use it because they don't have your private key.
If you don't check that the certificate's CN doesn't match the domain name then they can simply create their own certificate (and have it signed by a trusted CA so it looks valid), use it in place of yours, and perform a man in the middle attack.
Also, you need to be checking that the certificate comes from a trusted CA. It's the CA's job to make sure that you can only get a certificate with the CN= if you actually control that domain.
If you skip either of these checks then you are at risk of a MITM attack.
See also this answer for a different approach that will work if you have sufficient control over the client.
If you control the client code, then you can restrict the trusted CAs to just your own. Then the domain check is less important - any of your servers can pretend to be another one.
If you don't control the client code, then a cert signed by a trusted CA can be substituted for yours.
$0.02: using CN for host names is deprecated, X.509 Subject Alternate Names should be used instead.
- Verifying the certificate itself and that it can be chained to a CA certificate you already trust allows you to check that the certificate is genuine and valid.
- Checking the host name in the certificate allows you to check you're talking with the server you intended to talk to, provided you've verified the certificate to be valid indeed.
- (Checking that the remote party is indeed the one holding the private key for that certificate is done within the SSL/TLS handshake.)
If you want an analogy with passport/ID checking for people:
- Verifying the certificate is like checking that a passport or a form of ID is genuine. You can decide which forms of ID you want to accept from a person (e.g. passport, driving licence, staff card, ...) and which issuer countries you trust to be able to verify their authenticity.
- Checking that the remote party is the one holding the private key is similar to checking that the picture on the passport/ID matches the face of the person in front of you.
- Checking the host name is like checking the passport belongs to the person whose name is the one you're looking for.
If you don't check the host name, anyone with a valid passport that you consider genuine could come to you and claim they're the one you're looking for (by name).
In very limited set of circumstances, where you only trust a specific CA or self-signed cert where you allow any potential certificate to impersonate any other in the entire set of certificates you trust, it can be acceptable to ignore this verification, but this is very rare, and not good practice.
Checking that the name in the passport matches the name of the person you're looking for would be considered common sense; do it for certificates too. Not doing so allows anyone who has a certificate that you trust as genuine to impersonate any other certificate you would trust, thereby potentially perform MITM attacks.
The HTTPS host name verification rules are defined in RFC 2818 Section 3.1 (also more recently in a "best practices" spec, RFC 6125, not much implemented yet).
In short, the host name should be in a Subject Alternative Name DNS entry (although you can fall back on the CN of the Subject DN where there's no SAN in the certificate). When you're using an IP address, the IP address must be in a SAN IP-address entry (although some browsers will let you get away with the IP address in the CN of the Subject DN).
To do the same thing with "custom DNS settings" the attacker should exploit a DNS server (yours or a client's) to point example.com to an IP he controls, as opposed to just copying the certificate. If possible I'd create all the specific apps as subdomains of example.com and use a wildcard certificate (*.example.com) to be able to validate the CN.
Hostname verification (verifying the CN part) guarantees that the other end of the connection (server) is having a SSL Certificate issues with the domain name you typed in the address bar. Typically an attacker will not be able to get such a certificate.
If you don't verify the hostname part, somebody (somebody sit at any of the routers or proxies the request passes though) could do a man in the middle attack. Or somebody could do exploit some DNS attacks.
