バイトル常時HTTPS化完了
今年ももう終わりに近づいていますがバイトルもようやく先月、常時HTTPS化が完了しました。
そのためAdvent Calendarのタイミングに合わせ改めてご報告させていただきます。
それより皆さんHTTPS化何て呼んでます？
・常時HTTPS化
・常時SSL化
・完全HTTPS化
・フルHTTPS化
・フルSSL化
はじめは、フルHTTPS化などの呼び名で広まっていったのですがディップでは最終的に呼びやすさから
「フルSSL化」に落ち着いてしまったように見えます。
多分これはどこの会社でも呼び方は違うんだろうなーと思います。
なのでこれ以降は「フルSSL化」で記載させて頂来ますのでご了承ください。
フルSSL化のタイミングについて
フルSSL化については昨年ぐらいからどんどんと騒がれており、HTTP Archiveが公表している、HTTPSでの通信を表すグラフ HTTPS Requests では、2017年11月15日時点では**56%**とついに半分を超えておりました。
バイトルもこの流れに乗ってフルSSL化を進めよう！という話は出ていたのですが、すでにこの時バイトルのリニューアル案件が進んでおりました。
リニューアルのタイミングで一緒にフルSSLの導入を行えばとかったのですが、以下の理由でリニューアル後に行うという計画になりました。
- SEOのセオリーとして「いろんな変更を一気にしない」方が良い
- サイトの順位や自然検索流入に影響があった場合、問題の切り分けがややこしくなる
- アプリケーション側の不具合の影響がフルSSL化によるものなのかどうかの切り分けがややこしくなる
- フルSSL化も入れてしまうとその分工数も増える
フルSSL化で苦労した点
フルSSL化のプロジェクトが始まり期間としては2017年9月頃～2017年11月頃と結果的に約2か月半でフルSSL化が完了しました。
その中でいくつか苦労した点をご紹介したいと思います。
1.フルSSL化への各チームの理解
組織内への認識
いくつかの記事で書かれていますが、フルSSL化するに当たっては
・広告
・SEO
・アプリチーム
・グロースハック
・マーケ
と様々なチームとの協力が必要になってきます。
さらには各チームによってhttps化するにあたっての観点も違います。
そのためまず
・フルSSL化とは何ぞや
・フルSSL化する事で何が変わるのか
・利益はでるのか
・メリットデメリットは
・移行時にHTTP/HTTPS混在期間にする意味は何なのか
・移行時にHTTP/HTTPS混在期間を設けても不具合やSEOに問題はないのか
・SEOはあがるのかさがるのか
など各チームへの様々な理解が必要になってきます。
インフラエンジニアの方はよく分かると思いますが、リニューアル案件や機能追加などと比べると、HTTPS化など表上あまり変化のない裏方の仕事は後回しにされたり理解されないことが多いです。
エンジニア以外にも、正しく必要性・重要性を伝えることはとても大切なことだと今回思いました。
そもそもGoogleがHTTPSをSEOで優遇したり、今年の10月からはChrome62がHTTPのページに対してセキュリティ警告を発するようになったりなど流れはどんどんとHTTPS化へと進んでいます。
しかしHTTPS化する事ですぐに利益や恩恵が受けれるかというとそうではありません。
###フルSSL化の懸念点
SEOに関しても、フルSSLはURLの変更になるので、大規模サイトの場合は一時的に多少なりとも順位が下がることは可能性としてありうるという事(一時的に下がっても最終的には元に戻ります)なのでまずはそれをSEOチームに理解してもらわないと一時的にでもSEOが下がるからフルSSL化をしたくないと言われてしまうとフルSSL化のSEOの優遇も受けれなくなってしまいます。
さらに安全性を規すためHTTP/HTTPSの混在期間を設けました。
理由は開発環境での確認が取れても、いざ本番環境上でフルSSL化をしたときすべての機能が動くかどうかを確認するためです。
そのため混在期間はユーザからのアクセスは今まで通りHTTPアクセス(一部ログインや応募ページなどはHTTPS)で
弊社からのページ確認のためのアクセスはhttpsのアクセスで確認を行い、ページの表示やMixedContentsなど問題ないことが確認できてからhttp⇒httpsのリダイレクト設定を入れました。
2.Mixed contents
前述のhttpsの確認に伴いCSPでのMixedContensの確認を行いました。
MixedContentsについては大きく2つの種類があります。
Active Mixed Content
概要：
HTTPSで配信されているHTMLに埋め込まれたJavaScript, CSSや、XMLによるリクエストがHTTPのときに発生するもの
影響：
Webブラウザによりブロックされ、表示されなくなったり画面が崩れたりする
現象：
※右側に警告表示が出る
Passive Mixed Content
概要：
HTTPSで配信されているHTMLに埋め込まれた画像や動画によるリクエストがHTTPのときに発生するもの
影響：
ブロックはされないが安全なサイトであるという表示がなくなって安全ではないサイトという表示になる
現象：
※左側の「保護された通信」が消えiマークになる。
###CSP
これら全てを手作業で確認するには限度があります。
そのためCSP(Content Security Policy)を使用してMixed Contentsを見つける必要が有ります。
CSPとは
CSPとは、クロスサイトスクリプティング (XSS) やデータを差し込む攻撃などといった、特定の種類の攻撃を検知し、影響を軽減するために追加できるセキュリティレイヤーです。これらの攻撃はデータの窃取からサイトの改ざん、マルウェアの拡散に至るまで、様々な目的に用いられます。
CSPはHTTPヘッダーを1行返すだけで有効にすることができ、最近のブラウザならばまず対応しています。Report-Onlyにすればユーザーに悪影響はないので安心して付けることができます。
フルHTTP化とどのような関係があるのか
指定方法によってmixed contentsの警告に使えるので、今回のようなHTTPで動いているサービスをHTTPSに移行する際にmixed contentsを見つける用途にも使用することができます。
POSTメソッドでJSONのデータが送られるだけなので、そのJSONを保存する適当なシステムがあれば容易に確認できるようになります。
設定方法
Apacheでの設定例
Header always set Content-Security-Policy-Report-Only "default-src https: 'unsafe-inline' 'unsafe-eval'; report-uri http://example.com/csp-report"
ただしMixedContentsの発生要因はコード以外にあることも多いためcsp-reportの内容からどれが本当に修正する必要が有るものかなどポリシーの設定見直しや地味な確認作業が必要になります。
出力構成
cspreportの出力については report-uri.io という無料のサービスを使うこともできますが、大量のリクエストを送るとうまく出力されなかったりしたため使用するのであれば有料版を使った方がいいかもしれません。
そのためレポートの受信にはAPI-GATEWAYやElasticSearch+Kibanaを使いダッシュボードをコンテンツ制作のチームに提供しMixContents潰しを行っていきました。
まとめ
ということで今回バイトルがフルSSL化を行ったご報告と苦労した点などについてまとめました。
- フルSSL化はユーザが安心してサイトを利用してもらうために必要不可欠な課題である
- フルSSL化を行うには各チームへフルSSL化の必要性を理解してもらいデメリットについても受け入れてもらう必要がある
- MixedContents潰しは地道な作業だが誰かが舵をきってやっていくしかない
また今後フルSSL化を行う方にこの記事が参考になれば幸いです。
他にもフルSSL化に伴いhttp/2を取り入れたことや、CDNサービスを使用しての速度改善などの話もしようと思ったのですが、こちらはまた次回お話ししたいと思います。