Knowledge for Google Products: Google Chrome 43で「Upgrade Insecure Requests」が実装された、これなに！？

Web MIDI APIが実装されたことは説明したけれど、「Upgrade Insecure Requests」について忘れていた。この技術は端的に説明すると次のようになる。

https 接続しているページで呼び出している http コンテンツに対して、 httpsへの呼び出しに変更する

で、それがどうした！？

Google Chromeの場合にはバージョン42から、SSL暗号化されたページ（https://）内に、SSL暗号化されていないページを埋め込む（外部画像とか）場合、アドレスバーの左側に「ビックリマーク」がつくと同時に、そこをクリックすると

このページには安全でない他のリソースが含まれています。これらのリソースは、送信中に他のユーザーに参照されたり、悪意のあるユーザーにページの見た目を変更されたりする可能性があります。

とまぁ警告ができるようになりました。

これは暗号化された安全なページにいるはずという固定概念のある状態で、外部リンクは非暗号でそこに何か書き込んで情報漏洩、、てへっ、、とかにならないような措置かなーと思います。

WordPressでも

以前はたまーに、管理画面やサイト全体をSSL暗号化した場合、挿入する画像のリンクが http:// 決め打ちなプラグインとかあって、問題になってました。いまはだいぶ改善しているなという感じです。

SSL Insecure Content Fixer のようなプラグインを使えば、修正してくれるみたいですけどね。

だから、Upgrade Insecure Requestsを使うとどうなる？！

利用する設定（後述）をすると、SSL暗号化されたページ内に表示させる画像等のリンクを自動的に https:// 接続にしてしまいます。

もちろん相手が、SSL通信に対応していなければデータ参照できないので、壊れたデータ（データなし）とされます。

ほほーどうやって使うの？

<head>タグ内に下記のメタ情報を埋め込む
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">
HTTPレスポンスヘッダとして「Content-Security-Policy: upgrade-insecure-requests」を追加する

もちろんブラウザがUpgrade Insecure Requestsに対応していなければなりません。
今のところ、Chrome 43だけかなー（あまり詳しくない）とか思います。

もうちょっと具体的に教えてくれない？

説明を簡略化するために、説明に不要なタグは削除しておきます。

※画像は筆者のGoogle+のプロフィール画像

https://××/□□.html

<html>

<head>

</head>

<body>

</body>

</html>

なんて書くと、SSLサイトに非暗号化の画像を貼り付けているので警告がでます。

これを、

https://××/□□.html

<html>

<head>

</head>

<body>

</body>

</html>

の一行を加えることで、
http://lh3.googleusercontent.com/-a3mryD6QZT0/AAAAAAAAAAI/AAAAAAAAFs8/4tOoAJb_1oo/s120-c/photo.jpg
ではなくて
https://lh3.googleusercontent.com/-a3mryD6QZT0/AAAAAAAAAAI/AAAAAAAAFs8/4tOoAJb_1oo/s120-c/photo.jpg

よりデータを取得してくるように切り替わります。

技術的にどうなってるか教えてよ！

今日得た知識を纏めているので細かいことは分かりませんが、

Chrome拡張の、Live HTTP Headersを使って通信をチェックしてみました。
赤枠部分が注目点です。

Upgrade Insecure Requestsなしの場合

そのまま非SSLからデータを取得してます。

画像：http://lh3.googleusercontent.com/-a3mryD6QZT0/AAAAAAAAAAI/AAAAAAAAFs8/4tOoAJb_1oo/s120-c/photo.jpg

Host = lh3.googleusercontent.com
GET = /-a3mryD6QZT0/AAAAAAAAAAI/AAAAAAAAFs8/4tOoAJb_1oo/s120-c/photo.jpg

を見ればわかりますが、まぁそういう感じでゲットしてきます。
HTTP/1.1 200 OKの、200 OKが正常取得できたよん！！っていうコードです。

ステータスコードについては、W3CのHypertext Transfer Protocol -- HTTP/1.1 (RFC2616)の10 Status Code Definitionsが参考になります。まぁWikipediaのHTTPステータスコードでも十分ですけどね。

Upgrade Insecure Requestsありの場合

画像：http://lh3.googleusercontent.com/-a3mryD6QZT0/AAAAAAAAAAI/AAAAAAAAFs8/4tOoAJb_1oo/s120-c/photo.jpg

Host = lh3.googleusercontent.com:443
GET = /-a3mryD6QZT0/AAAAAAAAAAI/AAAAAAAAFs8/4tOoAJb_1oo/s120-c/photo.jpg

となっており、ホストの末尾に「:443」が付いていると思います。
これは、標準的なHTTPSポートになります。標準的なサーバーであれば

https://◯◯ = http://◯◯:443

という認識になります。
つまりSSLへアクセスしにいってますね。
さらに、HTTPステータスコードは、

HTTP/1.1 304 Not Modified

です。304はリクエストしたリソースは更新なしだよ！って伝えていることです。
まぁ、http:// を https:// へ見に行くように変えただけで、何度もアクセスしちゃったからですね...

ということで、今後、Upgrade Insecure Requestsが主要ブラウザに実装されてくると、SSLページ内の http://（非暗号化）リソース表示は、メタタグ一発で解消しそうですね。

ちょっとまって、

HTTPレスポンスヘッダとして「Content-Security-Policy: upgrade-insecure-requests」を追加する

ってのがあったけど、あれって何？

HTTPレスポンスヘッダに追加する

主にプログラムでHTMLを吐き出すときに追加するやり方ですね。

今はあんまり気にしなくても良くなりましたが、CGIとかの時は結構やったなー。

PHPなら、

header("Content-Security-Policy: upgrade-insecure-requests");

を加えるだけですね。注意点はheaderを呼び出すのは、一番最初じゃないとダメです。
このあたりは、

header — 生の HTTP ヘッダを送信する（php.net）

をご参照あれ〜。

2015年5月21日 @kimipooh

Knowledge for Google Products

ページ

2015年5月21日木曜日

Google Chrome 43で「Upgrade Insecure Requests」が実装された、これなに！？