はじめに
WEB DB PRESS 100 「完全HTTPS化」 感想・まとめ
1,2章のみです。
汎用的な項目のみをまとめてあります。
HTTPSとはそもそも何か
HTTPSは、みなさん同じみのHTTPによる通信をSSL(Secure Soke Layer)あるいはTLS(Transport Layer Security)によってより安全な通信とするための仕組みです。
HTTPSでは公開鍵暗号を用いて、Webサーバーにあるサーバー証明書をWebブラウザにインストールされているルート証明書で検証します。その上で共通鍵暗号の鍵を生成し、公開鍵暗号を使ってWebサーバーと鍵交換を行います。
利用者がHTTPかHTTPSのどちらで通信してるかを判定するには、ブラウザのアドレスバーが「保護された通信」かそうではないか確認するばいいので、一目瞭然ですね。
なぜ完全HTTPS化するのか
これまで
HTTPSはログインや登録情報の参照など、いわゆる個人情報や認証情報を扱う箇所のみに使われていました。 その理由は、データ量増加やHTTPSの処理負荷などオーバーヘッドが大きかったことが考えられます。
企業のコーポレートサイトだと、トップページはHTTPなのに、質問ページだとHTTPSなんてことよくあります。
入力フォームがあるのに、HTTPS化されていない企業のサイトは、その会社全体のセキュリティ意識の低さが体現されてます。
これから
サービスをよりセキュアにするという目的
情報の重要度に関わらず、全ての入力フォームをHTTPS化することで、情報の安全性の選別が必要無くなります。
OS、ブラウザ、検索エンジン等のプラットフォームの進化に対応する目的
Chorome56でリリースされた、HTTPページにログインフォームが表示されている場合に「保護されていない通信」という警告を出す機能は、多くのHTTPページでログインのモーダルを表示していたクックパッドにも影響を及ぼす変更でした。
たまに、HTTPS化されてないサイトにアクセスすると、赤い画面で警告が出ますよね
あれは心臓に悪い
ここ最近、はてなブロガーの間でも話題になってました。
アクセス数落ちるし
開発のしやすさを考慮して
(クックパッドの例として)HTTPSが必要な箇所全てに、HTTPSを必須化する共通のロジックを書く必要がありました。これでは、本来HTTPSであるべ画面とそうでないなどの事故が起きやすくなってしまいます。
ソースコードでURL指定してる箇所の修正って地味に面倒なんですよね
新しい技術に対応
新しいWebの仕組みは、その多くがHTTPSであることを前提としています。
最近の技術はHTTPSを前提に実装されています。
導入するまでのロードマップ
組織内での協力を得る
組織内で実践する場合はあらかじめ完全HTTPS化を宣言するなどして、多くの方の協力を得ることが重要です。なぜなら、完全HTTPS化は単純にURLが"HTTP://“から"HTTPS://"に変更されるだけではなく、コードの修正やユーザー体験の変化、壊れている箇所がないかのチェックなど様々な影響を及ぼす可能性があるためです。
トップダウンで、意識共有していかなければいけない問題です。
意思決定者が、なんのためにHTTPS化するのかを社内に浸透させて取り組まなければならないが、その意思統一が難しそう。
証明書の選び方
Webサービスに置けるHTTPS(TLS)通信には適切な公開証明書が必要です。「適切な」というのは、主に以下の要件を満たすことを指します。
・多くのブラウザが信頼する認証局から署名されている
・示したい情報を含められる認証方式が使われている
・安全な署名アルゴリズムが利用されている
公開鍵証明書は、HTTPS(TLS)を再構築する上で非常に重要な要素です。証明書そのものは検索エンジンで「SSLサーバー証明書」などと検索すれば販売しているサービスを多く見つけることができますが、それぞれの証明書が一体どういう特徴、意味を持つのかを押さえた上で利用する証明書を決めましょう。
証明書の選び方でのポイントは、箇条書きにすると下記の通り
- ブラウザ対応率
- 有償無償のどちらか
- 認証方式について
- 署名アルゴリズム
最後に
自分はインフラの部分の知識が弱く、本特集の後半部分のリリース後の運用、影響の部分は まだ、文章にして書き残さなくてもいいかなーと思っています。
必要な時期がきたら、本棚からこの号を引っ張ってきて見返します。
