This stops Transport Layer Security (TLS) providing any security and allows an attacker to perform a Man-in-the-middle attack against the application.

</p>

<p>

An attack might look like this:

<ol>

<li>The program connects to <code>https://example.com</code>.</li>

<li>The attacker intercepts this connection and presents one of their valid certificates they control, for example one from Let's Encrypt.</li>

<li>Java verifies that the certificate has been issued by a trusted certificate authority.</li>

<li>Java verifies that the certificate has been issued for the host <code>example.com</code>, which will fail because the certificate has been issued for <code>malicious.domain</code>.</li>

<li>Java wants to reject the certificate because the hostname does not match. Before doing this it checks whether there exists a <code>HostnameVerifier</code>.</li>

<li>Your <code>HostnameVerifier</code> is called which returns <code>true</code> for any certificate so also for this one.</li>

<li>Java proceeds with the connection since your <code>HostnameVerifier</code> accepted it.</li>

<li>The attacker can now read the data your program sends to <code>https://example.com</code>

and/or alter its replies while the program thinks the connection is secure.</li>

</ol>

If you have a configuration problem with TLS/HTTPS, you should always solve the configuration problem instead of using an open verifier.

<li>Android developers: <a href="https://developer.android.com/training/articles/security-ssl">Security with HTTPS and SSL</a>.</li>

<li>Terse systems blog: <a href="https://tersesystems.com/blog/2014/03/23/fixing-hostname-verification/">Fixing Hostname Verification</a>.</li>