Aurora MySQL 8.4.8 でサポートされた PQ 鍵交換を用いる TLS 接続を検証してみた
はじめに
2026年9月3日に公表された Aurora MySQL 8.4.8 については、先行記事で紹介しました。
先行記事で後日紹介するとしていた PQC への対応を、本記事で取り上げます。
8.4.8 は、TLS 1.3 における PQC によるハイブリッド鍵交換として X25519MLKEM768 と SecP256r1MLKEM768 をサポートします。
今回は、JDK 27 のクライアントから接続し、TLS ハンドシェイクで選択された鍵交換グループを確認しました。
検証内容
Aurora と同じ VPC に EC2（Amazon Linux 2023、ARM64）を1台置き、その上で動かした JDK 27 のコンテナから接続しました。
検証環境
検証には、GA 前の JDK 27（ビルド 27+35）、Aurora MySQL 8.4.8、MySQL Connector/J 9.0.0 を使用しました。JDK のバージョンは次のとおりです。
openjdk version "27" 2026-09-15
OpenJDK Runtime Environment (build 27+35-2325)
OpenJDK 64-Bit Server VM (build 27+35-2325, mixed mode, sharing)
接続先の Aurora のバージョンと TLS 設定は、次のクエリで確認しました。
SELECT VERSION();
SHOW VARIABLES LIKE 'tls%';
SHOW VARIABLES LIKE 'ssl%';
- VERSION(): 8.4.8
- tls_version: TLSv1.2,TLSv1.3
- tls_ciphersuites: TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384
tls% と ssl% の変数に、PQ 鍵交換を有効化または無効化する項目は見当たりませんでした。
接続クライアント
JDK の入手元と Connector/J のバージョンは Dockerfile のとおりです。
JDK 27 クライアントの Dockerfile
FROM debian:bookworm-slim
RUN apt-get update && apt-get install -y --no-install-recommends \
curl ca-certificates \
&& rm -rf /var/lib/apt/lists/*
ARG JDK_URL=https://download.java.net/java/GA/jdk27/55ce5470a6294008af0057ff4626d0e5/35/GPL/openjdk-27_linux-aarch64_bin.tar.gz
RUN curl -fsSL ${JDK_URL} | tar -xz -C /opt \
&& ln -s /opt/jdk-27 /opt/java
ENV JAVA_HOME=/opt/java
ENV PATH="${JAVA_HOME}/bin:${PATH}"
WORKDIR /app
ADD https://repo1.maven.org/maven2/com/mysql/mysql-connector-j/9.0.0/mysql-connector-j-9.0.0.jar /app/mysql-connector-j.jar
COPY MysqlTlsTest.java .
RUN javac -cp mysql-connector-j.jar MysqlTlsTest.java
CMD ["java", "-Djavax.net.debug=ssl:handshake", "-cp", ".:mysql-connector-j.jar", "MysqlTlsTest"]
接続に使ったコードの設定部分は次のとおりです。この設定で取得したハンドシェイクログは、証明書検証を無効にした接続のものです。
String url = String.format("jdbc:mysql://%s:%s/%s", host, port, database);
Properties props = new Properties();
props.setProperty("user", user);
props.setProperty("password", password);
props.setProperty("useSSL", "true");
props.setProperty("requireSSL", "true");
props.setProperty("verifyServerCertificate", "false");
上記の SSL 関連の3つのプロパティは Connector/J 8 以降では非推奨です。証明書検証を有効にする場合の書き方は後述します。
ビルドと実行は次のコマンドで行いました。
docker build -f Dockerfile.jdk27 -t mysql-tls-java-jdk27 java-client/
docker run --rm \
-e MYSQL_HOST="$MYSQL_HOST" \
-e MYSQL_PORT=3306 \
-e MYSQL_USER=admin \
-e MYSQL_PASSWORD="$MYSQL_PASSWORD" \
-e MYSQL_DATABASE=mysql \
mysql-tls-java-jdk27 > jdk27-handshake.log 2>&1
鍵交換グループはハンドシェイクログにしか現れません。Dockerfile の CMD で -Djavax.net.debug=ssl:handshake を付けて実行し、出力されたログの ServerHello を読みました。
OpenSSL での簡易確認
PQC 対応の JDK をすぐ用意できない場合は、接続元の OpenSSL が X25519MLKEM768 を持つかどうかを先に確認できます。この EC2 で次のコマンドを実行しました。
openssl version
openssl list -tls-groups
OpenSSL のバージョンと対応グループはこうなりました。
OpenSSL 3.5.7 9 Jun 2026 (Library: OpenSSL 3.5.7 9 Jun 2026)
secp256r1:secp384r1:secp521r1:x25519:x448:brainpoolP256r1tls13:brainpoolP384r1tls13:brainpoolP512r1tls13:ffdhe2048:ffdhe3072:ffdhe4096:ffdhe6144:ffdhe8192:MLKEM512:MLKEM768:MLKEM1024:SecP256r1MLKEM768:X25519MLKEM768:SecP384r1MLKEM1024
一覧の後半に MLKEM 系のグループが並び、X25519MLKEM768 も含まれていました。PQ 鍵交換が成立しないときに、クライアント側の対応状況を先に切り分ける手段として使えます。ただし、ライブラリにグループがあることと、接続時にそれが提示・選択されることは別です。成立したかどうかは、次のハンドシェイクログで読み取ります。
ハンドシェイクの確認
JDK 27 のクライアントは、ClientHello の supported_groups に X25519MLKEM768 を含めて提示していました。
"supported_groups (10)": {
"named groups": [X25519MLKEM768, x25519, secp256r1, secp384r1, secp521r1, x448, ffdhe2048, ffdhe3072, ffdhe4096]
},
続く ServerHello では、Aurora が X25519MLKEM768 を選択しました。
"ServerHello": {
"server version" : "TLSv1.2",
"cipher suite" : "TLS_AES_256_GCM_SHA384(0x1302)",
"compression methods" : "00",
"extensions" : [
"key_share (51)": {
"server_share": {
"named group": X25519MLKEM768
TLS 1.3 の key_share は合意された鍵交換グループそのものです。この "named group": X25519MLKEM768 から、サーバーとクライアントの双方でこのグループが使用されたことを確認できます。引用中の server version は、互換性のために TLSv1.2 が入るフィールドです。実際にネゴシエートされたバージョンは、ログの Negotiated protocol version に現れます。
javax.net.ssl|DEBUG|30|main|2026-09-07 04:41:02.984 UTC|ServerHello.java:1049|Negotiated protocol version: TLSv1.3
ハンドシェイクだけでなく接続も成立し、セッションの暗号スイートと TLS バージョンは次の値でした。
Connected successfully!
=== TLS Session Status ===
Ssl_cipher: TLS_AES_256_GCM_SHA384
Ssl_version: TLSv1.3
証明書検証との併用
証明書検証を有効にしても同じグループが選ばれるかを確認しました。
Connector/J の sslMode を VERIFY_IDENTITY にし、RDS の CA バンドルを truststore に取り込んで実行しました。使用したバンドルは https://truststore.pki.rds.amazonaws.com/ap-northeast-1/ap-northeast-1-bundle.pem（取得日 2026-09-07）です。接続プロパティは次のとおりです。
Properties props = new Properties();
props.setProperty("user", user);
props.setProperty("password", password);
props.setProperty("sslMode", "VERIFY_IDENTITY");
props.setProperty("trustCertificateKeyStoreUrl", "file:/app/rds-truststore.p12");
props.setProperty("trustCertificateKeyStoreType", "PKCS12");
props.setProperty("trustCertificateKeyStorePassword", "changeit");
この設定でも、ServerHello の server_share は同じ X25519MLKEM768 でした。
まとめ
PQC による鍵交換をサポートした Aurora MySQL 8.4.8 では、クライアントを PQC 対応にすることで PQ 鍵交換が成立しました。成立したことは、ハンドシェイクログの ServerHello で確かめられました。
政府機関などでは、2035年までの PQC 移行を目指す方針が示されています。
PQ 鍵交換は、2026年7月の MySQL 26.7.0 に続き、Aurora MySQL 8.4.8 で使えるようになりました。クライアント側も、PQ 鍵交換が既定で有効な JDK 27 が 2026-09-15 に GA 予定とされています。
今後 Aurora MySQL を採用し、PQC 対応を求められる可能性がある場合は、Aurora MySQL 8.4.8 と PQC 対応のミドルウェアおよび JDK の組み合わせで PQ 鍵交換を利用できるか、確認をおすすめします。
参考リンク
