NSAがhttps通信を盗聴できるという事実のやばさとWebアプリケーションの実装レベルで対策する方法についての考察
-
- いいね！1
じんぷ～
@_j6k1
でも、ユーザごとに個別の鍵ペア発行してみたところで、発行した鍵の一方はhttpsで送るしかないのでは、そこを盗聴されたら結局鍵が盗まれるから同じだよなあ・・・
2015-01-16 03:30:23
じんぷ～
@_j6k1
まじでどうやってhttps通信を盗聴したんだろう。sslのマスター暗号化キーを要求していた事実があるらしいから、そもそも鍵自体を強引に譲渡させてるのか？
2015-01-16 03:43:16
じんぷ～
@_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: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: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