メジャーなブラウザーが全員同時にTLS旧版(1.0, 1.1)のサポートを停止する

Firefox, Chrome, Edge, Internet Explorer, そしてSafariなどのWebブラウザーがすべて、オンラインのセキュリティプロトコルTLSの古いバージョンのサポートを停止する。TLSは、インターネット上の暗号化された情報交換のほとんどすべてで使われており、長く使われているあまり安全でないTLS 1.0と1.1も、今だに多くの接続で許容されている。しかしそれも、もう終わりだ。

Transport Layer Securityはコミュニティが開発したスタンダードで、その1.0は20年近く前にリリースされた。しかし1.0とその親戚の1.1には欠陥があって、暗号化による安全な通信に使うのは危険であることが、前から知られていた。2008年に1.2がその重大な欠陥に対処し、現在は大多数のクライアントがこれを使っている。今年初めにリリースされた1.3は、このスタンダードを改良および合理化したが、これにアップデートしたサーバーはまだそれほど多くない。

旧版のサポート停止についてMozilla, Google, Microsoft, WebKitの各陣営がそれぞれ別々に、同じような発表をしている。1.0と1.1は2020年初頭に全廃される。3月と言っている発表もあるが、他もだいたいそのころだろう。

MicrosoftのKyle Pflugがこう書いている: “セキュリティの技術が無変更であり続ける期間として20年は長い。TLS 1.0と1.1の弊社による最新の実装に重大な脆弱性は見当たらないが、サードパーティによる脆弱な実装は存在する。新しいバージョンへ移行することによって、誰にとってもより安全なWebが確保されるだろう”。

ユーザーは、何もしなくてよい。ブラウザーもアプリケーションも、前と同じように動く。おそらく今は、1.2を使っているところが多いだろう。Mozillaが作ったチャート(下図)によると、古いバージョンを使っているところはごくわずかだ。

しかしこれらの、数少ない古い危険な接続は、いろんなもので使われている。レガシーの組み込みマシンがあちこちにあるし、セキュリティスタックを何年もアップデートしていない古いアプリケーションや、ハックされたデバイスもある。そのことを、あなただけでなく、あなたのご両親も知らない。

リードタイムを長くしたのは、たとえば地方自治体などに重要なレガシーシステムがあるからだ。それらは、TLS旧版のサポート停止で動かなくなる〔例: あるアプリケーションが使えない〕かもしれない。その可能性も含め、本格的なシステム監査が必要だ。もっと何年も前に、やるべきだったのだが。

今回の変更によって、ネット上で誰もが前より安全になるが、すべては前と変らず動き続ける。そういう設計だから。

〔TLS 1.3関連本誌翻訳記事: IETFがTLS 1.3を承認、悪質なハッカーや盗聴者が仕事をしづらくなる仕掛けを盛り込む最新のトランスポートレイヤーセキュリティ(TLS)プロトコルを強化するライブラリを、Facebookがオープンソース化FirefoxやFacebookなどがインターネットの新しいセキュリティプロトコルTLS 1.3をすでにサポート。〕

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

最新のトランスポートレイヤーセキュリティ(TLS)プロトコルを強化するライブラリを、Facebookがオープンソース化

Internet Engineering Task Force(IETF)は何年にもわたって、Transport Layer Security(TLS)プロトコルの改善に取り組んでいる、このプロトコルはデータをインターネット上で移動させる際に、開発者がデータ保護を行いやすくするためのものだ。FacebookはFizzというAPIライブラリを開発していた。これは最新版であるTLS1.3を、Facebbokネットワーク上で改善するためのものだ。本日(米国時間8月6日)Facebookは、Fizzをオープンソース化し、誰でもアクセスできるようにそれをGitHub上に置いたことを発表した

Facebookは現在、トラフィックの50%以上をTLS 1.3とFizzを通じて扱っており、彼らはそれをこれまでで最も大規模なTLS 1.3の実装だと考えている。

これらはすべて、トラフィックがインターネット上をどのように動くのか、サーバー同士がどのように安全に通信するのかに関係している、これは、Facebookも指摘しているように、とても重要なことだ。なぜなら現代のインターネットサーバーアーキテクチャの中ではプロセスの重要な部分が世界中のあちこちに分散してしまっていることが珍しくないからだ。またこのことにより、データをサーバーからサーバーへ移動させる際のレイテンシー(遅延時間)を削減するという課題も生まれる。

主要な問題の1つは、膨大なデータをメモリ領域に書き込むことで、リソースのオーバーヘッドと速度低下が起きることだ。この問題を回避するために、Facebookはデータをメモリに移す際に、小さなチャンクに分割し、それらをその場で暗号化することを決定した。このプロセスはscatter/gather I/O(分断/結合を行うI/O)という名で呼ばれている。

ひとかたまりのデータを暗号化するのではなく、Scatter/Gather Fizzを利用してデータを小さな断片に分割しそれぞれを暗号化する。図提供:Facebook

TLS 1.3では、”early data”(これはゼロラウンドトリップデータ、もしくは0-RTTデータとしても知られている)という概念が導入され、レイテンシーの削減を助ける。ITEFによれば、これは「クライアントが直近にアクセスしたものと同じサーバーに接続しているのなら、クライアントが接続時の最初のラウンドトリップの際に、TLSハンドシェイクの成立を待たずにデータを送ることを可能にする」ものだ。問題は、このコンセプトが安全でない場合があることだ。そこでFizzはこのコンセプトに基くAPIを取り込み、既知の脆弱性を取り除きながらそのAPIの上にシステムを構築した。

FacebookはIETFと協力してきた、同社は日々扱う膨大な数のトランザクションに由来するユニークなニーズを抱えているからだ。Facebookによれば、TLS 1.3は「インターネットトラフィックをより安全にするための新しい機能が取り込まれている。例えば証明書をプライベートに保つための暗号化されたハンドシェイクメッセージの取り込みや、秘密鍵の導出方法の再設計、そしてゼロラウンドトリップコネクションセットアップ(これによりいくつかのリクエストは確かにTLS 1.2よりも速くなる)などだ」。

Fizzに関してFacebookは「TLS 1.3で実現された改良点に加えて、Fizzはミドルボックスハンドシェイクエラーへの改良されたソリューション、ディフォルトでの非同期I/Oサポート、そして余計なデータコピーを取り除くためにscatter/gather I/Oを利用する」と、ライブラリのオープンソース化を発表したブログ投稿の中で述べている。

Fizzは、Transport Layer Security(TLS)プロトコルの最新バージョンを改良したものだ。そしてそれをオープンソース化することにより、Facebookはこのテクノロジーを広くコミュニティで共有し、誰もがFacebookの作り上げた成果物を利用して開発が行えるようにしたのだ。

[原文へ]
(翻訳:sako)

写真: Maxiphoto / Getty Images

IETFがTLS 1.3を承認、悪質なハッカーや盗聴者が仕事をしづらくなる仕掛けを盛り込む

聞こえるかな? 世界中のハッカーや諜報員たちが大声で一斉に叫んでいるよ。Internet Engineers Task Force(IETF)が今日、全会一致で、Web上の暗号化されている接続を高速化し、盗聴しづらくするセキュリティフレームワークを承認した。

それはTransport Layer Security version 1.3と呼ばれ、派手な話題ではないけど、至るところに悪いやつがいるようになったWebの、安全強化策のひとつだ。IETFは、世界中のエンジニアたちの集まりで、このようなスタンダードの策定で協力し合っている。そして今回のTLS 1.3の承認までは、4年あまりという長い年月と、提出されたドラフト(草稿)数28という、たいへんな作業を経ている。

それは、インターネットがとてもデリケートなマシンで、その基本的な部分の変更、たとえばクライアントとサーバー間の安全な暗号化接続の確立は、きわめて慎重な協議を必要とするからだ。

ここで技術的な詳細は述べられないが(ぼくが挑戦しても途方に暮れるだけだろう)、TSL 1.3は、ユーザーの安全を守るためにいくつかの重要な変更を加えている。

  • クライアントとサーバー間の“ハンドシェイク”が簡素化され、平文で送信されるデータの量を最小化するので、暗号化がより早期に開始される。
  • 前方秘匿性”によりハッカーは一回の鍵交換から鍵を解読できないようになり、その後それを使ってそのほかの鍵を解読することもできない。
  • “レガシーの”暗号化アルゴリズムをオプションから除く。それがうっかり、やむを得ず使われると、その欠点を利用してメッセージの暗号を破られることがある。
  • 新たに“0-RTT”、ゼロ・ラウンドトリップ・タイムを導入。このモードでは、サーバーとクライアントが一部の要件を事前に確立していて、お互いを紹介し合わなくても直ちにデータの送信を開始できる。

このスタンダードのの全文は155ページあり、専門のエンジニアでないと理解は難しいだろう。でもとにかく容易に入手できるから、勉強意欲のある方はぜひ挑戦を。

もちろん、現場の実装努力がなければ新しいスタンダードも効果を発揮できないが、IETFの承認が下りたことによって、大企業やWebサービス、より高いレベルのスタンダードなどが実装に着手するだろう。そのことに、われわれ一般ユーザーは気づかないかもしれないけど、インターネットという舞台の縁の下で頑張っているエンジニアたちや暗号技術者などに、この場を借りて謝辞を述べておきたい。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa