Certificate Transparencyについて勉強会で発表したので、その補足や落ち穂拾い

終了後にメモするのをサボっていたら1週間経ってしまいましたが、主催している「すみだセキュリティ勉強会」を久々に開催しました。

• すみだセキュリティ勉強会2015#1

発表者の@inaz2さん、@furandon_pigさん、ありがとうございました。

今回の発表内容

私の発表は、最近ちょっと気になっているCertificate Transparencyについてでした。発表資料は以下です（パワポ資料を、ノート付きPDFにしています）。

• 俺とお前とCertificate Transparency

内容については資料を見てもらうとして、以下、時間内で話せなかった部分などを補足します。

復習と用語整理

まず、用語を思い出しておきましょう。

• CT: Certificate Transparency。CTログサーバに発行した証明書を登録することで、証明書発行の「透明性」を確保する仕組み。
• SCT: Signed Certificate Timestamp、署名付き証明書タイムスタンプ。CTログサーバに証明書を登録した際に、発行してもらえるタイムスタンプ。

はじめに復習です。Certificate Transparencyに対応していない証明書は、Google Chromeで閲覧すると、次のように「公開監査記録がありません。」というちょっと気になるメッセージが表示されます（悪の帝国Googleの、不安を煽る手口です）。

一方、Certificate Transparencyに対応している証明書は、Google Chromeで閲覧すると次のように「公開監査が可能です」と表示されます。次の図はドイツ銀行の例です。

ちなみにドイツ銀行は、「db.com」という、世界中のデータベースエンジニアが羨むドメインを所有しています。

証明書の中身を見ると、次のようにX509v3 extensionsの、OID=1.3.6.1.4.1.11129.2.4.2としてSCTが埋め込まれています。

OpenSSLでも、現在最新の1.0.2aでx509サブコマンドの-textオプションを使えば、次のように証明書内のSCTを直接見ることができます。

$ echo Q | openssl s_client -connect www.db.com:443 | openssl x509 -text -noout
....（省略）....
X509v3 extensions:
    X509v3 Subject Alternative Name:
        DNS:db.com, DNS:staging.ext.intranet.db.com, DNS:staging.www.db.com, DNS:www.db.com
....（省略）....
  CT Precertificate SCTs:
      Signed Certificate Timestamp:
          Version   : v1(0)
          Log ID    : A4:B9:09:90:B4:18:58:14:87:BB:13:A2:CC:67:70:0A:
                      3C:35:98:04:F9:1B:DF:B8:E3:77:CD:0E:C8:0D:DC:10
          Timestamp : May  6 08:29:23.108 2015 GMT
          Extensions: none
          Signature : ecdsa-with-SHA256
                      30:46:02:21:00:9C:59:F7:55:82:3D:88:13:62:D2:7A:
                      0B:3E:A7:E5:60:41:D2:B1:17:75:2F:0D:FD:BF:CF:F4:
                      AA:1A:50:D9:E1:02:21:00:89:20:3A:68:74:53:5B:D8:
                      74:9D:6D:86:A7:69:9F:54:C1:F3:20:C3:F8:E9:79:0E:
                      4E:F1:DE:A9:77:75:5D:2F
      Signed Certificate Timestamp:
          Version   : v1(0)
          Log ID    : 56:14:06:9A:2F:D7:C2:EC:D3:F5:E1:BD:44:B2:3E:C7:
                      46:76:B9:BC:99:11:5C:C0:EF:94:98:55:D6:89:D0:DD
          Timestamp : May  6 08:29:23.337 2015 GMT
          Extensions: none
          Signature : ecdsa-with-SHA256
                      30:45:02:21:00:C4:34:D5:81:95:B4:22:2D:D6:1F:4B:
                      86:04:82:A7:0C:C8:5B:DA:C7:40:CA:03:BA:B8:F1:73:
                      65:8B:3F:48:72:02:20:6C:FD:4C:FE:04:0F:F0:13:25:
                      B7:9E:0F:ED:56:71:10:DF:E5:7E:5B:F2:1D:E7:CB:21:
                      63:F4:9D:41:15:D3:0C
....（省略）....

以下、上記の勉強会資料で抜けていた部分や補足、落ち穂拾いです。

SCTは証明書に埋め込まないといけない?

発表では、SCT(Signed Certificate Timestamp)が上記のように証明書内に埋め込まれている様子を確認しました。しかしSCTは、仕様上は証明書に埋め込む必要は無く、TLS extensionもしくはOCSP Staplingを利用しても構いません。(OCSP StaplingだってTLS Extensionを利用しているので、こういう言い方は若干語弊があるけど、とりあえず細かい部分は無視）。

が、これらの方法に対応するにはWebサーバ自体の対応が必要です。一方、証明書に埋め込むだけならば、ひとつフィールドが増えるだけなので既存のアプリなどもほぼ影響を受けません。

そのため現実的には、2015年現在、SCTは証明書に埋め込むパターンでしか使われていません（し、たぶんこれから先もそうでしょう）。

SCTを証明書に入れ込む流れの奇妙な点

勉強会でちらりと言いましたが、実はCTログに証明書を登録する過程には「おかしい」ところがあります。

証明書をCTログサーバに登録して、SCTをもらうわけですが……CTログサーバに登録する時点では、証明書には当然のことながらSCTは入っていません。しかし皆さんが先ほどドイツ銀行の例で見たように、証明書にはちゃんとSCTが埋め込まれています。これはなぜでしょうか?

答えを先に言うと、CTログサーバに登録する証明書は「事前証明書(Precertificate)」であり、実際の証明書とは違うものだからです（ここで、「違う」の解釈で実は色々と揉めることになるのですが、とりあえず置いておきます）。

あるドメイン所有者が、CT付き証明書を発行するフローは、実際は次のようになります。

ここで注目すべき点が、事前証明書(Precertificate)の存在です。

事前証明書(Precertificate)

先ほど述べたように、CTログサーバからSCTを発行してもらうためにはまず証明書が必要です。このためSCTを証明書に埋め込みたい場合には、次のような手順を踏む必要があります。（ここ、理解が若干怪しいので後で修正するかも）

1. ドメイン保有者は、自らの秘密鍵を元に証明書署名要求(CSR)を作成して認証局(CA)に送付し、公開鍵証明書の発行を依頼する。
2. 認証局は、ユーザから受け取ったCSRからTBSCertificateを元にして、事前証明書(Precertificate)を発行する。この事前証明書は、実際に利用されないように、毒入れ(Poison Extensionの付加)をしておく。発行した事前証明書をCTログサーバに登録する。
3. CTログサーバは、証明書をログに登録してタイムスタンプ(SCT)を払い出す。
4. 認証局は、SCTを入れ込んだ証明書を、事前証明書と同一のシリアルID(Serial Number)で作成する。
5. 認証局は、SCTを入れ込んだ証明書をドメイン所有者に発行する。

※CTログサーバは実は誰でも登録できるのですが、ここでは一番ありがちなケースとして、ドメイン保有者が認証局から証明書を発行してもらうケースを考えています。

このうち、いかにもビミョーなのが、「毒入れをした事前証明書を発行する」「同一のシリアルIDで証明書を発行する」という2点でしょう。事前証明書には、OID 1.3.6.1.4.1.11129.2.4.3で定義されるpoison extensionを入れる必要があります(これもCertificate TransparencyのRFC 6962に記述がありますので、興味のある方は読んでみてください)。しかし、一般的なPKIの仕組みから見て、いきなりこんなものが出てくると、「なんだか気持ち悪いなぁ」という感想しか私は持てませんでした(個人的な感想です：小波感)。

さらに気持ち悪いのは、「事前証明書と、SCTを入れ込んだ証明書は、同一のシリアルIDで発行する」という点でしょう。社内認証局などを運用したことのある方ならお分かりでしょうが、認証局が同一のシリアルIDで違う証明書を発行するというのは、非常にイレギュラーな処理であり普通はやりたくありません。Certificate Transparencyは認証局にこれを強要しており、美しくありません。あるいは、スマートじゃありません、と言っても良いです。

事前証明書を失効(Revoke)させれば良いのでは

ここまでの話を聞いて、ちょっと詳しい方なら「じゃぁ、その事前証明書を失効(Revoke)させればいい」と思ったかもしれません。残念ながら、Certificate Transparencyの仕組みではそれはできません。

ここで、証明書失効リストの仕組みについてまず確認しておきましょう。先ほどのドイツ銀行の証明書を見てみると、下記のように「CRL配布ポイント」というフィールドがあります。

CRLとはCertificate Revocation List、すなわち証明書失効リストのことです。このURLにアクセスすることで、失効リストを入手することができます。

証明書失効リストは、例えばWindowsならば次のように、ファイルをダブルクリックすることで簡単に中身を閲覧できます。

これを見ると分かるように、一般的な証明書失効リストはシリアルIDに対して証明書を失効させます。通常、発行した証明書には、それを発行したIssuerごとに一意のシリアルIDが付いていますから、このIDを指定して失効させれば良いわけです。

が、先ほど見たようにCertificate Transparencyの仕組みでは、事前証明書とSCTを入れ込んだ証明書の2つは、同一のシリアルIDを持ちます。このため事前証明書を失効させると、肝心のSCTを入れ込んだ証明書も失効してしまいます。このため、事前証明書をシリアルIDを指定した方式で失効させることができません。

CT対応・非対応をユーザが選択できないか?

勉強会で解説しましたが、証明書をCT対応させてしまうと、証明書が誰でもアクセスできるCTログサーバに登録されます。そのため、CTログサーバをクロールしてCommonNameを収集されることにより、サーバのFQDNは秘匿することができず、全世界に公開されてしまいます。（例えば、test-admin-auth.example.comとかいうテストサーバは、内部だけで使いたいので、FQDN自体を外部に出したくありませんよね）。

このため、ユーザが証明書ごとに、CT対応させるかさせないかを選べるのがベターであると個人的には考えます。

ちなみにCybertrustのWebを見てみると、CT対応・CT非対応の証明書を選択してダウンロードできるようになっています。

• https://www.cybertrust.ne.jp/sureserver/productinfo/ct.html

これを見て「おっ」と思ったのですが、よく見ると証明書自体は問答無用にCTログサーバに登録してしまい、ユーザがSCT有・無の証明書を単に選択してダウンロードできるだけのようです。他の大手の認証局のWebも確認しましたが、「そもそもCTログサーバに登録しない」というオプションを提供しているところは無いようです。（あったらすみません、調査不足です）

なお、一部の認証局はEV証明書のみCTログサーバに登録しているので、敢えてOV証明書を使うことでサーバのFQDNを秘匿する、という手があります。しかしこれは現時点での微妙な解なので(OV証明書もそのうちCTログサーバに登録するかもしれません)、やはり根本的にCTログサーバに登録しないオプションがあるといいな、というのが私の感じたことでした。

参考リンク

• http://www.certificate-transparency.org/
  • 公式サイト、まずはここを熟読しないと始まらない。
• http://tools.ietf.org/html/rfc6962
  • Certificate TransparencyのRFC
• https://jp.globalsign.com/blog/2014/certificate_transparency.html
  • CTについて色々調べる際、こちらのGlobalSignさんの記事が大変参考になりました。
• http://blog.livedoor.jp/k_urushima/archives/1764230.html
  • Certificate Transparencyについて知るきっかけとなった、k_urushima様のブログ。証明書周りの情報が豊富で、大変参考になりました

Certificate Transparencyガチャを作った。

このところ、Certificate Transparency(RFC 6962)について調べている。

• http://www.certificate-transparency.org/

これについてはまだ日本語で書かれた解説も少なく、なかなかつかみ所が無くて理解に苦労した。

要するに、発行されるSSL証明書すべてをログDB(CT Log)にガシガシ記録し、みんなが見られるようにしておく。そうして監査ログを作っておき、「多数の目による監視」をして、意図しないニセモノ証明書の発行を防ごう……というのが表向きの目的のようだ。

しかしこのCTにはイロイロと突っ込みどころも多くて、あまりスマートじゃないなぁと私は思っている。とりあえず少し調べてみて、私が「これはどうかなぁ……」と思うのは次のあたり。

• 証明書にCTログのタイムスタンプ(SCT)を付けるために、本物の証明書と同じシリアルIDを持つPrecertificateを作らないといけない。これはとても気持ち悪い
  • Precertificateと本物のCertificateは同一シリアルIDを持つため、Precertificateは失効(Revoke)させることもできない
  • このためPrecertificateには、実際に利用されないようpoison extensionを入れておくんだけど、それも気持ち悪すぎる
• 「CTログ登録しないと、ChromeからEV証明書の緑表示を消すよ!」と脅しをかけるようなGoogleの態度がよろしくない
• あまり外部に公開したくないFQDNも、証明書を作っただけで強制公開されるというのは微妙

しかし、CTはまだ知名度が低すぎるので、まずは簡単に触れるツールがあった方が良い。ということで作ってみた。Certificate Transparencyガチャ。

Certificate Transparencyガチャとは何か

• http://ozuma.sakura.ne.jp/ct/

「number: 」のところにCT logのエントリ番号を入れると、そのCertificateを閲覧することができる。

例えば、2015/04/30現在、一番最後のエントリである7352182を入力すると、www.ageru.ne.jpのCERTIFICATEが表示される。

Log Entry: 7352182
Issuer: C=BE, O=GlobalSign nv-sa, CN=GlobalSign Domain Validation CA - SHA256 - G2
Subject: C=JP, OU=Domain Control Validated, CN=www.ageru.ne.jp
-----BEGIN CERTIFICATE-----
MIIFBjCCA+6gAwIBAgISESGzoK6eRVuALX5brYlguRj7MA0GCSqGSIb3DQEBCwUA
MGAxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTYwNAYD
VQQDEy1HbG9iYWxTaWduIERvbWFpbiBWYWxpZGF0aW9uIENBIC0gU0hBMjU2IC0g
RzIwHhcNMTUwNDI4MDkzMzMyWhcNMTYwNjAyMDU1NTIyWjBKMQswCQYDVQQGEwJK
UDEhMB8GA1UECxMYRG9tYWluIENvbnRyb2wgVmFsaWRhdGVkMRgwFgYDVQQDEw93
......(省略)......
6MrYU4qFxnQhlAa54NMn6BbdEr5YQyCxFBS63usgqTj0IIaOjFU6g9i8ohZwQNG9
OEokLJ7uQrxwezGh9rFQL2vo2lzn87uvyvGjwR/YLozYtbsU3FoPtxDDgT7u07Vw
jdslRjp+DpuPdDo562yLyO83JC4pzgn6ZJTUsxIUhK5QsRmOE/MOJgDJ
-----END CERTIFICATE-----

CT logはURLをポチっと叩けばサクっと簡単に見られるようなお手軽構造ではないので、こういうものがあると便利! ……だと思う。

そして目玉機能が、その下の「GACHA GACHA」機能。「I'm Feeling Lucky」ボタンを押すことで、CT Logからランダムに証明書を抽出して表示することができる。何度も試してみれば、どこかの組織の原則外部公開しない開発用サーバとか、運が良ければ引けるかもしれないぞ! しかもこのガチャ、なんと非課金です。

もう少し細かい話

Certificate Transparencyについて、次回のすみだセキュリティ勉強会で発表します。

• https://atnd.org/events/65530

是非お越しください……と言いたいところなのですが、既に満員になっちゃいました。次回をご期待ください。

参考リンク

GMO GlobalSignのブログ、Certificate Transparencyとはなにか がとても分かりやすく参考になりました。

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と表示されます。

この辺の事情は、以下のenigma63様のスライドが分かりやすいため必見です。ssmjpで聞かせて頂きました。すりーでぃーいーえす。

参考：3DESの件 〜俺、112bitになります〜

(おまけ) Windows版sslscan.exe

READMEには「まだexperimentalだ」という記述がありますが、sslscanはWindows向けにコンパイルされたsslscan.exeがリリースされています。

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

とりあえず、私の手元でちょっと試した限りだと特に問題なく動いているようです。

どうしてもWindowsで動かさないといけない人は、試してみると良いかもしれません。

結論

細かすぎて伝わらない部分が多かったかもしれませんが、だいたい語りました。まぁ、Kali Linuxを最新版にして使いましょう、ってことですな。

Markdown形式のファイルを整形してPDFにする

Markdown形式で書いたテキストを、PDFファイルにするという苦行を達成した。とりあえず、以下の環境で作業する。

• Mac OS X 10.9.5 (Mavericks)
• Sublime Text 2 (2.0.2)

基本方針

• Sublime Text 2のパッケージ「Markdown Preview」でHTML表示する
  • これをSafariの「ファイル」→「PDFとして書き出す」で出力する
• コードのインライン表示（`....`）部分には、枠線を付ける

なおMarkdownファイルをPDFにするにはpandocというツールを使うと良いらしいのだけど、これは内部でLaTeXを使っているため、ここではもっと手軽に作ってみることにする。

Markdown Previewをインストール

まずSublime Text 2でMarkdownファイルをいい感じに整形するために、Markdown Previewパッケージを利用する。ただしこれをインストールするためには、先に「Package Control」というSublime Text用のパッケージマネージャをインストールする必要がある。

• https://packagecontrol.io/

具体的には、「Ctrl + `」でSublime Text 2のコンソールを開き、上記Webサイトの「これを貼り付けろ」というテキストをペーストして実行するとインストールできる。

Package Controlがインストールできたら、「Command + Shift + p」でコマンドパレットを開く。

ここで、「Package Control: Install Package」を選択して実行。

するとリポジトリに接続後、パッケージリストが表示される。Markdown周りのパッケージはいくつかあるが、このうち「Markdown Preview」をインストール。

.mdファイルを整形して表示

Sublime Text 2はデフォルトでMarkdown形式に対応しているので、.mdファイルを開くといい感じに色分けして表示してくれる。

これを、Markdown Previewの機能でHTML出力してWebブラウザで表示してみる。具体的には、「Command + Shift + p」から「Markdown Preview: Preview in Browser」を選択する。

さらにサブメニューとして「github」フォーマットか「markdown」フォーマットかを聞かれるため、markdownを選択する。

これでSafariが自動的に起動されて、HTML形式に整形されたMarkdownファイルが表示される。

あとはSafariの「ファイル」→「PDFとして書き出す」で、PDFに出力することができる。

コードのインライン表示に枠線を付ける

このままだと、コードのインライン表示（`....`）がどうしても見にくい。背景色がグレーになっているだけで地の文と区別しにくいのだ。（具体的には、「ps xとして実行してみましょう。」の「ps x」のところ）

ということで、コードのインライン表示に枠線を付けることにする。具体的には、/Users/ユーザ名/Library/Application Support/Sublime Text 2/Packages/Markdown Preview/markdown.css がスタイルシートなので、これをいじることにする。

.markdown-body code,
.markdown-body samp {
  padding: 0;
  padding-top: 0.2em;
  padding-bottom: 0.2em;
  margin: 0;
  font-size: 85%;
  background-color: rgba(0,0,0,0.04);
  border-radius: 3px;
}

ここに、1行だけ次のように加えれば良い。

  border: 1px solid #000000;

こうすれば、次のように「ps x」のところに枠線が付く。これで地の文との区別がはっきりできて、見やすい。

あとはSafariの「ファイル」メニューで、PDFとして書き出せばOK。

おしまい。