[CONJ-511] Add legacy SSL certificate Hostname verification with CN even when SAN are set Created: 2017-08-22  Updated: 2017-08-29  Resolved: 2017-08-28

Status: Closed
Project: MariaDB Connector/J
Component/s: TLS
Affects Version/s: None
Fix Version/s: 2.1.1

Type: Bug Priority: Major
Reporter: Diego Dupin Assignee: Diego Dupin
Resolution: Fixed Votes: 0
Labels: None


 Description   

After invertigating joseph.witthuhn comment, and verification on SSL with aurora :

Issue is that when certificate has alternate names, only alt-name verification is executed as RFC 6125 indicate, hostname verification should be done against the certificate’s subjectAlternativeName’s dNSName field.
RFC 2818 discouraged the CN verification > 10 years ago, as it was only intended for legacy. The Baseline Requirements require a subjectAltName, and require that the only host-ish names in a CN must be a name also in the SAN.

That is not compatible with connecting directly aurora host.

Correction is to permit legacy CN verification when SAN doesn't match hostname.



 Comments   
Comment by Joseph Witthuhn [ 2017-08-22 ]

I appreciate that you are taking a look at this. I do have an open case with AWS (since August 2nd) where they are investigating fixing the Aurora certificates from their end. They haven't provided an ETA yet, but that is likely a better "long term" fix, assuming the fix eventually gets pushed out to all of their users.

Comment by Diego Dupin [ 2017-08-22 ]

To have a better explaination, taking the example of aurora certificates :
for a cluster with 3 instances A, B and C, there will be 5 DNS addresses :

  • cluster address : X.cluster-Y.amazonaws.com
  • read-only cluster address : X.cluster-ro-Y.amazonaws.com
  • direct access to instance A : A.Y.amazonaws.com
  • direct access to instance B : B.Y.amazonaws.com
  • direct access to instance C : C.Y.amazonaws.com

Good certificates for instance A would have SANs "X.cluster-Y.amazonaws.com", "X.cluster-ro-Y.amazonaws.com" AND "A.Y.amazonaws.com"

But Aurora has certificates with subject "C=US, ST=Washington, L=Seattle, O=Amazon.com, OU=RDS, CN=A.Y.amazonaws.com" and SANs "X.cluster-Y.amazonaws.com", "X.cluster-ro-Y.amazonaws.com" WITHOUT "A.Y.amazonaws.com"

This kind of certificate are deprecated since a long time (support of that has been completely removed in navigator : firefox,
chrome for example). To be coherent with C connector that rely on different SSL library that still implement this, java driver will permit this kind of certificates.

Driver use the cluster DNS to initially create the connection, but create a slave connection under the hood that cannot be validated without supporting CN hostname validation.

Comment by Diego Dupin [ 2017-08-23 ]

Correction is done on SNAPSHOT version, available on maven using : 

<repositories>
 
    <repository>
 
        <id>sonatype-nexus-snapshots</id>
 
        <name>Sonatype Nexus Snapshots</name>
 
        <url>https://oss.sonatype.org/content/repositories/snapshots</url>
 
    </repository>
 
</repositories>
 
 
 
<dependencies>
 
    <dependency>
 
        <groupId>org.mariadb.jdbc</groupId>
 
        <artifactId>mariadb-java-client</artifactId>
 
        <version>2.1.1-SNAPSHOT</version>
 
    </dependency>
 
</dependencies>

joseph.witthuhn Can you confirm that this solve your issue ?

Comment by Joseph Witthuhn [ 2017-08-23 ]

It doesn't appear to. I get the same exception, except I can tell it is longer because it is now checking additional fields.

This was my original exception:

java.sql.SQLNonTransientConnectionException: DNS host "d-p-m-c.cluster-ijklmno5p6qr.us-east-1.rds.amazonaws.com" not found in certificate alt-names certificate SubjectAltNames[{"rds-aurora-d-p-m-c-cluster-abcde12fgh34.cluster-ijklmno5p6qr.us-east-1.rds.amazonaws.com"|DNS},{"rds-aurora-d-p-m-c-cluster-abcde12fgh34.cluster-ro-ijklmno5p6qr.us-east-1.rds.amazonaws.com"|DNS}] This verification can be disable using the option "disableSslHostnameVerification" but won't prevent man-in-the-middle attacks anymore 
        at org.mariadb.jdbc.internal.protocol.AbstractConnectProtocol.handleConnectionPhases(AbstractConnectProtocol.java:708)
 
        at org.mariadb.jdbc.internal.protocol.AbstractConnectProtocol.connect(AbstractConnectProtocol.java:410)
 
        at org.mariadb.jdbc.internal.protocol.AbstractConnectProtocol.connect(AbstractConnectProtocol.java:368)
 
        at org.mariadb.jdbc.internal.protocol.AuroraProtocol.loop(AuroraProtocol.java:150)
 
        at org.mariadb.jdbc.internal.failover.impl.AuroraListener.reconnectFailedConnection(AuroraListener.java:204)
 
        at org.mariadb.jdbc.internal.failover.impl.MastersSlavesListener.initializeConnection(MastersSlavesListener.java:157)
 
        ... 6 more

This is my new exception with the snapshot:

java.sql.SQLNonTransientConnectionException: SSL hostname verification failed : DNS host "d-p-m-c.cluster-ijklmno5p6qr.us-east-1.rds.amazonaws.com" doesn't correspond to certificate CN "d-p-m-c.ijklmno5p6qr.us-east-1.rds.amazonaws.com" and SAN[{DNS:"rds-aurora-d-p-m-c-cluster-abcde12fgh34.cluster-ijklmno5p6qr.us-east-1.rds.amazonaws.com"},{DNS:"rds-aurora-d-p-m-c-cluster-abcde12fgh34.cluster-ro-ijklmno5p6qr.us-east-1.rds.amazonaws.com"}]
 
This verification can be disable using the option "disableSslHostnameVerification" but won't prevent man-in-the-middle attacks anymore
 
        at org.mariadb.jdbc.internal.protocol.AbstractConnectProtocol.handleConnectionPhases(AbstractConnectProtocol.java:707)
 
        at org.mariadb.jdbc.internal.protocol.AbstractConnectProtocol.connect(AbstractConnectProtocol.java:409)
 
        at org.mariadb.jdbc.internal.protocol.AbstractConnectProtocol.connect(AbstractConnectProtocol.java:368)
 
        at org.mariadb.jdbc.internal.protocol.AuroraProtocol.loop(AuroraProtocol.java:150)
 
        at org.mariadb.jdbc.internal.failover.impl.AuroraListener.reconnectFailedConnection(AuroraListener.java:204)
 
        at org.mariadb.jdbc.internal.failover.impl.MastersSlavesListener.initializeConnection(MastersSlavesListener.java:157)
 
        ... 6 more

The code I used to perform this test was simply:

import java.sql.DriverManager;
 
import java.sql.SQLException;
 
public class DbTester {
 
    public static void main(String[] args) throws SQLException {
 
        DriverManager.getConnection("jdbc:mariadb:aurora://d-p-m-c.cluster-ijklmno5p6qr.us-east-1.rds.amazonaws.com:3306/d?useSSL=true&connectTimeout=31000&username=" + args[0] + "&password=" + args[1]);
 
    }
 
}

In this case, d-p-m-c.cluster-ijklmno5p6qr.us-east-1.rds.amazonaws.com, is the value that appears in our cluster endpoint.

As I mentioned above, AWS has admitted this is likely an issue on their end and is investigating a fix.

Comment by Diego Dupin [ 2017-08-24 ]

Right, the new error clearly indicate that CN and SAN doesn't correspond to server host name. This is clearly an error on AWS side.
Beside that, after different tests on aurora and to be coherent with C driver, this task is still needed.

Comment by Joseph Witthuhn [ 2017-08-29 ]

Just to follow up, AWS has finished up with their fix, and the 2.1.0 release code now can correctly validate our Aurora cluster hostnames (without this additional change).

I also tested it again with the snapshot that you provided above, and confirmed that snapshot works as well (which makes sense, since in theory, it wouldn't hit the new code path).

Generated at Thu Feb 08 03:16:12 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.