You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If the checkServerTrusted method of a TrustManager never throws a CertificateException, it trusts every certificate. This allows an attacker to perform a machine-in-the-middle attack against the application, therefore breaking any security Transport Layer Security (TLS) gives.
The attacker intercepts this connection and presents a valid, self-signed certificate for https://example.com.
The vulnerable program calls the checkServerTrusted method to check whether it should trust the certificate.
The checkServerTrusted method of your TrustManager does not throw a CertificateException.
The vulnerable program accepts the certificate and proceeds with the connection since your TrustManager implicitly trusted it by not throwing an exception.
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.
Recommendation
Do not use a custom TrustManager that trusts any certificate. If you have to use a self-signed certificate, don't trust every certificate, but instead only trust this specific certificate. See below for an example of how to do this.
Example
In the first (bad) example, the TrustManager never throws a CertificateException and therefore implicitly trusts any certificate. This allows an attacker to perform a machine-in-the-middle attack. In the second (good) example, the self-signed certificate that should be trusted is loaded into a KeyStore. This explicitly defines the certificate as trusted and there is no need to create a custom TrustManager.
publicstaticvoidmain(String[] args) throwsException {
{
classInsecureTrustManagerimplementsX509TrustManager {
@OverridepublicX509Certificate[] getAcceptedIssuers() {
returnnull;
}
@OverridepublicvoidcheckServerTrusted(X509Certificate[] chain, StringauthType) throwsCertificateException {
// BAD: Does not verify the certificate chain, allowing any certificate.
}
@OverridepublicvoidcheckClientTrusted(X509Certificate[] chain, StringauthType) throwsCertificateException {
}
}
SSLContextcontext = SSLContext.getInstance("TLS");
TrustManager[] trustManager = newTrustManager[] { newInsecureTrustManager() };
context.init(null, trustManager, null);
}
{
SSLContextcontext = SSLContext.getInstance("TLS");
FilecertificateFile = newFile("path/to/self-signed-certificate");
// Create a `KeyStore` with default typeKeyStorekeyStore = KeyStore.getInstance(KeyStore.getDefaultType());
// `keyStore` is initially emptykeyStore.load(null, null);
X509CertificategeneratedCertificate;
try (InputStreamcert = newFileInputStream(certificateFile)) {
generatedCertificate = (X509Certificate) CertificateFactory.getInstance("X509")
.generateCertificate(cert);
}
// Add the self-signed certificate to the key storekeyStore.setCertificateEntry(certificateFile.getName(), generatedCertificate);
// Get default `TrustManagerFactory`TrustManagerFactorytmf = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
// Use it with our key store that trusts our self-signed certificatetmf.init(keyStore);
TrustManager[] trustManagers = tmf.getTrustManagers();
context.init(null, trustManagers, null);
// GOOD, we are not using a custom `TrustManager` but instead have// added the self-signed certificate we want to trust to the key// store. Note, the `trustManagers` will **only** trust this one// certificate.URLurl = newURL("https://self-signed.badssl.com/");
HttpsURLConnectionconn = (HttpsURLConnection) url.openConnection();
conn.setSSLSocketFactory(context.getSocketFactory());
}
}
CodeQL scanning https://github.com/eclipse-ee4j/openmq/pull/1384/checks?check_run_id=5150843489, for
TrustManager
that accepts all certificatesIf the checkServerTrusted method of a TrustManager never throws a CertificateException, it trusts every certificate. This allows an attacker to perform a machine-in-the-middle attack against the application, therefore breaking any security Transport Layer Security (TLS) gives.
An attack might look like this:
Recommendation
Do not use a custom TrustManager that trusts any certificate. If you have to use a self-signed certificate, don't trust every certificate, but instead only trust this specific certificate. See below for an example of how to do this.
Example
In the first (bad) example, the TrustManager never throws a CertificateException and therefore implicitly trusts any certificate. This allows an attacker to perform a machine-in-the-middle attack. In the second (good) example, the self-signed certificate that should be trusted is loaded into a KeyStore. This explicitly defines the certificate as trusted and there is no need to create a custom TrustManager.
References
openmq/mq/main/http-tunnel/tunnel/src/main/java/com/sun/messaging/jmq/httptunnel/tunnel/servlet/DefaultTrustManager.java
Line 27 in 7aace89
openmq/mq/main/http-tunnel/tunnel/src/main/java/com/sun/messaging/jmq/httptunnel/tunnel/server/DefaultTrustManager.java
Line 28 in 7aace89
openmq/mq/main/mq-broker/broker-core/src/main/java/com/sun/messaging/jmq/jmsserver/auth/ldap/TrustSSLSocketFactory.java
Line 50 in 7aace89
openmq/mq/main/mq-broker/cluster/src/main/java/com/sun/messaging/jmq/jmsserver/multibroker/fullyconnected/DefaultTrustManager.java
Line 31 in 7aace89
openmq/mq/main/mq-client/src/main/java/com/sun/messaging/jmq/jmsclient/protocol/ssl/DefaultTrustManager.java
Line 36 in 7aace89
openmq/mq/main/mqjmx-api/src/main/java/com/sun/messaging/jmq/management/DefaultTrustManager.java
Line 38 in 7aace89
The text was updated successfully, but these errors were encountered: