sslscanでサーバのSSL/TLS状態を簡単にチェックする

最近はSSL/TLSのセキュリティ問題が多発しているため、自分で運用しているサーバのSSL/TLSの設定をテストしたいという人は多いと思います。

SSL/TLSの状態をチェックするには、Qualys SSL LabsのSSL Server Testがよく使われます。しかしこれは外部から第三者にスキャンさせるわけですから、(心理的・社内政治的な)敷居が高いという点もありますし、そもそもインターネット側から直接接続できない環境のテストが行えません。

そこで、IPアドレスを指定するだけでよろしく対象のSSL/TLSサーバの状態をチェックしてくれるツールがあると便利だな、ということになります。本稿では、このような目的に利用されるsslscanというコマンドを紹介します。

sslscanはLinuxで動作し、ペネトレーションテスト用に使われるKali Linuxにもインストールされているお手軽なSSLチェックツールです。ただし、このソフトウェアは結構なスピードでモリモリとバージョンアップしているので、少し前の知識で使っていると色々置いてきぼりになってしまいます。最近はsslscanがかなりいい感じになってきているので、若干細かすぎて伝わらない感があるけど、頑張って伝えます。

sslscanの入手

sslscanはGitHub上で開発されているため、本体はそちらから入手できます。なお、これは本来のsslscanからのfork版であるようです。そのため作者に敬意を表して、rbsec-sslscanと呼んだ方がいいかもしれません。本稿では煩雑になるため、単にsslscanと記述します。

https://github.com/rbsec/sslscan/

なお先述した通り、最新版のKali Linuxを使っているならば既にイイ感じのが入っていますから、特に自分でビルドする必要はありません。しかしここでは、自分でビルドする際の注意点などを記しておきましょう。

staticリンク版の提供

sslscanは当然のことながらOpenSSL関連のライブラリを利用するのですが、昨今の事情から、OS付属のOpenSSLをそのままテストツールに使うことは望ましくありません。

例えばSSLv2は既にobsoleteとなっているため、最近のLinuxディストリビューションでは、OpenSSLのSSLv2サポートをdisableにしてコンパイルしたパッケージが提供されているものがあります(Ubuntu 14.04など)。これは「普通の」利用者にとっては当たり前なのですが、テストツールを使いたい立場としてはちょっと困ります。そのようなobsoleteな設定が無いかどうかをテストしたいのに、OS環境に引きずられてテストすべきプロトコルで投げてくれないのは困るわけです。

そこで、「ほんならsslscanの実行ファイルにOpenSSLのライブラリをダイナミックリンクせぇへんで、『アリアリ』のOpenSSLをstaticリンクしてmakeしたればええやん?」という発想がでてきます。そのため今のsslscanは、"make static"とコンパイルすることで、OpenSSLのライブラリをstaticリンクしてビルドすることができます。

sslscanをビルドする際に「make static」と打つと、次のようにまずその場でOpenSSLのリポジトリをドサっと持ってきて、OpenSSL自体をビルドするところからはじまります。なかなかにロックです。

これで、動作させるOS環境上のOpenSSLは利用しない、ポータブルなテストツールができます。こうしてビルドしたsslscanコマンドには、次のようにlibssl.soやlibcrypt.soがリンクされていないことが分かります。

[ozuma@cent6 sslscan]$ ldd ./sslscan
  linux-vdso.so.1 =>  (0x00007ffffe9d3000)
  libdl.so.2 => /lib64/libdl.so.2 (0x00007fec01756000)
  libc.so.6 => /lib64/libc.so.6 (0x00007fec013c2000)
  /lib64/ld-linux-x86-64.so.2 (0x00007fec01969000)

現在のKali Linux 1.1.0 には、このstaticリンク版が入っており、すぐに使うことができます。

static版かどうかの判定

自分が使っているsslscanコマンドがdynamic版なのかstatic版なのかは、--versionオプションを付ければすぐに分かります。以下はKali Linux 1.1.0に付属の、staticリンクされたsslscanコマンドの例です。

root@kali:~# sslscan --version
    -static
    OpenSSL 1.0.1m-dev xx XXX xxxx

このように、静的リンクされたsslscanでは「-static」と表示されます。あるいは、先ほどのようにlddコマンドで確認しても良いでしょう。

ちなみにKaliのsslscanコマンドは特殊で、上で見たように「-static」の前に何もありません。手でビルドすると、通常は次のようにバージョン情報が合わせて表示されます。

[ozuma@cent6]% ./sslscan --version
    1.10.0-rbsec-1-gf53f2f4-static
    OpenSSL 1.0.1n-dev xx XXX xxxx

SSLv2チェック

sslscanコマンドとSSLv2チェックのお話をする前に、ここで、Ubuntu 14.04の標準パッケージにあるsslscanコマンドを確認しておきましょう。

結論から先に言うと、Ubuntu 14.04の標準パッケージのsslscanコマンドは、テスト用ツールとしては不適切です。Ubuntu14標準パッケージのsslscanはバージョン1.8.2ですが、次のようにlibssl.soやlibcrypt.soがOS標準のOpenSSLライブラリにリンクされています。

ozuma@ubuntu14:~$ ldd /usr/bin/sslscan
  linux-vdso.so.1 => (0x00007fffe05fe000)
  libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f4df9653000)
  libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007f4df9279000)
  libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4df8eb2000)
  libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f4df8cae000)
  /lib64/ld-linux-x86-64.so.2 (0x00007f4df98cc000)

Ubuntu 14.04ではOpenSSLパッケージのSSLv2がはじめから無効化してありますから、このsslscanコマンドもSSLv2はテストしてくれません。これを知らずにこのまま実行すると、「SSLv2を検査しているつもりが検査していなかった!」ということになります。

なお最近のsslscanコマンドは気が利いており、実行時に、利用しているOpenSSLのライブラリがSSLv2をサポートしているかどうかをチェックして、サポートしていない場合は警告してくれます。

次の例は、Ubuntu 14.04上で、sslscan Ver.1.10.0を「make static」ではなく「make」でダイナミックリンクでビルドしたものです。これは当然Ubuntu標準パッケージのOpenSSLを使うため、SSLv2をサポートしません。そのため、実行時に次のように「OpenSSL version does not support SSLv2」と赤字で警告してくれます。

また、ちょっと前のKali Linux(確か、1.0.6の頃)に付属していたsslscan 1.8.2では、TLS1(TLS 1.0)しか対応していませんでした。現在のsslscan 1.10.0では、ちゃんとTLSv1.1、TLSv1.2に対応しています。(なお、この頃のKali Linux付属のsslscanは、先述のダイナミックリンク版だったため、SSLv2はテストしてくれないことにも注意が必要です)。

前置きが長くなりましたが、sslscanは進化が早いためなるたけ最新版を、staticリンク版で使いましょう。ということです。

sslscanの機能と出力

sslscanコマンドの使い方は簡単で、コマンドライン引数に対象のIPアドレスを記述するだけです。なお、対象ポートはデフォルトで443/tcpとなるため、別のポートを指定したい場合には「IPアドレス:ポート番号」の形でコロンで指定します。

$ sslscan <IPアドレス>

または

$ sslscan <IPアドレス>:<ポート番号>

現在、sslscanコマンドには次のようなチェック機能があります。なお、オプションを指定することでチェックを省略することもできます。

TLS renegotiation (CVE-2009-3555)
TLS Compression (CRIME)
Heartbleed (CVE-2014-0160)
サポートしているプロトコルとCipherのリスト

このうち最後のCipherリスト出力が、sslscanのメインテーマ(?)です。ここでは、基本的に問題のある設定が赤や黄色で表示されます。

例えば上の例では、「TLSv1.0」や「TLSv1.1」のところは黒字なので問題ありません(先ほど、SSLv2は赤字になっていましたね)。40bitの「40」が赤字になっていますが、これは鍵長が短い(weak)警告です。またピンク色になっているのはADH(anonymous) Cipherの警告、黄色はRC4の警告です。

このようにsslscanコマンドは結果を色で区別するため、パッと見は分かりやすいのですが、テキストに出力して後で見るときには困ってしまうのが欠点です。例えば鍵長が短いCipherは色で表示せず、[WEAK]とか付けて表示するモードがあると使いやすいんですけどね。

オプションの紹介

サポートしていないCipherも表示: --failed

sslscanの1.8.2の頃までは、Cipherリストはダメだったものも接続できたものも、全てが表示されていました。しかし現在の1.10.0では、接続できた(Accept)のもののみ表示されます。

それでは困る(試したCipherすべてを表示しておきたい)場合は、--failedオプションを付ければ、試行したすべてのCipherが表示されます。

これで、sslscan1.8.2の頃と同じ動作にすることができます。

結果をXML出力: --xml

xmlオプションを利用することで、出力結果をxmlファイルとして保存できます。ただし、警告のカラー表示などの情報は一切入らないので、純粋に結果テキストだけが保存されます。

テストの一部省略: --no-heartbleed など

「--no-heartbleed」や「--no-compression」などを指定することで、一部のテストを省略できます。Heartbleedチェックは応答待ちで少々時間がかかるので、大量のホストに実行する場合は指定してテストを省略した方がいいかもしれません。

すりーでぃーいーえす(3DES)の112bit問題

最後に、3DES(トリプルデス)の鍵長問題について補足しておきます。

sslscanでスキャンしていると、3DESのbit数が168bitではなく112bitと表示されることがあります。

これは、3DESでは原理上の鍵長は56(bit)×3=168(bit)ですが、既知の攻撃手法によって実質の鍵長が112bitとなってしまうためです。そのため最近のOpenSSLでは、3DES系の暗号方式の鍵長は112bitと表示されます。