2015年1月16日

NSAがhttps通信を盗聴できるという事実のやばさとWebアプリケーションの実装レベルで対策する方法についての考察

NSAが盗聴可能な通信の中にhttpsも含まれるという記事を読んで、なんとか通常のWebアプリケーションとして回避できる実装がないか考察してるうちにいかにhttps通信自体の盗聴が可能ということがヤバイことか気づいたお話
3
じんぷ~ @_j6k1

ふと思ったが、NSAはどういう方法でHTTPSの暗号化通信を解読してるんだろう。。。

2015-01-16 02:46:03
じんぷ~ @_j6k1

でも、ユーザごとに個別の鍵ペア発行してみたところで、発行した鍵の一方はhttpsで送るしかないのでは、そこを盗聴されたら結局鍵が盗まれるから同じだよなあ・・・

2015-01-16 03:30:23
じんぷ~ @_j6k1

まじでどうやってhttps通信を盗聴したんだろう。sslのマスター暗号化キーを要求していた事実があるらしいから、そもそも鍵自体を強引に譲渡させてるのか?

2015-01-16 03:43:16
じんぷ~ @_j6k1

だとしたら鍵がもれてる証明書を使った場合通信内容は筒抜けだからそこを通して個別の鍵ペアを送ったところで無意味だな

2015-01-16 03:44:04
じんぷ~ @_j6k1

そもそもじゃあなぜcsnapは公開鍵の送信時の通信のセキュリティを確保できてるんだ?複数のサーバを経由するこ盗聴を防いでいるとか?とで

2015-01-16 03:50:39
じんぷ~ @_j6k1

ユーザごとに個別の鍵ペアを使ってることで盗聴を防げてるとして、それはなぜなのか。大量のユーザが同じ鍵ペアで通信するとそれらの膨大なデータを付き合わせることで鍵を計算で割り出すことができるのだろうか?

2015-01-16 03:52:44
じんぷ~ @_j6k1

少なくとも、鍵を分けて通信している限りそれぞれの通信を解読できないのだとしたら、https通信はそもそも鍵そのものを秘密裏に要求して手に入れているか、大量の通信内容をつき合わせて解析することで鍵を計算で求められてるのだろうから

2015-01-16 03:54:26
じんぷ~ @_j6k1

なるほど、公開鍵だけをクライアントに送りつけて秘密鍵はサーバにのみ保存し、ユーザごとにわければhttps通信自体が解読されても一応効果は在りそう。

2015-01-16 03:55:36
じんぷ~ @_j6k1

いやだめか、公開鍵をクライアントに送信する通信そのものが丸見えならサーバから送ったデータは丸見えだ

2015-01-16 03:56:39
じんぷ~ @_j6k1

ならサーバから公開鍵送信⇒クライアントで共通鍵生成⇒公開鍵で暗号化してサーバに送信、サーバで保存⇒サーバからクライアントへ通信時共通鍵で暗号化後さらに秘密鍵で暗号化⇒クライアントの公開鍵で復号後さらに共通鍵で復号、これならどうだ

2015-01-16 03:59:05
じんぷ~ @_j6k1

サーバから公開鍵送信⇒クライアントで鍵ペア生成⇒サーバから取得した公開鍵で生成した公開鍵を暗号化してサーバに送信⇒送られた公開鍵をサーバに保存⇒以後クライアントで生成された鍵ペアで通信するようにすればよさげかな

2015-01-16 04:04:26
じんぷ~ @_j6k1

秘密鍵での暗号化/複合化のほうが軽い処理のはずだし、これなら最初のhttps通信が筒抜けになっていても公開鍵暗号で暗号化された暗号そのものを力技で解読されない限り鍵は一切漏れていない。

2015-01-16 04:06:04
じんぷ~ @_j6k1

問題なのはサーバ側に実際の通信で使うための鍵のうち公開鍵しか存在しないせいでクライアントの鍵が消えたとき同じものを再発行できないことだけど、最初のプロセスをやり直して鍵を更新すればいい

2015-01-16 04:08:05
じんぷ~ @_j6k1

ブラウザごとに鍵が分かれてしまうことになるから、鍵はセッション上に保存するべきだな

2015-01-16 04:09:29
じんぷ~ @_j6k1

セッションIDも盗聴可能なのか。https通信が盗聴可能となると。ダメじゃん

2015-01-16 04:10:22
じんぷ~ @_j6k1

セッションを乗っ取って別のユーザとしてシステムに入り込んで鍵を盗むことも可能ってことだ。うわあやっかいだなこれ。よくそんな悪質な技術実用化したもんだ

2015-01-16 04:11:29
じんぷ~ @_j6k1

そうだよ。ユーザーが実際に行ってる通信が盗聴されるだけじゃないんだ。セッションIDも筒抜けだからアカウントを自在に乗っ取れるんだよそれ。

2015-01-16 04:13:35
じんぷ~ @_j6k1

まじでやっかいだな。ログインプロセス自体をまずさっきの鍵交換プロセスを行って鍵ペアを作ったあと、秘密鍵でIDとパスワードを暗号化して送信し、クッキーを使わない独自のセッションシステムのためのIDを公開鍵で暗号化して送信し、以後それでユーザを識別しないと不十分なのか。

2015-01-16 04:16:39
じんぷ~ @_j6k1

もうそうなると、サーバ側はhttps使ったWebサーバを一応使えても、独自の通信プロトコルもどきで通信しなきゃいけなくなるから、ブラウザで実装するのきつそう

2015-01-16 04:17:30
じんぷ~ @_j6k1

大体、IDとパスも筒抜けなら、ログインプロセスそのものを全部その仕組みにしない限り意味がない

2015-01-16 04:18:21
じんぷ~ @_j6k1

パスワードそのものすら盗めるんだから。

2015-01-16 04:18:34
じんぷ~ @_j6k1

考えれば考えるほど悪質じゃん。NSAどんだけやばい領域に足突っ込んでるの

2015-01-16 04:18:58
じんぷ~ @_j6k1

こりゃ、相当本腰入れて最初からそういう風にシステム作りこまない限りNSAの盗聴対策としては中途半端だな

2015-01-16 04:20:11
残りを読む(46)

コメント

じんぷ~ @_j6k1 2015年1月16日
まとめを更新しました。
0
じんぷ~ @_j6k1 2015年1月16日
まとめを更新しました。
0
いくた♥️なお C99 1日目O24a @ikutana 2015年1月16日
2は無いですわ。SSLで使われてるアルゴリズムはProvable Secureなはずだし。あるとすればじっそうバックドアが仕込まれてるとかそういうのでは。
0
じんぷ~ @_j6k1 2015年1月16日
ssl通信そのものにバックドアが仕込まれてるとするとやっかいですね。だとしても、サーバで鍵ペア生成⇒公開鍵のみをクライアントに送信⇒クライアントで新しい鍵ペア生成⇒サーバから取得した公開鍵でクライアントで生成した公開鍵送信、という方法であれば鍵暗号の実装自体に細工されていなければ対処できるかもですが。
0
angel (as ㌵㌤の猫) @angel_p_57 2015年1月17日
うーん…。SSLそのものには関係ないネタのような。ありうる ( あるとは言ってない ) とすれば、技術力が高かったり、情報 ( アプリケーション/ライブラリの脆弱性とか ) を持っていることで、サーバなりクライアントをクラックして情報を盗み見ることができる、ということじゃないかな。
0
angel (as ㌵㌤の猫) @angel_p_57 2015年1月17日
ウイルス感染したPCでSSL通信してもセキュリティ的には無意味なように、本体をクラックされたらhttpsの意味ないからねえ。「バックドアが仕込まれている」というケースでも同じこと。
0