こんにちは。Milkです。
Googleの方針が明確になり、ちょっと「http」と「https」の話題が多くなりましたね。
私にもGoogle神から直接メールが来ました。
早く「https」に対応しないと、ユーザに入力を求める画面では「警告」を表示するようにしちゃうぞ☆って
これは、2017年10月以降に行われるらしいです。
現時点（2017年8月19日）では、このブログは「http」で運営されています。
「https」に切り替えたいけど・・・その前に、「https」って何だったっけ？
これは私の勉強も兼ねての記事になります。
「https」って何？
さて、Webサイトを運営するにあたって、基本的には「http」というものが使われてきました。
参照：https://time-space.kddi.com/ict-keywords/kaisetsu/20160311/
これは、ブラウザに対して「http」という方法で、データを送受信しなさいということで、http以下の文はサーバの中に保存しているHTMLファイルの格納先を指定しています。
つまり、「サーバの中に保管されているHTMLのファイルを、htttpという方法で通信していますよ」という意味なのです。
（厳密に言うと、今ではHTMLをその場でサーバが生成していることも多いので、そういう名前がついているWebページと言ったほうが正しいのかもしれません。）
何が問題になるの？
この状態で、互いに上手く通信が出来ているなら何も問題がありません。
そもそも、これでインターネットの世界は運営されて来たのですから。
しかし、ここでブラックハッカーの存在が問題になってきました。
クライアント（ブラウザで閲覧する人）とサーバの間でやり取りをするので、その間を盗聴しようとする輩が出てきたのです。
普段はそんなに問題になりません。
「いやーん。この人はエロサイトを見てる〜♡」ぐらいなものです。
ですが、ネットの利便性を活用して、銀行の口座の確認や振込、クレジットでの支払いなど、これらがWeb上で行えるようになりました。
この時、口座の持ち主であることやクレジットの持ち主であることを証明するために、口座番号や暗証番号を入力する必要があります。
これが「http」では、そのまま通信として流れていくので、盗聴されると内容がバレてしまいます。
これは困った。
なんとか見えないようにしなければなりません。
ここで登場するのが「https」なのです。
「https」は暗号化して通信を行う
今までの「http」と言う方法は単純に、「HTMLを下さいな。入力した内容を送りますよ。」と言ったやりとりでした。
しかし、このやり取りの最中を盗聴されると内容がバレます。
なので、この通信の途中を暗号化し、盗聴されても意味が不明な状態にしてしまおうと考えたのです。
その方法が「https」です。
と言うことは、「http」ってしてたのを、「https」って打てばいいの？
うーん。実は違います。
これは通信の方法に暗号化を絡ませているので、今までのサーバとのやり取りの仕方が異なってきます。
ですので、単純に「S」を付ければOKという話ではないのです。
「SSL/TLS」とは？
この「https」の話によく絡んでくるのは、「SSL/TLS」という話です。
「HTTPS = SSL/TLS」と言った風潮がありますが、これは別個のものです。
簡単に言うと、
- 暗号化技術：SSL/TLS
- 暗号化技術を使って通信する：HTTPS
となります。「https」を利用するということは、「SSL/TLS」と言う技術を使いながらやりとりするということなのです。
暗号化は進化している
「SSL/TLS」と言われていますが、これは厳密に言うとSSLが進化したものがTLSとなります。
ですがSSLは画期的で、その名前が先に浸透してしまったので、「SSL/TLS」と一括りに言われるようになったのです。
実は、この暗号化技術は常に進歩しています。あれこれと脆弱性（セキュリティ上の欠陥）を見つけ出されて、突破されることがあったためです。
こちらのページがその進歩について解説していました。
| バージョン | 開始 | 終了 |
|---|---|---|
| SSL 1.0 | 実装前に脆弱性が発見され中止 | |
| SSL 2.0 | 1994年 | 脆弱性により2011年3月に使用禁止 |
| SSL 3.0 | 1995年 | 脆弱性により2015年6月に使用禁止 |
| TLS 1.0 | 1999年 | 現在利用中 |
| TLS 1.1 | 2006年 | 現在利用中 |
| TLS 1.2 | 2008年 | 現在利用中 |
| TLS 1.3 | (未制定) |
参照：https://www.cman.jp/network/term/ssl/
このように、暗号化して通信を守りながらデータをやりとりするということが大事になってきました。
Googleは、これを利用した「https」での通信方法を推奨しており、特にユーザが何かを入力するページに対しては「警告」（暗号通信がされていないという表示）を出すと言う方針に決定しました。
「https」と「SSL/TLS」の関係
ここまで来ると、「SSL/TLS」という技術が「https」という通信手段にどのように絡んでくるのか・・・
「https」は暗号化して通信しますよと言われても、どこで「SSL/TLS」が使われているのか・・・
なんだかこんがらがって来ますね。
大丈夫。私もその一人ですから！（お前。それでいいのか？）
暗号化と復号化
暗号化と言うのは、通常のデータを意味が不明なデータに変換する技術です。
（厳密にはハッシュ関数と言うものが使われたりするのですが、これは一つの研究分野に匹敵するので、単純に解説させて下さい。）
このままでは、意味不明なデータになりますので、復号化という技術を使ってデータをもとの形に戻します。
この方法に、共通鍵暗号方式と公開鍵暗号方式というものがあります。
（鍵と言っているのは、暗号化と復号化のルールです。）
こちらに良い解説が載せられていました。
共通鍵暗号と公開鍵暗号の違い | 基礎から学ぶSSL入門ガイド | CSP SSL
各々にメリットとデメリットがあります。
●共通鍵暗号方式
| メリット | デメリット | |
|---|---|---|
| 互いに共通の鍵を使う方式 | 暗号化と復号化の処理速度が早い | 共通の鍵を使うので、それが漏れるとやり取りが復号化されてしまう |
参照：https://zenlogic.jp/aossl/basic/ssl-what/
●公開鍵暗号方式
| メリット | デメリット | |
|---|---|---|
| 公開鍵で暗号化し、秘密鍵で復号化を行う方式 （公開鍵と秘密鍵で鍵の種類が異なる） |
秘密鍵がバレない限り、復号化することはほぼ不可能 | 計算処理が複雑になるので処理速度が共通鍵暗号方式に比べ落ちる |
参照：https://zenlogic.jp/aossl/basic/ssl-what/
HTTPSの方式は掛け合わせる
暗号化方式は、それぞれメリットとデメリットがあります。
よってこれを掛け合わせて使うのです。
こちらの解説が分かりやすいです。
まず、処理の速さから考えると共通鍵暗号方式を使いたいと考えます。
でも、肝心の鍵を渡すときに盗聴されたら意味がありません。
よって、この共通鍵の”鍵を渡す”ときに、公開鍵暗号方式を使うのです。
参照：http://www.atmarkit.co.jp/ait/articles/1704/13/news030.html
この図をよく見ると、「サーバ証明書（公開鍵）」と言う文字が見えます。
これは一体何でしょう？
SSL証明書
通信する相手のサーバ（閲覧しようとしているWebサイトを保管しているサーバ）が信用に値するか？
もし、怪しいサーバなら通信を暗号化したところで、結局は情報を相手に与えることになります。
よって、「しっかりと、信頼出来るサーバです。他の機関からも証明されています。」と言う証明書を示すことになっているのです。
これがいわゆる、「SSL証明書」と呼ばれるものです。
これを発行してくれる機関は幾つかあります。
例えばセキュリティで有名な「Symantec」などです。
発行してもらうには、料金と身元の証明が必要になります。
これらによって、やっと「https」の通信は成り立つのです。
HTTPSを利用するにはサーバの設定が必要
設定方法については割愛しますが、この流れを見ると、結局は「サーバ側にSSL証明書を設定し、WebサイトをHTTPSで通信できるようにする」という作業が必要になります。
これは、個人でレンタルサーバを利用している人は対応が出来ますが、「はてなブログ」や「livedoorブログ」と言ったブログサービスを提供している所を利用している人は、自分でHTTPS対応が出来ないということになります。
なぜなら、ブログサービスを提供している会社がサーバの管理とメンテナンスを行っているためです。
（ある意味では、これはサーバを意識しないで良いのでメリットになります。）
ですから、Googleに「httpsで通信出来るWebサイトにしてね」と言われても、ユーザは自発的にどうこうは出来ないのです。
「WordPress」と言った、個人でサーバをレンタルしてWebサイトを構築している人は、HTTPS対応が可能です。
なので、「この際、WordPress に移行しようかなぁ」なんて意見もあちこちから出ています。
（これに関しては、先ずはサーバのレンタル費用等を計算するところから始めましょう。）
今回、私が利用している「はてなブログ」に関しては、対応について検討し対策を講じている最中（2017年8月19日時点）となっています。
はてなブログのHTTPS化について、お問い合わせを多数いただいております。以前の告知で「検討しており」とお伝えしましたが、現在は実施に向けて開発を進めております。詳細は追って開発ブログ等でお知らせいたしますので、しばらくお待ちください。近日中にお知らせできればと考えております。
— はてなブログ (@hatenablog) 2017年8月18日
最後に
いやぁ・・・HTTPSについて自分も勉強不足でしたから、あちこち調べながら備忘録としてまとめてみました。
ふむふむ。なかなか奥深いですね。
因みにですが、もっと細かい解説になるとこのような文章も発行されています。
この中に、「SSL/TLS暗号設定ガイドライン 」と言うのがあるんですけど・・・
全93ページ、7.52MB！
頑張って、かい摘んでですが読みました・・・
なかなか読み応えがあったね☆
興味がある人は、一度読んでみてみることをお勧めします。
暗号化技術の進化過程を見ることが出来ます（笑）
それでは、今回はこの辺で。
adios！！
