TLS 1.3 に関しては、いわばインクが乾いた状態になったので、標準を実装するソフトウェアの開発作業を本格的に開始する時期が来ています。
先週お伝えしたように、このプロトコルはIETFで必要なコンセンサスを得たため、実装には「すべてが適切に機能するように人々がいくらか努力する必要がある」とのことだ。
Vulture South は、その実装に関わった人物の 1 人であるモーリシャスの開発者である Loganaden Velvindron 氏に話を聞いた。同氏は、昨年 10 月のシンガポール IETF 100 以来見た最も大きな変化は、開発者たちがプロトコルに対してそれほど警戒しなくなったことだと語った。
「私にとって興味深かったのは、オープンソース開発者が TLS 1.3 について『様子見』と言わなくなったことです」と、ロンドンで開催された IETF 101 の TLS 1.3 ハッカソン*に参加した Velvindron 氏は語りました。
TLS 1.3インターネット暗号が承認され、世界は歓喜、サイバースヌープは嘆く
続きを読む
ベルビンドロン氏は、TLS 1.3 を OpenSSL に組み込むハッカソンの取り組みは、上流に最も大きな影響を与えるため、この集会の最も重要な貢献であると述べた。
OpenSSL アーキテクチャが役立った。「API の背後にある低レベルの変更の多くを抽象化します」と彼は語った。
彼のチームはハッカソンの終了までに、他にも多くのプロジェクトを準備していました。広く使用されている wget コマンドライン HTTP 取得ライブラリ、ネットワーク システム監視パッケージの Nagios プラグイン セット、Git および Mercurial バージョン管理ライブラリ、Eclipse Paho マシン間ライブラリ、Monit プロセス/ファイル モニターなどです。
ベルビンドロン氏によると、チームはその過程で、CLIENT HELLO他のアプリのメンテナーが注意すべき、サーバーがコードを構築する方法に誤りがあることを発見したという。
同氏は、一部のアプリケーションは「1.3 では動作しない。それは、...CLIENT HELLOが正しく構築されていないため、ハンドシェイクが失敗するからだ」と述べた。
また、Velvindron 氏は、承認された TLS 1.3 には「ミドルボックス論争」の解決策が含まれているものの、それが現場で実装されるまでにはしばらく時間がかかる可能性があると述べました。
ミドルボックス（主にエンタープライズエッジのトラフィックインスペクターとパケットフィルター）は、TLS 1.3 のリリースが 4 年遅れる原因となった争点の 1 つでした。
IETFは、OpenSSLのようなシステムは「ミドルボックス互換性」をデフォルトで有効にした状態で出荷すべきだと決定しました。Velvindron氏によると、このモードではTLS 1.3接続はTLS 1.2のように見えるとのことです。
「ミドルボックスが TLS 1.2 を正しく実装していると仮定すると、セッションは通過します。TLS 1.2 のように見えますが、実際には TLS 1.3 を使用しています。」
つまり、たとえば、ハッカーがシステムを騙して古くて安全でない暗号スイートに戻すことができるなど、TLS 1.2 の最悪の側面のいくつかは、顧客が既存のシステムに大規模なアップグレードを実施することなく回避されることになります。
ミドルボックスが TLS 1.2 を実装する方法に問題がある場合は、接続が切断され、ユーザーに警告が表示されます。また、一部のミドルボックスではファームウェアのアップグレードが必要になる可能性があると Velvindron 氏は述べています。
次はDNSプライバシー
TLS 1.3 の実装はまだ完成には程遠いですが、プロジェクトは順調にスタートしており、それを支えるグループは活動を広げています。
彼らの注目を集めているプロジェクトの 1 つは、暗号化された DNS セッションで情報が漏洩しないようにする IETF の DNS プライバシーに関する取り組みです。
「RFC 7830とDNSパディングはまだ必要です」とVelvindron氏はVulture Southに語った。
その理由は、暗号化されたメッセージのサイズが小さくても「メッセージに関する情報が漏洩する可能性があるため」だと同氏は説明し、「そのため、盗聴者が送受信されるメッセージの種類を把握しやすくなる可能性がある」と付け加えた。
RFC 7830 に基づくパディングにより、パケットが特定のブロック サイズに揃えられるようになります。
IETF 101 で明らかになったことの 1 つは、DNS が扱いにくくなっていることです。Velvindron 氏によると、著名な Power DNS 開発者の Bert Hubert 氏がプレゼンテーションで「このプロトコルが機能しなくなる前に、どれだけの機能を追加できるでしょうか?」と質問したそうです。
DNS 関連の RFC は 185 件あるため、すでに状況が悪化し始めている可能性があります。そのため、Hubert 氏は、IETF アーカイブをクロールして DNS 関連のドキュメントを探す「DNS Camel」(コードは GitHub にあります) を作成しました (集計表はこちら)。
「これらの機能のすべてを理解している人はほとんどいません。IETF 内でも非常に小さなグループです」と Velvindron 氏はVulture South に語った。
その結果、開発者が孤立して作業する傾向にあることへの懸念が高まっています。「私たちは、ある機能を他の DNS 機能と組み合わせてテストし、正しく補間されるかどうかを確認していません。」
これを変える必要がある、つまり開発者は自社の DNS 機能を他のものと比較してテストする必要がある、という点で意見が一致したと彼は述べた。
その一環として、会議では、ISP を参加させて、どの機能を使用しているかを説明し、開発者がテストすべき重要な点を把握する必要性について議論されました。®
*その他のハッカソン参加者および hackers.mu メンバーは、Pirabarlen Cheenaramen、Nitin Mutkawoa、Codarren Velvindron、Yasir Auleear、Rahul Golam、Nigel Yong Sao Yong、Yash Paupiah です。
