エントリータイトルはやや挑発的でなんだか恐縮ですが、ネイヴルがそれだけセキュリティに対して配慮し時間とコストをかけていること、そして、一般的にNPO法人が世に啓発と警鐘を鳴らすことはとても大事なことだ(と云われてるような気がする)、と言い聞かせてのことです。ちょっとだけ後悔しながらの公開です。
スマホ全盛期にあって個人的なコミュニケーションのやりとりが流出したりなど、セキュリティについての意識向上がとても大切だと痛感します。データベース上に多くの個人情報を抱え込んでいる企業さんの、特にサーバー管理者のみなさんはいつトラブルに巻き込まれるかひやひやの毎日ではないでしょうか。訴訟リスクを抱えるということはそれだけセキュリティにかけるコストも跳ね上がるわけですが、サーバーなんかは蓋を開けてみるとただの対策ミスや時代遅れだったりすることがあり、そうした情報に注視することに精神力をそがれることのほうがもしかしたら多いかもです。
すでにこれをご覧のみなさんのブラウザのアドレス欄にはカギアイコンが表示されていることかと思います。
念のためSSL対応したアドレスも貼っておきますね。[http://」が「https://」になっています。
Google社「今後SSLに対応したサイトのインデックス化を優先する」
インデックス化という難しい言葉が出てきましたが、みなさんが普段利用するGoogle検索の結果に表示される順番のあれです。あれを高くしたいのはWebサイトを作ったことがある人なら誰でもそう願うところですが、SEOという職能(といっていいでしょう)があるように掲載順位を上げるためのサイト最適化は2016年では標準装備であって当然の風潮となっています。実はネイヴルは、実施している事業そのものが地元地域に絞り込んで、かつ、ニッチなところをターゲットとしているのでこの順位にはさほど注力していません。いませんが、気にはなるのでそれなりに分析はしています。
分析の話はさておきまして、上のようにサイトへの通信の暗号化を優先するとGoogle社がいうならば世界中のサイト管理者で、中でも自らコンテンツを発信することで生業としているかたたちはこれを見過ごすわけにはいきません。ただ、このSSLという通信の暗号化、これ自体は認証局より正規証明書をだいたいは年単位で購入する必要があり、また、これを組み込むためにはいくつかの条件が必要です。証明証も松竹梅がございますので、ネイヴルさんは以前から思いついたら梅で公開してたりしていました。
そもそもホームページは暗号化されていなければいけないのか?
暗号化されていないのはもってのほかだ!なんてことはありえません。個人が、まあ、どれだけ個人情報を出しながらということもありますが、隠す必要が無い日記などのサイトに暗号化を要求するのはいくらなんでも無茶っぽいです。ただ、最近はなにげないホームページもJavascriptなど文字データを送る以外に閲覧者の端末に処理(アニメーションや各種計算)を要求するケースが増えてきています。セキュリティを高めるためにはこれすらオフにしようという動きが高まってきていますがまあこれはさておいて、個人ですらそうしたケースが今後増加してくることも想定してのSSL推奨なんでしょうね、きっと。広告の処理なんかにも影響しているはずです。
とはいえ、普段息を吐くように利用するSNSなどログインが要求されパスワードを入れる場合やネットショッピング、バンキングにはSSLはあって当たり前のもので、こういうところのコストを省くのは言語道断です。もっといえば、サイトのお問い合わせのメール送信フォーム、あれもSSL化されていなければならないでしょう。
ネイヴルのサーバー上では具体的に何がなされたのか
以前のエントリーで「サーバーメンテナンスを実施しました」という記事がありますが、今回はあの続編でSSLを導入したことの報告です。具体的になにをどうしたのかということはサーバー管理者はあまり語りたがらない理由も以前そこで説明しました。書いても一般的にはよくわからないことも多いと思うので、今回前置きを長くしております。実はこうしたサーバー管理は趣味の世界としても通用するくらいハマる要素があります。サーバーを日本では隠語で「鯖(さば)」などとされることもあり、その管理者は「鯖缶」などと美味しそうな呼ばれ方をされたりします。趣味性の高さがこれで伝わるとうれしいものです。最近ではルータが高度化したことも有り、量販店に駆け込めものの5分でNASも用意できるほど各ご家庭に一台は鯖あり状態なのでございます。
さて、SSLを導入するということは、逆に背中に荷物を背負い込むことになるわけです。そのわけはセキュリティ上の対策項目が増えるからです。これも以前のエントリーでしゃべりましたが、長期間世界中で見つかってこなかったSSLに「Heartbleed」という欠陥が見つかり一時期パニックになっていました。もう数年前のことです。その後、堰を切ったようにSSLにはさまざまな穴が見つかることになるとは、10年前の鯖缶には想像もつかないのでは。
SSLの導入そのものは基本的に一方通行の作業です。順序良く組み込んでいけば間違いは発生しないでしょう。レンタルサーバーなどでも、一時期までは独自証明書すら持ち込めないことがほとんどでしたが、現在ではSSLの導入について詳細な解説ページを用意していることがほとんどです。
では、具体的に何をしたのか?
一番気をつけていたのは、SSLを導入した段階ですでにセキュリティホールを開けてしまうことです。そのため、数日かけてゆっくり設定していくなどと悠長なことはできません。この穴を短時間でどう埋めるかがポイントになります。SSLが導入されたサーバーのセキュリティ状態を視覚化して判定してくれるSSL Server Test (Powered by Qualys SSL Labs)というとても便利なサービスがあります。
ネイヴルのサイトの判定を設定ファイルを書き戻しながら順番にお見せするとこんな感じで、SSLを導入した”だけ”の吊るしの状態で「C」判定です。
This server is vulnerable to the POODLE attack. If possible, disable SSL 3 to mitigate. Grade capped to C.
This server supports weak Diffie-Hellman (DH) key exchange parameters. Grade capped to B.
The server does not support Forward Secrecy with the reference browsers.
有名な「POODLEアタック=SSL 3.0の脆弱性」の影響を受けるのでSSL3.0をとめます。
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
設定ファイルを上のようにしてからNGINXをリスタート。これで下の状態になります。
B判定になりました。次は「TLS における Diffie-Hellman 鍵交換の脆弱性」、通称「Logjamアタック」へ対策します。
Cipher Suites対応
NGINXのconfファイルへ記述。
ssl_ciphers ‘ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA’;
ssl_prefer_server_ciphers on;
DH parametersを設定(事前に.pem作成)
ssl_dhparam {path to dhparams.pem}
NGINXをリスタートで以下のA判定に。
その他、ゴソゴソとありますがこのへんで。
最終的にはA+判定です。
本件に関して参考にさせていただいた大変貴重な情報をサイトで公開されている方が多数見えますので謹んでご紹介させていただきます。
Guide to Deploying Diffie-Hellman for TLS
NginxでHTTPS:ゼロから始めてSSLの評価をA+にするまで Part 2 – 設定、Ciphersuite、パフォーマンス
Weak Diffie-Hellman and the Logjam Attack
中身はこんな感じです。セキュリティ上の理由で少しだけマスクしています。
とにかく自分たちの声を聞いてほしいけれど現実には裏腹にも届かないことも・・・
今回、ネイヴルがどうしてSSL導入に踏み切ったのか。
・もともとSSLを含めたWeb上での通信の暗号化に多少なりとも見識があった
・サイト閲覧者のセキュリティリスクが異常に高まってきた
・NPO界隈のITリテラシー向上と啓発のため
などなどありますが、やはり一番はこれです。
ネイヴルにとって、伝えたい、聞いてほしい想いがあるからこそ手間をかけコストをかけWebサイトを公開している。
だからこそ、見ていただくかたにとってのセキュリティ上の安心感は大切だ。
発信するだけでなく、もちろん見ているかたからのフィードバックも受信したい。
ネイヴル代表の髙村(たかむら)です。
個人ブログ「takamura.jp」やSNSでも情報発信しています。
1 comment for “稲沢市で(愛知県でも)NPO法人として唯一(おそらく)、サイトすべてをSSL通信暗号化に対応させました。”