自堕落な技術者の日記

基本は喰ってるか飲んでるかですが、よく趣味でカラオケ・PKI・署名・認証・プログラミング・情報セキュリティをやっています。旅好き。テレビ好きで芸能通

I♡S/MIME(Mac、iPhone、Outlook 2013、Office 365のS/MIME署名暗号メールの設定与太話)

唐突ですが、私はS/MIME暗号メールが大好きだ。PGPが大嫌いなのに対してS/MIMEが大好きだ。何故ならばデジタル証明書が大好きだからだ。さらにはデータフォーマットがCMSやPKCS#7でありこれも大好物だからだ。S/MIMEは多くのメーラーで標準サポートされており奇妙なプラグインやソフトウェアを入れなくても、証明書さえあればすぐに使えるところが素晴らしい。こんな私に対して、最近首をつっこんでしまったインシデントレスポンスの世界ではPGPを強要される。標準でサポートするメーラーなど一つも無いのにもかかわらずだ。酷すぎる。 私にとある紳士がgmail.comアドレス用にパブリックなS/MIME用証明書を発行してくださった。(ありがたや、ありがたや) 本当は、Androidで良いS/MIME対応のメーラーを調べるために発行してもらったのだけど、幾つかみてみたものの結局ロクなメーラーは無かった。

最近、S/MIMEネタから遠ざかっていたが、今日からゴールデンウィークでもあり暇だし(本当はクソでかい宿題があるのだが全くやる気がおきず)、幾つか設定してみたS/MIMEメーラーについて紹介がてら徒然なるままに書いてみたいと思う。

注意:以下に書いたことは私の無知から間違っていることもあるかもしれないので、その時はいろんな方法で教えてください m(_ _)m

iOS 8.3 標準メーラー

前にも紹介しているがiOSの標準のメーラーはS/MIMEに対応しており、かなりしっかり作ってあり、AppleはPKIやSSLやS/MIMEに前向きで「良い会社だなぁ」と思う。

iOSで、S/MIMEを使えるようにするには、まずPKCS#12形式のS/MIME用証明書(と鍵)、必要な中間証明書などを、まずメールでiOSのデバイスに添付ファイルで送ってやる。添付ファイルを開くと、プロファイル設定の画面が出るので、これに従うとこれらがインストールされる。

iOS標準メーラーのS/MIME設定

次にメールアカウントでS/MIMEの設定をする。「設定>メール/連絡先/カレンダー>(S/MIMEを使うアカウント)>アカウント>詳細>S/MIME」で、S/MIMEをオンにして、証明書を選択する。あとは設定は好みだが、私は「署名=はい」「デフォルトで暗号化=いいえ」にして使っている。
smime20
smime21
smime22

iOS標準メーラーのS/MIMEメール受信

S/MIME署名暗号メールを受信するとこのようにアイコン表示され、正しい署名がついており、暗号化されて送られてきたことがわかるようになっている。差出人の箇所をクリックすると、メールの署名暗号化の状態が表示される。シンプルなインタフェースだが、まずまずの使い勝手だと思う。例えば暗号化のみのメールを受信した場合、以下のようになる。
smime16
smime17
署名暗号化されたメールの場合には以下のようになる。
smime18
smime19

iOS標準メーラーのS/MIMEメール送信

送信時は、先ほど設定した通り、全てのメールに対してS/MIME署名が付与されてしまい、メッセージ毎に署名の有無を切り替えられず、少し面倒だ。相手に暗号化してメールを送ろうとしたが、なぜかうまくいかなかった。前はできていたような気がするのだけど、、、

Mac OS X標準メーラー

Mac OS Xの標準メーラーもまたプラグイン不要でS/MIMEに対応している。 キーチェインに自分のメールアドレス用のS/MIME証明書(と鍵)、相手のS/MIME証明書を登録しておけば、送信時に署名や暗号化ができるようになる。

Mac OS X標準メーラーのS/MIME設定

アプリ「キーチェーンアクセス」を起動し、自分のS/MIME用証明書と鍵をインポートします。次に、標準メーラーを起動し、「環境設定」メニュー>「アカウント」タブを選び、なぜか「TLS証明書」の箇所で、登録した自分のS/MIME用証明書を選択します。
smimea01_

Mac OS X標準メーラーのS/MIMEメール送信

送信画面は以下のようになる。鍵やメダル (?)のボタンを押せば、暗号化、署名ができる。
smimea05_

Mac OS X標準メーラーのS/MIMEメール受信

受信した場合の表示は非常に地味で、詳細表示をしないと署名の有無がわからないのは非常に残念。 署名メール、暗号化のみのメール、署名暗号メールを受信した場合の表示はそれぞれ以下の通り。
smimea04_
smimea03_
smimea02_

Outlook 2013 for Windows

Outlook 2013のS/MIME設定

Outlook 2013のS/MIME設定はとてもわかりにくいところにある。もう、S/MIMEなんか使わせたくないんじゃないかと思うくらいだ。メニューの「ファイル>オプション>セキュリティセンター>Outlookセキュリティセンターの詳細設定>電子メールのセキュリティ」から設定することができる。証明書が設定されていれば、以下のようになる。
smime01
規定の設定の「設定」ボタンを押すと更に詳細設定ができる。
smime02
で、これみて気づいちゃいました。Outlook 2013 署名と暗号化のアルゴリズム設定が、まともになったんですよ。前は、Thunderbirdぐらいだけのもんだったんですけどね。署名のハッシュアルゴリズムはSHA1、SHA256、SHA384、SHA512、暗号化アルゴリズムはRC2 64bit、RC2 128bit、3DES、AES 128bit、AES 192bit、AES 256bitから選べます。すごいですよねぇ。さすがにDESはもう無くなりましたが、RC2はまだあるんですねぇ。古いメーラーとの互換性を気にするならSHA1、3DESのチョイスで、新しくて良いならSHA256、AES 128bitあたりがいいんじゃないですかね。

Outlook 2013のS/MIMEメール送信

Outlook 2013では、返信しようとするとき、メインウィンドウの中の右側に返信ウィンドウが表示されますが、あのままだとS/MIME使えないんですよ。も〜やる気あんのか?っていう。「ポップアウト」ボタンで別ウィンドウにしてから設定します。で、ポップアップしたとしてもですねぇ、署名、暗号化がとても探しにくい位置にあるんですよ。「も〜やる気あんのか!(Part2)」と。タブの「オプション>アクセス許可」なかにひっそりとあります。
smime04
これじゃ、あまりに寂しいので、リボンを右クリックして、リボンの編集機能で追加してしまいます。
smime03
ほら、メール送信ウィンドウから、すぐに署名、暗号メールが送れてしまいます。(素晴らしい)
smime05

Outlook 2013の連絡先のS/MIME証明書の登録

私の設定が間違っているだけなのかもしれないけど、Outlook 2013で署名メールを受け取ったら、自動的に証明書が連絡先に登録されるわけではなく、手作業でいちいち登録しなければならないようだ。非常に面倒臭い。(シンジラレナイ!)

送信先のS/MIME証明書ファイルを持っていないなら、S/MIME署名メッセージから取り出すことができます。Outlook 2013で署名メッセージを開き、赤いリボンをダブルクリックすると署名プロパティダイアログが表示されます。「詳細ボタン>署名者を選択>詳細の表示ボタン>証明書の表示ボタン>詳細>ファイルにコピー」でエクスポートすることができます。「も〜やる気あんのか!(Part3)」

送信相手のS/MIME証明書を登録しておくには、まず、Outlook連絡先のカードを開く必要があります。(これも非常に探しにくい。) 2通り開く方法があります。

  1. Outlookのメインウィンドウの下にある「連絡先」リンクを開き、対象の人をダブルクリックする。
  2. メインウィンドウで相手からのメールを開いている状態で、メールアドレスを右クリックし「連絡先カードを開く」を選択、「変更の保存先 Outlook 連絡先」をダブルクリック。
送り先の証明書を登録するには、上方真ん中の辺にある、「証明書」をクリックします。
smime06
先ほどダウンロードしておいた相手のS/MIME証明書をインポートして設定すると、こんな感じになります。
smime07

Outlook 2013のS/MIMEメールの受信

S/MIMEの署名だけのメール、暗号化だけのメール、署名暗号化されたメールを受信すると、メッセージの表示はそれぞれ下のようになります。
smime10
smime11
smime12
署名に問題があった場合には、ちゃんと警告も出ます。ただ、メッセージ一覧のところできになるところがあって、S/MIMEの時に赤リボンや黄色鍵が表示されるのはいいんですが、
smime08
PGP署名メールでも検証する気もないのに赤リボンが表示されるんですよね。これは如何なものかと、、、
smime09

Office 365 メール

Office 365のメールアプリでも標準プラグイン(アドオン)を使えば、ウェブアプリなのにクライアント側でS/MIMEに対応してしまう。アドオンはInternet ExplorerとFirefoxに対応しており、Chromeには対応していないようだ。

S/MIME用アドオンのインストール

画面キャプチャを撮り忘れてしまったのだが、メインウィンドウのメッセージを見る箇所で、S/MIMEメッセージの場合にリンクを辿っていけば、プラグインがダウンロードできる。"owasmime.msi"という名前のファイルだ。これをインストールしブラウザを再起動すればよい。

Office 365メールのS/MIMEメール送信

新規メールやメールの送信などで、編集ウィンドウを別ウィンドウにする。「…」のメニューがあるのでこれを開き、「メッセージオプションの表示」を選ぶと下記のダイアログが表示される。
smime13

ただ、何故かエラーができるようになってしまった。IE、FirefoxにかかわらずアドオンはWindowsキーストアの秘密鍵は読みに行こうとしているが署名ができない。また、送信先の公開鍵証明書も正しく選択できていないようだ。(前はちゃんと署名に成功した気がする。) ブラウザを再起動するなどすると復旧するかもしれない。

Office 365メールのS/MIMEメール受信

暗号メールを受信した場合には、場合によりWindowsキーストアの秘密鍵を使用する旨の確認ダイアログが出てから
smime14
別窓で暗号化メールが復号されて表示される。
smime15
アドオンの動作は私の環境ではとても不安定で、復号できたり、できなかったり、署名の赤リボンも表示されていたものが、最近全く表示されなくなってしまった。

おわりに

てなわけで、今晩はいくつかの手持ちのメーラーのS/MIME署名暗号メールの機能をみてみました。うまくいかないところもありましたが、ぼちぼち調べようとおもいます。ではでは。

関連記事

ISO/IEC 18014-4 Time-stamping services - Part 4: Traceability of time sourcesの制定について

苦節7年(といっても本当は自分の貢献なんか大したこと無いんですがorz)、自分も携わらせて頂いたタイムスタンプに関する日本発のISO/IEC国際標準が、ようやく制定されました。

ISO/IEC 18014-4 Information technology - Security techniques - Time-stamping services - Part 4: Traceability of time sources

マジ、うれしいっす。ちょっと泣きそう。ISO/IEC国際標準を制定するためのプロセスはここに解説があるんですが、本当に長い道のりです。

デジタルタイムスタンプとは

国際標準時って昔はイギリスのグリニッジ天文台の時間を使ってたんだけど、今は幾つかの国の原子時計の時間を比べながら、地球の回転(正しくは公転周期)なんかも考慮しながら協定世界時(UTC)という標準時間を作っています。

パソコンの時間って、NTPとかで自動的に合わせている人も多いけど、無理やり設定することもできますよね。例えば、同じような発明を2人がほぼ同時した時に、パソコンで時間戻して、ワードで発明資料を保存して、「オレの方が先に発明してた〜〜!!ファイルの更新日時見ろ〜〜っ!!」とかね。パソコンの時間って全くあてにならないから、データの存在時刻もあてにならないわけです。

医療、裁判、株取引、銀行業務、特許など、いろんな業務の電子化が進んでいるんですけど、デジタルデータはコピーや変更が簡単という性質があって、そのデータが本物かどうか、本当にその時間にあったかどうかが大切になるんですが、時間を証明するのって難しいんですよね。

これを解決するのがデジタルタイムスタンプという技術です。あるデータがある時刻に存在していて、それ以降変更されていない事を示すために、データを区別するための拇印のような情報であるデータのハッシュ値をタイムスタンプサービスに送ると、そのデータの存在証明、つまりデジタルタイムスタンプを作って送ってくれるというものです。日本でもこのようなデータの存在時刻を証明する時刻認証事業者、日本標準時からの誤差を保証しながら時刻を配信する時刻配信事業者が生まれサービスが開始されました

各国国際標準時とのトレーサビリティーの必要性

こうした中、デジタルタイムスタンプのフォーマットについては、ISO国際標準があるので問題ないのですが、発行されるタイムスタンプが、各国の国際標準時と比較してどれくらいの精度で発行されているのかを保証する仕組みがありませんでした。タイムスタンプ局は、自分の持つ時計を元に、タイムスタンプを発行することができますが、これが無いと、各国の国際標準時と連携しているのか、どれくらいの誤差範囲で提供されるか保証や監査ができないものは、お互いの国で信用ができないからです。

そのようなわけで、各国の標準時を起源として、時刻の精度のトレーサビリティが保証および監査できないと、その国のタイムスタンプは信頼できないという話になるため、まず日本でJIS規格を制定し、うまくいけば、これをISO国際標準にしましょうという話になりました。

私の個人的な時刻トレーサビリティーの興味と今回の策定の関わり

私はその頃、タイムスタンプ付きの署名フォーマットである長期署名に興味があり、PKI方式タイムスタンプを採用する事業者が、タイムスタンプトークンに含んでいる、時刻監査証もしくは時刻監査記録と呼んでいる、時刻のトレーサビリティーを示すX.509v2属性証明書に着目していました。当時懸念に思っていたのは以下の事柄でした。

  • この時刻監査証(TAC: Time Audit Certificate)という属性証明書とその証明内容は利用者が検証する必要があるのか、無いのかが明らかになっていなかった。そもそもデータ・フォーマットや検証に必要な情報は公開されていなかった。
  • この時刻監査証はASN.1として誤ったエンコーディングをされていた。
  • 時刻監査証に誤りがあった時に、利用者はそのタイムスタンプトークンを無効とすべきか否かが規定されていない。
認定基準を定め監督管理する団体、タイムスタンプ関係の事業者の専門家方、電子署名の専門家、国際標準の専門家の方と議論させて頂き、 2009年、日本データ通信協会で「タイムスタンプ局に対するUTCトレーサビリティ保証のTA技術要件に関する検討 中間報告書」にまとめて頂きました。私は4.3節「TACの課題と結論」を執筆させて頂いております。

当時の私の疑問に対する識者コンセンサスは、

  • デジタルタイムスタンプの利用者は時刻監査証を検証する必要はない。
  • 時刻監査証のASN.1エンコーディングはASN.1に準ずるようサービスを修正する。
  • 時刻監査証に誤りがあった際に、利用者はそのタイムスタンプトークンを無効とする必要はない。
ということで納得しました。

ただ結局、タイムスタンプ事業者のTP/TPSタイムスタンプポリシ/運用規定では、時刻監査証のASN.1シンタックスが公開されず、時刻監査証は検証不要であることが明記する所、しない所があったりといった状況です。(ちょっと残念)

JIS X 5094:2011という時刻トレーサビリティに関するJIS規格の制定

その後、その中間報告書をベースに、日本国内で日本標準時からのタイムスタンプのタイムスタンプの トレーサビリティーを保証するためのJIS規格が2011年に制定されました。(これは、これで結構大変だった。)

JIS X 5094:2011 UTCトレーサビリティ保証のためのタイムアセスメント機関(TAA)の技術要件

中間報告書をベースにこれがJIS規格になり、日本データ通信協会で認定を受けている、時刻配信事業者や時刻認証事業者が当たり前のように行っていたことが、JIS規格として後ろ盾を持つことができるようになりました。

日本標準時とのトレーサビリティーの標準化で面倒だったのが、タイムスタンプサービスの標準がISOにはあるのにJISには無かったことです。このことで、タイムスタンプサービスを参照せずに、JIS化する必要があり、用語など手間がかかりました。

そして、今回のJISからISO/IEC規格へ

そして、世界各国のタイムスタンプが互いに信頼できるようにするために、言い換えると、世界各国の標準時とのトレーサビリティを持つ時刻配信が信頼できるようにするために、標準時からのトレーサビリティを持つ時刻配信のJIS標準をISOに持って行くことになり、ISOのドラフト版を作成しました。

関係者いろいろな伝をあたって頂き、暗号セキュリティ関係のISO/IEC SC27でお世話になることになり、SC27会議で正式に受理されました。

丁度、ISO/IEC 18014シリーズのタイムスタンプサービスのISO/IEC標準を見直す時期に来ていたそうで、これ幸いと、持っていったら追加でPart 4として標準化良いのでは?という事でワーキンググループが立ち上がりました。

その後、表現や細かい文言の修正など関係者の協力のおかげで、数多く対応してきましたが、私に関係するところとしては、当時nCipher製品でサポートされていた、PKI方式で電子署名された時刻監査証について参考情報として掲載したのですが、米国ではXML形式の電子署名されないデータを監査証として使っていました。先行するサービスの監査情報に適用できないのはまずいということで、これも比較できるよう掲載し、各項目の対応関係の補足説明を追加させていただきました。

後は、本当に長い時間のかかる、表現や文言の調整で、単に英語表現の問題だけではなくて、ISO/IECにふさわしい英語表現というのがあるようで、本当にWGの英国の方には細かく見ていただけました。

もうすぐ、承認されるかも、されるかもと、言っては、国際会議で流れ、また手直しをし、2014年10月のSC27メキシコ総会でPublishしてよいとの承認を頂いたそうです。それで、みな1月頃にはでるんじゃないの?と心待ちにしていたんですが、結局は4月になっちゃいました。

今後のISO/IEC規格からJISへ

JIS規格からISO/IEC規格にする際に、何点か国際間の整合を取れるような改正をしています。ISO/IEC規格は、翻訳さえすればそのままJIS規格にすることができるルールになっているそうです。ただ、関係省庁にお伺いをたてたところ、このUターンのJIS化は、今年は実施せずに、来年がJIS X 5094:2011が制定後、ちょうど5年になり見直しの年になるので、来年にやりましょうという話になったそうです。

盛大に祝杯をあげねばっ!!!

参考リンク

メキシコの会議報告が見つからないなぁ。しかし、会議報告の置き場所がバラバラだったり、一覧になってないのは何でなんですかねぇ。

標準ドラフト、NBコメント等一覧

年月日番号文書名
2011.05.31N 10047Call for contributions to the proposed new project
2011.06.16N 9659Text for ISO/IEC 1st WD
2011.09.05N 10225Summary of NB comments on document SC 27 N9659
2011.09.20N 10388UK NB comments on document SC 27 N9659
2011.10.03N 10328Draft disposition of NB comments on document SC 27 N9659
2011.12.12N 10425Text for ISO/IEC 2nd WD
2011.12.12N 10426Disposition of NB comments received on SC 27 N9659 - 1st WD
2012.04.13N 10851Summary of NB comments on document SC 27 N10425 2nd WD
2012.04.27N 11060Draft disposition of NB comments on document SC 27 N10425 - 2nd WD
2012.06.06N 11173ISO/IEC 1st CD
2012.06.06N 11174Disposition of NB comments received on document SC 27 N10425
2012.09.12N 11485Summary of voting on document SC 27 N11173
2012.10.05N 11613Draft disposition of comments received on document SC 27 N11173 1st CD
2012.12.14N 11808ISO/IEC 2nd CD
2012.12.14N 11809Dispositions of NB comments received on document SC 27 N11173 1st CD
2013.03.26N 12185Summary of voting on document SC 27 N11808 2nd CD
2013.04.08N 12341Draft disposition of comments received on SC 27 N11808 2nd CD
2013.06.10N 12567Text for ISO/IEC DIS
2013.06.10N 12568Disposition of comments received in SC 27 N12185 on document SC 27 N11808 2nd CD
2013.07.02ISO/IEC DIS

DIS以降も改変があった記憶があるんですが、それはN番号つかないのかな?

(小ネタ)来月にはSHA2証明書の枚数がSHA1を追い越しそうな件

SSL Pulse の 2015年4月版が公開されましたね。いつもは2ヶ月に1回状況報告しようとしていたんですが、SHA1証明書からSHA2証明書への移行が気になってたので、証明書の鍵や署名アルゴリズムの移行状況だけグラフにしてみました。SHA1証明書が51%、SHA2証明書が48%とかなり近づいています。
sslpulse201504-keysig
同じように推移したとすると、2015年5月にはSHA1証明書の数がSHA256証明書の数を追い越しそうですね。

関連記事

世の中のDSAやECDSA公開鍵のサーバー証明書の利用状況

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

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

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についてはいろいろ深く突っ込んで調査しており、どこかで吐き出したいんですが、雑務に追われなかなかチャンスが無いなぁ。

ChromeのSHA1証明書対応計画の一部延期(2015年3月12日発表)

2015年3月12日、Googleのフォーラムで、 Chrome開発チームでクロスプラットフォームの暗号・PKIコアの開発を担当しているRyan Sleevi氏から、 Chrome 41のリリースをSHA-1証明書の警告表示のマイルストーンとしていたものを Chrome 42に遅らせるとアナウンスがありました。

具体的にChromeバージョンとリリース時期と表示される警告アイコンは、以前の計画では 以下のようになっていたものが
chromesha1-1
以下のようにChrome 41の箇所がChrome 42で変更が反映されるようになり、 1ヶ月半スケジュールが遅れるようになったという事です。
chromesha1-2

SHA1証明書警告表示の影響有無の簡単な確認方法

あるサイトがSHA1証明書の警告表示の影響があるかどうかは、 簡単に確認できるツールを提供しているところが2つほどあります。

このDigiCertのやつはオススメで確認したいドメインを入力し「LOOKUP」ボタンを押せば、各Chromeのバージョンでどのように警告表示されるのかわかります。
chromesha1-3
(出典:DigiCert SHA-1 Sunset Tool)

証明書発行サービスの対応状況

2015年3月7日のGoogleからの発表を受けて、 2015年3月17日時点で証明書発行サービス各社が、掲載情報を更新したかどうか 調べてみました。

おわりに

以上、3月12日のGoogleからの発表を受けて、遅くなりましたが、 Google ChromeのSHA1証明書警告表示の一部延期について説明しました。 今日はこの辺で。

追記1

おっと、一言言い忘れた。GoogleのSecurity-devフォーラムでちょっと書かれたやつを以て、こんな大事な事を「アナウンスした」とするのは、Googleさんはちょっと誠意がなさすぎるし、ひどすぎるなと、、、せめてChrome Releasesのページなどでは紹介して欲しいし、ブログでも整理して解説して欲しいし、日本語の公式な情報も欲しいなぁと思いました。

最新記事
Categories
Archives
Twitter
記事Google検索

本ブログ内をGoogle検索
Yahoo!アクセス解析
Travel Advisor
記事検索
QRコード
QRコード

  • ライブドアブログ