Googleの「常時SSL」の推奨とか、Let'sEncryptの発足とか、
常時httpsページ化に対する波が来ているので、
提案する為の材料とか、メリットデメリットとか、対応方法とかまとめてみた。

常時SSLとは

常時SSLとはウェブサイトの全てのページをHTTPS化するセキュリティ手法。多くの大手サイトの対応が増えている（FacebookやTwitter、YouTube、Netflix等）。
httpsに対応していれば、そのサイトが偽物の場合は警告がでるし、通信が暗号化される。

参考サイト

世の中の状況、やった方がいいわけ

https通信により通信が暗号化される

SSL対応によりhttps通信で通信が暗号化される。従来は個人情報を含むページに限られていたが、
常時SSL対応で、全てのページが暗号化されより安全になる。
公共のWifi環境だと、通信の傍受が自宅や携帯回線より簡単にされてしまうので、httpsにより暗号化がより重要になってくる。

参考サイト

常時SSL　| シマンテック

Googleが「常時SSL」の推奨を公式発表した。

HTTPS ページが優先的にインデックスに登録されるようになります
上記にあるように、サイトががHTTPSに対応してあれば、GoogleはHTTPSページとしてインデックスするようになります。HTTPSが使われているページは良いページということでSEO上有利になる可能性があります。

HTTPS をランキングシグナルに使用します
上記でもGoogle のランキングアルゴリズムでのシグナルとして、暗号化された安全な接続をサイトで使用しているかを考慮に入れたテストを実施しているということなので、全てのページをhttps対応にした方が良さそうです。

Let's EncryptによるSSL/TLS証明書の無償化

Let's Encryptという無料でSSL証明書を取得できる取り組みがあります。これで誰でもhttpsページを用意することができるようになっている。

参考サイト

Let's Encrypt 総合ポータル

HTTP Strict Transport Security(HSTS)対応のサイトが増えている。

httpsページ対応したとしても、httpでアクセスされたら意味が無い。
HTTPヘッダにセットすることで、ブラウザがHTTPで接続した際に、強制的にHTTPSへリダイレクトし、以降のそのドメインへの接続はすべてHTTPSとする機能として、HTTP Strict Transport Security(HSTS)がある。既にメジャーブラウザではこの機能に対応しており、
この設定をしているサイトが増えてきている。(Google、Twitter、Facebook等々）

参考サイト

Service Workerを使うためにはhttps対応にする必要がある

Webページとは別にバックグラウンドで実行するJavaScriptとしてService Workerという機能がある。
これでWebでもプッシュ通知の様なことができる。
これを使うためにはページがhttpsであることが必要。

参考サイト

Service Worker の紹介

Firefox DeveloperEditionでは、ログインフォームがhttpだと警告が出る。

ログインフォームがhttpのページだった場合、Firefox DeveloperEditionでは、アドレスバーやコンソールにエラーメッセージが出る。
ログインフォームのPOST先のURLがhttpsであれば、https通信となるが、ログインフォームのURLもhttpsさせることで、ログインフォーム自身が改ざんされていなことが判断できるためらしい。
TOPページにログインフォームが設置されているサイトがあったりするが、その場合はTOPページもhttpsにした方が良いことになるので、それなら常時SSL対応してしまった方が良いのではないか。

参考サイト

Mozillaがブラウザ新機能はHTTPSサイトのみサポート

Mozillaがブラウザ新機能はHTTPSサイトのみサポートとしてきたため、HTTPページでは使えない、正常に動作しない機能が出てくる可能性がある。

参考サイト

ブラウザ新機能はHTTPSサイトのみサポートへ、Mozillaが表明

2017年1月にリリースのChrome 56からhttpページにパスワードの入力フォームがあると警告が表示される。

突然「保護されていません」と警告が!?Chromeの新しい安全性表示にあるようにhttpページ内にパスワードの入力フォームがあると「！」アイコンと「保護されていません」の表示がアドレスバーに表示される。
これを見て不安になる人がいるかもしれない。

２０１７年10月にリリースのChrome 62からhttpページに入力フォームがあると警告が表示される。

サイト内検索にも警告が?Chromeが10月にさらにセキュリティ強化
のサイトによると、10月にリリースのChrome 62から、検索フォームなど、テキストボックスがhttpページに含まれるとアドレスバーに警告が表示される。シークレットモードだとhttpであればテキストボックスがなくても警告が表示される。それほど目立たない警告かもしれないけど、「Not Secure」と出れば不安になるかもしれない。
あと、Cookpad開発者ブログ Web サービスの完全 HTTPS 化にもあるように、検索キーワードにダイエットとか持病とかあまり知られたくない情報を入れる場合があるかもしれないので。

2018 年 7 月に Chrome 68 がリリースされると、すべての HTTP サイトに「保護されていません」と表示される

2018/2/27付の保護されたウェブの普及を目指して
によると
2018 年 7 月に Chrome 68 がリリースされると、すべての HTTP サイトに「保護されていません」と表示されるようになるとのこと。自分のサイトが安全ではありませんと言ってるみたいになってしまうのは良くないので、HTTPS非対応の場合は、ちょっと焦ったほうがよさそう。

Chrome の新しいインターフェースでは、すべての HTTP サイトが保護されているわけではないことがわかりやすくなるため、ウェブをデフォルトで保護された HTTPS に切り替えるよう促す効果があります

ということなので、 GoogleがHTTPS対応していないサイトにいい加減に対応してくれと煽っているのかも。

気をつけること、デメリットなど

SSL/TLS証明書の準備、対応

常時SSL対応にするにはSSL/TLS証明書を準備する必要がある。価格が年間数千円〜十数万円するので
余分にお金がかかってしまう。
Let's Encryptという無料の仕組みもあるが、有効期間は９０日で更新が面倒だし、商用サイトで使うのはどうなのだろうかというところがある。
CDN(Contents Delivery Network)やロードバランサーを導入していれば必要なSSL/TLS証明書が増えてコストがかかってしまう可能性がある。
使用しているツール類がすべてhttps通信に対応しているか確認が必要。

SSL/TLSによるパフォーマンスへの影響

SSL/TLSによる暗号化により、パフォーマンスに影響が出る可能性がある。
SSLアクセラレータ、ロードバランサーの導入で回避することは可能。

HTTP/2やSPDYの対応により、将来的にはhttps通信の方が速くなることが期待できる。

参考サイト

SSL/TLSで暗号化されたことにより、攻撃データも暗号化される。

SSL/TLSで暗号化されることによって、ユーザのデータが暗号されるが。
攻撃者のトラフィックも暗号化されてしまい、IDS/IPSなどのセキュリティ製品での検知が難しくなる。

参考サイト

URLを書き換える手間がいる

相対パスで指定されていれば良いが、
リンク内のURLがhttpになっていたら、httpsに置き換える必要がある。
canonicalが設定されていたらそれも書き換える必要がある。CDNのリンクもhttpsにする必要がある。

参考サイト

常時SSL導入の注意点とSSLページのインデックスまでにかかる時間

Facebookのいいねがリセットされてしまう。

http→httpsと変わっただけでもURLが変わったことになるので、Facebookのいいねはリセットされてしまう。
og:urlに旧　URL（つまり httpのURL）を指定すれば引き継がれるらしいが、ずっと旧URLを指定し続けないといけないかとか気になる。

参考サイト

常時https/SSL化してもFacebook記事の「いいね!」数を引き継ぐ方法

すぐにやったほうがいいのか

~~やれるならやったほうがいいけれど、あわてて急ぐ必要は多分ない。~~
可能ならば、2018年7月ぐらいまでには対応したほうが良さそう。

2018年7月、Chrome68でHTTPサイトに「保護されていません」表示が出るようになる。
保護されたウェブの普及を目指してによるとGoogleはHTTPSの採用を強く働きかけている。
SEO的にはhttpsの方が優位だが、他の要因に比べると微々たるもの。
内部リンクの置き換えは割と手間がかかる、システム側で生成するところだけじゃなく、デザイナーさんが修正している部分とかもちゃんと把握しておく必要がある。ページ数が多いところは長期計画になりそう。

対応方法

SSL証明書を準備する

部分的にでもhttps対応していれば、そのSSL証明書使えば良いので、追加の証明書は不要。CDNを使用していてhttpsに対応していなければ、追加のSSL証明書が必要。CDNサービス側が提供しているSSL証明書を使うのでも良い。

URLを書き換える。

サイト内のhttpになっているところを全てhttpsに書き換える。サイトマップXMLやAtomフィード、canonicalなど漏れがないように。メルマガ等のリンク先の置き換えも忘れずに。

リダイレクトの設定をする。

外部のサイトからリンクされている。古いメルマガのリンクをクリックした、Googleでまだインデックスされていない場合があるので、httpでアクセスされたら、httpsにリダイレクトの設定をする。

HSTS (HTTP Strict Transport Security) の設定

ブラウザ側で次回以降はhttpsで接続するために、httpヘッダー情報にHSTSを設定する。初回アクセス時や、HSTS未対応のブラウザのためにも、リダイレクトの設定と併用で設定する。TwitterやFacebookを参考にする。
これが設定されていれば、リダイレクトする前にブラウザ側でhttpsに切り替えてくれる。IE11でも対応しているので、実際のところリダイレクトはしなくてもいける気はする。

Strict-Transport-Security:max-age=有効期間秒数;includeSubDomains

Apacheの場合

<VirtualHost *:443>
    ServerName example.com
    SSLEngine on
    Header set Strict-Transport-Security "max-age=31536000; includeSubDomains"
</VirtualHost>`

max-ageで指定した期間、設定が有効になってしまうので、もしやめたい場合は、max-age=0にする。

includeSubDomainsを指定しているとサブドメインも対象になる。
サブドメインとは、foo.example.comから見るとabc.foo.example.comに該当する。
bar.example.comはfoo.example.comから見るとサブドメインには該当しない。

参考サイト

HSTS (HTTP Strict Transport Security) の導入
HTTP Strict Transport Security
HSTS をやめる方法

SEO関連、ツール設定

Google Analytics、Search Consoleの設定をhttpsに対応させる。
Search Consoleは、httpとhttps両方設定しておく。

参考サイト

常時SSL化の際に必要なGoogle系ツールの設定

実際やってみて、大変だと思ったところ、気になったところ。

httpで書かれている箇所探し

「混在コンテンツ」(mixed content) の存在

httpsページ中にhttpで参照されてしまう箇所があるかチェック。
httpsページにscriptがhttpで参照されるブロックされて動作しなくなってしまう。
httpsページにimgやcss等がhttpで参照されていたら、ブラウザに警告が表示される。
httpsページにiframeがhttpで参照されていたら、中身が表示されない場合がある。
逆に、httpページでajaxでhttpsのURLと通信しようとすると、クロスドメインと判定されて拒否されてしまうようだ。
HTTPのページからJavaScriptでHTTPSで通信する方法
ページの一部をキャッシュするような設定にしていた場合、その箇所だけがhttpで残ってしまってmixed contentになる可能性がある。切り替え時点はキャッシュしないようにする、もしくは、先にhttpsに置き換えできるなら切り替えておくとか。

サイトの転送

httpでアクセスしてきた場合はhttpsに置き換えてリダイレクトするが、計測用のパラメータも引き継ぐようにする。　http://www.example.com/AAA/BBB?cid=XXX はcid=XXXも引き継いで転送させる。
固定でhttps://www.example.com/AAA/BBB にリダイレクトするとかなっているかもしれないので。
HSTSを導入すると楽。ブラウザでアクセスする場合は２回目のアクセスからは全てhttpsでアクセスされるようになる。主要ブラウザは全て対応しているので(IE11も）。
さらにプリロードHSTSを使っていれば、最初からhttpsでアクセスされるようになる。１回目からhttpsでアクセスできていれば不正な手段でDNS書き換えられていても気付けるか。
クローラーなどはHSTS関係なくアクセスが来たりするので、必要なところはリダイレクトは設置する。

SEOのこと

切り替えることでどのくらい変動する気になるが計測できていない。
httpsに置き換えたサイトマップXMLをpubsubhubbubを使ってすぐ反映されるように促す。
canonicalの設定　が間違っていないか確認。この設定が間違っていると誤ったURLでインデックスされてしまう。ちゃんとhttpsにしているか。
Googleの検索結果がhttpsに切り替わり始めるのは数日かかる。ほぼ切り替わるのは2週間程度だという情報もある。

XML Namespace (xmlns) のURLはhttpsにしてはいけない

<html xmlns="http://www.w3.org/1999/xhtml" >
上記のような、xmlファイルやXHTML形式のファイルに記載のあるURLはhttpsでアクセス出来るが、だからと言ってURLをhttpsに変えると問題が起きるのでやめた方がいいらしい。

xmlファイル内でhttpsを使うと「誤ったネームスペース」とされる
サイトマップのxmlnsを安易にhttpsに変えるとBingは読めない

構造化マークアップ(schema.org)のURLはhttpとhttpsのどちらでも良い

最新のSEO事情！schema.orgで構造化マークアップせよ！


<section itemscope itemtype="http://schema.org/Book">
    <h1>本の情報</h1>
    <span>Ruby入門</span>
    <p>本の説明</p>
    <p>著者名</p>
</section>

上記のようにSEO対策としてHTML内に記載されるschema.orgのURLはhttp://が標準だが、https://も使えるらしい。　あえてhttps://に変える必要はない。

参考になる事例とか

QiitaをHTTPS化しました
QiitaサイトがHTTPS化した話と、httpsとhttps化の影響について。https化すると認証が必要な画像が使えなくなるなど。
pixivを常時HTTPS化するまでの道のり（前編）
pixivの
pixiみたいに大量のコンテンツを抱えていると、切り替えるURLがあって大変。
配信広告タグの対応から、OSの載せ替え、OpenSSLはAES-NI対応にまで及んでいる。
　Cookpad開発者ブログ Web サービスの完全 HTTPS 化
 cookpad.com 全 HTTPS 化の軌跡
Cookpadで１年半ぐらいかけてhttps化した話。
検索キーワードも暗号化して保護すべきデータであるとか、　mixed contentsの潰し方とか、幅広く。
Yahoo! JAPANコーポレートブログ httpをすべて「http"s"」に！　ユーザーの安全を守るAOSSL対応
Yahoo! JAPANのAOSSL対応についての話。
盗聴リスクなどセキュリティについてなど。AOSSL化する必要性について。
激闘! Mixed Contents!! 〜はてなブログHTTPS化への道
はてなブログの常時SSL化対応について、mixedcontens潰しが大変な話。はてなブログだと色んな外部コンテンツを取り込んでいたり、利用者が好きにブログにコンテンツを埋め込めるので、全部なんとかするのは難しい。
AWSではてなブログの常時HTTPS配信をバーンとやる話
はてなブログでは、独自ドメインが使えるので、SSL証明書の発行がそれぞれ必要となってくる。それをLetsEncryptで一括管理するための仕組みづくりの話。発行が失敗するときもあるので、それも考慮するとか。