From 8df5d77398b847616441ed20c3cb1dd4b07138d5 Mon Sep 17 00:00:00 2001
From: intrigus
+If a
+Do NOT use an unverifying HostnameVerifier
always returns true
it will not verify the hostname at all.
+This allows an attacker to perform a Man-in-the-middle attack against the application therefore breaking any security Transport Layer Security (TLS) gives.
+
+An attack would look like this:
+1. The program connects to https://example.com
.
+2. The attacker intercepts this connection and presents one of their valid certificates they control, for example one from Let's Encrypt.
+3. Java verifies that the certificate has been issued by a trusted certificate authority.
+4. Java verifies that the certificate has been issued for the host example.com
, which will fail because the certificate has been issued for malicious.domain
.
+5. Java wants to reject the certificate because the hostname does not match. Before doing this it checks whether there exists a HostnameVerifier
.
+6. Your HostnameVerifier
is called which returns true
for any certificate so also for this one.
+7. Java proceeds with the connection since your HostnameVerifier
accepted it.
+8. The attacker can now read the data (Man-in-the-middle) your program sends to https://example.com
while the program thinks the connection is secure.
+HostnameVerifier
!
+
+In the first (bad) example, the HostnameVerifier
always returns true
.
+This allows an attacker to perform a man-in-the-middle attack, because any certificate is accepted despite an incorrect hostname.
+In the second (good) example, the HostnameVerifier
only returns true
when the certificate has been correctly checked.
+
Java offers two mechanisms for SSL authentication - trust manager and hostname verifier. Trust manager validates the peer's certificate chain while hostname verification establishes that the hostname in the URL matches the hostname in the server's identification.
+Java offers two mechanisms for SSL authentication - trust manager and hostname verifier (not checked by this query). Trust manager validates the peer's certificate chain while hostname verification establishes that the hostname in the URL matches the hostname in the server's identification.
And when SSLSocket or SSLEngine is created without a valid parameter of setEndpointIdentificationAlgorithm, hostname verification is disabled by default.
-Unsafe implementation of the interface X509TrustManager, HostnameVerifier, and SSLSocket/SSLEngine ignores all SSL certificate validation errors when establishing an HTTPS connection, thereby making the app vulnerable to man-in-the-middle attacks.
-This query checks whether trust manager is set to trust all certificates, the hostname verifier is turned off, or setEndpointIdentificationAlgorithm is missing. The query also covers a special implementation com.rabbitmq.client.ConnectionFactory.
+Unsafe implementation of the interface X509TrustManager and SSLSocket/SSLEngine ignores all SSL certificate validation errors when establishing an HTTPS connection, thereby making the app vulnerable to man-in-the-middle attacks.
+This query checks whether trust manager is set to trust all certificates or setEndpointIdentificationAlgorithm is missing. The query also covers a special implementation com.rabbitmq.client.ConnectionFactory.
The following two examples show two ways of configuring X509 trust cert manager and hostname verifier. In the 'BAD' case, +
The following two examples show two ways of configuring X509 trust cert manager. In the 'BAD' case, no validation is performed thus any certificate is trusted. In the 'GOOD' case, the proper validation is performed.
Java offers two mechanisms for SSL authentication - trust manager and hostname verifier (not checked by this query). Trust manager validates the peer's certificate chain while hostname verification establishes that the hostname in the URL matches the hostname in the server's identification.
+Java offers two mechanisms for SSL authentication - trust manager and hostname verifier (checked by the java/insecure-hostname-verifier
query). Trust manager validates the peer's certificate chain while hostname verification establishes that the hostname in the URL matches the hostname in the server's identification.
And when SSLSocket or SSLEngine is created without a valid parameter of setEndpointIdentificationAlgorithm, hostname verification is disabled by default.
Unsafe implementation of the interface X509TrustManager and SSLSocket/SSLEngine ignores all SSL certificate validation errors when establishing an HTTPS connection, thereby making the app vulnerable to man-in-the-middle attacks.
This query checks whether trust manager is set to trust all certificates or setEndpointIdentificationAlgorithm is missing. The query also covers a special implementation com.rabbitmq.client.ConnectionFactory.
From e021158b5fa034d3aecb4267b55fefb2cc8cf84c Mon Sep 17 00:00:00 2001 From: intrigusHostnameVerifier
.
6. Your HostnameVerifier
is called which returns true
for any certificate so also for this one.
7. Java proceeds with the connection since your HostnameVerifier
accepted it.
-8. The attacker can now read the data (Man-in-the-middle) your program sends to https://example.com
while the program thinks the connection is secure.
+8. The attacker can now read the data your program sends to https://example.com
and/or alter its replies while the program thinks the connection is secure.
-Do NOT use an unverifying HostnameVerifier
!
-
HostnameVerifier
.
+HostnameVerifier
only returns
Do not use an open HostnameVerifier
.
+
Do not use an open HostnameVerifier
.
+If you use an open verifier to solve a configuration problem with TLS/HTTPS you should solve the configuration problem instead.
If a HostnameVerifier
always returns true
it will not verify the hostname at all.
-This allows an attacker to perform a Man-in-the-middle attack against the application therefore breaking any security Transport Layer Security (TLS) gives.
+This stops Transport Layer Security (TLS) providing any security and allows an attacker to perform a Man-in-the-middle attack against the application.
+
https://example.com
.
-2. The attacker intercepts this connection and presents one of their valid certificates they control, for example one from Let's Encrypt.
-3. Java verifies that the certificate has been issued by a trusted certificate authority.
-4. Java verifies that the certificate has been issued for the host example.com
, which will fail because the certificate has been issued for malicious.domain
.
-5. Java wants to reject the certificate because the hostname does not match. Before doing this it checks whether there exists a HostnameVerifier
.
-6. Your HostnameVerifier
is called which returns true
for any certificate so also for this one.
-7. Java proceeds with the connection since your HostnameVerifier
accepted it.
-8. The attacker can now read the data your program sends to https://example.com
and/or alter its replies while the program thinks the connection is secure.
++An attack might look like this:
+ +https://example.com
.example.com
, which will fail because the certificate has been issued for malicious.domain
.HostnameVerifier
.HostnameVerifier
is called which returns true
for any certificate so also for this one.HostnameVerifier
accepted it.https://example.com
+and/or alter its replies while the program thinks the connection is secure.
Do not use an open HostnameVerifier
.
-If you use an open verifier to solve a configuration problem with TLS/HTTPS you should solve the configuration problem instead.
+If you have a configuration problem with TLS/HTTPS, you should always solve the configuration problem instead of using an open verifier.
HostnameVerifier
only returns
If a HostnameVerifier
always returns true
it will not verify the hostname at all.
-This stops Transport Layer Security (TLS) providing any security and allows an attacker to perform a Man-in-the-middle attack against the application.
+This stops Transport Layer Security (TLS) providing any security and allows an attacker to perform a man-in-the-middle attack against the application.
@@ -14,10 +14,10 @@ An attack might look like this:
https://example.com
.example.com
, which will fail because the certificate has been issued for malicious.domain
.HostnameVerifier
.example.com
. This check fails because the certificate has been issued for a domain controlled by the attacker, for example: malicious.domain
.HostnameVerifier
exists.HostnameVerifier
is called which returns true
for any certificate so also for this one.HostnameVerifier
accepted it.https://example.com
From b4692734b28edb09d6b72d8a947233ec1b433467 Mon Sep 17 00:00:00 2001
From: intrigus https://example.com
.example.com
. This check fails because the certificate has been issued for a domain controlled by the attacker, for example: malicious.domain
.HostnameVerifier
exists.TrustManager
of the program verifies that the certificate has been issued by a trusted certificate authority.example.com
. This check fails because the certificate has been issued for a domain controlled by the attacker, for example: malicious.domain
.HostnameVerifier
exists.HostnameVerifier
is called which returns true
for any certificate so also for this one.HostnameVerifier
accepted it.HostnameVerifier
accepted it.https://example.com
and/or alter its replies while the program thinks the connection is secure.