Professional SSL/TLS Reading Chapter 6

プロフェッショナル SSL/TLS 輪
読会
6. 装の実問題
2017/09/05

Overview
• - プロフェッショナル SSL/TLS
• 6. 実装の問題
– 6.1 証明書の検証における欠陥
– 6.2 乱数生成における欠陥
– 6.3 Heartbleed
– 6.4 FREAK
– 6.5 Logjam
– 6.6 プロトコルダウングレード攻撃
– 6.7 強制切断攻撃
– 6.8 デプロイにおける弱点
• - 実践ハンズオン

6. 実装の問題
• 証明書チェーンのそれぞれに対して確認が必要な項目
• 1. エンドエンティティ ( サーバ ) 証明書が意図したホスト名に対して有効であること
• 2. 証明書チェーンの証明書全て ( エンドエンティティのものを含む ) が下記を満たすこ
と
– いずれも期限切れになっていない
– 署名がいずれも有効である 3. 中間 CA 証明書は場合によってさらに下記の要求を満たす必要が
ある
– 意図したものである場合に、他の証明書に対する署名に使えること
– 他の CA 証明書に対する署名に使えること
– 末端の証明書におけるホスト名の署名に使えること

6.1.1 ライブラリとプラットフォームにおける検証の不備
• Microsoft 社の CryptoAPI(,OpenSSL) における Basic Constaints( 基本制約 ) の
確認に欠陥があった事例 (2002 年 )
• GunTLS における証明書チェーン検証の欠陥
• OpenSSL における DSA および ECDSA の署名検証の欠陥
• iOS 関連の TLS 実装バグ
• GnuTLS における証明書チェーン検証の欠陥 (2014 年 )
• OpenSSL の ChangeCipherSpec インジェクション攻撃 (2014 年 )
• OpenSSL における証明書チェーン検証の欠陥 (2015 年 )

Microsoft 社の CryptoAPI(,OpenSSL) における Basic Constaints( 基本制
約 ) の確認に欠陥があった事例 (2002 年 )
• 有効なサーバ証明書であればどんなものでもドメイン名などを詐称した証明書に
対する署名に利用でき、その詐称した証明書を信頼されたものにできてしまう可
能性
• 対象
– Microsoft 社の全プラットフォーム
– その他の OS 上で動いている製品
– Konqueror(KDE のデスクトップ環境でデフォルトのブラウザ )
– OpenSSL
• Bound by Moxie Marlingspike in 2002.8
• エクスプロイト sslsniff

GunTLS における証明書チェーン検証の欠陥
• 信頼されていない証明書チェーンの末尾に、どんなものでもいいから信頼された
ルート証明書を追記するだけで、不正な証明書が有効なものとして認識されてし
まうという欠陥。
• 手順
• 1. /etc/hosts に localhost のエイリアスとしてサーバを追加
• 2. アタッチされたファイルを使って以下のコマンドを実行
– $ gnutls-serv --http -p 4433 -a --x509keyfile server.key --x509certfile chain.pem
• 3. GNU TLS クライアントを使ってサーバに接続
– $ gnutls-cli gnutls-cli --x509cafile thawte.pem -p 4433 server

実装
• _gnutls_x509_verify_certificate in x509/verify.c
• http://repo.or.cz/w/gnutls.git?a=commitdiff;h=c154545b8a3df4f7d06c6aa335c18740cbec
f57a

OpenSSL における DSA および ECDSA の署名検証の欠陥
• DSA 署名と ECDSA 署名の欠陥が検出されない。
• 詐称された証明書が有効とみなされる。
• Fix されたコード
– https://bugzilla.redhat.com/attachment.cgi?id=327115&action=diff
– チェックが甘い

iOS 関連の TLS 実装バグ
• iOS における Basic Constraints( 基本制約 ) の確認に欠陥があった事例 (2011 年 )
– 証明書を下位 CA 証明書として利用してよいかを確認しておらず、どんな末端の証明書
でもあらゆる証明書に対する署名が可能になっていた 4.2.10,4.3.5 より前
• iOS および OS X における接続認証の欠陥 (2014 年 )
– 接続認証のコードにミスがあって、能動的なバグであり、 MITM 攻撃で DHE および ECD
HE の接続が乗っ取られてしまうバグ 6.x,7.xOS X(10.9)TLS ハンドシェイク中のほんの短い
一瞬で起こり、ログにも残らない

GnuTLS における証明書チェーン検証の欠陥 (2014 年 )
• 1. X.509 バージョン 1 形式の証明書が、公開鍵所有者を特定できない任意の中間 CA 証明
書として GnuTLS に扱われてしまうバグ
– https://www.gitorious.org/gnutls/gnutls/commit/b1abfe3d18?p=gnutls:gnutls.git;a=blobdiff;f=lib/x509/
verify.c;h=b916ee51de36eb7854e5a93958e5d92caa767fd8;hp=2b64ab690bf2be20837594beafdb6fe23
8db3cf6;hb=b1abfe3d18;hpb=a49d49d0520fa738c03cb714eb0d8040177108c6
• 2. 不正な証明書が検証プロセスを迂回して有効なものとなってしまうバグ

OpenSSL の ChangeCipherSpec インジェクション攻撃 (2014 年 )
• 通信の両端で OpenSSL が使われている時有効
• ChangeCipherSpec メッセージは、 TLS ハンドシェイク中に双方からネゴシエーション終了
と暗号化への切り替えの合図として使われるのに、ハンドシェイクプロトコルの一部で
はないために認証されない。
• 予測可能なマスターしっくれっとをネゴシエーションするように強制できる。
• https://bugzilla.redhat.com/attachment.cgi?id=901373&action=diff

OpenSSL における証明書チェーン検証の欠陥 (2015 年 )
• 証明書チェーンの検証コードのバグ
• ネットワーク上の攻撃者が末端の証明書を有効な中間 CA 証明書として使える

6.1.2 アプリケーションの検証における欠陥
• セキュリティクリティカルなアプリケーションおよびライブラリの多くで SSL 証明書の
検証が完全に壊れている。
• Amazon EC2 の Java ライブラリおよびそれをベースにしたクラウド用のクライアントすべ
ても！
• ライブラリのデフォルトの安全ではなく、開発者が自分で安全なコードを書かないとい
けないという API の設計がまずい。
• 今はこの論文が言ってることに関しては問題ではなさそうだが (SOAP リクエストに関わ
る SSL 証明書の検証でホスト名検証を省略するという話なので )
• 論文 PDF
– https://www.google.co.jp/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uact=8&ved=0ahUK
Ewjf_4yT6_TVAhVNOrwKHS-ZCrQQFggvMAE&url=https%3A%2F%2Fblue-sea-697d.quartiers047.workers.dev%3A443%2Fhttps%2Fwww.cs.utexas.edu%2F~shmat%2Fs
hmat_ccs12.pdf&usg=AFQjCNGPKl-0ZNPcFUIaE16t6E5OJyki2w

論文引用
• Codehaus XFire is another open-source Java implementation of SOAP
• Both versions of HttpClient rely on SSLSocketFactory for SSL connection establishment but mistak
enly omit hostname verification (Section 4.2).
• SSL vulnerabilities caused by bugs in Web-services middleware are pervasive in Amazon libraries.
Affected software includes Amazon EC2 API Tools Java library, which uses XFire to set up SSL conn
ections to EC2 servers

6.1.2 アプリケーションの検証における欠陥
• 該当箇所の関数の実装

6.1.3 ホスト名の検証における問題
• たいていのクライアントが Null バイトをホスト名の終端とみなすことを利用
• Microsoft 社の CryptoAPI,GnuTL,SNSS ライブラリ ,Firefox,IE etc…

6.2 乱数生成器 (RNG)
• Netscape Navigator における RNG の欠陥 (1994 年 )
• Debian における RNG の欠陥 (2006 年 )
• 組み込みデバイスにおける不十分なエントロピー

Netscape Navigator における RNG の欠陥 (1994 年 )
• ブートからの経過時間をマイクロ秒で表した時間と、 OS におけるプロセス ID および親プロセ
ス ID から単純なアルゴリズムで乱数を生成。条件によっては、数十 bit までのセキュリティレ
ベルに落とし込んで総当りできる。
– Seed を決定する処理
– 鍵生成アルゴリズム

Debian における RNG の欠陥 (2006 年 )
• 間違って暗号処理部分のコメントアウトをしたことで、プロセス ID から得られる補助的
なエントロピーしか残らず 16bit になる。
– https://anonscm.debian.org/viewvc/pkg-openssl/openssl/trunk/rand/md_rand.c?p2=%2Fopenssl%2Ftrunk%2Frand%
=141

組み込みデバイスにおける不十分なエントロピー
• 2002 年 2 月にインターネット上にある RSA および DSA 鍵の品質を調査した結果が発表さ
れたところ、組み込みデバイスで問題が多く見つかった。
– デフォルトの鍵
– エントロピーが低いので鍵が使いまわされた
– 素因数分解可能な鍵

6.3 Heartbleed
• OpenSSL の Heartbeat プロトコルの実装の脆弱性。返信するデータの長さの確認を怠って
いる箇所がコード中にあることが原因で、遠隔からの攻撃者が送信した以上のデータを
引き出せる。
• 1 回の Heartbeet リクエストで、サーバプロセスが含まれるメモリから 64K バイトまでの
データを取り出せるので複数回繰り返すことで、メモリ上にのっかった秘密鍵や SSL/TLS
のセッション鍵、パスワードなどのデータを取り出す。

実装
• https://bugzilla.redhat.com/attachment.cgi?id=883475&action=diff
• a/ssl/d1_both.c
• a/ssl/t1_lib.c

対策
• 対策として、パッチを当てるか、 Heartbeat プロトコルはそもそもそんなに使われていな
いので無効化する。
• OpenSSL の資金難とコードの品質の悪さ
– 「 OpenBSD has started a massive strip-down and cleanup of OpenSSL 」
http://undeadly.org/cgi?action=article&sid=20140415093252
• Heatbleed をきっかけに対策に乗り出した。

6.4 FREAK
• 背景
– 1998 年 9 月までアメリカは強力な暗号技術の輸出を規制していた。
– 秘匿のための暗号処理については 40 ビット。鍵交換については 512 ビットまで。
– 鍵交換の際に、輸出用の暗号スイートをネゴシエーションする際には一時的に弱い RSA 鍵を生
成して ServerKeyExchange メッセージをいれてクライアントに送信
• TLS 実装の欠陥が明白
• ( 引用 : http://d.hatena.ne.jp/jovi0608/20150304/1425461359)

実装
• https://github.com/openssl/openssl/commit/ce325c60c74b0fa784f5872404b722e120e5cab0

悪用の障壁と克服
• 1. メッセージに対する署名は攻撃対象であるサーバの強力な RSA 鍵で暗号化されている
こと
• -> クライアントからの接続をかまえて、クライアントの本物の乱数を攻撃対象のサーバ
への接続にコピー
• 2.TLS のハンドシェイクに干渉して変更を正当化するには適切な Finished メッセージを捏
造しなければならない
• ->Finished メッセージを送る頃には、鍵交換の強度を 512bit まで下げられている。さらに
現実の運用では、接続ごとに新しい鍵を使いまわしている場合があるので時間をかけて
攻撃できる。

6.5 Logjam
• Log は DH 鍵交換の原理として利用されている「一方向の離散対数問
題 (Discrete Logarithm Problem) 」からきている
• 概念的には FREAK 攻撃を模倣したもの

FREAK 攻撃の手法を模倣したもの ( 相違点 )
• サーバが安全でない DH パラメータを使ってしまう場合
– 最も典型的なのはサーバが DHE を含む輸出用暗号スイートを使う場合で鍵長が 512bit に制限
– ただし、多くのサーバではより高速な ECDHE や RSA による鍵交換を採用していて DHE がネゴシ
エーションされる確率は低い。
• DHE 鍵がサーバでキャッシュされている
– Mallory は DHE 鍵を 1 分以内 ( モダンブラウザがハンドシェイクをあきらめるまでのおおよその
時間 , 1)※ にやぶらないと行けないが、キャッシュしていれば話は別
– IIS は一時的な鍵を 2 時間に渡ってキャッシュ。 OpenSSL にはキャッシュする機能があるが、 Apa
che や Nginx 、は利用していない
• クライアント ( ブラウザ ) が弱い DH パラメータを受け入れてしまう
– 鍵交換にふさわしい強度が指定されない ( 強度を決定するのはサーバ )
– DH パラメータのサーバ署名が再送できてしまうプロトコルの弱点 ( 実装による欠陥ではない )
– TLS ではリプレイ攻撃に対する保護が署名の設計に含まれているが、そのための仕組みはクライアントとサー
バの乱数に依存している。問題は、この値を能動的な攻撃者が同期できてしまう。クライアントが申し出た
乱数の値を観察し、別のハンドシェイクで再利用することが可能。この欠陥により、本来であれば選択され
ない暗号スイートのネゴシエーションを攻撃者が強制できる。

安全ではない DHE 鍵交換に対する事前計算攻撃
• DH 鍵交換ではドメインパラメータの同意が必要。 ( 素数 p, 原始根 g)
• Mallory にもこれは分かるが、 DH 鍵交換を破るには、鍵交換の最中に生成される
2 つの秘密鍵の内の一方を見つけ出す必要がある。
• NFS(Number Field Sieve, 数体ふるい法 ) を 2 段階に分割することが可能で、難しい
のは最初の方。しかし、素数 p のみに依存；最初の結果さえ手に入れてしまえ
ば、同じ素数 p を使うあらゆる鍵交換を迅速に発見できる。
• 多くのアプリケーションでは、標準グループ (standard group) と呼ばれる DH パラ
メータを使いまわしている。この標準グループが弱いことが問題。

緩和策
• 輸出用暗号スイートを無効 ( 過去の遺物 )
• 1024 ビットより短い DH パラメータを使わない。
• DH パラメータを単純に 2048 ビットに対応できない場合がある (Java 6 のクライア
ントが 1024 ビットを超える強度に対応していない )
– 1024 ビットの DH パラメータを使い続けながら標準グループを使わないようにする
– DHE を無効にする (RSA 鍵交換は PFS がないのでつかうべきではない。 ECDHE はセキュ
リティ、パフォーマンスで優れている )

6.6 プロトコルダウングレード攻撃
• ハンドシェイク時のパラメータを操作してセキュリティの劣るプロトコルや弱い
暗号スイートを強制する。 SSL2.0 ではハンドシェイクの完全性が保証されないの
で、攻撃が簡単

6.6.1 SSL 3.0 のプロトコルロールバック対策
• SSL2.0 にフォールバックするときに RSA 鍵交換における PKCS#1 のブロックを特別
な形式でフォーマットする。このブロックの末尾に少なくとも 8 ビットを 0x03
で埋める。
• 攻撃を受けた場合このフォーマットを検知して攻撃を察知。
• ただし、マスター鍵で 40 ビットのものを使われると総当りで攻撃するのは簡
単。 (IE6 に期待できるセキュリティ強度 )

6.6.2 相互運用性の問題
• バージョンに対する不寛容
– SSL3.0 では、互換性を崩したが、 SSL2.0 は考慮してなく仕様が曖昧だったので、多くのサーバでは提示された
プロトコルのバージョンが好ましくない場合にハンドシェイクを拒否した。
– Renegotiation Indication という拡張 (RFC 5246 で既に規定されているもの )
– TLS サーバは、クライアントから提示された不明な拡張についてはすべて無視しなければならない
– 自分の最大のバージョン番号より大きなバージョン番号については、受け入れた上で互いに共通する最大のバージョンをネゴ
シエーションしなければならない
• 拡張についての不寛容
– プロトコルの初期のバージョン (SSL3.0 および TLS1.0) のサーバの大部分は、 ClientHello,ServerHello メッセージの
末尾に負荷的なデータを指定してきたクライアントのハンドシェイクを拒否する ( データを含められるが、実
装で、理解出来ない場合は拒否するものになっていた ) 。その後 TLS 拡張に置き換えられた
• 相互運用性に関する他の問題
– 長いハンドシェイクに対する不寛容 : F5 射精の BIG IP ロードバランサで 255 バイト以上 512 バイト未満のハン
ドシェイクメッセージを処理できない
– 任意の拡張に対する不寛容 : 明確な理由なしに未知の拡張を含む接続のネゴシエーションに失敗 (SNI 拡張、 Sta
tus Requesrt 拡張 (OCSP ステープリング ))
– フラグメンテーションの適切な処理の失敗 : SSL の分割したフラグメンテーション以外は拒否。長さが 0 のレ
コードの処理に失敗

6.6.3 プロトコルの自発的なダウングレード
• SSL2.0 はマスター鍵の総当たり攻撃に対して脆弱 (IE6 に期待できるセキュリティは最大で 40 ビット )
• SSL 3.0 は POODLE 攻撃によって安全でないことが判明 (2014 年 10 月 )
– 攻撃者は、 SSL 3.0 を使う暗号化通信において、リクエスト送信を繰り返し試み、暗号化通信の一部を解読する
恐れが発生。また攻撃者は、 TLS ／ SSL のバージョンをダウングレードさせる可能性がある。
– 32 文字の Cookie の値を取得することを考えると、おおよそ 8,000 回程度のリクエストをクライアントから繰り
返し送らせる必要がある
– http://developers.mobage.jp/blog/poodle
• 他のバージョンも TLS1.2 に比べて以下の点で劣る
– - GCM,SHA256,SHA384 を含む暗号スイートに対応していない
– - 楕円曲線暗号に対応していない ->PFS がない状態 ( 最悪 )
– - SSL3.0 は BEAST 攻撃に脆弱だが、対策はされている。とはいえど、 TLS1.0 より以前のプロトコルで RC4 を使え
てしまうサイトが多い
– - Microsoft 者の SSL3.0 スタックは AES に対応していないので、 IE は RC4 と 3DES の暗号スイートしか提示できな
い
• いずれも対策はされていて過去のこと

6.6.4 TLS1.0 以降のロールバック対策
• - ロールバック保護のために、クライアントから送信される PremMasterSecret のバージョン番号
には、サーバの秘密鍵で保護されるバージョン番号 (ClientHello.client_version の値 ) が追加された
ので、これを利用する。
• - ロールバック保護を新しいクライアントとの間のみで強制するように勧告 (ClientHello.client_ver
sion が TLS 1.1 以上 )
• それでもプロトコルの自発的なダウングレードの挙動で攻撃可能。

6.6.5 プロトコルの自発的なダウングレードを悪用した攻撃
• MITM 攻撃でパラメータを変更しなくても SSL3.0 より大きなバージョンをブロックすれば良い。
• - SCSV(Signaling Cipher Suite Value) 低いバージョンがネゴシエーションされる場合であっても、ク
ライアントが自信の対応している最良のプロトコルを伝達できるような特別なシグナリング ( ク
ライアントは大勢いるので普及に時間がかかる、最終的にはこれが Google の Chrome,Web や Ope
nSSL(1.0.1j),Firefox35 で対応 (POODLE 攻撃対策になる )
• - 暗号スイートのシグナリングを用いてクライアント側で攻撃を検知出来る仕組み (RFC5746 の再
ネゴシーエションを指示するための拡張の仕様 ) 安全なネゴシエーションを実装しながらも新し
いバージョン番号には不寛容であるようなサーバがわずかながらに存在して関心をあまり集めな
い
6.6.6 代的なロルバック攻への防御現ー撃

6.7 強制切断攻撃
• 安全なメッセージがきちんと終了する前に、攻撃者によってメッセージの配送がぼうがいされて
しまう攻撃。
• SSL3.0 では close_notify が追加されたが、多くのクライアントやサーバではシャットダウンの手続
きを省略 ( 例 IE)
• SSL3.0 の標準で記載されている。
• TLS1.1 でセッションリザンプションに関する規則緩和でさらに悪化。防御方法は事実上ない。
• 2007 年ぐらいに話題に上がる。

クッキーカッター攻撃
• クッキーカッター攻撃をよりいっそう効果的に
• HTTP のレスポンスヘッダに対する強制切断攻撃
• 任意の長さの HTTP リクエストとレスポンスを挿入することでリクエストヘッダ、レスポンス
ヘッダを分割して、攻撃するきっかけをつくる
– 1. 攻撃対象の Web サイトとの間でまだセッションを確立していない利用者を攻撃する
– 2. HTTP レスポンスに任意のデータを挿入できるエントリーポイントを探す
– 3. レスポンスヘッダを 2 つの TLS レコードに分断するパディングを送信うする
– 4. 1 つめの TLS レコードの後で HTTPS 通信を閉じる
– 5. Secure 属性のないクッキーを抜き出す
• HSTS に対しても有効
• -> - max-age パラメータのさいしょの数字の直後で切り詰められば最大で 9 秒無効。
• - includeSubDomains パラメータを無効

6.8 デプロイにおける弱点
• 6.8.1 仮想ホスト混同
– 証明書を共有しているすべてのサイトでは秘密鍵を共有することになる。弱いサイトを手中に収
めると、クライアントの安全な TLS 接続を乗っ取られる恐れがある。長年放置されてた問題を De
lignant らが 2014 年に論文として、現実のシナリオで悪用する方法や有名な Web サイトになりす
ます方法を紹介。
– https://www.semanticscholar.org/paper/Virtual-Host-Confusion-Weaknesses-and-Exploits-Delignat-Lavaud-Bhargavan/a0e410d945f5
• 6.8.2 TLS セッションキャッシュの共有
– クライアントはいったん RLS セッションを確立したら、本来のサーバとだけでなく、同じセッ
ションキャッシュを共有している他の任意のサーバとの間でもセッションを再開できる。
– セッションチケットでも同様のことがいえるが回避策があり、ホストごとに専用のチケット鍵を
使うのがベストプラクティス

実践ハンズオン
• 2 つの証明書の類似性を利用して、 TLS 通信を解読できる
• http://ksnctf.sweetduet.info/q/33/q33.pcap

Professional SSL/TLS Reading Chapter 6

More Related Content

What's hot (13)

Similar to Professional SSL/TLS Reading Chapter 6 (20)

Recently uploaded (8)

Professional SSL/TLS Reading Chapter 6

Editor's Notes