Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
None
-
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.
Attachments
Activity
| Field | Original Value | New Value |
|---|---|---|
| Fix Version/s | 2.1.1 [ 22619 ] |
| Description |
After invertigating [~joseph.witthuhn] [comment|https://jira.mariadb.org/browse/CONJ-503?focusedCommentId=98224&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-98224], and verification on SSL with aurora :
Issue is that when certificate has alternate names, only alt-name verification is executed. |
After invertigating [~joseph.witthuhn] [comment|https://jira.mariadb.org/browse/CONJ-503?focusedCommentId=98224&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-98224], and verification on SSL with aurora :
Issue is that when certificate has alternate names, only alt-name verification is executed. [RFC 2818|https://tools.ietf.org/html/rfc2818] 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. According to [RFC 6125|https://tools.ietf.org/search/rfc6125], hostname verification should be done against the certificate’s subjectAlternativeName’s dNSName field. The check is done against the certificate’s commonName field, but commonName is deprecated and has been deprecated for quite a while now |
| Description |
After invertigating [~joseph.witthuhn] [comment|https://jira.mariadb.org/browse/CONJ-503?focusedCommentId=98224&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-98224], and verification on SSL with aurora :
Issue is that when certificate has alternate names, only alt-name verification is executed. [RFC 2818|https://tools.ietf.org/html/rfc2818] 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. According to [RFC 6125|https://tools.ietf.org/search/rfc6125], hostname verification should be done against the certificate’s subjectAlternativeName’s dNSName field. The check is done against the certificate’s commonName field, but commonName is deprecated and has been deprecated for quite a while now |
After invertigating [~joseph.witthuhn] [comment|https://jira.mariadb.org/browse/CONJ-503?focusedCommentId=98224&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-98224], and verification on SSL with aurora :
Issue is that when certificate has alternate names, only alt-name verification is executed as [RFC 6125|https://tools.ietf.org/search/rfc6125] indicate, hostname verification should be done against the certificate’s subjectAlternativeName’s dNSName field. [RFC 2818|https://tools.ietf.org/html/rfc2818] 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 still permit CN verification when SAN doesn't match hostname. better : permit to provide custom hostname verification if that is not needed. |
| Description |
After invertigating [~joseph.witthuhn] [comment|https://jira.mariadb.org/browse/CONJ-503?focusedCommentId=98224&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-98224], and verification on SSL with aurora :
Issue is that when certificate has alternate names, only alt-name verification is executed as [RFC 6125|https://tools.ietf.org/search/rfc6125] indicate, hostname verification should be done against the certificate’s subjectAlternativeName’s dNSName field. [RFC 2818|https://tools.ietf.org/html/rfc2818] 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 still permit CN verification when SAN doesn't match hostname. better : permit to provide custom hostname verification if that is not needed. |
After invertigating [~joseph.witthuhn] [comment|https://jira.mariadb.org/browse/CONJ-503?focusedCommentId=98224&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-98224], and verification on SSL with aurora :
Issue is that when certificate has alternate names, only alt-name verification is executed as [RFC 6125|https://tools.ietf.org/search/rfc6125] indicate, hostname verification should be done against the certificate’s subjectAlternativeName’s dNSName field. [RFC 2818|https://tools.ietf.org/html/rfc2818] 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. |
| Summary | Hostname verification must take in account CN when having alt-name | Add legacy SSL certificate Hostname verification with CN even when SAN are set |
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.
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 ?
| Status | Open [ 1 ] | Confirmed [ 10101 ] |
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.
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.
| Component/s | TLS [ 13805 ] | |
| Resolution | Fixed [ 1 ] | |
| Status | Confirmed [ 10101 ] | Closed [ 6 ] |
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).
| Workflow | MariaDB v3 [ 82218 ] | MariaDB v4 [ 135006 ] |
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.