TLS（https）にしたからといっても、即完全に守られている状態になるわけではない。

脆弱性が報告されている方式を有効にしていたり、サーバーの更新を怠っていたらせっかくサーバー証明書を買ってTLSに対応した意味がなくなってしまう。

セキュリティが強固かどうかはサーバー証明書の値段の高さではない。
値段の高いサーバー証明書とはどういうことか?
それはサイトの所有企業の法的実体などをちゃんと確認して本当にその企業がサーバー証明書を買ったのかどうかを証明している。
サーバー証明書には、企業名などが表示されているのだがそれは基本自己申請になっており、たとえばすごい有名企業の似たドメインを取得して、証明書にその企業名の名前を騙るという詐欺じみた行為ができてしまう。
それを防ぐために、多くの企業向けサーバー証明書では企業の存在確認をしている。
高いサーバー証明書はその信頼性が高い。

ちなみにウチのような個人向けサイトは、このドメインの所有者が僕であるという証明をして払い出されているサーバー証明書になっており安い。

ウェブサイトと閲覧者の間の通信が、第三者に読まれないかどうかということに関してはサーバー証明書の値段ではなく、サーバー管理者の正しい設定にかかっている。
だから、ウチのような安い個人サイトでもちゃんと強固にすることがでできる。

これは今ウチのサイトのセキュリティの強固さを検査した結果。

 

TLSを導入したブロガーならどの程度かしらべてみるといい。
https://www.ssllabs.com/ssltest/index.html

導入しただけでデフォルトの設定のままならば、C程度の可能性がある。
事実、うちのサイトは最初はCだった。

そもそもTLSとは？

そもそもTLSとは何か？
これを導入すると何が良くなるのか？

SSLという言葉も聞くと思う。これはTLSと同じだ。
名称がSSLからTLSに変わったのだが、昔からSSLと使っているからSSLという人もおおい。
イオンになった今もサティやジャスコと呼び続けているようなものだ。

このTLSというのは、公開鍵と言われる暗号の規約だ。

暗号というのは、手紙の内容を他の誰かに見られないように一見無意味なものに置き換えることで、
コンピュータの世界はすべてのデータは数字で処理されているので、数学的に置き換えている。

鍵はその元となる数値データだ。

暗号方式では、データを暗号化するのも復号化(元に戻すこと)のも同じ鍵で行っていた。
1＋3＝4というすごい簡単な計算の場合。
1が本来のデータ、3が鍵、4が暗号化されたデータだとしたら、3がわかれば暗号化も復号化もできる。
ただし3という数値を知られてはならない。
言ってみればパスワードのようなものだ。
これは非常にでかい数値の鍵を使えは非常に強固な暗号になるのだが、以下のようなデメリットがある。

この鍵は予め知って居なければならない。
僕のサイトと訪れる閲覧者の二人のみが知っている鍵を双方最初にもっておかなければならないので
こういう不特定多数見るウェブサイトではこの方式は不向きだ。

それを解決するために編み出されたのが公開鍵方式。その公開鍵方式の規約の一つがTLSだ。
サイトが「この鍵で暗号化してウチにデータ送ってください」と誰にでも公開する。
この公開鍵は暗号化することはできるけれど、暗号化したデータを復号化させることはできない。

復号化できるのは秘密鍵といわれており、サーバー内にのみ存在している。
このサイトの秘密鍵を見られる人間は全世界で僕だけだ。

この秘密鍵で送られてきた暗号化されたデータの中身を見られる。

サーバー証明書とは公開鍵が本当にこのドメインの持ち主が提供しているものかを証明しているものだ。
ベリサインやジオトラストなどそういう企業が証明書を発行しており、この発行しているところを認証局という。
認証局が発行している証明書は各ブラウザにもともと組み込まれており、認証局によって払い出されたという証が各サイトのサーバー証明書に署名されている。
このサーバー証明書には公開鍵が含まれているので、閲覧者は『権威ある認証局にドメインの持ち主と証明された正しい公開鍵』ということがわかるわけだ。

これらのチェックに引っかかるとブラウザはそのサイトを開かないようにする。

この公開鍵を使って、共通鍵を交換して暗号化してデータをやり取りする準備が整う。

これで、このウェブサーバーと閲覧者のブラウザの間は完全に秘匿され、
プロバイダも会社のファイアウォールも政府もどんなデータがやり取りされているか見ることができない。

 

セキュリティを強固にする

このようなTLSの方式でも、セキュリティリスクはある。
たとえば鍵の長さ。
鍵は数値データになっており、その数値が大きい数であれば解析に必要なパターンが膨大になるので非常に強固になる。
昔は今より鍵長は短かった。
昔のコンピュータは性能が低かったので、それほど長くなくても解析が困難だったからだが、今の時代だと問題がある。

ほかには暗号化の方式に欠陥があった場合がある。
つまり突破する方法がバレたものがある。
こういったものは無効化すべきだが、古い設定のままだと有効になっていたりする。

暗号化するソフトウェアに重大なバグがあったこともある。
このバグのおかげで秘密鍵が漏洩する危険があった。
すぐさまソフトウェアは修正されたが、サーバーがそのアップデートをしなかったらもう暗号化は意味をなさなくなる。

ただTLSにしただけでなく、こういったポイントをチェックしなければならない。

ちなみに設定方法などはCentOS Apacheを対象に書いているので、他の環境の場合はググってほしい。

SHA-1はやめよう

ここ数年証明書を買った人はあまり気にしなくて良いかもしれない。
SHA-1というハッシュ関数は生成される値が短くて、そこが攻撃の足がかりになりうるので、いまはSHA-2という方式に切り替わっている。
そろそろSHA-1で署名された証明書はもう払い出されていないけれども、もし持っているならば証明書を変えよう。
はてなブックマークのログインページはSHA-1なので、すでにブラウザで鍵マークがみれなくなっている。

SSLv3はやめよう

TLSはバージョンがある。
SSLはv3まで、TLSは1.0から1.2までが今あるバージョン。

SSLv3まではもう古いので、無効化しなければならない。

SSLv3は2014年にすでに暗号解読する方法がわかってしまった。
POODLEという手法なのだが、もしSSLv3で通信をした場合盗聴される恐れがある。

今は主要なブラウザも基本的に無効になっている。
ただ、互換性を残すためその機能はまだまだ残っている。
やむにやまれぬ事情以外は無効にしなければならない。

自分のCentOS6環境だと、デフォルトでSSLv3が有効になっていたので、ちゃんと確認しよう。

https://access.redhat.com/ja/node/1232613

↑ここで詳しい設定ができる。

RC4は無効にしよう

RC4とは暗号アルゴリズムの一つだ。
TLSでも使われている。

このアルゴリズムは、解読が実現可能なレベルだと報告されている。
よってこの方式はもう使うべきではない。

httpd.conf もしくは conf.d/ssl.conf の中に
SSLCipherSuite  という設定項目があるので、!RC という文字を追加しよう。
!マークは無効にするという意味だ。

SSLCipherSuite DEFAULT:!EXP:!SSLv2:!DES:!IDEA:!SEED:+3DES:!RC4:+ECDH

ただ、これについてはもう少し良い方法を提供しようと思う。

このSSLCipherSuiteの項目は、どの暗号アルゴリズムを使うか、何を使わないかを設定する項目だ。
非推奨のものを無効にするだけではなく、推奨されているものを有効化したい。

しかし、ApacheやOpenSSLのバージョンで使えるものに差がでてくる。
何ができるのかが持っているサーバーの環境によって変わってくるのだ。

何が一番いい設定なのか、ここで自動で決められる。

https://mozilla.github.io/server-side-tls/ssl-config-generator/

httpサーバーとOpenSSLのバージョンを指定すると、その中でも最もおすすめの設定を教えてくれる。

画像には写っていないけれが、SSLCipherSuiteの設定も載っており、
非推奨はOFFに推奨はONになり、より強固な設定できる。

たとえばForward Secrecyといわれる、秘密鍵が漏洩されてもそれまでに通信していた過去の通信が解読されないようにする仕組み。
DHEやECDHEなどの方式がいま実用化されている。
DHEはディフィー・ヘルマン鍵共有
ECDHEは楕円曲線ディフィー・ヘルマン鍵共有

このようないま推奨されている方式もこのサイトでは有効化する設定をしらせてくれる。

 

サーバーのセキュリティパッチは絶対忘れてはならない

2年前、OpenSSLに致命的なバグが混入した。
心臓出血を意味する、Heartbleedと呼ばれているバグで、門外不出の秘密鍵が漏洩する恐れのある非常に重大なバグだ。

当時は大々的にニュースになり、そして警視庁から注意喚起も出たほどだった。

セキュリティパッチはすぐに提供された。
実際の攻撃が流行る前には誰もが修正できる状況だった。

しかし、世の中には困った信仰がある。
安定しているサーバーやソフトウェアは何も追加変更しないほうが安全という神話だ。

その変更を避ける道を選ぶのもいいだろう。
本当に停止不可能、再起動不可能で、代わりのサーバーもないシビアな環境で動いている場合もある。
その場合は、手動でパッチを当てる必要がある。だが非常にめんどくさい。
その道を選び本当に脆弱性をちゃんと対応しているサーバーももちろんたくさんある。
その信仰を正しく信じて、正しくリスクに向き合っている。
一方で神話を盲信して何もしない場合も悲しいかな存在するのも事実だ。

RHELはサーバー向けだから、他のディストロのように不用意にバージョンを上げることはない。
多くのソフトウェアは古いバージョンでセキュリティパッチを当てていくようになっている。
たまに新機能が加わるバージョンアップもある。

特別に考慮する事情なくバージョンアップをしない運用にするならば、検証環境用意して積極的にyum updateして行ってほしい。
盲信はやめてほしい。

話がそれたが、そのハートブリードと言われるバグはサーバーをちゃんと管理していたらもう駆逐されているはずのバグなのだが、
神話を盲信して何もしていない場合はこのバグが放置されている可能性がある。

これがあった場合は、チェッカーサイトではランクはFになる。

どんなに素晴らしい暗号方式をやっていても、一発アウトでFだ。

この手の脆弱性は時たま報告される。
ニュースをよく読み、必要とされている対応をすぐに行わなければならない。

まとめ

他にもチェックポイントはあるけれども、いまTLSを導入する場合はあまり考慮せずともサーバーの設定値がいい状態になっている。

ただ、insecureという赤字が表示された場合は、適宜対応して問題を取り除いてほしい。

だいたいこれくらいやればA+に簡単になる。