0

I have a reported finding saying that hostname verification is disabled. This can be deduced from this line of code:

final HttpClientBuilder httpClientBuilder = HttpClientBuilder.create();    
httpClientBuilder.setSSLContext(sslContext).setSSLHostnameVerifier(NoopHostnameVerifier.INSTANCE);

If I want to check the hostname of can I do this? are there several ways to do that? and is that affected by the format of certificate used (ex: x509, PEM, etc ..)

Furthermore I was reading RFC of SSL (https://www.rfc-editor.org/rfc/rfc6125.html) the Server Identity section:

3.1. Server Identity

In general, HTTP/TLS requests are generated by dereferencing a URI. As a consequence, the hostname for the server is known to the client. If the hostname is available, the client MUST check it against the
server's identity as presented in the server's Certificate message,
in order to prevent man-in-the-middle attacks.

If the client has external information as to the expected identity of the server, the hostname check MAY be omitted. (For instance, a client may be connecting to a machine whose address and hostname are
dynamic but the client knows the certificate that the server will
present.) In such cases, it is important to narrow the scope of
acceptable certificates as much as possible in order to prevent man
in the middle attacks. In special cases, it may be appropriate for
the client to simply ignore the server's identity, but it must be
understood that this leaves the connection open to active attack.

If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead.

Matching is performed using the matching rules specified by
[PKIX-OLD]. If more than one identity of a given type is present in
the certificate (e.g., more than one dNSName name, a match in any one of the set is considered acceptable.) Names may contain the wildcard character * which is considered to match any single domain name
component or component fragment. E.g., .a.com matches foo.a.com but not bar.foo.a.com. f.com matches foo.com but not bar.com.

In some cases, the URI is specified as an IP address rather than a hostname. In this case, the iPAddress subjectAltName must be present in the certificate and must exactly match the IP in the URI.

If the hostname does not match the identity in the certificate, user oriented clients MUST either notify the user (clients MAY give the user the opportunity to continue with the connection in any case) or terminate the connection with a bad certificate error. Automated clients MUST log the error to an appropriate audit log (if available) and SHOULD terminate the connection (with a bad certificate error). Automated clients MAY provide a configuration setting that disables this check, but MUST provide a setting which enables it.

Note that in many cases the URI itself comes from an untrusted
source. The above-described check provides no protection against
attacks where this source is compromised. For example, if the URI
was obtained by clicking on an HTML page which was itself obtained
without using HTTP/TLS, a man in the middle could have replaced the
URI. In order to prevent this form of attack, users should carefully examine the certificate presented by the server to determine if it
meets their expectations.

It says that If the client has external information as to the expected identity of the server, the hostname check MAY be omitted. So if in my case the client knows the certificate, can I just ignore this finding, and keep the hostname verification disabled ?

1
  • If you know the expected fingerprint, then yes, ignoring hostname is perfectly valid.
    – vidarlo
    Commented Apr 18 at 12:37

1 Answer 1

4

Hostname verification checks the hostname you connect to against the hostname in the certificate. If you connect to security.stackexchange.com, it should present a certificate issued to security.stackexchange.com, and not to attacker.com.

In most situations, skipping hostname verification totally breaks the security of the encryption. I can register any domain such as attacker.com, request a valid certificate for it, and use that to intercept your traffic.

If I want to check the hostname of can I do this?

Normally, the TLS library does this for you. If you remove the line with setSSLHostnameVerifier(NoopHostnameVerifier.INSTANCE), the default behavior is probably to verify the hostname.

So if in my case the client knows the certificate, can I just ignore this finding, and keep the hostname verification disabled ?

If you have certificate pinning, your setup could be secure without hostname verification. Your question does not really describe your exact setup, so it's hard to say whether this applies to you. However, even with certificate pinning there is generally no reason to disable hostname verification.

I think this is a valid finding, or at least it should be considered seriously.

1
  • Thanks a lot for the explanation! crystal clear ! Does the certificate type affect on the way to apply the hostname verification ? (I am not familiar of how many types of ceritificate there is , I am only aware of the x.509 )
    – anonymous
    Commented Apr 18 at 12:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .