HostnameVerifier vs TrustManager?

Question

Under what circumstances would one use a HostnameVerifier over a TrustManager in Java? Is one recommended over the other? Looking at the Java docs (Interface HostnameVerifier and Interface TrustManager), I can't tell when its best to use either (though the TrustManager seems more versatile).

In the past, I have always used a custom TrustManager. However, I noticed Heartbleed exploit in java uses both (but I don't think its correct).

EDIT: when using HostnameVerifier, are the other customary X509 checks performed, like path building and expiration and revocation (if configured)? I think I am essentially asking if HostnameVerifier supplements the other checks (rather than replacing them).

For example, suppose a dev server is at dev.example.com and its signed by an internal CA. There's one DNS name in dev.example.com's certificate, and its dev.example.com. Further, suppose I connect to it as 192.168.1.10. Could I use a HostnameVerifier to allow both dev.example.com and 192.168.1.10? In this scenario, is the additional name allowed and are the other customary X509 checks are performed?

Boschbok

Answer 1

Under what circumstances would one use a HostnameVerifier over a TrustManager in Java?

Never. They do different things. TrustManage authenticates certificates as part of SSL. HostnameVerifier verifies host names as part of HTTPS. They're not in competition.

Is one recommended over the other?

No.

EDIT

• The TrustManager runs during the TLS handshake. If it indicates failure, the handshake is aborted and the connect fails.
• The HostnameVerifier runs after the TLS handshake, over a TLS connection that is already valid from the TLS point of view, so at that point you know that the certificate is valid, signed by a trusted issuer, non-expired (?), etc., and all you have to do is decide (a) whether it's from the correct server and (b) whether you trust that server. You might do (b) inside a TrustManager, but far more commonly you wouldn't provide your own TrustManager at all.

Lindsy

Thanks EJP. So I'm clear: a TrustManager cannot be used to override a hostname mismatch in checkServerTrusted? – Boschbok

@Boschbok I didn't say that. I said there is no circumstance in which you would prefer one over the other. TrustManager is part of TLS; HostnameVerifier is part of HTTPS. They're not in competition. You can verify hostnames in a TrustManager if you need to: see the Javadoc, but you're doing so for a different reason, under a different RFC, and at a different phase of the communication. – Lindsy

More detailed explanation: op-co.de/blog/posts/java_sslsocket_mitm/#index2h2 – Windstorm

@Windstorm JSSE implements RFC 2246 and successors, which at the time of implementing had no requirement for hostname verification. SSL/TLS only ever undertook to provide message secrecy+integrity and authentication. Authorization was always up to the application layer, in this case HTTP. The design still seems perfectly sensible to me even after 18 years. – Lindsy