HTTPでアクセスするWEBページは危険？

HTTPとHTTPSの違い

インターネットを介してWEBページを見るための通信方法（プロトコル）は、大きく分けて2つあります。WEBという仕組みが始まった当初から存在するプロトコル「HTTP（Hyper-Text Transport Protocol）」と、より安全性の高い通信を実現するプロトコル「HTTPS（Hyper-Text Transfer Protocol Secure）」です。

HTTPSの安全性を担保するポイントは「暗号化」と「認証」。HTTPの通信がすべて「平文」、つまり何も暗号化されていないのに対し、HTTPSでの通信はすべて「SSL」というプロトコルを利用して暗号化されます。

ネットワークを流れているパケット（データのかたまり）を覗き見ると、HTTPの場合、どういうリクエストを送ってどういうWEBページや画像、動画、ファイルを取得しているのかが丸わかりですが、HTTPSだと、どのIPアドレスのホストに通信しているかくらいしかわかりません。

さらに、HTTPSで通信すると、サファリなどではURL欄の左端にどのサイトにアクセスしているかが表示されます（図1）。これはWEBサーバから送られてきたサーバの証明書を検証したうえで、そのサーバが指定したWEBサイトのサーバであることを確認し、その結果を表示しています。これが「（サーバの）認証」です。

常時SSLとは？

これまで、通常のWEBページはHTTPで通信し、パスワードやクレジットカード番号など大事な情報を扱うときには、HTTPSを使うのが一般的でした。

SSLの処理はCPUに負荷がかかります。インターネットの黎明期の2000年前後のサーバでは、多数のクライアントから送られてくる大量のSSLの処理をさばくのは困難でした。そのため「大事なところだけ安全にする」という考えになったわけです。

「常時SSL」は、そうした考え方を改め、HTTPを一切使わずすべてのWEBページをHTTPS化しよう、というセキュリティ手法です。公衆無線LANのように、見知らぬ第三者と同じネットワークを共有する機会が増えている昨今、HTTPを使っていると、ふとしたことからその人のプライバシーが漏れかねません。

HTTPで通信する場合、相手のWEBサーバは認証されていないので、送られてきたHTMLを盗聴されたり、ページを改ざんされ本来とは異なるリンクを踏まされてれてしまう可能性があります。HTTPで通信される情報は漏洩しやすく、信用もしがたいのです。

すべてをHTTPSにしてしまえば、こうした問題は起きません。2000年代に比べ今のサーバの性能やネットの帯域は桁違いに増大しており、今なら常時SSLでもサーバに問題はありません。

広がる常時SSL

すでにアップル、グーグル、マイクロソフト、アマゾンといった著名な企業のWEBサイトは、すべて常時SSL化されています。こうしたWEBサイトでは、HTTPでアクセスしても自動的にHTTPSに切り替わるようになっており、利用者が気にする必要はありません。

またiOS 9より「Apple Transport Security」 が導入されたことで、2016年末以降、すべてのアプリはWEBにアクセスする際にHTTPSを使わなければならない旨がアナウンスされています。

さらに、主だったブラウザでは、まだ常時SSLになっていない、従来のHTTP通信のWEBサイトの場合「保護されていません」などの表示が出るようになっています。知らず知らずの間に、ネットのほとんどは「常時SSL」が前提となっているのです。

HTTPSで通信するためには、WEBサーバの証明書が必要です。サーバ証明書は「認証局（CA＝Certification Authority）」と呼ばれる機関に依頼して発行してもらいます。ベリサイン、シマンテック、ジオトラストなどがよく知られたCAになります。こうしたCAから証明書を発行してもらうには、大なり小なりお金がかかります。独自ドメインの個人サイトでは大変です。

そこで、「レッツ・エンクリプト（Let's Encrypt）」という組織が無償で証明書を発行する仕組みを提供し始めました。まだ開発者や高度な技術者向けで導入手順が難しいのですが、将来的にはこうした非商用向けのサーバ証明書の発行サービスも提供されていくものと見込めます。

仕事で困る「自己署名証明書」

HTTPSが安全な理由は、SSLによる通信の暗号化と、サーバから送られてくるサーバ証明書が電子署名によって改ざんされていないことを確認できる、という２点にあります。ところが、サーバから遅られてくる証明書が正当なCAから電子署名されてないこともあります。たとえば、NASやブロードバンドルータのWEBブラウザを使った設定画面では、その機器が自動生成したサーバ証明書に、これまた自分自身で電子署名を行って送付してきます。このような証明書を自己署名証明書と呼びますが、常時SSLで強化されたブラウザのセキュリティと相性が悪いのです（図2）。

では、正しい電子署名を入れればいいの？となりますが、こうした機器はどういったIPアドレス、どういったホスト名で運用されるかが、設定されるまでわかりません。電子署名はホスト名ごとに生成される必要があるので、運用先でセットアップが終わるまでは証明することができないというわけです。レッツ・エンクリプトなども「インターネットに接続されていて、定期的に通信ができる」ことを前提に発行した相手を確認しているので、こうしたイントラネットに送られる機器には使いにくいのです。常時SSLの流れの中で、こうした自己署名証明書を許可しづらくするように、各社ブラウザとも許可の手順が複雑化しています。困ったことですが、現時点では効果的な解決策はありません。

常時SSLは、ほとんどのインターネットのユーザにとっては利便性を損なわず安全性を向上させるいい方法ですが、そのためにWEBサーバの運用者やネットワーク管理者は、それぞれ課題を持つようにもなっているというのが現状です。