0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

sslハンド

Last updated at Posted at 2024-10-02

質問
上記の続きですが、送信元のjavaとUbuntuの条件は以下の通りです。何かsslハンドシェイクに影響を与える可能性はありますか?

■java側の設定
java11
sun.security.ssl.allowLegacyHelloMessages=false
sun.security.ssl.allowUnsafeRenegotiation=false

■ubntu側の設定
openssl 3.0.14
kong ver3.4.2

解答
提供されたJavaとUbuntuの設定条件に基づき、SSLハンドシェイクに影響を与える可能性のある要因を以下に詳述します。

Java側の設定

  • Javaバージョン:Java 11

    • Java 11は、TLS 1.2およびTLS 1.3をデフォルトでサポートしています。これにより、古いバージョンのTLS(例えば、TLS 1.0や1.1)はデフォルトで無効化されており、これ自体は問題ではありません。ただし、サーバー側でTLS 1.2や1.3がサポートされていないと、接続が失敗します。
  • sun.security.ssl.allowLegacyHelloMessages=false

    • この設定は、TLSハンドシェイクの初期メッセージで使用される古い形式の「ClientHello」メッセージを許可しないという設定です。TLS 1.2以降のプロトコルでは、通常「レガシーハンドシェイク」は必要ありませんが、サーバーが古いプロトコルや非標準の実装をしている場合、これが原因でハンドシェイクが失敗する可能性があります。

    しかし、Ubuntu側のOpenSSL 3.0は新しいTLS仕様に準拠しているため、この設定が直接問題を引き起こす可能性は低いです。

  • sun.security.ssl.allowUnsafeRenegotiation=false

    • この設定は、SSL/TLS接続の再ネゴシエーションにおける「安全でない再ネゴシエーション」を許可しない設定です。再ネゴシエーションは、通信中に暗号スイートなどを再交渉するプロセスですが、この設定によって安全性の高い再ネゴシエーションのみが許可されます。最近のTLS実装では、再ネゴシエーションの脆弱性に対処するため、この機能はほとんど無効化されています。

    OpenSSL 3.0は安全な再ネゴシエーションをサポートしているため、この設定が問題を引き起こす可能性も低いです。

Ubuntu側の設定

  • OpenSSL 3.0.14

    • OpenSSL 3.0はTLS 1.3とTLS 1.2をサポートしており、セキュリティやパフォーマンスが向上した最新のバージョンです。TLS 1.2以降のプロトコルに対応しており、セキュアな通信が可能です。Java 11と互換性のある暗号スイートをサポートしているため、大きな問題は想定されません。

    ただし、暗号スイートの設定が適切でない場合、ハンドシェイクに失敗する可能性があります。たとえば、サーバー側(Kongの設定やNginxの設定)でサポートする暗号スイートがJava側のTLSクライアントと一致しない場合、ハンドシェイクに失敗することがあります。Kongの設定ファイルやNginxの設定を確認し、暗号スイートがJava側と互換性があるか確認してください。

  • Kong ver3.4.2

    • KongはNginxをベースにしたAPI Gatewayであり、TLSの設定は主にNginxに依存します。Kongのデフォルト設定では、モダンなTLSバージョンや暗号スイートがサポートされていますが、設定によっては特定のTLSバージョンや暗号スイートに制限がかかっている場合があります。

    Nginxの設定ファイル(nginx.confkong.conf)に記載された以下の項目を確認してください:

    • ssl_protocols が TLS 1.2およびTLS 1.3をサポートしているか。
    • ssl_ciphers がJava側と互換性のある暗号スイート(例えば、AES、ECDHEなど)を含んでいるか。

SSLハンドシェイクに影響する可能性のあるポイント

1. TLSバージョンの不一致

  • Java 11ではTLS 1.2および1.3がサポートされていますが、Kong(Nginx)がTLS 1.3のみを許可していると、ハンドシェイクに失敗する可能性があります。**ssl_protocols**の設定を確認し、両方のバージョンがサポートされているかを確認してください。

例:

ssl_protocols TLSv1.2 TLSv1.3;

2. 暗号スイートの不一致

  • Java 11でサポートされている暗号スイートが、KongまたはNginx側で許可されていない場合、ハンドシェイクに失敗します。NginxやKongの**ssl_ciphers**の設定を確認し、Java側と互換性がある暗号スイートがサポートされているか確認します。

例:

ssl_ciphers HIGH:!aNULL:!MD5;

3. 証明書の問題

  • サーバー側(Ubuntu/Kong)のSSL証明書に問題がある場合、例えば、自己署名証明書や証明書チェーンの不備がある場合、Javaクライアントが証明書を受け入れずにハンドシェイクが失敗します。
  • サーバー証明書がJavaクライアントで信頼されているか、証明書チェーンが正しく設定されているかを確認してください。

4. ファイアウォールやネットワークの問題

  • SSLハンドシェイクそのものに影響を与えるものではありませんが、Ubuntuのファイアウォール(ufwiptables)がポート443などをブロックしている場合、接続が拒否されることがあります。ファイアウォール設定も併せて確認してください。

まとめ

Java 11とUbuntu(Kong & OpenSSL 3.0.14)間でのSSLハンドシェイクにおいて、以下の項目が特に影響を与える可能性があります:

  1. TLSバージョンの不一致:Nginx/Kongのssl_protocolsがJava側と一致しているか。
  2. 暗号スイートの不一致ssl_ciphersの設定が互換性のあるものか確認。
  3. 証明書の問題:サーバー証明書が正しく設定され、クライアント(Java)で信頼されているか。
  4. ファイアウォールやネットワーク:適切なポートが開いているか。

これらの項目を確認することで、SSLハンドシェイクの問題を解決できる可能性があります。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?