  |
はてなキーワード: 公開鍵とは
例の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(&hashCtx, &serverRandom)) != 0) goto fail; if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) goto fail; goto fail; if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0) goto fail; ... fail: SSLFreeBuffer(&signedHashes); SSLFreeBuffer(&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はこの問題には関係なかったよ。
ちなみに、別件でOpenSSL使ったセキュリティー（C)をやらせたら、丸投げ外注だと数ヶ月たっても上がってこなかったけど、
仕方がないから、ノウハウ開示して指導しながらやったら７日で出来た。（テスト別）
実作業で言えばSIerがちゃんとしてればそんなもの。（実データ）
１０年前かなぁ。おおざっぱに。
行って来い（復号可能）で、公開鍵使って１０年前でそんなもの。OpenSSLを銀行じゃ使えないだろうがマシな商用SSLぐらいいくらでもあっただろう。
公開鍵使ってれば、外注じゃどうにもならん。アドミンでも抜けない。
仕方がないという前提でいいけど、１０年以上技術水準が遅れちゃってるという事実は関係者一同が認識するべき事態だと思う。暗号化だけで言えば２０年近く概念が遅れてる。
情報漏洩自体は不正利用自体は金で片がつく事ではあるけど、経営幹部のITに対する知識が２０年遅れているというのは、日本全体としてはピンチだろう？
俺達が何を言っているかわかってほしい。
これまで他の人に用意してもらったサーバで自分のプログラムを動かしたことはありましたが
自分自身で一からサーバをセットアップしたことはほとんどなかったので、いろいろとハマりました。
作業を進める上で困ったり考えたりしたことを書いていきます。
ちなみにサーバ自体はさくらのクラウド、OSにはCentOSを使用しているので、それ前提のお話になります。
最初にサーバを起動してから速やかにSSHとファイヤーウォールの設定を変更しました。
はてブなんかでも定期的に話題になっているのでおなじみですね。
・SSHやHTTP(S)など、どうしても公開しなければならないポート以外は遮断する
さらっと書きましたが、設定をミスって自分自身もログインできなくなり、何度かOSの再インストールを繰り返しています。
後から気付いた事ですが、さくらのクラウドではクラウド管理画面のリモートスクリーン経由でローカルログインできるので
別にOS再インストールしなくてもiptablesの設定を変更できたんですよね...
逆に言うといくらファイヤーウォールとSSHを設定しても管理画面にパスワードログインの環境が残ってしまうので
パスワードの管理には引き続きしっかり気を使う必要がある。ということでもあります。
httpd,php,mySQL,memcachedなど必要なサービスをインストール、設定し
作成したWebアプリのプログラムを乗せて動かしてみました。が、動作が重いような...
開発環境ではさくさく動いていたのに、本番環境ではどのページ遷移ももっさりしています。
abで計測してみたところ、開発環境のおよそ2分の1のスコアとなってしまいました。
開発環境が仮想2コアのメモリ1Gだったのに対し、本番環境が仮想1コアのメモリ2Gと
CPUの性能について半減しているのでそのせいかな、と思いつつ設定を見なおしていたところ
特に使っていないと思われたipv6を停止した途端にパフォーマンスが改善されました。
ページ遷移に伴うもっさり感が解消され、abの計測結果も開発環境と遜色ない結果が出ています。
デフォルトで有効になっていたipv6の影響により余計な処理が走っていたのかもしれません。
パフォーマンス改善に喜んだのも束の間、会員登録などの処理でWebアプリからメールを送信したところ、Gmail宛のメールがことごとく迷惑メールと判定されるという事案が発生。
spfの設定を行なう、メールの内容について吟味するなどの回避策を試してみましたが一向に改善されません。
試しにHotMailとexciteのメールアカウントに送信したところ、そちらではそもそもメールを受け付けてもらえずエラーコードが返って来る始末。
困り果てていたところ、エラーの内容からサーバのIPがspamhousにスパム送信元として登録されていることが判明しました。
postfixのホスト名の設定がデフォルトで「localhost.localdomain」などとなっており、それをそのまま使っていたためにGmailがスパム送信元として通報してしまったようです。
設定を修正し、spamhousに解除依頼を提出。事なきを得ました。
クラウドを利用すれば、サーバを停止することなく簡単な設定でスケールできるようになる。
と、自分で勝手に思い込んでいたせいなのですが、消えては困るデータの一部をmemcachedに保存する実装を行なっていました。
実際のところさくらのクラウドではサーバを完全に停止しなければプラン変更を実施できないし
そもそもサーバが落ちたらどうするんだよ。ということで、急遽KVSを変更する必要に迫られました。
速度の低下が気にかかったため、いくつかの候補を実際に動かし
phpのスクリプトから1万件のデータ読み書きを行うという形でmemcachedと比較してみたところ次のような結果に。
| サービス | 1万件書込 | 1万件読込 |
| memcached | 2.55秒 | 2.30秒 |
| handlersocket | 21.23秒 | 2.71秒 |
| InnoDB | 20.23秒 | 5.10秒 |
| kyotoTycoon | 8.22秒 | 7.72秒 |
さすがに読み書きそれぞれmemcachedが最速ですが、読み出しについてはhandlersocketも負けていません。mySQLから普通にSELECTしてもmemcachedの2倍程度の時間しかかからないという結果が意外でした。
しかしながら書き込みのほうではhandlersocketもmemcachedの10倍近くの時間がかかっており、少々速度的な影響が気になってきます。memcachedの倍のパフォーマンスを記録したという記事を見たことがあるので、設定、チューニングについて生かしきれていない部分があるのかもしれないとも思いましたが、知識が不足しているところで無理をすると問題が発生した時に対処できないと考え、候補から除外することとしました。
結局、今回の用途では読み込み処理より書き込み処理のほうが圧倒的に多いことも考慮し、kyotoTycoonを採用しました。実際の利用箇所に組み込んでabで計測してみたところ、だいたい30%程度のパフォーマンス低下にとどまっており、これなら許容範囲かと考えています。
実行系と参照系に分ける形でmySQLのレプリケーションを行なっていたのですが、度々レプリケーションが停止する現象が発生しました。
一部のテーブルについて肥大する可能性が考えられたため、参照系に接続するプログラムで使わないテーブルをレプリケーションから除外していたのが原因です。
例えばtabelAをレプリケーションし、tableXをレプリケーションしないという設定にしたうえで
実行系でINSERT INTO `tableA` SELECT `value` FROM `tableX`などといったクエリを発行すると、参照系にtableXが無いためエラーが発生して止まってしまいます。
レプリケーションするテーブルを限定する場合はプログラム側でも注意を払わないと危険です。当たり前ですが。
監視といえばcactiやnagiosが定番なのかもしれませんが、設定が複雑そうで尻込みし、monitを使用することにしました。
簡単な設定でloadaverageやメモリ、HDDの使用量をチェックできるほか
httpdやmysqldなどといったサービスのプロセスを監視し、もし落ちていたら自動で起動してくれるので助かります。
パスワード保護を行うとしても、サイト全体の管理画面など自分しか使わないプログラムはWebに晒しておきたくない。
というわけで、一部のWebアプリを秘匿する設定を行いました。
管理画面のWebアプリを9999番など閉じているポートに設置した上で、SSHを利用したトンネルを掘ります。といっても
上記のようなコマンドで管理画面のWebアプリを置いたサーバへログインするだけです。
ブラウザのアドレス欄にhttp://localhost:9999/と打ち込めば、接続が開いている間のみアクセス可能になる感じですね。
サーバにログインできる人でなければ実行できないことなので、気分的にある程度安心します。
自動でログのバックアップを行いたいと考えたのですが、パスワード無しの鍵でログインして転送する形には抵抗がありました。
調べてみたところ、authorized_keysに公開鍵を記入する際の設定で、その鍵でできることを制限するという手段があるようでした。
具体的には、authorized_keysに
no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="some commands" ssh-rsa AAAAB3NzaC1yc2EAAA...
などとして公開鍵を追加しておくと、その鍵でログインした直後にcommand=""の部分で設定したコマンドを実行して接続を終了する挙動となり
接続のフォワードもできなくなるため、パスワード無しでも鍵の流出に関するリスクを最低限に留めることができるというわけです。
commandの実行結果は標準出力から受け取ることができるので、例えばcommand=""の部分にファイルの内容を表示する処理を設定していたとすれば
ssh -i .ssh/no_password_key user@xxx.xxx.xxx.xxx > /path/to/file
などとしてログインの結果をファイルに書き込むだけで、簡単にファイルの転送が実現できます。
他にも大小さまざまな問題に行きあたりましたが、忘れてしまったor書ききれないのでここまでとします。
たった1つのサイトを公開するにしても問題というのは尽きないものだと実感させられました。
今は基本的な情報だけでなく、ちょっと突っ込んだ内容でも検索で解決していけるので嬉しいですね。手がかりを残してくれた先達に感謝することしきりです。
現状ではひとまずの見切りを付けて公開していますが、より堅牢で負荷に強いサーバとなるよう、随時チューニングを行なっていこうと考えています。
個人サイトや小規模な商業サイトなどプロモーションにあまりお金をかけられないサイトを主な対象とした、無料で出稿できる広告ネットワークサービスです。
既存のサービスで近いのは「あわせて読みたい」や「zenback」、各社提供のRSS相互リンクサービスなどになるでしょうか。
広告としての体裁がある分、それらより若干積極的な性質になるのではと考えています。
現時点ではサービス本体のプロモーションに苦心するという本末転倒そのものの状況でありますが、もしよろしければ見ていただけると嬉しいです。
