Block Rockin’ Codes

back with another one of those block rockin' codes

HTTPS 化する Web をどう考えるか

web security tls https

Update

  • 2015/5/8: 指摘頂いたタイポや誤訳などを更新しました。
  • 2015/5/8: 構成を一部修正しました。

Intro

4/30 mozaiila のセキュリティブログに下記のようなエントリが投稿されました。

Deprecating Non-Secure HTTP | Mozilla Security Blog

エントリはそこまで長くないので、ここに翻訳の全文を記載します。 そして、元エントリのライセンスである CC BY-SA 3.0 に則り、 本エントリも同じく CC BY-SA 3.0 とします。

Deprecating Non-Secure HTTP

原文: Deprecating Non-Secure HTTP

今日は、 non-secure な HTTP から、徐々に廃止していくという方針についてアナウンスします。

HTTPS が Web を前進させる手段であるという点は、広く同意が得られています。 ここ数ヶ月でも、 IETF, IAB (こっちの IAB でも), W3C, そして アメリカ政府 においても、 インターネットのアプリケーションでは、暗号化通信を広く使おうという声明が出ています。 Web について言えば、それは HTTPS です。

コミュニティ ML での活発な議論を踏まえ、 Mozilla はセキュアな Web の開発に新しい開発リソースを投入し、セキュアでない Web から機能を取り除き始めていくという合意にいたりました。 この計画は、大きく二つの要素から成ります。

  1. 期限となる日を決め、その日以降はセキュアな Web サイトでしか、すべての新しい機能が使えなくします。
  2. 特に、ユーザにとってセキュリティやプライバシー上のリスクが発生する可能性がある機能については、徐々にセキュアではない Web からはアクセスできないようにしていきます。

最初のステップとしては、この期限をコミュニティで決める必要があります。そして、どれが「新しい」機能なのかを定義する必要があります。 例えば、「新しい」を「Polyfill できない機能」と定義するなどが考えられます。 これなら、 CSS や他のレンダリングの機能は、ページ上で (<canvas> などを使って) 再現することで、引き続きセキュアではない Web でも使うことができます。 しかし、例えばハードウェアの機能にアクセスするようなものは、制限されます。

このプランの二つ目の要素は、セキュリティと互換性のトレードオフを踏まえて進む必要があります。セキュアでない Web から機能を削れば、壊れるサイトも出るかもしれません。 そのため、私たちはその破損具合をモニタし、セキュリティ的なメリットとのバランスを取る必要があります。 同様に私たちは既に、セキュアではないサイトから使われる機能のより緩い制限についても考えています。 例えば、 Firefox はすでにカメラやマイクへのアクセス権限の恒久的な取得を、セキュアでない Web には許していません。(訳注: http:// だと毎回聞かれるという意味) セキュアではない Cookie のスコープについても制限する提案がなされています。

注意して頂きたいのは、このプランは URI スキーマとしての "http" が古いコンテンツでも使えなくなるという意味ではないことです。 HSTS や CSP の upgrade-insecure-requests 属性を使うことで、 http:// スキーマがブラウザによって自動で https:// と解釈され、セキュアになります。

この取り組みのゴールは、 Web 開発者コミュニティに、 Web をセキュアにするべきだというメッセージを送ることであり、この取り組みは Web のコミュニティと強調して進めることで最も成果が得られます。 私たちは、まもなくW3C の WebAppSec Working Groupに対して何らかの提案を作成するつもりです。

この ML で議論に参加してくれた多くの人に感謝します。 Web をよりセキュアにしましょう！

Richard Barnes, Firefox Security Lead

要するにどういうことか

簡単に言えば、「これからの Web を http:// を使わず https:// を中心としたセキュアな世界にしていこう」という提案です。

これまでも、それを実現するためも「呼びかけ」というレベルでは Mozilla や Google 含め多くの人が多くの場所で行ってきました。 しかし、 Web にはすでに HTTP で公開されたサービスが多く有り、これは徐々にしか移行していくことができません。

そこで、「これから公開する Web については、極力 HTTPS にする」という状態を促すために、「これから Web に入る新しい機能は、 HTTPS のサイトじゃないと使えなくする」ようにすることで、開発者にHTTPS への移行を促すということです。

そのための作業として、まず以下があります。

  • それをいつからやるか？
  • 新しい機能ってどれのことか？

より詳細なプランはここに書かれています。

Insecure HTTP Deprecation Plan

何がおこっているのか？

言うまでもありませんが、 Web が一般化し、その使われ方も多岐にわたるようになりました。 しかも家で PC を開くときだけでなく、普段持ち歩く様々な端末が Web につながり、 その上で SNS やメールや金融取引まであらゆることを行います。

人がそこに依存すれば、同時に攻撃するメリットもどんどん増えていきます。

空港やカフェで Wifi を使えば、そのパケットはだれかに盗み見られているかもしれません。 どこかから送られて来たメール内のリンクは、罠サイトに通じているかもしれません。 そして、スノーデン事件によって NSA という米国機関までもが、大規模な盗聴を実施していた可能性がでてきました。

とはいえ、 Web のユーザの多くは、プロトコルや暗号の知識など無いでしょう。 そうした人にも安全に使えるように、安全側に倒されていくのは必然かと思います。

ログイン画面だけ HTTPS で後は HTTP という構成も多く有るかと思いますが、 誰がどこで何を盗聴しているかがわからない以上、「どれを暗号化すべきか」ではなく「基本的に全て暗号化する」という考えに移行し、 実際そういったサービスは増え始めています。 Google や Twitter や Github のコンテンツは、もしかしたら今までなら「ログイン画面と設定画面以外は平文で良いだろう」と思われていたかもしれませんが、実際これらサービスはフル HTTPS 化が完了しています。

また、新しく出てくる Web の API やプロトコルには、セキュリティ上の理由から HTTPS で無いと使用できないものもあります。(後述)

一方で、 HTTP で公開され続けている古いコンテンツや、新しいにもかかわらず HTTP で公開されるコンテンツはまだまだあります。

Mozilla だけでなく Google を始めとする多くの団体や企業が、これから新しく公開されるコンテンツについては極力 HTTPS に移行するように呼びかけてきました。 今回の提案は、それをより加速するために、一定の制約を設けることで、開発者の HTTPS への移行を促すものと解釈できるでしょう。

どうなっていくのか？

端的に言えば「暗号化すべきかどうか」ではなく、「暗号化しない理由があるか」を考えることになっていくんだと思います。つまり、基本は HTTPS という世界です。

個人的にはずっと扱ってきたテーマでもありますが、 Web の HTTPS 化っていうのは結構前から始まっていました。 しかし、いよいよ本格的にそういう時代になっていくんだなという気がします。

もちろん、 Web に携わっている人なら思うところはあるでしょう。でももうそういう事を言ってられる局面ではないのかもしれません。

そして、 API 的に言っても「新しいことをやりたければ HTTPS」になっている実感はありました。

でも今回の提案はそれを逆手に取るというか、より「HTTPS じゃないと新しいことができない」のニュアンスを強めるということでしょう。

俺自身は、特に「ビジネス用途」で「これから作る」ものであれば、 HTTPS を選ばない理由はあまり無いと思っています。

しかし、 Web は別にビジネスだけの基盤ではありません。どんな使い方もできて、何をしてもいい。

それをふまえて一番気になっているのは、

「それが Web を窮屈にするのかどうか」

です。

確かに、デバッグしにくいなどの気持ちもわかります。自分も自分のサイト にワイルドカード証明書を入れ年間 26000 円くらい払っています。

でも、例えば遊びで作った WebRTC や ServiceWorker が悪用されて誰かに迷惑をかけた場合どうでしょう。 そういう事例があった場合、証明書で検証できないドメインで公開されたデモアプリは手軽に試せるでしょうか？ 俺にはまだその答えはわかりません。 でも、これはこれからの Web を考える上で重要な問題だと思います。

単純に是非だけで割り切れる問題ではないし、個々の立場やコンテキストによって結論は変わっていくでしょう。 必要があれば声を上げる必要が有るし、必要に応じて準備をしていく必要が有ります。

今回は、そうした議論をする上で知っておくべき動きについて知っている範囲で紹介します。

知っておきたい動き

もう少し技術的な側面から、 HTTPS が要求される流れやその理由を紹介します。

新しいプロトコルからの視点

新しいプロトコルを Web にデプロイするには、中間に入る全てのネットワーク機器(Proxy, FireWall, NAT など、 Intermedialies や Middle Box と言われる) が、そのパケットを正しく通過させる必要があります。

例えば WebSocket や HTTP2 の平文通信が使っている Upgrade ヘッダは、 Middle Box で意図的に落とされてしまい接続が確立できない場合が報告されています。 また、新しいプロトコルを新しいポートに割り当てるには、全ての FireWall でそのポートを空ける必要もあります。

このパターンに対処する一番簡単かつ確実な方法の一つが、経路を暗号化してしまう事です。 End-to-End で暗号化されていれば、 Middle Box は Upgrade ヘッダはもとより、自分を経由したパケットを一切見る事ができないため、基本的には丸っと通すしかなくなります。 そして HTTPS のデフォルトポートである 443 を通してしまえば、新たな穴を空ける必要も有りません。

HTTP2 や QUIC がそうであるように、今後出てくる新しいプロトコルについても、同様に TLS+443 という組み合わせに載ってくる可能性が予想されます。

新しいブラウザ API からの視点

最近ブラウザに追加された新しい機能の中には、非常に重要な情報やハードウェアへのアクセスを行う API があります。 こうしたものは、仕様自体が最初から暗号化前提で作られているものがあります。

例えば WebRTC の通信は DTLS での暗号化が必須になっています。

ServiceWorker は、 HTTPS でないと登録することすらできません。

そして、 WebRTC とセットでよく使われる getUserMedia によるカメラやマイクのアクセスは、 HTTPS では初回のみ使用許可を求められますが、 HTTP の場合は毎回求められます。

最近の流れで言えば、ブラウザのかなり低レベルな機能へアクセスする API が整備されつつ有ります。 こうした仕様の策定は、セキュリティサンドボックス化が非常に重要になり、慎重に設計されています。

こうした理由からも、これから出てくる新しい API について、 HTTP ではそもそも使えない、もしくは制限がかかるものは増えていくと予想されます。

移行を助ける仕様など

全てを暗号化前提にするといっても、現実的に難しい場面があることは既知の問題です。 そうした問題に対する解決策や、それに準ずる回避策として、最近ある話題について紹介しておきます。

Explicit Trusted Proxy

すべての通信が暗号化されると逆に困る場面も考えられます。 例えば、ペアレンタルコントロールやウイルス対策のようなフィルタリングサービスを、プロバイダなどが提供していた場合、 通信が暗号化されていては、中身が見えないのでフィルタリングできません。 同じように、平文だったから提供できたサービスは実は色々あります。

そこで、そうしたサービスが提供する Proxy を「ユーザが信頼した上で明示的に許可」することで、 その Proxy が途中で通信をほどいて、そうしたサービスが提供できるようにするための仕様が考えられています。 要するに MITM を明示的に許すというイメージです。

これを "Explicit Trusted Proxy"(明示的に信頼された Proxy) と呼ばれ、議論されています。

Opportunistic Encription

HTTPS は TLS で暗号化するため、 TLS の持つ証明書検証の仕組みなどを使います。そのためクライアントは、サーバが提示する証明書を CA に問い合わせて検証し、相手を確認する必要があります。

ところが、NSA のような大規模な盗聴を考えると、「相手の検証」といった HTTPS の大事な部分を犠牲にしてでも 「とりあえず通信経路を暗号化」できるとうれしいという考え方もできます。

これを実現するのが "Oppotunistic Encription"(通称 OE) と呼ばれる方式で、日本語では "日和見暗号" と呼ばれます。

ALT-SVC というヘッダを用いてクライアントを暗号化通信に誘導します。 そもそも検証が行われないことが前提なため、証明書はいわゆる「オレオレ証明書」でサーブできます、ただしエラー画面は出ません。

もちろん検証が行われないため TLS の仕組みから見て「安全な通信」とは言い切れません。 移行が可能であれば TLS にし、そうできない場面への対応というとこになるでしょう。

Upgrade Insecure Request

HTTPS で提供されたコンテンツの中に HTTP で提供される JS や画像や iframe などのコンテンツが含まれる場合、 HTTP のコンテンツが改ざんされるとそこを経由して HTTPS のコンテンツも攻撃される可能性があります。

こうした混在したコンテンツは Mixed Content と呼ばれ、現状ブラウザはコンテンツに応じて以下のようなアフォーダンスを提供します。

  • HTTPS でも、 URL バーの TLS 表示にマークが付く
  • コンソールに warn ã‚„ error メッセージを表示する
  • HTTP コンテンツをブロックする

特にコンテンツがブロックされる場合、正しい表示にならなくなります。 これは、多くのコンテンツが http:// の URL でハードコードされたコンテンツにとっては頭の痛い問題で、 これが HTTPS への移行を妨げる原因になる場合があります。 (ドラフト では BBC や NYT などの膨大なレガシーコンテンツを例に出しています。)

この Mixed Contents への対策として提案されているのが Upgrade Insecure Requests です。

これは CSP のヘッダに Upgrade Insecure Requests を指定すると、コンテンツ内の http:// リンクを https:// に書き換えてリクエストを発行してくれるというものです。 これにより URL がハードコードされたコンテンツも、コンテンツを一切いじらずサーバの設定変更だけで HTTPS オンリーに移行できるということです。

content-security-policy: upgrade-insecure-requests

しかし、ここまで単純な例ばかりではないため、実際はより細かい設定が可能になっています。

ちなみに最後のデモは、レスポンスヘッダではなく meta タグで指定されています。

Let's Encrypt

TLS の証明書取得には、種類などあれどそれなりの費用がかかります。 もちろん、ビジネスでやっているのであればしかるべき証明書を買うべきだと思いますが、 個人で趣味でやっているサイトなどで証明書を入れるのは、手軽とは言えない現実もあります。

そこで、 Mozilla や Cisco や Akamai などが共同で作ったのが "Let's Encrypt" であり、 これは誰でも無料で手軽に証明書を取得できるというものです。

無料なため、例えば組織の身元を証明するような機能は無く、単純にドメインの所有権が正しいかを見る(DV 証明書)だけのものになっており ビジネス用途で使うものではありませんが、個人が趣味で使うドメインなどに使うことができます。

パフォーマンス関連

TLS にすれば、 TCP の 3-way-handshake に加えていくつかのやり取りが両者間で発生します。 通信する両者だけでなく、 CA など外部とのやり取りも発生します。 接続が確立した後は、平文の HTTP に比して暗号/複合の計算コストも追加されます。

しかし、こうした問題は既知であり、最適化の手段も整備されつつある印象です。

例えば、以下のようなものがあります。

  • Session Resumption/Session Ticket などによる接続開始の簡略化
  • OCSP-Stapling による失効確認の最適化
  • AES-NI によるハードウェアサポートによる高速化

この辺は、そのうちまた別途まとめて書きたいと思います。

Acknowledgement

翻訳部分は @jovi0608 さんにレビュー頂きました。

また公開後以下の方々にフィードバックを頂きました。

有難うございました！