アカウント名:
パスワード:
求めてるのは基本的に暗号化だけですから認証局利権なんてものはまったく無用の長物。信頼性?そんなものそもそも騙されるバカはドメインが詐称されていても騙されますので
相手がなりすましかも知れない状況で暗号化する意味とは?そもそも、認証局無しでどうやって暗号鍵を安全に交換するの?手渡しですか?銀行なら郵送でも良いかもしれませんがw
そもそも企業なんて信用してないですし公開鍵で暗号化して秘密鍵で復号するだけでいい別に何も利権に金払う必要なんてないね認証局を信用するバカはいつも騙されるだけなんじゃないの
だからさぁ、公開鍵を安全に持ってくる方法を聞いてるんですけど?通信経路上の攻撃者に鍵をすり替えられていない事をどうやって検証するの?
マジでど素人です。すり替えられた公開鍵で暗号化した場合、正しい秘密鍵では復号できない。が真なら、すり替えがないことの証明にならないのでしょうか。正しい復号をする秘密鍵が既に漏れていない限り任意に合致する公開鍵を作れるとは思えないし、秘密鍵が漏れているなら公開鍵をすり替える必要はない。毎回公開鍵をすり替えられてしまえば、いつまでも正しい通信が出来ないことには変わりがないのでしょうけど。
ネットバンキングを使う例で説明します。ユーザーの端末が接続しているネットワークの管理者が悪意を持った攻撃者だったとします。攻撃者は透過プロキシを用いて通信内容を中継し、パスワードなどを盗み見ようとします。当然、ユーザーと銀行は相互に鍵を交換して暗号化を試みるわけです。
しかし、ユーザーが銀行に送る公開鍵、銀行がユーザーに送る公開鍵は両方とも攻撃者にすり替えられてしまいます。攻撃者は自分の秘密鍵と対になる公開鍵をユーザーと銀行に送ります。すると、ユーザーと攻撃者、攻撃者と銀行の間で暗号化が行われます。攻撃者はユーザーと銀行の間で通信をいったん復号してから中継(盗聴、改ざんも)出来るわけです。攻撃者が証明書をすり替えるとブラウザは証明書エラーを吐きますが、オレオレ証明書なのか、攻撃者にすり替えられた証明書なのかユーザーには区別が付きません。
ちなみに、企業向けのセキュリティ製品の中にはユーザーに警告を行った上で上記のような手法でSSLによる通信内容の監視を行うプロキシサーバーが存在します。正当な目的で使用されるモノなのでそれはそれで問題ないのですが、ブラウザはちゃんと証明書エラーを吐いてくれます。
#2617173のど素人です。丁寧な解説のおかげで多分理解できました。お馬鹿なんで、暗号化公開鍵を暗号化秘密鍵で暗号化して復号化公開鍵で複号化すれば安全に暗号化公開鍵をやり取りできるかも、と一瞬考えた後まったく意味が無いことに気がついたり。鍵を百重ぐらいこの方法でラップした上で毎回使い捨てれば、根競べぐらいには持ち込めるかなあ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
普通のやつらの下を行け -- バッドノウハウ専門家
SSLなんて捨てちまえ (スコア:-1)
求めてるのは基本的に暗号化だけですから認証局利権なんてものは
まったく無用の長物。信頼性?そんなものそもそも騙されるバカは
ドメインが詐称されていても騙されますので
Re: (スコア:0)
相手がなりすましかも知れない状況で暗号化する意味とは?
そもそも、認証局無しでどうやって暗号鍵を安全に交換するの?
手渡しですか?
銀行なら郵送でも良いかもしれませんがw
Re: (スコア:-1)
そもそも企業なんて信用してないですし
公開鍵で暗号化して秘密鍵で復号するだけでいい
別に何も利権に金払う必要なんてないね
認証局を信用するバカはいつも騙されるだけなんじゃないの
Re: (スコア:0)
だからさぁ、公開鍵を安全に持ってくる方法を聞いてるんですけど?
通信経路上の攻撃者に鍵をすり替えられていない事をどうやって検証するの?
Re: (スコア:0)
マジでど素人です。
すり替えられた公開鍵で暗号化した場合、正しい秘密鍵では復号できない。が真なら、すり替えがないことの証明にならないのでしょうか。
正しい復号をする秘密鍵が既に漏れていない限り任意に合致する公開鍵を作れるとは思えないし、秘密鍵が漏れているなら公開鍵をすり替える必要はない。
毎回公開鍵をすり替えられてしまえば、いつまでも正しい通信が出来ないことには変わりがないのでしょうけど。
Re:SSLなんて捨てちまえ (スコア:0)
ネットバンキングを使う例で説明します。
ユーザーの端末が接続しているネットワークの管理者が悪意を持った攻撃者だったとします。
攻撃者は透過プロキシを用いて通信内容を中継し、パスワードなどを盗み見ようとします。
当然、ユーザーと銀行は相互に鍵を交換して暗号化を試みるわけです。
しかし、ユーザーが銀行に送る公開鍵、銀行がユーザーに送る公開鍵は両方とも攻撃者にすり替えられてしまいます。
攻撃者は自分の秘密鍵と対になる公開鍵をユーザーと銀行に送ります。
すると、ユーザーと攻撃者、攻撃者と銀行の間で暗号化が行われます。
攻撃者はユーザーと銀行の間で通信をいったん復号してから中継(盗聴、改ざんも)出来るわけです。
攻撃者が証明書をすり替えるとブラウザは証明書エラーを吐きますが、オレオレ証明書なのか、攻撃者にすり替えられた証明書なのかユーザーには区別が付きません。
ちなみに、企業向けのセキュリティ製品の中にはユーザーに警告を行った上で上記のような手法でSSLによる通信内容の監視を行うプロキシサーバーが存在します。
正当な目的で使用されるモノなのでそれはそれで問題ないのですが、ブラウザはちゃんと証明書エラーを吐いてくれます。
Re: (スコア:0)
#2617173のど素人です。丁寧な解説のおかげで多分理解できました。
お馬鹿なんで、暗号化公開鍵を暗号化秘密鍵で暗号化して復号化公開鍵で複号化すれば安全に暗号化公開鍵をやり取りできるかも、と一瞬考えた後まったく意味が無いことに気がついたり。
鍵を百重ぐらいこの方法でラップした上で毎回使い捨てれば、根競べぐらいには持ち込めるかなあ。