Security Implications for Disabling Common Name Verification for HTTPS

Question

I am going through some client code that I have inherited to ensure secure communication via HTTPS, and it seems that it does not check the common name in the server certificate (for example, "CN =" example.com "against the actual URL that is being requested. This, probably intentionally, since our client application must talk with different environments, therefore, after contacting the source portal (for example, example.com/main) and the user choosing the environment, the application is redirected to a specific IP, so all future requests look like that : Http://127.0.0.1/page ".

However, as a newbie to SSL, I'm not sure about the ability to disable this check. My first reaction was that it would be easier to carry out some kind of “man in the middle” attack, as someone else could just copy our certificate and pretend that it is one of our servers. But if we were doing a regular name check, you could still do the same with your custom DNS settings, so it seems we are not getting anything. Are there other attacks that leave us open, for which we will not be otherwise?

thanks

Answer 1

Someone else cannot just copy your certificate and use it because they do not have a private key.

If you do not verify that the CN certificate does not match the domain name, they can simply create their own certificate (and sign it with a trusted CA so that it looks valid), use it instead of their own, and execute the person in an average attack.

In addition, you need to verify that the certificate comes from a trusted CA. This is a CA job to ensure that you can only get a certificate with CN = if you are actually in control of this domain.

If you skip one of these checks, you risk a MITM attack.

See also this answer for another approach that will work if you have sufficient control over the client.

Answer 2

If you manage the client code, you can restrict trusted CAs only to your own. Then a domain check is less important - any of your servers may pretend to be different.

If you do not control the client code, the certificate signed by a trusted CA can be replaced by yours.

Answer 3

$ 0.02: Using CN for host names is deprecated, X.509 Instead, use alternative subject names.

Answer 4

• Verifying the certificate itself and attaching it to a CA certificate that you already trust allows you to verify the authenticity and validity of the certificate.
• Checking the hostname in the certificate allows you to verify that you are talking to the server you want to talk to, provided that the certificate is valid.
• (Verifying that the remote party really belongs to the one who has the private key for this certificate is performed in SSL / TLS confirmation mode.)

If you need an analogy with passport / ID verification for people:

• Verifying a certificate is similar to verifying the authenticity of a passport or form of identification. You can decide which forms of identifier you want to accept from a person (for example, passport, driver’s license, personnel card, ...) and which issuing countries you trust to verify their authenticity.
• Checking that the remote side belongs to the private key is similar to checking that the image on the passport / ID matches the face of the person in front of you.
• Checking the host name is similar to checking that the passport belongs to the person whose name you are looking for.

If you do not check the host name, anyone who has a valid passport that you think is genuine can come to you and claim that he is the one you are looking for (by name).

In a very limited set of circumstances where you trust only a particular CA or a self-signed certificate, where you allow any potential certificate to impersonate another from the entire set of trusted certificates, it may be acceptable to ignore this check, but this is very rare and not good practice.

Checking that the name in the passport matches the name of the person you are looking for will be considered common sense; do this for certificates too. Doing this does not allow anyone who has a certificate that you trust to be genuine to represent any other certificate you trust, thereby potentially leading to MITM attacks.

HTTPS hostname validation rules are defined in RFC 2818 Section 3.1 (also most recently in the Best Practices specification, RFC 6125 , has not yet been implemented).

In short, the host name should be in the DNS record of the subject of the alternative name (although you can return to the CN DN of the object where the certificate does not have SAN). When you use the IP address, the IP address must be in the SAN IP address entry (although some browsers allow you to leave with the IP address in the CN DN of the topic).

Answer 5

To do the same with “custom DNS settings”, the attacker must use a DNS server (yours or client's) to point example.com to the IP address that it controls, and not just copy the certificate. If possible, I would create all the specific applications as subdomains of example.com and use a wildcard certificate (* .example.com) to check CN.

Answer 6

Verification of the host name (verification of the CN part) ensures that at the other end of the connection (server) there are problems with the SSL certificate with the domain name entered in the address bar. Typically, an attacker will not be able to obtain such a certificate.

If you do not confirm part of the host name, someone (someone is sitting on any of the routers or proxy servers that pass through) can make a person in an average attack. Or someone might use some DNS attacks.