/ photo ソロセプエデ CC
なぜそんなに長い
新しいバージョンのプロトコルの承認には時間がかかりました。更新によって一部の企業、特に銀行に懸念が生じたためです。 新しいプロトコルのアーキテクチャは静的 なキーではなく一時的なキーを使用するため、TLS 1.3では、ネットワーク上の通過トラフィックを復号化できません。 銀行は、接続の透明性を確保するためにトラフィックを分析する必要があります。通常、金融機関のデータセンターには特定の要件 （たとえば、 PCI DSS標準の要件）が適用されます。
トラフィックを追跡できるようにするため、一部のオペレーターは 、一種の「バックドア」をプロトコルに統合することを提案しました。静的なDiffie-Hellman プロトコルを導入することです 。 この問題の議論により、TLSの承認が遅れています。 イニシアチブが拒否されたことに注意してください。
失敗の最初の理由は、Diffie-Hellman静的プロトコルを使用すると、ネットワークでリッスンできるようになるためです。これは、盗聴に関するRFC 2804 IETFポリシーに違反しています 。
2番目の理由は、IETFワーキンググループが新しいプロトコルで弱い暗号化サポートを標準化する準備ができていないことです。 歴史は、輸出グレードのRSA暗号などの弱い暗号化アルゴリズムを使用すると、中間者などの攻撃につながる可能性があることを示しています。 したがって、IETFは、ネットワークプロバイダーの作業を複雑にする場合でも、TLSの安全性の低いバージョンを展開することに同意しませんでした。
TLS 1.3への途中で、Chromebook のケースも登場しました 。 2017年1月、GoogleはTLS 1.3をサポートするChrome 56リリースを発表しました。これは、Linux、macOS、Windows、Android、およびiOSのデバイスで利用できます。 しかし、Chromeを新しいバージョンにアップグレードした後、米国モンゴメリー郡の学校のChromebookとWindows PCはネットワークに接続できませんでした。
後で、失敗の原因がBlue Coat 6.5セキュリティツールであることが明らかになりました。 開発者がGoogleの仕様を完全には守っていなかったため、ChromeがTLS 1.3を使用して接続を確立した場合、彼はシステムを「ハングアップ」させました。 その結果、ITの巨人はプロトコルの実装を一時的に中断しました 。
/写真ジャック・ベニー・パーソン CC
TLS 1.3の主な機能
TLS 1.3では、開発者は以前のバージョンのプロトコルと比較していくつかの重要な変更を加えました。
ハンドシェイク手順を変更しました
TLS 1.2を使用する場合、接続を確立するプロセスはいくつかの段階で進行します。
- まず、クライアントはサーバーにアクセスし、動作可能な暗号化システムをいくつか提供します。
- サーバーはクライアントに応答し、使用する暗号化システムを報告し、暗号化キーを送信します。
- クライアントはキーを受け取り、それを使用してランダムな文字シーケンスを暗号化して送信します。
- 次に、マスターキー（より強力）とセッションキー（より弱い）の2つの新しいキーが作成されます。
- さらに、クライアントは、セッションキーに使用する予定の暗号化システムを報告します。
- 最後に、サーバーは暗号化システムを承認し、データ交換が開始されます。
TLS 1.3は、いくつかのステップを組み合わせることでプロセス全体を2倍高速化し、情報交換が始まるまでの時間を短縮します。 シーケンスは次のとおりです。
- クライアントは、使用できる暗号化システムについてサーバーに通知します。
- サーバーはシステムを承認し、そのキーを転送します。
- クライアントはセッションキーを提供します。
同時に、開発者がブロック暗号化のAEADモードを使用しないすべてのアルゴリズムを削除したため、メカニズム自体の安全性が向上しました。 さらに、一般的な暗号スイートの構造では、認証およびキー交換メカニズムは、 HMACの書き込み保護アルゴリズムおよびハッシュ関数から「分離」されていました。
前方秘匿性の実装
この革新により、攻撃者は1つのセッションのコピーされたキーを使用して他のデータを復号化できなくなります。 マスターキーが侵害されても、セッションキーは解読されません。
0-RTTモードを追加
サーバーとクライアントが既にパケットを交換している場合、古いキーを使用して接続を確立できるモード。 このアプローチにより、データの送受信が開始されるまでの時間が短縮されます。
ただし、この場合、クライアント（ブラウザなど）はサーバーとの安全なチャネルを確立せず、単にリクエストを送信します。 同時に、攻撃者はパケットを傍受し、必要に応じて偽造することができます。 したがって、プロトコル仕様では、以前に送信された正しいメッセージを記録してから送信することによって実装されるリプレイ攻撃 、およびそれらに対抗する方法を個別に考慮します。
サーバーはそのような攻撃に対する保護を実装する責任があることをここで覚えておくことが重要です。したがって、IETF文書は攻撃者の活動に対抗する保護メカニズムに特に重点を置いています。 ここで提案されたアプローチを見つけることができます 。
標準の他の機能と機能の説明はここで見つけることができます 。
PS最初の企業IaaSブログの記事：
PPSHabréのブログ「IT-GRAD」からの記事の選択：