Oracle JavaでのSSL/TLS Renegotiation脆弱性への対応の影響について
拝啓 貴社ますますご清祥のこととお慶び申し上げます。平素は弊社製品をご愛顧賜り、厚く御礼申し上げます。
さて、2009年11月にSSL/TLS Renegotiation（再ネゴシエーション）における脆弱性※1が指摘され、これへの対策がRFC 5746※2として施されています。しかし、Oracle Javaでは、この脆弱性への対応が段階的に行われたため、ご利用のOracle Javaのバージョンによっては、ACMS E2X/B2B(LE)（以下、ACMS）でのHTTPSをベースとした通信手順において通信障害となることが確認されております。
そこで、お手数ではございますが、通信相手先やお客様でのACMSの利用範囲ならびに稼働環境（Oracle Javaのバージョンや脆弱性への対応の有無など）を確認いただき、下記の通り稼働環境に合わせた対処を実施していただく様お願い申し上げます。
今後とも弊社ならびに弊社製品をよろしくお願い申し上げます。
※1 SSL/TLSのRenegotiation（再ネゴシエーション）における脆弱性の詳細については、独立行政法人情報処理推進機構（IPA）のWebサイトをご参照ください。
http://www.ipa.go.jp/security/fy21/reports/tech1-tg/b_02.html
※2 SSL/TLSのRenegotiation（再ネゴシエーション）における脆弱性への対応策であるRFC 5746についての詳細は、以下のドキュメントをご参照ください。
http://www.rfc-editor.org/rfc/rfc5746.txt
記
１．通信障害になる条件と対応
ACMSと通信相手の稼働環境のSSL/TLS Renegotiation（再ネゴシエーション）における脆弱性への対応が一致しない場合に通信障害となります。
【通信障害となる条件】
①ACMSのHTTPSをベースとした以下のいずれかの通信手順を利用している
HTTPS、EDIINT AS2、RosettaNet、ebXML MS（ECALGA）、ebXML MS(NACCS)、ebXML MS(流通BMS)、ebXML MS 3.0(JEITA)、JX手順 、Chem eStandards
②SSL/TLS Renegotiation（再ネゴシエーション）を利用している
・ACMSがサーバ側の場合、拡張機能「SSLクライアント認証の判定（名前ベース）」※3を（cps.ssl_client_mode.https.enable_vhostプロパティ）を使用しているか否かを確認
・ACMSがクライアント側で、通信相手よりSSL/TLS Renegotiation（再ネゴシエーション）が要求されるか否かを確認（ACMS上の設定がないため通信相手先に確認が必要）
③ACMSと通信相手の脆弱性への対応（Oracle Javaバージョン）の組み合わせが以下のいずれかである（下表の「×」の組み合わせの場合に通信障害となる）
 |
＜脆弱性への対応の組み合わせ（凡例 ○：正常通信可、×通信障害となる）＞
| 脆弱性あり | Phase1※4
（無効化対応） | Phase2※5
（RFC 5746対応） |
|---|
| 脆弱性あり |
○ |
× |
× |
|---|
| Phase1（無効化対応） |
× |
× |
× |
|---|
| Phase1（無効化対応） |
× |
× |
○ |
|---|
通信相手
ACMS
＜JDK Family別脆弱性対応＞
| JDK Family | 脆弱性あり | Phase1※4
（無効化対応） | Phase2※5
（RFC 5746対応） |
|---|
| JDK/JRE 7 |
－ |
－ |
全Update |
| JDK/JRE 6 |
Update 18以前 |
Update 19～21 |
Update 22以降 |
| JDK/JRE 5.0 |
Update 23以前 |
Update 24～25 |
Update 26以降 |
| JDK/JRE 1.4.2 |
Update 25以前 |
Update 26～27 |
Update 28以降 |
|
【通信障害への対応】
ACMSと通信相手の稼働環境をSSL/TLS Renegotiation（再ネゴシエーション）における脆弱性に対応した環境に統一することで、通信障害を回避することができます。具体的には、ACMSならびに通信相手のOracle Javaのバージョンを以下のRFC 5746に対応したものに統一してください。
JDK/JRE 7 全Update
JDK/JRE 6 Update 22以降
JDK/JRE 5.0 Update 26以降
JDK/JRE 1.4.2 Update 28以降
尚、通信相手側で当該対応が行えない場合などで環境を統一できない場合には、通信障害への対応を行った後に、ACMSの起動パラメータ（acms_startまたはサービス起動のAcms.ini）に、次のJavaパラメータを追加することにより脆弱性を残したままでの通信となりますが、障害を回避することができます。
Java -Dsun.security.ssl.allowUnsafeRenegotiation=true acmsjvm.rc.AjRc acms.properties
２．障害を特定する稼働記録
ACMSと通信相手の稼働環境のSSL/TLS Renegotiation（再ネゴシエーション）における脆弱性への対応が一致しない場合の通信障害で出力される稼働働記録は以下の通りです。
尚、特にACMSがクライアントの場合、通信相手先の振る舞いによって出力される稼働記録が異なりますので、代表的な稼働記録のみを記載しています。
【ACMSがサーバの場合】
10084201 ＨＴＴＰ手順のオブジェクト受信待ちで障害が発生しました
①障害詳細=javax.net.ssl.SSLHandshakeException: renegotiation is not allowed
②障害詳細=Error of SSL client authentication(null cert chain)handshake alert: no_negotiation
③障害詳細=javax.net.ssl.SSLHandshakeException: Insecure renegotiation is not allowed
【ACMSがクライアントの場合】
10087007 JX手順クライアントにて応答電文の受信時に障害が発生しました
10084601 ＨＴＴＰ手順のデータ送信時に障害が発生しました
①障害詳細=HTTPレスポンス受信待ち javax.net.ssl.SSLException: HelloRequest followed by an unexpected handshake message
②障害詳細=HTTPレスポンス受信待ち javax.net.ssl.SSLException: Received fatal alert: unexpected_message
③障害詳細=HTTPレスポンス受信待ち javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
３．Oracle Java以外の環境でのACMSご利用の場合
Oracle Java以外の環境でACMSをご利用の場合については、お手数ですが「お問い合わせ先」までお問い合わせください。
※3 この拡張機能の詳細については、「ACMS E2X, ACMS B2B Additional Guide 2.1.10.3 SSLクライアント認証の判定（名前ベース）」をご参照ください。
※4 Oracle Javaでは、この脆弱性に対して段階的に対応を行っており、Phase1ではSSL/TLSを使用した再ネゴシエーションを無効化する暫定処置を行っています。
※5 Oracle Javaでは、この脆弱性に対して段階的に対応を行っており、Phase2ではRFC 5746を実装し、安全にSSL/TLSを使用した再ネゴシエーションが行えるようになっています。
|
