Webサイトの常時SSL対応は必須になる

記事内容

常時SSL対応を通してWebサイトを取り巻く世の中の流れを扱うと言いましても、Webサイト運営者であれば十分にご存知の内容か、または既に対応済かもしれません。時勢に遅れているかもしれませんが自ら経験して得た知識をコラム記事にします。

但し、ハウツー情報を扱った内容ではありません。具体的な情報になるほど環境によって様々となりますので、今回は「常時SSLとはどういうことか？どうして対応を急ぐ必要があるのか？」といった概要的な内容を扱います。

まず「常時SSL」について振り返ってみましょう。常時SSLとは、Webサイトの全てのページをHTTPS^[1]化するセキュリティ手法です。HTTPS化するとWebサイトは「https://」で始まるURLに変わります。

従来のインターネット（狭義では WWW： World Wide Web）の通信においては、HTML等のコンテンツをWebブラウザとWebサーバーの間で送受信する為の通信プロトコルとしてHTTP（Hypertext Transfer Protocol）を用いてきました。HTTPSはSSL/TLS^[2]プロトコルによって提供されるセキュアな接続の上でHTTP通信を行うこと指します。

常時SSL対応を行う目的は、Webサイト全体の通信をSSL/TLSで暗号化することで第三者による通信内容の盗聴や改ざんを防ぎ、また通信相手（接続するWebサーバー）の「なりすまし」といった行為を防ぎます。

従来のSSL対応は個人情報を含むページ（パスワードやカード番号を入力するフォーム等）に限られていましたが、常時SSL対応により全てのページが暗号化されることで、より安全になるとされています。例えば公共のWi-Fi環境では、自宅や会社やスマホでの通信よりも簡単に内容を傍受されてしまうので、通信の暗号化はより重要になります。

それではWebサイトをSSL対応してHTTPS化するには、どのようなことが必要になるのでしょうか。大きくは３点が挙げられます。

• SSL/TLSサーバー証明書の準備（購入）
• SSL/TLSサーバー証明書をWebサーバーにインストール
• Webサイトコンテンツ（ソースコード）の変更

それぞれ具体的には環境によって異なるので、今回の記事では踏み込みません。ただ、少しだけ補足しますと、SSL/TLSサーバー証明書には種類があり、価格や信頼度等の違いがあるのでWebサイトの用途に合わせた選定が必要になります。またソースコードの変更については「https」用のパス情報に置き換える等が想定されます。

このように、セキュリティ対策の観点から常時SSL対応の重要性が高まっていることは確かです。とは言え、世の中が「早急な常時SSL対応」の流れにあり、特に今年に入ってからは「喫緊の課題」のように扱われ、Webサイト運営者が常時SSL対応に踏み切る動機はセキュリティ対策よりも別の理由が大きいと考えられます。

Googleが「常時SSL」の推奨を公式発表しているように、ブラウザベンダーによる後押しが背景にあります。具体的にはWebブラウザの仕様変更です。

WebブラウザのトップシェアはGoogleの「Chrome」（クローム）になりますが、Chrome 68（2018年7月）から、全てのHTTPサイトに対して「保護されていない通信」と表示されるようになりました（アドレスバー部分に）。実際の表示は下図のようになります（Chrome 69による表示です）。

このようにHTTPSサイトでないと警告対象になります。今のところはインフォメーション調の表示ですが、Chrome 70（2018年10月）からは文字色が赤に変わり、アイコンも警告を現わす形状に変わる等、より強い警告がなされます。

Webサイトの利用者（訪問者）側でこのように見られているにもかかわらず、運営側がHTTPサイトのまま提供し続けていては「我が社のWebサイトは安全ではありません」と言っているようなものです。商用サイトであれば「死活問題」になります。

Webサイトの運営者はHTTPS化（つまり常時SSL対応）を進めることがWebサイトの安全性をアピールすることになり、利用者（顧客）からの信頼を高め、ひいては新規顧客の獲得や売上向上にも繋がるので早急な対応を目指すことになるのです。

常時SSL対応（HTTPS化）を推奨する流れはGoogle以外のベンダーも追随しており、MozillaのWebブラウザである「Firefox」では、新機能はHTTPSサイトのみサポートする方向性を表明しています。業界団体の動向からも、いずれ常時SSLは業界標準になると目されています。これらのような時勢を踏まえて当サイトも常時SSL対応を実施いたしました。

なお、前述のようにWebサーバーにSSL/TLSサーバー証明書をインストールしただけでは不便な事態に陥りますので補足します。Google Chromeでの具体例として、（同じサイトに対して）利用者が「https://」から始まるURLで接続した場合は鍵アイコン表示（保護された通信）となりますが、「http://」から始まるURLで接続した場合は「保護されていない通信」となってしまいます。

利用者側に「https://」で始まるURLで接続して貰うことを周知するにも限界があります。現実解としてはWebサーバー側で転送処理（301リダイレクト^[3]）の設定を行うことで解決を図ります。これによって旧URLへの接続要求時に新URLへ転送して自動的に接続させることができます。

このように利用者側に意識させることなく、HTTPS化されたWebサイトに接続して貰うようにできる訳ですが、今までいろいろなところに記載したであろう旧URLの情報は放置しないで新URLに修正するべきでしょう。URLを見るだけで常時SSL対応（安全なサイト）だと判りますし、セキュリティ意識が高いことを印象付けられます。

とは言え、修正対象はWeb上のURL情報だけとは限らないでしょう。Webサイトへの導線としてQRコードを利用していたら再作成して差し替えたり、名刺等の印刷物に記載していたら修正して再印刷が必要になる場合もあるでしょう。

意外と広範囲に影響が及ぶ場合もあると思いますが、自動転送が行われるようにしておけば後から対応していくこともできます。また、過去の印刷物は既に差し替えができない場合もあるでしょうから、自動転送は一層有効かもしれませんね。

当方もWebブラウザに「保護されていない通信」と表示されないようにする対処を先に済ませておき、新URL情報の周知は後追いで対応しようとしているところです。

補足（2022/6/23追記）

Chromeブラウザでの表示について、コラム記事の執筆時点では予定の情報を扱っていました。その後、Chrome 102での表示においても予定とは異なっているようです。

具体的には「 保護されていない通信」と表示されますが、文字色は赤色ではなく黒色表示止まりとなっています。