SSL/TLSについてちょっと真面目に調べてみたよ
こんにちは、どうも僕です。オーパーツが好きです、でも陰謀論の方がもっと好きです。
SEOにおけるSSLはランキング要素となることが公表され、今後対応しないといけない技術の一つによくあげられるようになりました。ですが、難しくてよくわからないので触れたくない領域だなと、僕は思っています。ともあれ、新年だし良い機会と思い、SSLについて少し調べ物をしていたら、わりと真面目な領域を覗けたことと、セキュリティをめぐるダイナミズムの中のSSLという飽きない地点に着地できたことで満足。SSLをきちんと考えるのも悪くないなと思いました。
SSLサーバ証明書の種類
まずは、各社が提供するサービスから。SSLサーバ証明書を提供するサービスのサービスプランを見ると、以下のようなプランで提供されています。
ドメイン認証(クイック認証SSL)
ドメイン管理者が証明書の発行を要請しているか認証局が確認した上で発行される。ドメインの所有者が誰であるかは検証しない。企業実在認証(企業認証SSL)
証明書に記載される組織が法的に存在すること、またその組織が証明書に記載されるドメインの所有者であることを認証する。Extended Validation (EV SSL)
企業実在認証に加えて、物理的実在の認証を行う。
これらの違いは、ユーザーの安心を勝ち取るためにどこまで調べて認証するかであり、強度に由来するものではないんですね。
参考：SSLサーバ証明書 サービス一覧／GMO グローバルサイン
暗号化の強度について
暗号の強度はなにに由来するのかを、考えてみようと思いますが、その前に、SSL/TLSについての簡単なまとめ。
通信の流れ
SSL/TLSを利用した通信の流れは、以下のような手順を踏みます。
| クライアント | 流れ | サーバー |
|---|---|---|
| SSL通信をリクエスト | → | |
| ← | SSL証明書を送信 | |
| ← | 公開鍵を送信 | |
| 暗号化した共通鍵を送信 | → | |
| 共通鍵を保持 | ←→ | 共通鍵を保持 |
| 暗号化された状態で通信 |
https://datahotel.jp/service/sslcoupon/service/structure/ http://d.hatena.ne.jp/kasei_san/20120329/p1
ここでのキーワードは「公開鍵」と「共通鍵」
公開鍵
暗号通信を行う際に利用する「共通鍵」を暗号化して共有するための暗号の鍵。共通鍵
暗号通信を行う際に利用する暗号の鍵。
暗号通信を行うための鍵をさらに暗号化して共有する、２重での暗号化が行われているんですね。そして、クライアントとサーバの２者のみがしる共通鍵でやり取りを行う。
Google が非推奨といっている1024bitとは？
ここで、一旦SEOの方面に目を向けます。ウェブマスター向けのブログやSearch Console ヘルプでは、「2048bitを利用する」と書かれていますが、これは公開鍵の暗号化強度のこと。ここでは、RSA暗号を使うことが想定されているようです。
http://googlewebmastercentral-ja.blogspot.jp/2014/08/https-as-ranking-signal.html https://support.google.com/webmasters/answer/6073543
暗号化の種類としては、RSA暗号の他に、楕円曲線暗号とかがありますが、今のところ、RSA暗号を使っているところがほとんどのようですね。また、1024bitは非推奨ですが、これは、Googleの言い分というよりは、業界の流れ（暗号2010年問題）のようで、大手の第三者機関では、すでに1024bitの証明書の発行を行っていないケースもあり、新たに導入する際には、このハードルは普通にクリアーしているケースが多いようです。
参考：1024bitのSSLサーバ証明書について
また、SSL証明書のサービスでは、SHA-1とかSHA-2とか書かれているのも見受けられます。こちらも、暗号化の要素の一つで「暗号学的ハッシュ関数」と呼ばれるようなものだそうです。こういった技術的なところが、本当によくわからないのがSSLを理解する上でのネックですね。
参考：TLS/HTTP2演習/ セキュリティ・ミニキャンプ in 北海道 2015
セキュリティ強化が進む背景
この業界にいてもGoogle自身のSSL導入、ランキング要素への組み込み、そして、Yahoo!での導入と、どんどん推進されているという感触があると思います。なんとなく、セキュリティが強化されていくことは良いような気がしますけどね、なにかあるのかなと思っていたら、わりと大きな話でした。
IETFが推進
インターネットで利用される技術の標準化を策定する組織「The Internet Engineering Task Force (IETF)」が、 セキュリティに関する提言を提出しており、ステータス段階が「Standards Track」、標準化過程に乗っかっている状況だそうで。つまり、セキュリティ強化の流れは、すでに規定路線で、各社がそこに乗っかっているという状況ですね。
https://tools.ietf.org/html/draft-hallambaker-prismproof-req-01
概要には、「通信の傍受というリスクを軽減するために」というようなことが書かれていますが、その中でもひときわ物騒な「PRISM計画」。「アメリカ国家安全保障局（NSA）が2007年から運営する、極秘の通信監視プログラム」で、「ユーザーの電子メールや文書、写真、利用記録、通話など多岐にわたる情報の収集を意図している」というものだそうで。物騒ですねー。ちょっと前に話題になったエドワード・スノーデン氏が証言した、あれだそうです。当時は、ものすごく遠いことだと思っていましたけど。
世間をにぎわせたスキャンダルが引き金となって、身近なところに余波が及んでいたんですね。
SSL/TLSとどう付き合うか
SSL/TLSについて、僕は「Googleがそうしなさいというのだから、そうなのだろう」という観点でしか考えていませんでしたが、その背景を知ると、それ以上に自衛のための行為だというのがわかります。インターネットというフィールドが、民主的でありつづけるための自衛。と考えると、少しは面倒なこともやる気が出てくるなと思いました。ここまでは、わりと振り返りの話。こっから先、HTTP/2などと絡んで、さらに真面目に向き合う必要があるのですけど、その話はまた今度。
