注：CVE-2016-6304に従ってOpenSSLをアップデートされた場合、OpenSSL 1.1.0aとOpenSSL 1.0.2iにはCVE-2016-6304の修正コードに問題があって、OpenSSL 1.1.0aの場合は1.1.0bに、OpenSSL 1.0.2iの場合は1.0.2jにアップデートするようにとの報告が出されています。
OpenSSLのOCSP Status Request extensionに脆弱性があり、OpenSSLが動作しているサーバに対してDDoS攻撃が成立する可能性があるという報告がされています（CVE-2016-6304)。
SWANStorシステムはSSL-VPNですのでこの脆弱性の影響を受ける可能性がありますが、弊社運用サーバでは影響を受けないことがわかっています。SWANStor Suiteをご利用でSWANStorゲートウエイの運用もされているお客様については、運用されているシステムのOpenSSLのバージョンや設定をご確認ください。
OpenSSLの報告によれば、OpenSSLの1.0.1g以降のバージョンでこの脆弱性の影響があるそうです。また1.0.1g以前のバージョンをご利用でもOCSP stapling supportの設定をしている場合には本脆弱性の影響を受けるようです。
運用されているサーバのOpenSSLのバージョンの確認は、ご利用のサーバ上で
rpm -qa openssl
によりインストールされているパッケージバージョンを見ることができます。また、SSLを利用するアプリケーションによってはOpenSSLライブラリを静的にリンクしている可能性がありますので、それぞれのアプリケーションで確認する必要があります。SWANStorシステムで利用しているstunnelの場合
stunnel -version
でOpenSSL ライブラリのバージョンを確認することができます。
また、OCSP stapling supportの有無については
openssl s_client -connect SSL-Server-Name:443 -tls1 -tlsextdebug -status
で確認できます（SSL-Server-Namenにはご利用のサーバのホスト名を入れます）。表示される結果の20行目くらいあたりで
OCSP response: no response sent
が表示されている場合にはOCSP stapling supportは無効になっています。それ以外のOCSP responseの応答が表示される場合には有効設定になっています。
なお、OpenSSLのサイトによれば、1.0.1g以降ではOCSP stapling supportの有無に関係なく本脆弱性の影響を受けると報告されており、1.0.1u以降にアップデートすることを勧めています。
ところで、”OCSP Status Request extension“や”OCSP stapling support”とは何でしょうか？
SSL証明書の正当性は次のような情報で検証されます。
１）SSL証明書に書かれているコモン名とアクセス先のホスト名が一致している
２）SSL証明書の有効期限内である
３）上記を含めたSSL証明書全体が正当なものであることを第三者認証局により認証されている
SSLサーバにアクセスしたブラウザは上記情報をチェックし、いずれかに問題がある場合にはワーニングの画面を表示するなどしてアクセスを継続させないように促します。３）についてはブラウザにあらかじめインストールされているルート証明書と第三者認証局がSSL証明書につけている署名とを付け合わせて、その認証の正当性を検証しますが、それだけでは十分ではないことがあります。
例えばSSL証明書の認証方式を応用してアクセス認証に利用されている「SSLクライアント認証」の場合、クライアント証明書は有効期限内であっても利用ユーザごとに証明書を無効化する処理が必要になります。証明書を無効化する処理は第三者認証局が発行する「失効リスト」によって確認することが可能です。
SSLサーバ証明書においても第三者認証局は同じように署名をつけた情報を管理し、「失効リスト」を確認することでブラウザはSSL証明書の有効性を確認することが可能です。つまりSSL証明書の正当性は次の第四の方法で更に検証することができます。
４）SSL証明書を認証した第三者認証局が、その証明書を失効処理していないこと
2011年3月に某大手認証局が外部からの攻撃を受けて偽の証明書を発行してしまったという問題が発生し、ユーザが気がつかないままに偽サイトを経由してSSL通信を行ってしまい大事な情報を盗聴される、いわゆるMan-in-the-Middle攻撃が成立する懸念が取りざたされるという事件がありました。某大手認証局は直ちに、発行されたサーバ証明書の失効処理を行い、またブラウザ側の対応もあり、実害の報告はなされていないようですが、上記の４番目の検証方法の重要性が再認識された事件でもありました。
ところでこの「失効リスト」ですが、第三者認証局からダウンロードして確認することができますが、ファイルには認証局が発行し失効させた全ての証明書のシリアル番号が書かれているため、一般的に非常に大きなサイズのファイルになります。シリアル番号からは発行した相手や時期などの情報はわからないため、全ての情報を含んでいるからといってセキュリティ上の問題になることはないのですが、ブラウザからすれば、たった一つのSSLサーバの正当性を確認するために、他の多くのサーバの失効情報を入手しなければならない、ということになってしまいます。
これに対して、ブラウザが直接第三者認証局に、SSL証明書が失効していないかを確認する手続きがOCSP(Online Certificate Status Protocol）になります。
IE11では、「インターネットオプション」の「発行元証明書の取り消しを確認する」にチェックが入っている場合、SSLサーバに初めてアクセスした際などに、証明書を認証した認証局にOCSP Status Requestを送り、該当証明書が失効していないかどうかを問い合わせます。
一方、ブラウザが認証局にOCSP Status Requestを発行することで、SSL通信のレスポンスが大きく悪化することもあります。例えば、第三者認証局のOCSPサーバの応答速度や負荷、ユーザのアクセス環境によって通信先を規制している場合など、特に後者のケースでは10秒近く表示が遅れるようなケースもあります。
「OCSP stapling support」とはSSLサーバが認証局の「OCSP Status Response」をキャッシュし、ブラウザからのSSL通信開始時にこの情報を渡すことで、ブラウザの認証局へのOCSP Status Request発行を省略させる仕組みです。また「OCSP stapling support」が有効なSSLサーバは、ブラウザからの「OCSP Status Request」を受け付け、キャッシュされた応答を返します。