Webブラウザの Google Chromeが2017年10月より、通信が暗号化されないHTTP接続を使ったWebサイトに対する警告をURLバーに表示するよう仕様変更されました。
これまでは個人情報を送信するフォームへだけが対象でしたが、今後はどんどん対象が広まっていくという事で、Web運営者の間ではちょっとした騒ぎになりました。
ところで、Webサイトの常時SSL化はどこまで暗号化されるのでしょうか？
もし、完全に暗号化されるのであれば通信内容を覗き見出来なくなるので、職場で仕事に関係のないサイトを見ていてもシステム管理者（＝会社）にバレない！という事になりそうですが、少し気になったので調べてみました。
スポンサーリンク
職場からHTTPサイトを見た場合
まずは職場から暗号化されていないHTTPサイトを見た場合の通信を傍受してみます。
クライアント（192.168.0.1）からHTTPサイト（old.worklog.be）へアクセスするとこのような通信が流れます。
■ クライアントからHTTPサイトへアクセス
# wget -O - http://old.worklog.be
■ クライアントとHTTPサイト間の通信内容
# ngrep -q -W byline dst\ port 80 and host 160.16.94.41 interface: eth0 (192.168.0.0/255.255.255.0) filter: ( dst port 80 and host 160.16.94.41 ) and (ip or ip6) T 192.168.0.1:40618 -> 160.16.94.41:80 [AP] GET / HTTP/1.0. User-Agent: Wget/1.12 (linux-gnu). Accept: */*. Host: old.worklog.be. Connection: Keep-Alive. .
HTTPは平文通信なのでこんな感じになります。
職場からHTTPSサイトを見た場合
次は常時SSLで暗号化されたHTTPSサイトを見た場合の通信を傍受してみます。
クライアント（192.168.0.1）からHTTPSサイト（worklog.be）へアクセスするとこのような通信が流れます。
■ クライアントからHTTPSサイトへアクセス
# wget -O - https://worklog.be
■ クライアントとHTTPサイト間の通信内容
# ngrep -q -W byline dst\ port 443 and host 160.16.94.41
interface: eth0 (192.168.0.0/255.255.255.0)
filter: ( dst port 443 and host 160.16.94.41 ) and (ip or ip6)
T 192.168.0.1:56748 -> 160.16.94.41:443 [AP]
...........Y..8......xQT/....8......k!B...S....0.,.(.$...
.....k.j.9.8.....2...*.&.......=.5.../.+.'.#.........g.@.3.2.....E.D.1.-.).%.......<./...A.............
...................T........
worklog.be.........
...........#..... .....................................
T 192.168.0.1:56748 -> 160.16.94.41:443 [AP]
....F...BA.-..]..+..r..'3+.8Wf.`=`rk.S..-.........d..8*0.B+6@...........jT...........(....|....f...9O.....%.....R".Mv.a...F...
T 192.168.0.1:56748 -> 160.16.94.41:443 [AP]
.........|...e...km.Zs....G.`@....K.Yp0....zK.....%..:.+..se......\ kDLEt.X..4.....Y;Zh.W.=1....]..w..p..h..C.#....c;~.RH..Y...{....r...p
T 192.168.0.1:56748 -> 160.16.94.41:443 [AP]
.........|.....|0..[..S.D)..z@.
よくわからない文字の羅列が並んでいて殆どは暗号化されていますが、接続先のドメイン名は平文のままでした。
ここも暗号化されていると勘違いしていたのですがどうも違うみたいですね。
つまり、常時SSL化されているからと言って職場で仕事に関係のないサイトを見ていたらバレる！という事ですね。
ただしHTTPSだとURLクエリを隠せる
SSL通信でも接続先のドメイン名は筒抜けですが、その後のURLクエリはちゃんと隠せるようです。
■ HTTPの場合
# wget -O - http://old.worklog.be/?hogehoge ----- # ngrep -q -W byline dst\ port 80 and host 160.16.94.41 interface: eth0 (192.168.0.0/255.255.255.0) filter: ( dst port 80 and host 160.16.94.41 ) and (ip or ip6) T 192.168.0.1:40624 -> 160.16.94.41:80 [AP] GET /?hogehoge HTTP/1.0. User-Agent: Wget/1.12 (linux-gnu). Accept: */*. Host: old.worklog.be. Connection: Keep-Alive.
■ HTTPSの場合
# wget -O - https://worklog.be/?hogehoge
-----
# ngrep -q -W byline dst\ port 443 and host 160.16.94.41
interface: eth0 (192.168.0.0/255.255.255.0)
filter: ( dst port 443 and host 160.16.94.41 ) and (ip or ip6)
T 192.168.0.1:56760 -> 160.16.94.41:443 [AP]
...........Y......?....W._.h....s.p.(. .D......0.,.(.$...
.....k.j.9.8.....2...*.&.......=.5.../.+.'.#.........g.@.3.2.....E.D.1.-.).%.......<./...A.............
...................T........
worklog.be.........
...........#..... .....................................
T 192.168.0.1:56760 -> 160.16.94.41:443 [AP]
....F...BA.$....coA.>.rG...q..ae,YkQw.[m~.....f....s..U..|.#...L...E...w}.E..........(.M...O....!..g.../-..]._6....d.7.....BD|
T 192.168.0.1:56760 -> 160.16.94.41:443 [AP]
......M...O....f.d'..w.|$/...4......R...K...0...a.........q{.....,$.3!..FL.7........D.!9..I:&.;.%..D4..].{J....d;?.H.$R..A.@.....Z.r..p./.........
T 192.168.0.1:56760 -> 160.16.94.41:443 [AP]
......M...O..|...|./7H......k.>
情報をサーバへ送信するようなWebサイトを作っているとこの辺ってどうなっているんだっけ？と思うことがあるので、今回の検証でスッキリしたような気がします。
百聞は一見に如かずといやつです。
HTTPSサイトへの接続時はIPとドメイン名だけは筒抜けになりますが、その他はきちんと暗号化されるのでユーザーにとっては確かにメリットが大きいですね。
また、URLクエリが隠せるというのは、Web開発をする側とってもメリットがあって、特に意識しなくてもSSL化するだけでセキュリティの強化に繋がると思います。
他にも悪意のある第三者にCookieの改ざんをされにくくなったりとか、セキュリティ面で色々と恩恵があるようなので、運営者としてはやらざるを得ないって感じですかね。
常時SSL化に対する懸念
最後に、常時SSL化を急速に進めようとする一部の方達に対する懸念事項を書きます。
これまでは情報を送信するフォームがあるページに対してに警告だけでしたが、今後はこれがどんどん厳しくなり、Firefoxが2015年に発表した『HTTPの廃止』が現実味を帯びています。
Webリテラシーの高い人からは『早く常時SSLで統一して欲しい』という声も多いですが、これまで趣味でやってきたような素人運営者を切り捨ててまで常時SSL化するのはどうなのかなという思いもあります。
Webを盛り上げて来たのは技術者よりも個性豊か素人運営者達だと思うのですが、Webサイトを運営しているからと言って必ずしもWeb技術に明るい訳ではないです。
お金を出せる人だったら、自分で出来なくてもこの変化に付いてこれると思いますが、そうじゃない人の方が大勢だと思うので、これらの対応は少し強引すぎじゃないかなと懸念しています。
多分、自分で出来なくて外注する方も多いと思いますので、常時SSL化対応が得意なエンジニアは、ランサーズとかでお小遣いを稼ぐチャンスですが、Webサイト運営ってどんどん面倒くさくなってきて、記事を書きたくても他に時間を取られる現状はなんだかなーと思ってます。
今回は、気が重い常時SSL化の作業を前に、中々やる気起きない自分を奮い立たせるために常時SSL化についてあれこれ書いてみました。
既存サイトのメンテナンスは確かに大変なんですけど、常時SSL化に対応させしてしまえば後は黙ってhttpsと書くだけで済むと思うのできっと楽になると思います。
という事で、これから常時SSL化に対応する方は頑張りましょう。