加えて、LINEでは、仮に通信ネットワークの傍受が行われたとしてもメッセージを覗くことができないように、公開鍵暗号(public key encryption)方式を使っています。ユーザーに対してLINE アプリを提供する際、暗号化ができる公開鍵のみをアプリに入れて提供し、ユーザー端末とサーバが接続されたときだけLINE サーバでのみ解析できる暗号化された安全なチャネルを作ります。こうすることで、SSL(Secure Socket Layer)より軽く、LINEの全バージョンで使用できる安全な暗号化を実現できます。

SSL はすでに時代遅れの代物で、 2015年秋現在は皆さん TLS を利用されていることでしょう。 Web ブラウザで SSL 2.0 や SSL 3.0 を有効にしているそこのあなた、今すぐ無効にしましょう。

TLS では、公開鍵暗号方式や共通鍵暗号方式、電子証明書、暗号学的ハッシュ関数といった複数の暗号技術要素を組み合わせて安全な通信路を確保しています。

RSA に代表される公開鍵暗号方式は一般的に AES に代表される共通鍵暗号方式と比べて計算量が大きい、つまり重たい処理となります。

このため TLS では、通信路を流れるデータの暗号化に共通鍵暗号を用いて、共通鍵の共有や相手の認証のために公開鍵暗号方式を用いるのが一般的です。

仮にメッセージの暗号化に RSA を用いているとしたら、 SSL より軽いという点をどのように実装しているのか気になります。

http://developers.linecorp.com/blog/ja/?p=3591 より引用、2015年 10月14日 22時40分に閲覧：

ユーザー側のLINE アプリ(クライアント)には、サーバが発行したRSA鍵を使用してデータの暗号化に使う暗号化鍵値を共有します。この鍵を利用してデータを暗号化すると、第三者はメッセージを見ることができなくなります。

これは上で説明したとおり SSL や TLS でも行っていることです。

RSA を用いているので安全であるという主張をしていますが、メッセージの暗号化に用いられている暗号スイート（アルゴリズムの種類、鍵の長さ、ブロック暗号の場合は暗号利用モード、そしてハッシュアルゴリズムの種類）は、その通信路が安全であると判断できるか否かを決める大切な情報です。

http://developers.linecorp.com/blog/ja/?p=3591 より引用、2015年 10月14日 22時40分に閲覧：

既存のRSA 方式も秘密データの共有に使う安全な方式ではありますが、鍵管理の面から見ると、ユーザー側の端末でそれぞれのRSA鍵をすべて管理しなければならないという問題があり、その代替手段としてDHを使用するようになりました。

DH および ECDH による共通鍵暗号に用いる鍵の交換は SSL や TLS でも実装されており近年では広く使われています。 SSL より軽いと主張し、 SSL や TLS が公開鍵暗号方式以外の要素によって担保している安全性をどのように確保しているか不明な実装に比べると、大きな改善です。

なお SSL や TLS においては通信相手の公開鍵を全て管理する必要がないように、上で説明した電子証明書による公開鍵基盤 (PKI) の仕組みを利用しています。

つまり共通鍵暗号に用いる鍵の交換にどのような手段を用いるかは、鍵管理とは（ほぼ）独立です。

共通鍵暗号と暗号利用モード

http://developers.linecorp.com/blog/ja/?p=3591 より引用、2015年 10月14日 22時40分に閲覧：

ここでメッセージの暗号化に使用している暗号化アルゴリズムはAES-CBC-256という方式で、現在一般に使われている暗号化アルゴリズムの中で最も強度が高いと評価されています。

メッセージ認証と組み合わせない CBC はビット反転攻撃に弱いことが知られています。 GCM ではデータの暗号化と認証を同時に行うためビット反転攻撃に耐性があります。 AESを GCM で利用するのは、最近の TLS の実装では広く用いられており、 Google や twitter も利用しています。

CBC も CBC-MAC のようにメッセージ認証と組み合わせることでビット反転攻撃に強くなります。

解決されない鍵管理 問題

図6 のとおり、 ECDH で共通鍵暗号に用いる鍵の交換を行うにしても通信相手の公開鍵は必要です。上で説明したとおり鍵管理という問題への解決策になりません。また公開鍵が本当に通信相手のものであることをどのように検証するのかについても不明です。通信相手の検証は、送信側では秘密の話を他の人に知られないように、受信側では他の人になりすまされないように、双方にて必要です。

ここからは安易なパターンの想像ですが、通信相手の公開鍵情報は LINE ユーザー情報の一部として LINE サーバーで管理されており、必要に応じて安全な通信路を用いて LINE サーバーから取得するようなものではないかと思います。公開鍵情報のやりとりに用いられる通信路に正しく実装された TLS が用いられていて、サーバーとクライアントの両方が認証されていて、現在の水準から見て妥当なレベルの暗号スイートが用いられていることを願うばかりです。

公開鍵と秘密鍵がどこでどのように保管されているのか気になります。各端末で保管するのが安全ですが、サービスの要求として端末を乗り換えてもメッセージが読めるという条件を安易に満たすために秘密鍵を LINE サーバーに預託していないことを祈るばかりです。

ECDH 鍵の生成は計算量が大きい処理であり質の良い乱数を必要とします。 PC に比べると非力なスマートフォンで生成した鍵の質をどのように担保しているのか気になります。

2015年 10月17日 10時16分追記

先ほど閲覧したところ、上記引用箇所の多くは削除されていました。公開鍵が本当に通信相手のものであることをどのように検証するのかについては明らかではないようです。 LINE サーバーが介在する形であれば、鍵をすり替えることで別のユーザーになりすますことが可能でしょう。または、 LINE アプリに何か細工をする方がより簡単でしょう。

ECDH 鍵はその場限り (ephemeral) という説明がないので Perfect Forward Secrecy ではないと考えられ、望ましくないという意見もあるようです。 LINE サーバーとの間に安全な通信路を確立する目的で ECDH 鍵を用いる場合、 LINE サーバーが用いる秘密鍵の漏洩は全てのユーザーに影響を与えうるため PFS は非常に重要です (TLS を用いた Web サーバーでも同様です) 。一方ユーザー間でメッセージを暗号化する場合、ユーザー所有の ECDH 鍵についてはそのユーザーに影響が限定されます。通信相手ごとに必要なその場限りの鍵生成とユーザー所有の ECDH 鍵を利用した鍵交換にかかる計算量と ECDH 鍵漏洩のリスクを天秤にかけて PFS を採用しないという判断かもしれません。

通信の秘密という観点ではメッセージの内容だけではなく誰と通信したか (または、していないか) という情報も守りたくなります。宛先を LINE サーバーで確認できない形に暗号化されるとメッセージの配送ができなくなるため、通信相手や通信の有無については秘密ではないと考えられます。

Permalink | 記事への反応(0) | 00:27

2015-10-10

■proxytunnel を Apache2.4 で使う方法について

一般的に外に出るために HTTP proxy 他を経由する必要があってしかも HTTP と HTTPS くらいしか通らないし、443/tcp で ssh を上げても proxy で弾かれるみたいなネットワークが存在する。

そんな場合に良く使われる proxytunnel(http://proxytunnel.sourceforge.net/) というソフトがあり、 Apache を SSL で HTTP proxy としても動作させて特定の ssh 等の port に接続させることで SSH over HTTPS を実現することが出来る。(proxytunnel で HTTP proxy を二段経由させた後で SSH に接続する)

ただし Apache2.2 では SSL での HTTP proxy の動作にバグがあり、上記を実現するために proxytunnel 用のパッチを適用しておく必要があった。(https://bz.apache.org/bugzilla/show_bug.cgi?id=29744)

このバグは Apache2.4 において修正されている筈なのであるが、何故か Windows の proxytunnel で接続出来ないという現象が起こったのでその対処法を書いて置こうと思う。

proxytunnel の最新版は上のページの通り 1.9.0 で Windows 用のcygwin ビルドもあるのであるが、

Debianなどのパッケージでは 1.9.0+svn250-5 までバージョンが上がっている(https://packages.debian.org/ja/jessie/proxytunnel)

そしてこの 1.9.0+svn250-5 だとパッチ無しの Apache2.4 で問題なく動作するのだ。

なのでこの 1.9.0+svn250-5 のソースを持って来て cygwin 環境で Windows 用にビルドするのが解決策となる。

cygwin でのビルド自体はライブラリが揃っていることと、manページの生成でエラーが出るので本体のビルドだけにしておいた方が良いこと以外はとくに特殊なことは無かった。

元のcygwin ビルドと同様にcygwinのdllを同じ場所に置けば元と同様に使用可能である。

Permalink | 記事への反応(0) | 20:10

2015-09-05

■悪質勝手 登録 出会い系サイトcommunity site @ dkij2.b3qzt.com

配信停止依頼しようにもドメインがデタラメでたぶん単純な返信メールには応じなさそうだし、

しかも無事Web フィルタリングソフトを突破できても

配信停止依頼にはこちらのメールアドレスを晒してメールを送らないといけないので、晒しておきますね。

※特商法ではありません

※ビジネス上の公開情報

http://dkij2.b3qzt.com/special.php?special=3&s=1441443363&code=def&ssl=1441443363&ssl=1441443363

《運営者》

dkij2.b3qzt.com事務局

《メールアドレス》

info@dkij2.b3qzt.com

ドメイン名義：Whois Privacy Protection Service by onamae.com

Permalink | 記事への反応(0) | 17:56

2015-08-19

■GIGAZINEのシークレットクラブに迂闊に登録してはいけない

先月、GIGAZINEのプレゼント企画があったんだけど、

http://gigazine.net/news/20150718-present-summer-2015/

当選者発表の期日過ぎてもGIGAZINE から連絡は無いから当たり前のようにプレゼントはハズレ（というか応募忘れてた）。

その代わり、「GIGAZINE シークレットクラブ無料体験コード」なるものが届いた。

GIGAZINE シークレットクラブは、まあ簡単に言うとGIGAZINEをもっと便利に使えますよ、有料だけど。というやつで、

そういや応募時のアンケートにそんなのあったなーと思って試しに使ってみたんですよ。

そしたらユーザー登録の画面、SSLじゃねえのな。

メール、ユーザー ID、パスワード、ダダ漏れ環境なのな。

セキュリティ関係の情報をも発信するGIGAZINE様がそんなんでどうするんだって話だ。

プレゼント当選しなくてよかった。

きっとあいつら、個人情報そのうち流出させるぜ。

Permalink | 記事への反応(0) | 10:04

2015-08-07

■一体なんだよこの記事

http://webbingstudio.com/weblog/cms/entry-773.html

知ってか知らずかちょっとこの記事ひどいので、突っ込む。

共用SSL証明書が当たり前？

小規模の商用サイトでは、フォームを暗号化する際には、共有SSLを利用するのが当たり前となっています。独自ドメインのSSL証明書を取得すると、フォームを通して得られる収益よりも、維持費の方がはるかに高くなってしまうからです。

とこの記事では書かれていますが、一体どこで「当たり前」なんでしょうか？

SSL証明書の取得費用は、サーバーホスティングによって額がまちまちなのは確かですけれども、

安く独自 SSL証明書を取得して利用できるサーバーホスティングは山ほどあります。

WEB制作者として「自分が良く知っているだけ」のサーバーのレンタルをクライアントに押し付けてはいませんか？

また、小規模商用サイトにしても、仮に年額35,000円のSSL証明書をつけ、かつ、月額3,000円のサーバーを借りていたとすると

月額でいえば6,000円くらいの負担ですが、

いくら小規模とはいえ、広報活動の中核をなすWEBサイトであるならば、

月額6,000円をペイできないとすると、

ちょっと商用サイトとしては破綻しているように感じます。

（というか、効果測定をしていないだけ？）

改ざんの認識

共用SSLのリスクに関して言えば、この記事が引用している、高木浩光氏の書かれている通りではあります。

cookieを取得できてしまうという点においては。ですね。

で、その部分の帰結が、完全におかしい。

cookieが取得できてしまう結果として、一番最初に狙われるのは、管理画面へのログイン。

いわゆるセッションハイジャックです。

ログイン状態を乗っ取られた時点で、どんなCMSでも、WEBサイトの改ざんは可能です。

なぜか。

CMSは「コンテンツをマネージメント」する仕組みで、

そのコンテンツは多くの場合 MySQLに代表されるDBに保存してあります。

したがって、ファイルの改ざんなどを行わずとも、WEBサイトの内容は書き換えることが可能なのです。

WEB アプリケーションの仕組みに明るくない方が読むと

「なるほど」と思ってしまうかもしれないので、

早々に訂正していただきたい。

また、この記事にある a-blog cmsというCMSについてはよく知りませんが、

多くのモダンなCMSでは、ほとんどの管理画面ログインにおいて、

セッションハイジャックに対する防衛は行われていますので、

cookieの取得が、即WEBページの改ざんに繋がるような書き方も、

CMS 利用者に対して、誤解を広げる結果になりそうですので、

ここも早々に訂正していただきたい。

CMSを過信していないか？

この筆者さんは、a-blog cmsというCMSを利用されているようだ。

このCMSはどうやら、PHP製ながらPHPのソースを暗号化しているようだ。

なるほど、それならばファイルの改ざんは確かに起きにくい。

が、それはあくまで起きにくいだけの問題。

こう言ってはなんですが、攻撃者にしてみれば、a-blog cmsを攻略するくらいならMovable TypeやWordPressを攻めた方が楽というものです。

この記述はむちゃくちゃである。攻撃者にしてみれば、誰でも手に入れられるCMSであれば、

ファイル構造の解析はそんなに難しい話ではない。

a-blog cmsの公式サイトを拝見すると、MySQLを利用しているようで、

ともすれば、インストールさえしてしまえば、

ファイルの暗号化はなされていようとも、DBの中身の仕様は丸見えだ。

前提条件として「知っている」「知らない」の差はあれど、攻撃に関して「ラク」というのは

どう考えても楽観的に過ぎる考えだ。

「安全」の認識

最後に突っ込んでおきたい。というか質問というか。

どうも「SSLで確保される安全の領域」について、かなり認識が甘いようだ。

SSLはあくまで、TCP/IP ネットワークにおいて通信経路を暗号化するための技術だ。

通信する際に、通信先のサーバーが正しく認証されているかどうか？に必要なのは SSL証明書。

で、ここに書いたとおり、SSLはあくまでサーバーと利用者の通信においての暗号化だ。

この記事に書かれていることは「メールフォームについて」のことのようだが、

サーバーに到達したあとのメールについては安全性をかんがえていますか？

メールは全く暗号化されず平文で送信されるとても脆弱な通信手段だ。

いくらSSLで通信を暗号化しようとも、問い合わせフォームの送信がメールだったとすると…

外部から傍受される危険性が高くなります。

とこの記事ではかかれていますが、そもそもHTTPやHTTPSの通信を傍受するより遥かに

メールを傍受したほうがラクとも考えられるはず。

CMSを使っている方を非難するわけではないが、

CMSの機能に甘んじて、こういったベーシックな問題に考えが及んでいないとすると、

WEB制作者としては、ちょっと配慮が足らなくはないですか？

とおもう。

P.S SSLということばはもうないよ。

記事に対するつっこみではないですが、

SSLということばは、とても古い言葉です。

便宜上みんな「SSL」といっているだけで、

正しくは「TLS」でっせ。

Permalink | 記事への反応(0) | 19:02

2015-02-20

■http://anond.hatelabo.jp/20150220120628

【秘宝】サーバー運用管理の会社がメールでSSL期限管理しているという事実が発覚

Permalink | 記事への反応(1) | 12:23

■サーバー 運用 管理の会社がExcelでSSL期限管理しているという事実が発覚

https://teratail.com/questions/6972

ホスティング業者なら皆さん悩まれる所だと思いますが、多数のhttps サイトを運用しており、当然サイト毎に証明書を作ってサーバに配置しているのですが、これが10個20個ならともかく、900個以上、将来的には2000とか3000とかに膨らむ予定なのです。
そこで問題になってくるのが証明書の期限です。大体1年なのですが、取得年月日がバラバラなので、現在はExcelにまとめて管理していますが、期限切れ管理について限界を感じています。

投稿者のプロフィールから

http://www.nnetworks.co.jp/

サーバー監視専門にしてる会社が、Excel 管理！？

Permalink | 記事への反応(3) | 11:31

2015-01-17

■http://anond.hatelabo.jp/20150117154005

いや怒ってるわけじゃない。

最初のスラドでは

「そもそもクリティカルじゃないところまでSSLにする必要なくね？」

↓

「電話番号とか改ざんされるかもしれないじゃん」

↓

「そのレベルの改ざんがあって、何か問題あるの？」

つってさらに続いてたから、あなたも実は納得してないんじゃないかと邪推したの。

Permalink | 記事への反応(1) | 15:47

■http://anond.hatelabo.jp/20150117152443

皮肉でいってるのかい？

いやセキュリティ界隈の人たちは、全ページがSSLになって全利用者が証明書きちっと確認する理想を目指して活動してんでしょうから、批判もするでしょうよ。

Permalink | 記事への反応(1) | 15:28

■http://anond.hatelabo.jp/20150117145314

そこがモヤモヤしてるんだよね。

ルータにマルウェアしこまれちゃったら、SSL 意味あるの？

シェイクハンド時にいくらでも情報盗めるし、改ざんする必要もなさそうに思える。

Permalink | 記事への反応(1) | 14:57

2014-12-23

■増田 クリスマス会　提案

この記事は増田アドベントカレンダー 23日目の記事です。

本当は秘蔵のウンコネタを投稿しようと思ったが、

時間がないのと厳密に言うと漏らしたわけではないのでやっぱやめた。

複数回やるのはネタが切れる。

この間見た17日目の記事に便乗。

いろいろ申し訳ない。

増田 クリスマス会　提案

[開催日]　12月25日

[時間]　20時～24時

[場所] IRC サーバ( irc.anonops.com ) ch: #MerryChristMasda

持ち物

[入場券(chパス)] hatena

[増田用の記事] 投下する増田の記事を１本用意してください

概要

・各人適当な増田ネームをつける（はてなidが分かるような名前はダメ）

・25日の20時までに各人は持ち物をもって会場へ入場

・なお、会場は既に入場可能なので自由に出入りOK

・25日の夜にみんなで祝おう！

・企画案ではプレゼント交換があったけど色々面倒なのでパス

・進行は適当。

・増田への記事投下は25日の20時～24時。投下方法はチャットで話しあうとかして決める。

注意事項

・会場はIRC クライアントを使ってSSL 接続推奨だけど、webchatからの参加も大歓迎だよ！(anonops webchat) ※webchat経由の場合は接続後に「/JOIN #MerryChristMasda hatena」と書き込むと入室できます。

・匿名ちゃっと環境としてanonopsを選び、ｃｈ登録までは増田がすませています。よって、anonopsのルールにあわない書き込みや接続はNGです。

(追記)

・IRC クライアントで接続する場合は文字コードを「UTF-8」にしてください。

Permalink | 記事への反応(4) | 22:19

2014-10-30

■３６５日一日も欠かさずハテブしたけどなにも変わらなかった

ちょっと技術の最新で何が起こってるのかには詳しくなったけど

基礎ができてないから SSLがバグっているとかニュースになっても

やべえアップデートしないとぐらいしかできなかった。

あとは増田やプロはてな村民のつりに振り回されただけ。

Permalink | 記事への反応(2) | 17:06

2014-10-16

■http://anond.hatelabo.jp/20141015235552

hisawooo スタープラチナみたいになる人いそう

スターフェラチナ - Google 検索 : https://www.google.co.jp/search?hl=ja&q=%E3%82%B9%E3%82%BF%E3%83%BC%E3%83%95%E3%82%A7%E3%83%A9%E3%83%81%E3%83%8A&lr=lang_ja&gws_rd=ssl#safe=off&hl=ja&q=%E3%82%B9%E3%82%BF%E3%83%BC%E3%83%95%E3%82%A7%E3%83%A9%E3%83%81%E3%83%8A

約2,100件

Permalink | 記事への反応(0) | 23:24

2014-10-04

■小説投稿サイト一覧

サイト名	ジャンル	作者登録	ルビ	挿絵	アクセス解析	EPUB	PDF	モバイル	SSL	料金	開始
作家でごはん！	自由	不要	-	-	-	-	-	-	-	無料	1998年
ノベリスト.jp	自由	必要	-	○	○	-	-	-	-	無料	2009年
星空文庫	自由	必要	○	○	○	○	○	-	○	無料	2010年
ふみふみ	自由	必要	○	○	-	○	-	-	-	無料	2008年
dNoVeLs	自由	必要	-	○	-	-	○	○	-	一部有料	2008年
FC2小説	自由	必要	-	-	-	-	-	○	-	無料	2008年
のべぷろ！	ライトノベル	必要	-	○	-	-	-	○	○	一部有料	2009年
小説家になろう	ライトノベル	必要	○	○	○	-	○	○	-	無料	2004年
アットノベルス	ライトノベル	必要	○	○	-	-	-	○	-	無料	2009年
ライトノベル作法研究所	ライトノベル	不要	-	-	-	-	-	-	-	無料	2004年
ラノベジェネレーション	ライトノベル	必要	-	○	-	-	-	-	-	無料	2010年
Arcadia	ライトノベル	不要	-	-	-	-	-	-	-	無料	2000年
小説カキコ	ライトノベル二次創作	不要	-	-	-	-	-	○	-	無料	2007年
SS投稿速報	二次創作	必要	-	-	○	-	-	-	-	無料	2014年
すぴばる小説部	二次創作ドリーム小説	必要	-	○	-	-	-	-	○	無料	2011年
QBOOKS	短編	必要	-	-	-	-	-	○	-	無料	1998年
jyunbun	純文学	不要	-	○	-	-	-	-	-	無料	2010年
幻創文庫	官能小説	必要	-	-	○	-	-	○	-	無料	2004年
PiPi's World『投稿小説』	官能小説	不要	-	-	-	-	-	○	-	無料	2002年

Permalink | 記事への反応(3) | 00:36

2014-03-28

■http://anond.hatelabo.jp/20140327222203

ここブックマークしとけ

https://freespot.com/

あとはまだ登録数少ないけどこれ入れとけ

http://www.ntt-bp.net/articles/news/?p=572

暗号化なしだから使いたくないとかわがまま言うな。ログイン系のサービスはSSL経由で使っとけ

Permalink | 記事への反応(0) | 10:06

2014-02-27

■Apple's SSL/TLS bug (22 Feb 2014)の意訳

例のAppleのSSL/TLSのバグの件、日本語情報がなかったので意訳しました。

Adam Langleyさんによって書かれた原文はこちら。要所要所に親切なリンクがついているので、ぜひ原文も見てみてください。

Apple's SSL/TLS bug (22 Feb 2014)
https://www.imperialviolet.org/2014/02/22/applebug.html
(Hi Adam Langley, Than you for your blog! We really appreciate you.)

-----

昨日、AppleはばかばかしいiOS向けのセキュリティアップデートを発行した。
それは詳しく明かされていないが、SSL/TSLについてとんでもなく恐ろしい間違いを示すものだった。

その答えは既にハッカーニュースのトップにタレこまれている(https://news.ycombinator.com/item?id=7281378)し、アップルが隠したい秘密はもうバレてしまっていると思う。
そして現在、俺たちはその誤った情報を正すステージに来ているんだ。

ほらここに、Appleのbugがあるんだ。：

static OSStatus
SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams,
                                 uint8_t *signature, UInt16 signatureLen)
{
 OSStatus        err;
 ...

 if ((err = SSLHashSHA1.update(&amp;amp;hashCtx, &amp;amp;serverRandom)) != 0)
  goto fail;
 if ((err = SSLHashSHA1.update(&amp;amp;hashCtx, &amp;amp;signedParams)) != 0)
  goto fail;
  goto fail;
 if ((err = SSLHashSHA1.final(&amp;amp;hashCtx, &amp;amp;hashOut)) != 0)
  goto fail;
 ...

fail:
 SSLFreeBuffer(&amp;amp;signedHashes);
 SSLFreeBuffer(&amp;amp;hashCtx);
 return err;
}(Quoted from Apple's published source code.)

(訳者注：(Quoted from Apple's published source code)→sslKeyExchange.c)

2行のgotoがあるだろ。
2行目のgotoは、見て分かる通り常に発動する。
変数[err]にはエラーを示す値が入らず、正常を示す値のままfailに飛ぶってことだ。
それって成功したのと同じなんだよね！

この署名検証処理は(訳者注：SSL/TLSハンドシェイクのやりとりのうちの一つである)ServerKeyExchangeメッセージの署名を検証するものだ。
このServerKeyExchangeでは、"the ephemeral key"（通信のための一時的な鍵）を交換するためのDHE や ECDHE という暗号スイートが使われる。
そのサーバーは言うんだ。
「ここに"the ephemeral key"と署名があるよ、ほら、これが証明書だ。君はこれが僕からのものだってわかってくれるよね！」

今、もし"the ephemeral key"と証明書の関係が破たんしているならば、すべては無意味なんだ。
これってつまり、正規の証明書チェーンをクライアントに送信したけど、ハンドシェイクへの署名には正しくない間違った（つまり適当にその辺で作った）鍵を使ったり、そもそもハンドシェイクに署名しなかったりってことができるってことなんだよ！

そこには、今君が通信しているサーバーが、サーバー証明書に含まれる公開鍵の秘密鍵を持っているってことの証明が、何もないんだ。

これはSecureTransport(というライブラリ)に入っていて、以下に影響する。
・iOS 7.0.6より前(俺は7.0.4で確認した)
・OS X 10.9.2より前(10.9.1で確認した)
(訳者注：つまりiOS 7.0.6、OS X 10.9.2で解決した)

これはSecureTransportを使っているすべてに影響するけど、ChromeとFirefoxはそうじゃない。
ChromeとFirefoxはSSL/TLSのためにNSSを使っている。
でも、それはあんまり君のマシンがSecureTransportを使っていないってことを意味しないよ。(ソフトって更新されるしね)


超特急でテストサイトを作ってみたよ。https://www.imperialviolet.org:1266
ポート番号に気を付けてね。(テストサイトはCVE番号になってるよ)
443は通常通りに動いているからね。

ポート1266のサーバーと443のサーバーは同じ証明書を送っているけど、完全に異なるキーで署名しているんだ。
君がもしポート1266のHTTPSサイトにアクセスできたんだったら、君のマシンはこのイケてるバグを抱えてるってことだね。:)


それってつまり、証明書チェーンは正しいってことで、そしてハンドシェイクと証明書チェーンの関係は壊れたってことで、もう俺はどんな証明書も信じないよ。

またこれは、DHE または ECDHE 暗号スイートを使っているサイトに影響を及ぼすだけじゃないんだ。
攻撃者は、この暗号スイートを使うサーバーを自分で建てるようになるだろう。

また、これはTLS 1.2には影響しない。このバグを含まないTLS 1.2の別の関数があったから。
でも攻撃者は使うプロトコルをある程度選ぶことができるから、安心できないよ。
(訳者注：サーバー側がTLS1.2を使えないことにしていたら、それ以外の例えばSSL3.0とかTLS1.0とか1.1で通信が始まっちゃうから。)
でもでも、クライアント側でTLS1.2だけを使えるようにしておけば、それは今回の問題の回避策になる。。
同じく、クライアント側でRSA暗号スイートだけを許可するということも、ServerKeyExchangeが発生しなくなるので今回の問題の回避策になる。
(2つのうち、1つ目のほうがだいぶ好ましい。)

俺のテストサイトでは、iOS 7.0.6 と OS X 10.9.2で問題は解決していた。
(更新：このバグはOS X 10.9 のときに入ったように見えたけど、iOS6にもっあったぽい。iOS 6.1.6は昨日リリースされたよ。)

こんなような微妙なバグって、悪夢だ。
俺はこれは単なるミスだと思うし、なんかもうほんと最悪って思う。


ここに、今回の問題を明らかにするコードがある。：

extern int f();

int g() {
 int ret = 1;

 goto out;
 ret = f();

out:
 return ret;
}

もし俺が"-Wall "を付けてコンパイルしたとしても、XcodeのGCC 4.8.2 や Clang 3.3は死んでるコード(the dead code)について警告をしないんだ。
本当にビックリだよ！！！

ここで警告が出ていたらこの問題は止められたのに。でもたぶん、現実には死んでるコードが多すぎて無視することにしてるんだろうね。
(ピーター・ネルソンが教えてくれたけど、Clangはこれを警告するための"-Wunreachable-code"を持ってる。でもこれ、なんと"-Wall "には含まれてない！)

if文に{}をつけないことを許すコーディングスタイルはこの問題を誘発したかもしれない。
でも、人は{}を付けたとしても間違ったプログラムを書くことがあるから、これは俺はあんまり関係ないように思う。

テストケースはこれを見つけることができたはずだけど、今回のはいろいろ条件が複雑なやつだったから難しかったと思う。
TLSのめちゃめちゃ多くのオプションを試さなきゃいけなかったからね。しかも正常系じゃないやつも。
俺、TLSLiteでちゃんとテストしてるか思い出せないもん。(月曜日怖いかも)

コードレビューはこの種類のバグについて効果的でありえる。
ただし単なる審査じゃなく、それぞれの変更に対してしっかりとレビューすることだ。
Appleのコードレビューカルチャーがどんなもんか知らないけど、もし俺が同じようなことをやっちゃったとしたら、同僚のWan-Teh や Ryan Sleevi がばっちり見つけてくれたと、固く信じてる。
でも、誰もがそんなにいい仲間を持てるわけじゃないよね。


最後に。昨日、Appleが証明書のホスト名をちゃんとチェックしていなかったことについて多くの議論があったんだけど、
それは OS X のコマンドラインでcurlを使うと、IPじゃない証明書でもIPでHTTPSにつながっちゃうってだけだったよ。変だけど。
Safariはこの問題には関係なかったよ。