自堕落な技術者の日記

Chrome 56からGoogleの「素人はすっこんでろ」UI/UXポリシーによりHTTPSで接続した際に使用しているSSLサーバー証明書の表示が鍵アイコンから簡単にできなくなってしまいました。証明書大好きっ子にはなんとも辛い仕打ちでした。開発ツールからは証明書が表示できるので、メニューを辿って操作するか、ショートカットキーを素振り100回していた方も多いのではと思います。

Windows: Ctrl + Shift + I or F12
Mac: ⌘ + Opt + I

今日は、やっとChrome 60からフラグ設定で証明書が簡単に表示できるようになったので、今日はその設定について紹介します。

何も設定していないと、HTTPSサイトを見ている際の、鍵アイコンをクリックして見られるメニューはこんな感じ。

そこで、アドレスバーで以下のように入力します。

chrome://flags/#show-cert-link

すると、このようなフラグ設定が表示されます。

「有効にする」をクリックし、指示に従ってブラウザを再起動します。すると、HTTPSサイトを表示した場合このように

「証明書、有効」というリンクが表示されるようになり、クリックすると証明書が表示されるようになります。いや〜〜、よかった、よかった。

Certificate Transparency(以下CT)には色々問題があって何だかな〜〜〜と思っているわけですが、山がそこにあったら、登りたくなるのもまた人情（＾＾； CTログサーバーや格納されているデータについて、いろんなツールを作りながら調査をしています。何回かに分けて、CTについてわかったことを書いていこうと思ってます。

プレ証明書について

CTに対応していることを示すために、幾つか方法はあるのですが、実際に有効になっているのは発行する証明書にSigning Time Stamp(SCT)拡張を埋め込むことです。TLSの拡張やOCSPとついでに渡すという方法の実装を見たことがありません。

SCT拡張を含めるためにはプレ証明書なる証明書が必要になるんですが、プレ証明書がどんなものか、どんなフローで発行されるのかはこのスライドで説明しています。DigiCertさんの幾つかのページでもプレ証明書について解説されているのでよかったらご覧ください。 [1] [2] [3]

これまでにCTの仕組みが導入される前の証明書、CTに対応する予定のなかった証明書に関してはCTのログサーバーに普通にX.509証明書のチェーンが格納されるんですが、CTにまともに対応しようとしているベンダーの証明書は、プレ証明書のチェーンが格納されています。Chromeで「公開監査情報があります」と表示されるものについても、プレ証明書ベースのSCT拡張がX.509証明書に含まれているものしか、このように表示されないと思います。

今日の時点で、Google pilotのCTログサーバーには約670万の証明書チェーンが登録されていますが、そのうちプレ証明書として登録されているもの(=Chromeで公開監査ありと表示されるもの)は16万枚分しかありません。

プレ証明書の発行枚数推移

Google pilotログサーバーへのエントリの登録自体は2013年3月26日から、既存の証明書(パス)について登録が開始されていますが、CT導入以降のプレ証明書発行枚数推移をグラフで見てみましょう。

最初のプレ証明書がGoogle pilotのCTログサーバーに登録されたのが、2013年11月で、プレ証明書というかSCT対応の証明書発行をサービスとして正式にサポートし始めたのは2014年12月頃であることがわかります。

CTの対応が早かったのはどこの認証局(ブランド)か

2015年9月時点で、96の中間認証局(サブCA)、30のブランドがプレ証明書を発行しています。 プレ証明書の発行が早かった30のブランドの順序、発行日は以下のようになっていました。

認証局ブランド	初プレ証明書発行日
DigiCert	2013年11月01日
COMODO	2014年01月23日
TAIWAN-CA	2014年05月09日
Entrust	2014年07月21日
AffirmTrust	2014年10月27日
Symantec	2014年11月11日
GlobalSign	2014年11月28日
GeoTrust	2014年12月08日
Thawte	2014年12月08日
Buypass	2014年12月10日
Network Solutions	2014年12月15日
USERTRUST	2014年12月16日
Trend Micro	2014年12月22日
Starfield	2014年12月23日
Go Daddy	2014年12月23日
TERENA	2014年12月29日
Trustwave	2015年01月05日
Cybertrust	2015年01月07日
VeriSign	2015年01月12日
QuoVadis	2015年01月14日
HydrantID	2015年01月22日
Google UK	2015年01月27日
Aetna	2015年01月29日
IZENPE	2015年02月04日
Certum	2015年02月05日
Camerfirma	2015年02月20日
NCC	2015年03月30日
SECOM Trust	2015年04月30日
Actalis	2015年05月18日
WoSign	2015年08月20日

CTの仕様策定や実装などでGoogleと協力関係にあったDigiCertが対応が早いのはいいとして、台湾のTAIWAN-CA(TWCA)が対応早かったんですねぇ。日本のベンダーさんも頑張っています。

プレ証明書の発行枚数順位

次にプレ証明書の発行枚数で見てみましょう。大手が多いのは当たり前として、 Cybertrustさん頑張っている感がありますね。 そういえば、StartSSLはどうなってるんでしょうか。 10枚程度以下のところは、まだテスト中って感じですかね。

認証局ブランド	プレ証明書発行枚数
Symantec	50760
DigiCert	20856
GeoTrust	17447
COMODO	14573
Cybertrust	13020
Go Daddy	12635
Thawte	9891
Entrust	6616
GlobalSign	6063
TERENA	2363
QuoVadis	1873
Google UK	1861
Starfield	1262
Network Solutions	939
Trend Micro	615
Certum	367
VeriSign	196
WoSign	187
Trustwave	177
SECOM Trust	161
Buypass	154
IZENPE	116
TAIWAN-CA	76
HydrantID	37
Aetna	34
NCC	25
AffirmTrust	10
Actalis	7
USERTRUST	7
Camerfirma	4

どんなツールをつくったか

調べるにあたっては、PerlやNode(+jsrsasign)などで幾つかツールを作ったりぼちぼち環境を整備しています。公開してもいいんですけど、ドキュメント整備したり、コマンドラインオプションなどちゃんと作り込まないと、「ドキュメントがないから使いもんになんね〜〜！！」とか怒られて非常にヘコむんすよね。オープンソースなんだから、ちょっとコードみてくれりゃいいし、テストコード見りゃそのまま使い方ズバリなので、、、と思うんすけどね〜〜〜。(jsrsasignの愚痴っぽくてすみません。)

ざっくりこんなツールを作ってみています。(他にもいろいろありますが、今回に関係する分だけ。)

• プレ証明書とその解析情報だけを集めたSQLiteデータベース
• ログエントリのleaf_input保存ツール
• ログエントリのextra_data保存ツール
• ログエントリからプレ証明書のチェーンを取り出して証明書として保管するツール
• leaf_inputのデータファイルの解析ツール
• プレ証明書のTBSCertificateからニセ署名をつけて適当な証明書に仕立てるツール (TBSCertificateビューアーって一般的に無いのでこれができると 普通の証明書ビューアー(openssl x509コマンドなど)が使えるのでとても便利。)
• ログエントリの登録日を表示するツール

おわりに

今回は、ログデータベースを調べてわかった、統計的な話を中心にレポートしました。次回はデータ構造、プレ証明書の内容なんかを中心に書けるといいなと思ってます。ではでは。

GoogleのCertificate Transparency (解説 [1] [2] [3]) のログデータベースはパブリックなHTTPSサイトに関する証明書のログデータベースなので、いろんな情報が取得できます。2015年3月27日時点で、6,949,166枚のSSLサーバー証明書に関する情報が格納されており、毎日1万枚以上増え続けています。これだけの枚数ですから、ここ数年有効な全世界のSSLサーバー証明書は網羅されているとして良いのかなと思います。以前紹介したgo.jpドメインのHTTPSサイトの調査もこの公開データをもとに調査しました。

本当は講演資料つくらないとマジでヤバイ感じなんですが、現実逃避して、ちょっと訳あってDSAやECDSA公開鍵のSSLサーバー証明書の利用、発行状況について調べてみたのでご報告を。そもそもはDSA公開鍵のSSLサーバー証明書を使っているDSSの暗号スイートなんて本当に使える公開サイトなんかあんのかって話を知りたかったわけです。

ほとんどの証明書はRSA公開鍵のSSLサーバー証明書であり、SSL Pulseの調査結果を見てもECDSAの証明書など割合からしてちょびっとな状況なわけですが、ログデータベースで見てみるとこんな感じです。(以下、2015年3月27日時点)

証明書	枚数	比率(%)
登録サーバー証明書(ログエントリ)の枚数	6,949,166枚	100%
うちECDSA公開鍵のSSLサーバー証明書の枚数	398,841枚	5.3%
うちDSA公開鍵のSSLサーバー証明書の枚数	100枚	0.0014%

念のため補足しとくと、DSA公開鍵のSSLサーバー証明書とはSubjectPublicKeyInfoフィールドにDSA公開鍵が格納された証明書の事を意味し、これを発行する認証局の鍵のアルゴリズムはRSAでもDSAでもECC(ECDSA)でも何でも構いません。SSLサーバー証明書のSubjectPublicKeyInfoのアルゴリズムにより、SSL/TLSで通信した場合の暗号スイートの認証や鍵交換が決まり、DSA公開鍵の場合にはDSSの暗号スイートが使用されます。ECC(ECDSA)証明書についても同じような感じです。

DSA公開鍵のSSLサーバー証明書

100枚の証明書のうち、さらに実際に接続してみて現在も利用可能なサイトを調べてみました。

証明書	枚数	比率(%)
登録サーバー証明書(ログエントリ)の枚数	6,949,166枚	100%
うちDSA公開鍵のSSLサーバー証明書の枚数	100枚	0.0014%
うち接続可能なDSA公開鍵のSSLサーバー証明書のサイト	11	0.00016%
うちシマンテック以外のDSA公開鍵のSSLサーバー証明書のサイト	3	0.00004%

いや〜、たった11サイトでしたよ。そのうち8サイトはドメイン名から シマンテックさんのテストサイトであることは明らかなので、一般のサイトは たった3つでした。DSA証明書を発行しているブランドは、 シマンテックさん以外は、Thawte、cacert.org、ips CAだけでした。 クライアントもサーバーもDSA公開鍵SSLサーバー証明書を使った DSS暗号スイートを使う可能性は殆ど無いと考えてよいんじゃないですかね。

ちなみに、Firefox 36、Chrome 41 でこのDSA証明書のサイトへアクセスしてみると、以下のように表示され、暗号スイートとしてそもそもサポートしていなかったり、信頼するルートに入っていなかったりで接続できません。OpenSSLのs_clientコマンドで接続するしかないわけです。

ECDSA公開鍵のSSLサーバー証明書

ECDSA証明書については5%とそれなりに数はあるわけですが、 ちょっとドメインのリスト見てみると殆どcloudflaressl.comドメインばっかりなんですよ。

証明書	枚数	比率(%)
ECDSA公開鍵のSSLサーバー証明書の枚数	398,841枚	100%
うちcloudflaressl.comのECDSA公開鍵のSSLサーバー証明書の枚数	398,262枚	99.85%
うちcloudflaressl.com以外のECDSA公開鍵のSSLサーバー証明書の枚数	569枚	0.15%

誰かが、「全世界で数パーセントもECDSA証明書が使われてて純増していて、ECDSA証明書は段々流行りつつあるんですよ」なんて教えてくれた人がいたような気もするんですが、cloudflare以外では全世界でたった569枚しか売れてないんじゃないですか！！！ECDSA証明書はcloudflareさんが支えてたんですねぇ。しみじみ。

あ、そうそうGoogleでは*.google.comとかECCの公開鍵のSSLサーバー証明書を使っていてSSL/TLSで接続するとECDHE_ECDSAの暗号スイートになるんですが、その証明書の発行する認証局の鍵はRSAでSHA1withRSAで署名してるんですよね。「ChromeでSHA2移行をせかせる割には、お前はSHA1なんかいっっつ！！」みたいな。

おわりに

というわけで、全世界でどれくらいDSA証明書、ECDSA証明書が使われているのかを見てみました。結構興味深い事実もわかって個人的にはよかったかなと思います。オレはまだ本気出してないだけ。明日から講演資料作成頑張りまっすorz Certificate Transparencyについてはいろいろ深く突っ込んで調査しており、どこかで吐き出したいんですが、雑務に追われなかなかチャンスが無いなぁ。

慶応義塾大学とレピダムさんで共同調査された「日本政府機関Webサイト(.go.jp)のTLS対応状況について(2015.03.04)」を大変興味深く拝見し、もうちょっと知りたいことも多々あったので、私も調べてみるかなぁと思い、今日はそのご報告を、と。

調査対象

.go.jpドメインのサイトには省庁、外局、独立行政法人、政府系のイベントで作られたサイトなどがあり、そのうちパブリックなサイトのSSLサーバー証明書の枚数は2015年3月4日時点で累計1,819枚のようでした。そのうち、ユニークなコモンネーム(FQDNもしくはワイルドーカード証明書のドメイン)の数は877ありました。

省庁、それらの外局、それらが所管する独立行政法人の数で分類すると以下のような構成になっています。(実はこの表を作るのが一番大変だった。証明書はあるからFQDNはすぐに集まるんだけども、FQDNの独法や局や委員会なんかがどこの省庁が所管しているのかとか、イベントサイトはどこで管理されているかなどをGoogle先生やブラウザで開いたりなんかして、ちまちま調べるわけです。いや〜、独法っていっぱいあるんすねorz)

独立行政法人を除いたものの比率は以下のようになっていました。これには最高裁判所、内閣官房、会計検査院、国会図書館なども含まれています。

ワイルドカード証明書を使っている場合には、そのワイルドカード証明書を使っている任意の1つのサイトが見つかれば、そのサイトを調査対象としました。

イベントで一時的に立ち上がってたサイトや停止したサーバーなどがあり、インターネットからアクセス可能なgo.jpドメインのHTTPSサイトは882中、722であり、 今回は722のgo.jpドメインサイトを調査対象としました。

SSL/TLSプロトコル

まず最初に、go.jpドメインのサイトのSSL/TLSプロトコルのサポート状況を見てみたいと思います。ダウングレード攻撃やPOODLE攻撃で問題となるSSLv2、SSLv3をサポートしているサイトがかなりあることがわかります。まず最初に、全ての*.go.jpドメイン、つまり省庁と独法を合わせた接続可能な722サイトに対して、対応プロトコルをグラフにしました。

独法を除いた場合、333サイトが接続可能で、同様に対応プロトコルをグラフにしました。

ダウングレード攻撃で脆弱なSSLv2はかなり少ないですが、POODLE攻撃で脆弱とされるSSLv3が使えるサイトは未だに3、4割のサイトで利用可能になっていることがわかります。

暗号スイート(共通鍵暗号)

次に、暗号スイート(CipherSuite)のうち、使用可能な共通鍵暗号アルゴリズムについて見ていきましょう。最初に全*.go.jpドメインに対してです。

独法を除いた場合のグラフは以下の通りです。

どちらもAESはほとんどのサイトで利用できるようになっており、弱い暗号である3DESやRC4も8、9割のサイトで利用できるようになっています。また、国産の暗号であるCamelliaも2割程度のサイトで使えますが、SEEDやIDEAも同程度しかないというのは少し残念ですね。

ブロック暗号モードについては、GCMとCBCしかありませんが、全*.go.jpでのサポート状況は以下の通りになります。

また、独法を抜いた場合以下のようになります。

ブロック暗号を一切サポートせず、ストリーム暗号の暗号スイート、つまりRC4しかサポートしないサイトは無かったため、全数は722、333で同じになっています。

暗号スイート(鍵交換)

次に、暗号スイートで使われている鍵交換についてみてみましょう。

まず最初に気になるのが、スノーデンの暴露したNSAの盗聴問題をきっかけに、PFS(Perfect Forward Secrecy)をサポートする暗号スイートを使うことを推奨されるようになりました。 具体的にはDH、DHE、ECDH、ECHDEのいずれかを鍵交換に使う暗号スイートが推奨されています。 PFS、DH、DHE、ECDH、ECDHEの*.go.jpドメインでのサポート状況は以下の通りです。

独法を除いた場合、以下のようになります。

DHEやDHは処理パフォーマンスが悪かったり、長い鍵長をサポートする実装が少ないので、ECDHやECDHEを使えるようにして欲しいですね。

DH、DHEの暗号スイートで不十分な鍵長の脆弱なサイトが無いか確認するために、DHの鍵長別にサポート状況をみてみましょう。まずは全*go.jpドメインで見てみます。

独法を除いた場合、以下のようになります。

RSA 1024bit以下の証明書が使えなくなったのと同様にDiffie-Hellman(DH) 1024bit以下による鍵交換をするべきではないそうです。ただ、DH 1024bit以下しかサポートしない実装が多かったり、デフォルトでDH 1024bitであったりすることから、リスク回避のためにDHやDHEを使わないようにするのが良いと思います。

ECDH、ECDHEでは鍵パラメータ(=曲線名)はどうなっているでしょうか。まずは、全*.go.jpドメインで見てみましょう。

独法を除いた場合、以下のようになります。

ECDH、ECDHEをサポートする場合に、鍵交換で使われる名前付き曲線がNIST P-256(=secp256r1)なのは一般的だし、ブラウザでサポートされている事が多いのでいいですが、NIST B-571(=sect571r1)って世の中で使ってるところを見た事がなかったのでビックリしました。省庁の1サイトと独法の9サイトは先進的というか、デフォルトでは設定されず、意図的にやってるに決まってるので凄いなぁと思いました。そこにブラウザで繋いでみたんですが、TLS_RSA_WITH_RC4_128_SHAで接続してしまい残念orz。

暗号スイート(メッセージ認証(MAC))

世の中では、メッセージ認証に関してはMD5はダメ、SHA1からSHA2に移行している過程にあるのかなと思います。まず、全*.go.jpドメインについて見てみましょう。

独法を除いた場合、以下のようになります。

脆弱なHmacMD5を使った暗号スイートが利用できるサイトが4割近く残っているのは問題かなと思います。

SSL/TLS攻撃に脆弱なサイト

BEAST攻撃、POODLE攻撃、FREAK攻撃など、SSL/TLSプロトコルや暗号スイートの設定による脆弱性の影響をみてみましょう。全*.go.jpドメインでのこれらの攻撃の影響は以下のようになっています。 (少しグラフにゴミが入ったけど、まぁ、いっか)

独法を除いた場合、以下のようになります。

その他のSSL/TLSサーバーの設定

SSL/TLSでは接続する際、デフォルトではクライアントが提示する暗号スイートのリストの優先順位に基づいて、サーバーと使用する暗号スイートがされますが、これだと酷いクライアントの場合、脆弱な暗号スイートが使用されてしまう可能性があります。これを防止するために、設定によりサーバー側の持つリストを優先して使うようにすることができます。これが「サーバー側暗号スイート優先」です。ApacheであればSSLHonorCipherOrder "on"で設定できます。

OCSP Staplingとは、TLSの拡張でプライバシー保護と証明書失効検証の誤りへの対策です。 まずは全*go.jpドメインで見てみましょう。

独法を除いた場合、以下のようになります。

OCSP Staplingの導入はなかなか進んでいない現状がよくわかります。ただ、先進的な設定をしている政府系サイトもあることがわかります。

SSLサーバー証明書

全*.go.jpドメインのアクティブなサイトのサーバー証明書の発行元の 証明書発行サービスで分類したのが以下です。

独法を除いた場合、以下のようになります。

やはりVeriSignの比率がかなり高く、GPKI Application CA、GlobalSign、Cybertrustなども頑張っています。特に独法を除いたには、GPKI Application CA 2の比率もかなり高いです。 珍しい所ではServision、KAGOYA、Firstserver、AlphaSSLなどを使っているところもありました。 822枚のうちワイルドカード証明書は19枚、EV SSL証明書は24枚でした。

次に接続可能な全*.go.jp 723ドメインにおける、証明書の公開鍵アルゴリズムと鍵長についてみてみましょう。全てがRSA鍵であって、ECC鍵やDSA鍵はありませんでした。また、鍵長は2048bitがほとんどで、ほんの少し1024bitが残っており、4098bitなどの長いものはありませんでした。

また、723のRSA鍵について公開指数は全て65537(0x10001)でした。公開指数に3などが使われているために秘密鍵が入手できるといった問題があるサイトは0でした。

署名アルゴリズムについてはSHA256withRSA、SHA1withRSA、MD5withRSAのいずれかしかなく、SHA256withRSAの移行が30%以上とChromeやWindowsのSHA1の無効化が2017年1月に迫っていることから、SHA1からSHA2への移行はかなり進んでいます。

証明書の有効期間については、1年物、3年物、2年物の順に多く、10年物は1サイトのみでした。

Google Chromeが2017年1月までにSHA1証明書に対して段階的に警告を出していき、SHA2証明書への移行を促すというマイルストーンがアナウンスされていますが、有効期限がどの時期であるかを調べてみました。

有効期限が2017年1月を超える証明書が144サイトであり、Chromeでの警告表示を避けるためにSHA2証明書へのリプレースが必要になります。

また、証明書のOCSPによる失効検証、EV SSLサーバー証明書、Certificate Transparency(CT)のための組込みのSigned Certificate Timestamp(SCT)拡張のサポート状況について調べてみました。CTサポートが11サイトもあったのには、少し驚きました。

おわりに

以上、*.go.jp ドメインのHTTPSサイトについて自分なりに調査してみました。SSL Pulseとの状況と比較して、以下のポイントで若干コンサバティブというか古い設定になっているなという感じはします。

• GCMがあまり使われていない
• ECDHEよりもDHEが使われる
• EXP、DESなどの古い暗号スイートがかなり残っている
• SSLv2などもかなり残っている感じがする

サーバーがきちんと対応してくれないなら、クライアント側で最新のブラウザを使うなどで自衛するしかないのかなと思います。

今日はこの辺で。

追記

• 2015.03.11 08:34 - 3/4から3/11 0:00頃の更新を確認したらgo.jpドメインのHTTPSサイトは3つしか増えていないようです。そんなに頻繁に更新確認しなくてよさそうなので、ちょっと安心しました。現時点では証明書の調査項目が十分でないので、そのうち追加しておきたいと思います。
• 2015.03.12 00:11 - *.go.jpドメインのSSLサーバー証明書について調べた事を追記しました。
• 2015.03.12 07:55 - 証明書の調査でなぜ722から723に増えたかというと、HTTPS通信はできて証明書は取れるんだけど、対応暗号スイートを調べようとするとタイムアウトしちゃうサイトが一つあったため、こんなことになってます。

@raysato さんのTLを見ていたらTwitter社の人のブログを紹介していて、以下のようなエントリがありました。

REST API SSL certificate updates
https://dev.twitter.com/blog/rest-api-ssl-certificate-updates

TwitterはAPI用の証明書を切り替えるそうです。

まじかー。api.twitter.comの証明書を見てみると、 確かに有効期限が2013年12月31日までになっとるなー。

でもapi.twitter.comの証明書はちゃんとRSA 2048bit だからいいじゃんと思って 見てみたら、なるほどルートCA RSA 1024bit X.509v1証明書なんだね。そりゃだめだ。

認証サービスの共通ルールを作っているCA Browser Forumのガイド 「Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, v.1.1.5」というのが 出ていて

2013-12-31
CAs SHALL confirm that the RSA Public Key is at least 2048 bits or that one of the following ECC curves is used: P-256, P-384, or P-521. A Root CA Certificate issued prior to 31 Dec. 2010 with an RSA key size less than 2048 bits MAY still serve as a trust anchor.

とあります。RSA 2048bit未満のCAは使えなくなっちゃうんだなぁと。

やべやべ、明日の資料を作らないと。

自堕落な技術者の日記 : MD5証明書に警告を出すFirefoxアドオン - livedoor Blog（ブログ）

CodeFromThe70s.org
SSL BLACKLIST 4.0 Firefoxアドオン
SSL BLACKLIST Local Databse Firefoxアドオン
http://codefromthe70s.org/sslblacklist.aspx

インターネットでとある申し込みをしようとしたら、のけぞって「あちゃ〜〜〜」と加藤浩次のような声を上げてしまった。





ステータスバーはこんなの、、、、





うむむ、どうやら危殆化したDebianで作られた鍵を使っているようだ、、、、

どうやって申し込みますかね、、、、

このブログのコメント欄でなひ様に教えてもらった

CodeFromThe70s.org
SSL BLACKLIST 4.0 Firefoxアドオン
SSL BLACKLIST Local Databse Firefoxアドオン
http://codefromthe70s.org/sslblacklist.aspx

を早速インストールしてみました。

これは、以前ブログでも何回か書いたDebianが生成したOpenSSH,OpenSSL鍵の危殆化問題に対応して、やばい鍵に警告ダイアログを出してくれることを主目的としたプラグインなようですが、MD5withほにゃららの証明書をHTTPSで使おうとした場合にも対応しているようです。

とりあえずの自衛策としてはいいんじゃないでしょうか。






＃なんか、間違い探しみたいですか？！（＾＾；（謎）

警告ダイアログっぽくないですね、、、赤・黄色・黒なんか使ってババ〜〜ンとやってほしかったです。

ちなみに、ステータスバーは問題無い証明書だとこんな感じ、、、、




MD5証明書だとこんな感じの警告が出ます。

情報処理推進機構：情報セキュリティ：調査・研究報告書：情報セキュリティに関する脅威に対する意識調査 報告書

せきゅめもで書かれていたことも、IPA報告書もちょっと違うんじゃないかなぁと思いまして、ひとこと書いてみたいと思います。

IPAで行われたセキュリティの意識調査の報告書で被験者の方に以下のような質問をしており正解は「○」だったりします。

ブラウザの SSL の鍵マーク (サイトの証明書) を確認することは、偽サイトかどうかを見破るのに有効です

正解「○」

この問題の正解率は35.5%だったそうで、せきゅめもさんとこでは設問を勘違いしたのでは？という論調だったんですが、EV SSLサーバー証明書(以下EV証明書)を知っている人なら、この設問はあえて「×」をつけたんじゃないでしょうか？私も「×」だと思います。

EVができる前、とある米国の金融系サービスでHTTPSサイトなのにフィッシング詐欺を行うためのウェブサイトが初めて出現し話題となりました。例えば、本物の金融サービスサイトは

https://www.aaa-bank.com/

であるのにフィッシングサイトは以下のようになっていました。

https://www.aaabank.com/

どちらもHTTPSのサイトでありドメイン名も酷似しているサイトでフィッシングが行われたのです。ここでミソなのはフィッシングサイトの方もショボイ自己署名やプライベートルートではなくWindowsやFirefoxの信頼するルート認証局に入っているルート認証局から発行されたものであるということです。安物のサーバー証明書であるにせよ、騙す方も得するならきちんと投資するんですよね〜〜〜〜。

SSLサーバー証明書は通信しているウェブサイトとそのFQDNホスト名が一致している事のみを保証するもので、そのウェブサイトが非合法であろうがアダルトであろうがフィッシングサイトであろうが構わないわけです。ですから鍵マークがついているからといってニセサイトであるかどうかはわからないのです。

問題を引き起こす原因は以下の通り。

1. ドメイン名は運営主体組織の名称と何ら関係なくても取得することができる


2. そのドメイン名の持ち主であれば、本当の銀行のドメイン名に酷似していようがメール一本でSSLサーバー証明書を発行するような認証サービスがある

このような問題を解決するためにEV証明書が生まれました。EV証明書は運営企業の登記情報や企業活動拠点を確認した上で発行するので、この証明書でHTTPSフィッシングサイトを立ち上げてもすぐ足がつきます。従って逆に、安心して利用できる正式のサイトということになります。
登記された実体のある企業でも潰れる前とか悪いことしないとは限らないんですけどね、、、（＾＾；

というわけで鍵マークがついているだけでは安心ではなくて、ホスト名が正しいものかどうか、格安ではなくまともなところから出ている証明書かどうか確認したほうがいいんじゃないかと思います。でも、一般ユーザにこんなことをお願いするのって難しいですよね、、、、うちの家族は誰もEV証明書の事なんか知らないと思います(；´Д｀)

EVのウェブブラウザの実装でアドレスバーの色や証明書の表示だけでなく、whoisなどによるドメインの所有者の情報も表示するようになれば、より安心なんじゃないかと思います、、、、

全日空のCIO、搭乗システム障害について会見、「担当者の会話が不十分だったためのごく初歩的なミス」と反省の弁：ITpro

2点目は、暗号化認証機能ソフトの有効期限切れを見逃した担当者の確認ミスについてである。「有効期限切れを2回防げるチャンスがあった」（佐藤室長）。 2度のチャンスの1回目は、2005年のサーバー導入時である。当時から有効期限の設定を初期設定から100年後など影響が及ぼさないように変えておくべきだったと話す。

んん？これって100年有効なSSLサーバー証明書を使えばよかったって言ってるんでしょうか？！

ANAのシステム障害、原因は「認証機能の有効期限切れ」 - ITmedia News

せきゅめもさんとこでSSLサーバー証明書の期限切れだと書いてありました。

人がウェブブラウザなんかでHTTPSのサイトを閲覧する際のSSLサーバー証明書なんかは期限切れに気づきやすいんですけど、Webサービスなんかのシステムが自動的に利用するようなケースでは、SSLサーバー証明書やコードサイニング証明書の期限切れには気づきにくいですよね。

特にコードサイニング証明書の方は一般ユーザは見ることがないのでシステムの奥底でサードパーティーのライブラリとして使われていたり、JDKやJREのバージョンが古かったりした場合に期限切れでサービスが立ち上がらないなどの障害が起こりやすいですよね。

以前こうした問題がおきた際に、マシンに含まれているSSLサーバー証明書やコードサイニング証明書の有効期限の一覧を表示するようなツールを作った覚えもあります。

親切な証明書発行サービスなんかの場合には「期限切れに近づきましたよ〜〜〜」メールが来たりするもんですが、そういうのも無かったんでしょうね。