Baseline Requirementとは？

09.05.12 / 未分類 / Author: aico / Comments: (0)

2011年に偽造証明書が発行されるという事件がありました。

発行されてしまったのはComodo社とDigiNotar社の偽造証明書。
Comodo社のケースではGmailやskypeなどの偽造証明書が、
DigiNotar社のケースではなんと531件の偽造証明書が発行されてしまい、
DigiNotar社は事業継続が困難になり倒産に追い込まれてしまいました。
どうしてそのような事件が起きてしまったのでしょう？
まずComodo社のケースから見てみましょう。

認証局(CA)は、
申請者の情報を確認し発行する前の審査を行う登録局(RA)と
審査の結果を受けて証明書発行のみ行う発行局(IA)に分かれます。
1つの認証局が両方を行う場合もありますが、
Comodo社では事件の起きた2011年時点では登録局の業務を外部に委託しており、

Comodo社では認証を簡素化するために自動発行を行っていたため、
登録局がハッキングされ偽造証明書が発行されてしまいました。

一方、DigiNotar社では、ComodoHackerと名乗る人物が
DigiNotar社のシステムへのパスを不正に入手、
証明書を発行のための情報を得て偽造証明書を発行しました。

GoogleなどのWebブラウザには認証局が自ら署名して発行する
ルート証明書があらかじめ組み込まれています。
このルート証明書を使ってコンピュータはwebサイトに発行されている
証明書が正しいものなのか確認しています。

今回のケースでは偽造証明書は、ルート証明書が登録されているDigiNotar社の
証明書として不正に発行されてしまっていたため、信頼できる証明書として扱われてしまっていました。

なぜ偽造証明書に気づいたかというと、Google ChromeがGoogleのサイトのみ
各ページの証明書を発行するルート認証局の一覧を所持する機能をサポートしていたため、
偽のGmailのページにつけられたDigiNotarの証明書に対してセキュリティ警告したためでした。

それまでに実に531件もの偽造証明書が発行されてしまったため、
Google Chromeを始めとするWebブラウザベンダーによって
DigiNotar社のルート証明書がリストから削除されてしまい、
DigiNotar社は事業継続が困難になり倒産に追い込まれてしまいました。

実は、原則的には認証局は誰でも作ることが出来ます。

各認証局ごとに安全性への取り組みは異なりますが、
信頼できる証明書とは認証局が考える「PDCA」を遵守して発行される必要があります。

PとはPlan(企画・計画)。

認証局はそれぞれの証明書を発行する際の運用規定をまとめたCPSを制作し、
ホームページ上でまとめています。

DとはDo(実行)。

CPSに従って運用を行います。

CとはCheck(評価)。

定期的にセキュリティの脆弱性アセスメントを行い結果を監査報告します。
また、外部監査も行います。

AとはAction(改善・見直し) 。

セキュリティの促進やインシデント(問題)が起こった時のルールのドキュメント化などを行います。
ベリサインではこのようにCPSによって認証の運用規定を作成し、運用を行っています。

しかし、ComodoやDigiNotarの偽造証明書発行事件が起こってしまいました。
事件が起きた当時、業界全体での運用規定をまとめた文書の作成を行う議論が進んでいましたが、
この事件がおきたことで議論が加速し、
業界全体での運用規定をまとめた文書、Baseline Requirementが調印されることとなりました。

Baseline RequirementはCA Browser Forumによって制定されました。
Baseline Requirementは、それまでCPSによってそれぞれが定めていた運用規定を
業界でまとめた初の試みで、2012年の7月から発行されます。
ベリサインやジオトラスト、グローバルサインや、IEやsafari等の主要なCAとブラウザベンダーが
サインをしているため、Baseline Requirementに準拠しない場合は
ブラウザの信頼されるルート証明書から除外される可能性があります。

Baseline RequirementはベリサインのHPにて近日公開予定のようです。

常時SSLとは？

02.05.12 / 未分類 / Author: aico / Comments: (0)

先週、ベリサインさんでカンファレンスがあったので参加してきました！
その中で常時SSLとbaseline requirementについてもお話があったので、
自分でも調べてまとめてみました。

SSL証明書はこれまではログインの画面や、ネットでのショッピングの際に
選んだものが表示されるショッピングカートのページのみにつけられていました。
常時SSLとは、ログイン画面などだけではなく、
トップページ等ユーザが訪問する全てのページでHTTPS通信を行うようにすることです。

Firesheepなどwifi通信で暗号化されていないセッションを自動的に検出してcookieの
情報を読み取るツール等が出現したことが原因です。

cookieを使うと一度訪問したwebサイトにもう一度訪れた時に、
cookieの情報をもとにwebサイトはユーザを識別することが出来ます。

例えば、何回訪問したかといった情報や、ログイン情報を記憶し入力を省略したり、
見たページから好みに合いそうな商品や広告を表示することができます。

さらに、cookieにはセキュアcookieというものがあります。
セキュアcookieにすると受け渡しするのは暗号化されているhttps通信の時のみにすることができます。

Firesheepはカフェやホテル等、オープンなwifiを通じて
firesheepが登録しているサイトに、暗号化されていないhttp通信でログインしている
ユーザのcookieの情報を簡単に見ることが出来てしまいます。
さらに情報を見るだけではなくその情報を使ってなりすましてアクセスすることだって出来てしまうのです。

そのため全てのページにSSLをかけてhttps通信にすることで
情報を暗号化して守ろう！というのが常時SSLです。Firesheepは暗号化されていないセッションを検出するものなので
https通信にすることでcookieの情報を守ることができます。

すでに常時SSLを実装しているサイトとして、twitterやFacebook、Google等があります。
GoogleではGmailとGoogleAppのユーザ向けに、
Facebookでは選択可能になっていますが約2割のユーザが常時SSLを選択しています。

やりとりをする情報が重要なサイトやログインするユーザの多いサイトでは
セキュリティは常に意識して運営していきましょう！

SANsとは？ワイルドカード証明書とは？

13.04.12 / こあくまのSSL日記, 未分類 / Author: aico / Comments: (4)

社会人になってからあっという間に２週間がすぎました。
覚えることがいっぱいでなんだか毎日があっという間に過ぎていきます。

先日、VeriSignさんと打ち合わせがありました。
VeriSignさんとは何度かお会いしていますが、今回は社会人になって初めての打ち合わせ。
知らない言葉もたくさん出てきたので自分なりに調べてみました。

今回はSANsとワイルドカード証明書についてです。

普通、サーバ証明書はコモンネーム１つにつき、サーバ証明書を１枚申請します。

ワイルドカード証明書とSANsは１枚のサーバ証明書で複数のコモンネームへのSSL通信を可能にする方法です。

ワイルドカード証明書はコモンネームを、「*.usausa.usa」のように
アスタリスクをサブドメインに相当する階層に記載した形で申請します。
すると、ワイルドカード証明書は複数のサブドメインを使用しているサイトで
それぞれのコモンネームでサーバ証明書を取らなくても１枚のSSLサーバ証明書で
httpsアクセスを有効にします。
ただし、アスタリスク(＊)の後ろのドメイン名は同一である必要があるため、
たとえば、www.usausa.netのようにドメイン名が違うとまた別にSSLサーバ証明書を取得する
必要があります。
→現在ベリサインでは発行していません。

SANsはコモンネームをwww.usausa.usaで申請し、SANsにusausa.usaを登録すると、
１枚のサーバ証明書でwww.usausa.usaとusausa.usaの両方でhttps通信を有効にすることが出来ます。
SANsはワイルドカードとは異なり、SANsに登録すれば同一ドメイン名でなくてもSSLが有効になります。
→ベリサインでは2012年6月15日以降の申請からSANsフィールドを追加するそうです。