お久しぶりです。ビジネス開発部の神谷です。
みなさん、Webサイトの暗号化はされていますか?ユーザーが安全に通信を行ったり、個人情報の盗難を防ぐためには必須ですね。 また、暗号化しているWebサイトはGoogleの検索で上位に表示されたりと、SEO対策という観点でも注目を浴びています。
今回は、そんな暗号化に使われる「SSL/TLS」について書いていきたいと思います。
SSL/TLSとは
- SSL(Secure Sockets Layer)
- TLS(Transport Layer Security)
上記2つはどちらも、クライアント <-> サーバー間の通信を暗号化する技術です。 TLSはSSLを元にして定められたプロトコルであるため、名称は違いますが技術的には同じものを指しています。
ご存知の方がほとんどだと思いますが、HTTP通信をセキュアに行うためのプロトコルであるHTTPSは、SSL/TLSが使用されています。
SSL/TLSの歴史
2017年12月現在の最新バージョンはTLS 1.2となります。 更に暗号強度を高めたTLS 1.3も現在策定中であり、2017年7月3日にドラフト仕様のバージョン21が標準化団体IETFによって公開されています。
名称 | 年 | 補足 |
---|---|---|
SSL1.0 | - | プロトコルの設計レビュー時に深刻な脆弱性が発見され、実装されることなく破棄 |
SSL2.0 | 1995 | 脆弱なアルゴリズムが使用可能なダウングレード攻撃を受ける恐れあり。2011年3月、RFC 6176 によって使用を禁止された |
SSL3.0 | 1996 | 通信の一部を解読可能な「POODLE」という脆弱性あり。2015年6月、RFC 7568によって使用を禁止された |
TLS1.0 | 1999 | SSL3.0と同じく、「POODLE」の対象。PCI SSCではTLS 1.0は非推奨とされている |
TLS1.1 | 2006 | SSL3.0と同じく、「POODLE」の対象。共通鍵暗号アルゴリズムにAESが追加されている |
TLS1.2 | 2008 | ハッシュのアルゴリズムにSHA-256が追加、認証付き暗号を用いたcipher suiteが利用可能に |
TLS1.3 | - | 現在策定中。TLS1.2に比べ、ハンドシェイクの効率化・暗号強度の向上が見込まれる |
▲SSL/TLSのバージョン表
上記の表の通り現在までに様々なバージョンがリリースされていますが、SSLはRFCによってすべて使用を禁止されています。 ですが、一般的にサーバー証明書のことは「SSLサーバー証明書」と呼び、「TLSサーバー証明書」という言葉を聞いたことがない人がほとんどではないでしょうか。 実態はTLSでも用語として「SSL」が普及しているため、まだまだ表記上は「SSL」が使われる傾向にあります。
TLS1.2に移行しましょう
さて、SSLがRFCによって使用が禁止されていることは記載した通りですが、TLSはどうでしょうか。
クレジットカード業界における国際セキュリティ基準であるPCI DSS v3.2に、TLSに関して記載があります。 一部抜粋し要約すると、次のようになります。
- セキュリティ機能の新規実装時には、SSLと早期のTLS(1.0と1.1の一部の実装)を使用してはいけない
- 既存で実装されているSSLと早期のTLSに関しては、2018年6月30日までに廃止し、TLSの安全なバージョンのみを使用しなければならない
早期のTLSを利用してはいけない主な理由としては、暗号化通信の一部を解読可能な「POODLE」という脆弱性が存在しているからです。
発見された当初はSSL3.0 のみが対象とされていましたが、その後TLS1.0/1.1の一部の実装においても影響を受けると発表されました。
そのため、様々な企業・団体が「TLS1.0/1.1」の使用をやめ、「TLS1.2」への移行や使用の推奨を始めています。
Apple
・Apple will require HTTPS connections for iOS apps by the end of 2016 – TechCrunchMicrosoft
・[IT 管理者向け] TLS 1.2 への移行を推奨していますスターバックスコーヒージャパン
・ 「重要なお知らせ」
2017年12月現在、脆弱性が確認されていないバージョンはTLS1.2のみとなります。 新規に使用する場合、特別な理由がない限りTLS1.2を使用しましょう!
クライアント側の対応
サーバー側でTLS1.2対応を行ったとしても、クライアント側が対応していなければ意味がありません。
クライアントのOSやブラウザのバージョンが古いと、警告が表示されたり接続ができなかったりすることがあります。
TLS1.2対応をする際は、Webサイトで事前にアップデートの案内をするなどの対応も検討すべきでしょう。
各クライアント端末における対応状況を、次にまとめます。
種類 | OS | ブラウザ |
---|---|---|
PC | Windows 7 以上 | Internet Explorer 8 以上 |
Google Chrome30 以上 | ||
Mozilla Firefox 27 以上 | ||
Mac OS 10.9 以上 | Safari 7 以上 | |
Google Chrome30 以上 | ||
Mozilla Firefox 27 以上 | ||
スマートフォン | iOS5 以上 | Safari5 以上 |
Google Chrome30 以上 | ||
Android 4.4 以上 | Androidブラウザ 4.1 以上 | |
Google Chrome30 以上 | ||
フィーチャーフォン | ほとんどの機種でTLS1.2未対応 |
IDCFでの対応状況
さて、ここまでTLS1.2の推奨をしてきましたが、実際の移行はそう簡単ではありません。 大きな課題の一つとして、HTTPSの暗号化/復号が多くのサーバーリソースを必要とすることによる、インフラへの負荷が挙げられます。 Appleが発表しているATSなどは暗号化アルゴリズムの要件も厳しく、インフラへの負荷はかなり大きいです。
IDCFなら、そんな悩ましい課題を次の2つのサービスで解決できます。
インフィニットLB(ILB)
www.idcf.jp
SSLオフロード機能をもった高性能ロードバランサーサービスです。
暗号化/復号処理をインフィニットLBに集約できるだけでなく、負荷によって自動でスケールアウトするためボトルネックになることはありません。
コンテンツキャッシュ
www.idcf.jp コンテンツ配信の高速化を行うCDNのサービスです。インフィニットLB同様、SSLオフロード機能によってSSL/TLSを用いた通信を簡単に実現できます。
構成例
IDCFクラウドとインフィニットLB、コンテンツキャッシュを組み合わせることによって、たとえば次のような構成が考えられます。
★構成のポイント★
- インフィニットLBは負荷によって自動でスケールするため、ボトルネックになる心配なし
- 暗号化/復号処理をインフィニットLB・コンテンツキャッシュに集約しているため、既存サーバーのスペック変更なしでOK
- オリジンサーバー <-> コンテンツキャッシュ間の通信は仮想ルーターを通すことにより、帯域を分散
このように、インフィニットLB・コンテンツキャッシュによってアプリケーションのパフォーマンスを向上させつつ、SSL/TLSの対応が可能です。
まとめ
- SSL/TLSは、クライアント <-> サーバー間の通信を暗号化する技術
- 2017年12月現在、SSL/TLSにおいて脆弱性がないバージョンはTLS1.2のみのため、移行しましょう
- IDCFなら、インフィニットLBとコンテンツキャッシュでお手軽にSSL/TLSの対応が可能
TLS1.2への移行が終わっていない方は、早めの対応をおすすめします。
また、過去に本記事と関係が深い「常時SSL化」についてもIDCFテックブログで紹介しています!
ぜひ合わせて読んでみてください!
それではまた次回の記事でお会いしましょう!