TLS1.0及びTLS1.1の無効化対応(Java編)(ShanonAdventCalendar2017・1日目)

このエントリーをはてなブックマークに追加
この記事はShanonAdventCalendar2017・1日目の記事です。


はじめに

みなさん、TLS1.0の無効化対応は進んでいるでしょうか?

PCI DSS(クレジットカード事業者向けのセキュリティ標準)で、2018年6月30日までに「安全でないSSL/TLS」を「安全なTLS1.1以上」に移行する勧告が出されました。

シャノンも外部連携サービスを用いてクレジットカード決済サービスを提供する事業者であり、顧客に安全なサービスを提供するために、TLS1.0及びTLS1.1の利用を停止する対応を進めています。

弊社のこれまでのSSL/TLS関連の取り組みについては、
以下に記事がありますので、よかったら見てみてください。

安全なWebサイトの構築方法(SSL編)〜Qualys SSL LABSでA評価を目指して〜
SSL sha-1廃止に伴うsha-2への移行 Shanonの取り組み


私が今回対応したのは、弊社の製品であるShanon Marketing PlatformとAPI連携してJVM上で動く製品のTLS1.0及びTLS1.1の無効化に伴う移行作業です。

対象は大きく分けて、以下の二つの言語のサービスが存在します。
  • Java(Playframework、Spring)
  • Scala(Playframework)

これらのサービスはリリースされてから、メンテナンスが定期的に行われているもの、ほとんど行われていないもの、さまざまあり対応方法も異なりました。

今回はその対応するまでの道のりについて、ご紹介しようと思います。


SSL/TLSとは

SSL/TLSはセッション層に位置するセキュアプロトコルで、通信の暗号化、データ完全性の確保、サーバ(場合によりクライアント)の認証を行うことができます。
(「SSL/TLS暗号設定ガイドライン」より)

この内容が難しい方は、ブラウザからhttps://〜でアクセスすると、SSL/TLSのプロトコルにより、通信が暗号化され、盗聴を防ぐことができるということだけ覚えておけば、とりあえず大丈夫です。

SSL(Secure Socket Layer)は1994年にNetscape社によって作られたプロトコルで、その後継にあたるのがTLS(Transport Layer Security)です。TLSのプロトコルバージョンは現在TLS1.2まであり、バージョンが後になるほど、以前の攻撃に対する対策が盛り込まれるため、より安全性が高くなります。

そのため、弊社では今現状、最もセキュアであるTLS1.2をサポートし、TLS1.0及びTLS1.1の無効化の対応を進めることとなりました。

JDKにおけるTLSプロトコルサポート状況

以下の記事を参考にし、JDKのバージョンの選定を行いました。
https://blogs.oracle.com/java-platform-group/diagnosing-tls,-ssl,-and-https

デフォルトプロトコルがTLS1.2になっているのが、JDK8以上で、JDK6以下はそもそもTLS1.2のサポートがない、JDK7はデフォルトではないので、何らかの対応が必要であることがわかります。


対応内容

・基本的にはJavaのバージョンを8以上にあげる

上記の記事を見ると、デフォルトプロトコルがTLS1.2であるJava SE 8以上にすることが必須であるということがわかり、Javaのバージョンアップ並びにフレームワークのバージョンアップを行いました。

・どうしてもJavaのバージョンをあげられないものについて

中には初回リリース後、ほとんど改修が行われておらず、Javaのバージョンを8に上げようとすると、かなりの時間と労力を要するものがあることがわかりました。今後、仕様変更等発生するのであれば、それなりの時間をかけて対応してもよかったのですが、サービス自体の是非が問われている場合、やむを得ず対応しなくてはなりません。

・HTTPクライアントライブラリにっては、デフォルトプロトコルがTLS1.2になっているものもある

Playframework2.3の製品があり、調べていくと使われているWSというライブラリではTLS1.2がデフォルトプロトコルになっており、対応しないでいいことが判明しました。


・実際プロトコルのバージョンが何になっているのか、よくわからないときはテスト環境の設定を変更して通信できるかどうか試す

最初にこれをやって通信できないものを洗い出せばよかったのですが、対応当初はこの方法が思いつかず、だいぶ遠回りしてまったような気がします。。

通信相手であるフロントサーバのapacheの設定を以下の通り変更し、各サービスからのリクエストが受け付けてもらえるか確認しました。

SSLProtocol -ALL +TLSv1.2

結果、Javaのバージョンが7のものは、ことごとくTLSのエラーになりました。

・HTTPクライアントのカスタムソケットファクトリを追加して対応

Javaのバージョンが7で、apacheのHTTPクライアントライブラリを使っているものはstack overflowの記事を参考にしたりして、カスタムのSocketFactoryを追加して対応しました。


感想

今回の移行作業は一人で行なっており、JavaのTLS1.2に関する情報が少なかったため、当初はとても戸惑いました。
この記事が私と同じような作業をあたる方の何かの参考になれば幸いです。

これをきっかけに、SSL/TLSの通信がどのように行われているか、どんな暗号技術が使われているか調べ、先日社内勉強会で「今さら聞けないSSL/TLS入門」というタイトルで発表させてもらいました。
(この分野の技術の奥は深く、全体を理解するまでに2ヶ月ぐらいかかってしまったのは内緒ですw)

ひとえに暗号通信と言っても、中ではあらゆる暗号技術が部品として組み合わさって、入れ替え可能な形でフレームワークとして提供されているということを知り、暗号技術は常に脅威にさらされているという認識を持ち、最新の情報にアンテナを張って生活していくことの必要性を強く感じました。

暗号技術の面白さにも少し触れた(公開鍵の数式のシンプルさ等)ので、また近いうちに調べてみようと思います。

それでは良い暗号ライフを!


次の記事
« Prev Post
前の記事
Next Post »
Related Posts Plugin for WordPress, Blogger...