Security implications of disabling the Common Name check for HTTPS

Question

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

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

$0.02: using CN for host names is deprecated, X.509 Subject Alternate Names should be used instead.