HTTPS を理解しているようで理解していなかったのでざっくりまとめてみた
Written by @ryysud Aug 14, 2017 19:00 · 1517 words · 4 minutes read
まえおき
当ブログは独自ドメインで運営しているのですが HTTPS への対応を行っていなかったため、Webブラウザで表示される際に「怪しいサイトです」の警告が出されていることに気付きました (´・ω・｀)
Google Chrome
Safari
Firefox
GitHub Pages でホスティングして Route53 で独自ドメインをあてる形をとっているため GitHub Pages 用の github.com での SSL証明書 は発行されていますが、当ブログのドメイン reboooot.net では適用されていないことがわかります。
そもそもブログなのでユーザーの個人情報を頂くことはないのですが、この状態だとクソブログのレッテルを貼られかねない（既には貼られている可能性もある）ので HTTPS 対応するまでの流れを書きなぐっていこうと思います。対応するにあたり HTTPS の理解が浅かったので、まずは今回の記事で HTTPS についてざっくりまとめてみました。
HTTPS とは？
- Hyper Text Transfer Protocol over SSL/TSL の略
- Hyper Text Transfer Protocol Secure の略とも書いてあった
- SSL も TLS もデータを暗号化して送受信するためのプロトコル
- SSL/TLS により暗号化されたデータのやりとりが行われる
- 要は HTTP にセキュリティー機能を追加したもの
SSL と TLS の違い
- SSL ( Secure Sockets Layer ) は 米Netscape社 によって開発されたプロトコル
- 1994年に SSL 1.0 を改良した SSL 2.0 がリリースされ同時に同社のウェブブラウザ Netscape Navigator 1.1 に実装されたことで一般に知れ渡った
- 1995年に SSL 3.0 がリリースされたものの2014年に脆弱性「POODLE」が発見されたため現在 SSL は非推奨となっている
- 代わりに利用されるようになったのが TLS ( Transport Layer Security )
- TLS は IETF によって標準化が行われている
- TLS が登場した段階で既に SSL という名称が広く使われていたため現在も SSL/TLS と併記されている
SSL/TLS の仕組み
SSL も TLS も仕組みはほとんど同じで以下の技術を組み合わせることで実現されている
- 公開鍵暗号（暗号用と復号用に別の鍵を用いる暗号方式）
- 共通鍵暗号（暗号用と復号用に同じ鍵を用いる暗号方式）
- デジタル署名（送信されてきたデータが間違いなく本人のものと証明する技術）
- デジタル証明書（公開鍵を配布する送り主が信頼できることを証明するための仕組み）
具体的な流れは以下の通り
① クライアントからサーバーに対してSSLの接続要求をする
② サーバーからクライアントにSSLサーバ証明書を送信する
③ 認証局の鍵を用いてSSLサーバ証明書に含まれるデジタル署名を復号する
④ 復号したデジタル署名を元にSSLサーバ証明書が認証局から発行されたものか確認する
⑤ SSLサーバー証明書からサーバーが生成した公開鍵を取り出す
⑥ クライアント側で発行した共通鍵を取り出した公開鍵で暗号化してサーバーに送信する
⑦ サーバー側で共通鍵を秘密鍵で復号する
⑧ クライアント <-> サーバー 間で共通鍵を用いて暗号化通信を行う
こちらの最下部にある図がわかりやすかった → SSL - ネットワークエンジニアとして
HTTPS 対応のメリット
メリットとして以下のものが挙げられる
- サイトのセキュリティ強化
- サイトの信頼性向上
- SEO 向上
今回はブログということもありユーザーから個人情報を頂くことはないため、SEO向上（「安全ではないサイト」呼ばわりさせないこと）が1番の目的となります。
まとめ
HTTPS の仕組みやメリットを理解することができたので、次回のブログで導入するまでの流れを紹介していこうと思います。
余談ですが、タイムリーにこんな言い回しを見かけて面白かったのでこの記事の説明に使わせてもらいました。
迫り来る「安全ではないサイト」表示の波に恐れおののくhttps対応チーム
引用：アメブロ2017 – 大規模サービスhttps化 ~ All Greenを目指して ~
