NSAがhttps通信を盗聴できるという事実のやばさとWebアプリケーションの実装レベルで対策する方法についての考察
-
- いいね！1
じんぷ～
@_j6k1
ただ、鍵交換のところだけで言えば、この方式で鍵ペアを作って通信するようにするネイティブアプリからクッキーなど使わず作った鍵ペアでユーザを識別するIDを送信してセッションを確立することでサーバ側はapacheでもセキュアなアプリケーションは一応実装できそうですね。
2015-01-16 04:41:14
じんぷ～
@_j6k1
特にandroidやiphoneのWebView使ったアプリならブラウザの動作に独自のセッションIDを生成した鍵ペアで暗号化して常に送信させることも容易そうだし
2015-01-16 04:42:19
じんぷ～
@_j6k1
とぎゃったーにまとめた鍵交換のプロセスで通信を暗号化してその鍵ペアでセッションIDも何もかもやり取りするフロントエンドとサーバ再度両方を統合したフレームワーク必要になりそうだなあ。
2015-01-16 04:48:51
じんぷ～
@_j6k1
ブラウザアプリ用のフレームワークで対応する場合、メモリの開放周り考えると完全なシングルページアプリケーションはやめたほうがよさそう。ページのコンテンツの中身を常にAjaxで取得するようにしてその通信時に鍵ペアでセッションID暗号化して送信するほうがいいな
2015-01-16 04:54:28
じんぷ～
@_j6k1
いくら鍵をユーザ毎にその都度発行したところで、国家権力の力で全部譲渡させられていたとしたら結局無意味だから、NSAのそういう行為は本当に問題だよね
2015-01-16 04:59:48
じんぷ～
@_j6k1
俺はたぶんsslの鍵そのものを強引に提出させているか、大量の通信をつき合わせて大量のコンピュータで解析することで鍵を計算で導き出せるんじゃないかと思ってる
2015-01-16 05:07:23
じんぷ～
@_j6k1
とりあえず、NSAによる盗聴対策は最初からそれを想定して防げるようにしっかり作りこまないと無理だから、全く新規に何か作るときに行うようにして今は忘れよう
2015-01-16 05:14:49
じんぷ～
@_j6k1
あ～、っていうか、鍵ペアでセッションID暗号化して独自に送信もダメなのか。暗号化済みのセッションIDを盗聴して直接送りつければ暗号化前のIDなんか知らなくてもセッション乗っ取れるんだ。
2015-01-16 05:17:26
じんぷ～
@_j6k1
ログインページをローカルネットワークの開発サーバにおいて、開いたときにajaxで開発サーバ上のPHPから取得してその鍵でIDとパスワードを暗号化してログイン、外部ネット上のホームへ移動直後クロスドメインajax通信で再度開発サーバから鍵を取得してlocalstorageへ保存
2015-01-16 05:27:35
じんぷ～
@_j6k1
あとは保存した鍵でセッションID以外の通信を常に暗号化すればいい(セッションIDは暗号化しても暗号化済みのIDを盗まれれば同じことなので普通にクッキーで送る)
2015-01-16 05:28:57