SSL/TLS — その概要、プロトコル、暗号化の動作原理

SSL/TLSとは？

SSL（Secure Sockets Layer）は、1995年にNetscapeがウェブトラフィックを保護するために開発したプロトコルです。最初のバージョンSSL 1.0は公開されることはなく、SSL 2.0（1995）とSSL 3.0（1996）は2000年代初頭まで使用されましたが、深刻な脆弱性を含んでいました。SSLの後継としてTLS（Transport Layer Security）が登場しました。これはIETFによって標準化された改良版です。TLS 1.0（1999）はSSL 3.0に基づいていましたが、その後のバージョンTLS 1.1（2006）、TLS 1.2（2008）、TLS 1.3（2018）は徐々に元のアーキテクチャから離れ、新しい暗号化アルゴリズムを追加し、脆弱性を修正しました。現在、SSLは時代遅れと見なされており、すべての最新システムはTLSを使用していますが、両方のプロトコルは慣例としてSSL/TLSと一緒に言及されることがよくあります。

プロトコルの歴史

SSL/TLSの歴史は、初期のウェブにおける安全なデータ送信の必要性から始まりました。1994年、Netscapeは自社のブラウザNavigator用にSSL 1.0を開発しましたが、深刻なセキュリティ問題のため公開されることはありませんでした。SSL 2.0は1995年にリリースされ実用的に使用されましたが、多くの脆弱性を含んでいました。中間者攻撃に対する保護の欠如、弱い暗号化アルゴリズム、トランケーション攻撃への脆弱性などです。SSL 3.0（1996）はほとんどの問題を修正しましたが、2014年までにPOODLE脆弱性が発見され、その後IETFはすべてのSSLバージョンを正式に時代遅れと宣言しました。TLS 1.0〜1.3は、暗号強度、パフォーマンス、プライバシーを段階的に改善し、TLS 1.3ではハンドシェイクを2ラウンドトリップから1ラウンドトリップに削減しました。これは不安定な接続のモバイルアプリケーションにとって極めて重要です。

SSL/TLSハンドシェイクの仕組み

ハンドシェイクは、クライアントとサーバー間で安全な接続を確立するプロセスです。これは、両者がプロトコルバージョンに同意し、暗号化アルゴリズムを選択し、キーを交換し、相互に認証するといういくつかの連続したステップで構成されます。TLS 1.3では、ハンドシェイクは1回のネットワークラウンドトリップ（1-RTT）のみで済みますが、TLS 1.2では2回（2-RTT）必要でした。

最初のステップは、クライアントがClientHelloを送信することです。これは、サポートされているTLSバージョン、暗号スイート、および乱数を含むメッセージです。サーバーは、選択されたバージョンと暗号、X.509証明書、およびデジタル署名を含むServerHelloで応答します。クライアントは証明書を認証局（CA）チェーンを通じて検証し、セッションキーを生成して、証明書から取得したサーバーの公開鍵で暗号化して送信します。サーバーによる確認後、安全なデータ送信が開始されます。ハンドシェイク全体は最新のデバイスで1〜3ミリ秒かかり、ユーザーには認識されません。

X.509証明書と信頼の連鎖

TLS認証の基盤は、X.509形式の証明書に基づく公開鍵基盤（PKI）です。各証明書には、ドメイン名（Common NameまたはSubject Alternative Name）、サーバーの公開鍵、発行者の名前（認証局）、有効期限、およびCAのデジタル署名が含まれます。クライアントは、信頼の連鎖に沿ってサーバーの証明書を検証します。サーバー証明書からルートCAまで、その証明書はオペレーティングシステムに組み込まれています。Androidデバイスでは、ルート証明書はシステムキーストアに保存され、Google Play Servicesを介して更新されます。iOSでは、iOSアップデートを介して更新されます。チェーンのいずれかのリンクが壊れた場合（証明書の期限切れ、ドメインの不一致、不明なCA）、クライアントは接続を終了します。自己署名証明書（開発で使用）の場合は、明示的な信頼が必要です。AndroidではNetwork Security Configを介して、iOSではInfo.plistのNSExceptionDomainsを介して行います。証明書チェーンの検証プロセスには、CRL（証明書失効リスト）またはOCSP（オンライン証明書ステータスプロトコル）による失効ステータスの確認も含まれますが、モバイルデバイスでは接続を高速化するためにOCSPリクエストがスキップされることがよくあります。これは、アーキテクトが考慮すべきセキュリティとパフォーマンスのトレードオフです。

val client = OkHttpClient.Builder()
    .connectionSpecs(
        listOf(
            ConnectionSpec.Builder(ConnectionSpec.MODERN_TLS)
                .tlsVersions(TlsVersion.TLS_1_3, TlsVersion.TLS_1_2)
                .cipherSuites(
                    CipherSuite.TLS_AES_128_GCM_SHA256,
                    CipherSuite.TLS_AES_256_GCM_SHA384,
                    CipherSuite.TLS_CHACHA20_POLY1305_SHA256
                )
                .build()
        )
    )
    .hostnameVerifier { hostname, session ->
        SSLSession.DefaultHostnameVerifier.verify(hostname, session)
    }
    .build()