将来のTLSバージョンはトラフィック検査を防ぐ予定ですか？
現在、組織内のTLS（HTTPS）トラフィックを検査（暗号化解除）することが可能です。 ルートCAを使用することでメカニズムが構成されます Webクライアントで構成され、HTTPS接続を受信し、そのルートCAを使用して宛先のオンザフライ証明書を偽造するネットワークデバイス。したがって、このTLSトラフィック検査では、エンドポイントとネットワークの両方を制御する必要があります。 IPS、プロキシ、DLPなどの一部のネットワークデバイスはこれを実装しています。
トラフィック検査にはビジネスケースがあります。組織は、これらの暗号化されたチャネルを使用して情報漏えいやマルウェア通信から身を守りたいと思うかもしれません。トラフィック検査が不可能な場合、組織には攻撃者によって悪用される可能性のある穴ができます。
しかし、私は将来について、そして傾向がどうなるかについてはわかりません。たとえば、ある時点までのトラフィック検査を回避しようとする certificate pinning について読みました。
TLSの将来のバージョンはトラフィック検査を回避する予定ですか？
最近、このメカニズムを使用してすべてのHTTPSトラフィックを検査できましたか？Google、Apple、Microsoftなど...
番号。
私の知る限り、それについて TLS 1.3ドラフト の内部には何もありません。そして、これには技術的な解決策もないと思います。誰かが追加のルートCAをコンピューターにインストールすることを許可すると、すべての賭けは無効になります。
TLS自体は、2つのエンドポイント（クライアントとサーバー）間のトラフィックのスニッフィングと変更を保護します。 TLSインターセプトは、クライアントがインターセプトデバイスに、インターセプトデバイスがサーバーに接続されている2つのTLS接続を確立するだけです。これは今後のTLSバージョンでも機能します。
TLSインターセプトは、エンドポイントの検証でインターセプトが検出されない（または明示的に許可されている）場合にのみ可能です。 エンドポイントの検証方法はTLSプロトコル自体の一部ではないため、TLSプロトコルへの変更はこの部分には影響しません。したがって、信頼できるプロキシCAを使用したSSLインターセプトの現在のメカニズムは傍受を許可しない場合でも、SSLピン接続と同様に機能します。証明書が明示的に追加されたCAによって署名されている場合、今日のブラウザーはピン留めを無視することに注意してください。つまり、正当なTLSインターセプトが使用されている場合、ピン留めは無視されます。ただし、これも証明書の検証に関する問題であり、TLSバージョンとは無関係です。
1.3がトラフィック検査を正常にブロックしていることを示す新しい研究があるようです： https://tools.ietf.org/html/draft-camwinget-tls-use-cases- 。 2015年以降、仕様が変更された可能性がありますか？