TLSチャンネルID 翻訳 - 6. Security Considerations
TLSチャンネルIDの翻訳シリーズの第5回です。「6. Security Considerations」の翻訳結果を投稿します。
シリーズの過去の記事は、 以下を参照ください。
ｰ 第1回：「TLSチャンネルID 翻訳 - 1. introduction」
ｰ 第2回：「TLSチャンネルID 翻訳 - 2. Why not client certificates」
ｰ 第3回：「TLSチャンネルID 翻訳 - 3. Requirements Notation / 4. Channel ID Client Keys」
ｰ 第4回：「TLSチャンネルID 翻訳 - 5. Channel ID Extention」
ｰ ｰ ｰ
6. セキュリティ上の考慮事項
6. Security Considerations
There are four classes of attackers against which we consider our security guarantees: passive network attackers, active network attackers, active network attackers with misissued certificates and attackers in possession of the legitimate server's private key.
我々がセキュリティの保証を検討するとき、攻撃者の4つの分類がある: 受動的なネットワーク上の攻撃者、能動的なネットワーク上の攻撃者、不正に発行された証明書を持つ能動的なネットワーク上の攻撃者、正当なサーバーの秘密鍵を持つ攻撃者である。
First, we wish to guarantee that we don't disclose the Channel ID to passive or active network attackers. We do this by sending a constant-length Channel ID under encryption. However, since the Channel ID may be transmitted before the server's Finished message is received, it's possible that the server isn't in possession of the corresponding private key to the certificate that it presented. In this situation, an active attacker could cause a Channel ID to be transmitted under a random key in a cipher suite of their choosing. Therefore we limit the permissible cipher suites to those where decrypting the message is infeasible.
第一に我々は、チャンネルIDを、能動的または受動的なネットワーク上の攻撃者に対して暴露しないことを保証したい。一定の長さのチャンネルIDを、暗号化して送付することによりこれを行う。しかしながら、チャンネルIDは、サーバーのFinishedメッセージが受信される前に送信されるため、サーバーが、提示された証明書に対する秘密鍵を持っていない状態になる可能性がある。このような場合、能動的な攻撃者は、彼らが指定した暗号スイートのランダム鍵の下でチャンネルIDを伝送することを、引き起こすことができる。それ故我々は、メッセージの復号ができないように、利用可能な暗号スイートを制限する。
Even with this limit, an active attacker can cause the Channel ID to be transmitted in a non-forward-secure manner. Subsequent disclosure of the server's private key would allow previously recorded Channel IDs to be decrypted.
この制限があったとしても、能動的な攻撃者は、フォワード安全でない方法の下でのチャンネルIDの伝送を引き起こすことができる。後々サーバーの秘密鍵が暴露されると、それ以前に記録されたチャンネルIDが復号されることを許してしまう。
Second, we wish to guarantee that none of the first three attackers can terminate/hijack a TLS connection and impersonate a Channel ID from that connection when connecting to the legitimate server. We assume that TLS provides sufficient security to prevent these attackers from being able to hijack the TLS connection. An active attacker illegitimately in possession of a certificate for a server can successfully terminate a TLS connection destined for that server and decrypt the Channel ID. However, as the signature covers the handshake hashes, and therefore the server's certificate, it wouldn't be accepted by the true server.
第二に我々は、最初の3種の攻撃者のいずれも、TLSコネクションを終了させるかハイジャックし、正規のサーバーに接続しているコネクションのチャンネルIDに対して、なりすましをできないことを保証したい。我々は、TLSは、これらの攻撃者がTLSコネクションをハイジャックするのを防ぐのに十分なセキュリティを提供しているものと見なす。あるサーバーに対する証明書を不正に取得した能動的な攻撃者は、そのサーバー宛のTLSコネクションを終了させ、チャンネルIDを復号すること事ができる。しかし、署名はハンドシェイクハッシュを、したがってサーバーの証明書をカバーする*1ので、正しいサーバーから受け入れられることはない。
Against an attacker with the legitimate server's private key we can provide the second guarantee only if the legitimate server uses a forward-secret cipher suite, otherwise the attacker can hijack the connection.
正規のサーバーの秘密鍵を持った攻撃者に対しては、フォワード安全な暗号スイートを使っているサーバーに限り、（二次的な）*2保証をすることができるが、そうでなければ、攻撃者はコネクションをハイジャックすることができる。
