アカウント名:
パスワード:
求めてるのは基本的に暗号化だけですから認証局利権なんてものはまったく無用の長物。信頼性?そんなものそもそも騙されるバカはドメインが詐称されていても騙されますので
相手がなりすましかも知れない状況で暗号化する意味とは?そもそも、認証局無しでどうやって暗号鍵を安全に交換するの?手渡しですか?銀行なら郵送でも良いかもしれませんがw
そもそも企業なんて信用してないですし公開鍵で暗号化して秘密鍵で復号するだけでいい別に何も利権に金払う必要なんてないね認証局を信用するバカはいつも騙されるだけなんじゃないの
>認証局を信用するバカはいつも騙されるだけなんじゃないの
ルート認証局とか中間認証局になるときのレギュレーション、監査の厳しさを知らないんですね。普通のセキュリティ監査は、字面は厳しくても実態にあわせた対応を可能にする「遊び」(外部監査の一部を、記録付きの社内チェックで代替できるとか)があるもんだけど、あれは文字通りのガチ。
「利権」しかボキャブラリのない痴呆はとりあえずこれを読め。http://qiita.com/kawaz/items/f90810b9ea823b6556a8 [qiita.com]
だからさぁ、公開鍵を安全に持ってくる方法を聞いてるんですけど?通信経路上の攻撃者に鍵をすり替えられていない事をどうやって検証するの?
マジでど素人です。すり替えられた公開鍵で暗号化した場合、正しい秘密鍵では復号できない。が真なら、すり替えがないことの証明にならないのでしょうか。正しい復号をする秘密鍵が既に漏れていない限り任意に合致する公開鍵を作れるとは思えないし、秘密鍵が漏れているなら公開鍵をすり替える必要はない。毎回公開鍵をすり替えられてしまえば、いつまでも正しい通信が出来ないことには変わりがないのでしょうけど。
>すり替えがないことの証明にならないのでしょうか。
通信する相手が既知ならばね。
SSHの場合は、公開鍵は既知だと仮定して、公開鍵だけで暗号データのやり取りをしています。
SSLの場合、既知だと仮定するのはあまりに無理があります。公開鍵の数が違いすぎるからです。
現状のSSLの使用方法の場合
CA証明書 -> SSLサーバ証明書
という形態になっています。SSLサーバ証明書は、CA証明書の秘密鍵で署名してあるわけですな。
で、CA証明書だけ(通常は自己署名証明書)SSLクライアント(ブラウザ)に登録する方式にしています。
SSLサーバ証明書を使用せず、公開鍵だけで行こうとした場合、一応正しい、と仮定するためには、いままでSSLサーバ証明書に含まれていた公開鍵をすべてブラウザに登録する必要が生じます。
そうでないとSSLサーバの公開鍵すべてを無条件に信頼することになってしまうからです。
その場合のブラウザで登録する公開鍵数、100億では済まないでしょうな、、数は見当もつかない。。
公開鍵で暗号化する方はそれに対応する秘密鍵を持ってないので ”正しい秘密鍵では復号できない。”ことを認識できないってことは理解できますか?つまり公開鍵で暗号化する方は公開鍵が正しいものかすり替えられたものか解りません。
そしてすり替える事ができるぐらいなので正しい公開鍵を攻撃者は持っています。被攻撃者がすり替えられた公開鍵で暗号化すると攻撃者のみ復号できます。攻撃者が復号したものを正しい暗号鍵で再度暗号化し、もともと被攻撃者が通信を行おうとしてた正しい通信相手に送ります。こうなると正しい通信相手も盗聴、改竄されていることを検知することができません。
こうならないために最初に公開鍵がすり替えられていないことを保証するための電子証明です
ネットバンキングを使う例で説明します。ユーザーの端末が接続しているネットワークの管理者が悪意を持った攻撃者だったとします。攻撃者は透過プロキシを用いて通信内容を中継し、パスワードなどを盗み見ようとします。当然、ユーザーと銀行は相互に鍵を交換して暗号化を試みるわけです。
しかし、ユーザーが銀行に送る公開鍵、銀行がユーザーに送る公開鍵は両方とも攻撃者にすり替えられてしまいます。攻撃者は自分の秘密鍵と対になる公開鍵をユーザーと銀行に送ります。すると、ユーザーと攻撃者、攻撃者と銀行の間で暗号化が行われます。攻撃者はユーザーと
#2617173のど素人です。丁寧な解説のおかげで多分理解できました。お馬鹿なんで、暗号化公開鍵を暗号化秘密鍵で暗号化して復号化公開鍵で複号化すれば安全に暗号化公開鍵をやり取りできるかも、と一瞬考えた後まったく意味が無いことに気がついたり。鍵を百重ぐらいこの方法でラップした上で毎回使い捨てれば、根競べぐらいには持ち込めるかなあ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall
SSLなんて捨てちまえ (スコア:-1)
求めてるのは基本的に暗号化だけですから認証局利権なんてものは
まったく無用の長物。信頼性?そんなものそもそも騙されるバカは
ドメインが詐称されていても騙されますので
Re: (スコア:0)
相手がなりすましかも知れない状況で暗号化する意味とは?
そもそも、認証局無しでどうやって暗号鍵を安全に交換するの?
手渡しですか?
銀行なら郵送でも良いかもしれませんがw
Re:SSLなんて捨てちまえ (スコア:-1)
そもそも企業なんて信用してないですし
公開鍵で暗号化して秘密鍵で復号するだけでいい
別に何も利権に金払う必要なんてないね
認証局を信用するバカはいつも騙されるだけなんじゃないの
Re:SSLなんて捨てちまえ (スコア:1)
>認証局を信用するバカはいつも騙されるだけなんじゃないの
ルート認証局とか中間認証局になるときのレギュレーション、監査の厳しさを知らないんですね。
普通のセキュリティ監査は、字面は厳しくても実態にあわせた対応を可能にする「遊び」(外部監査の一部を、
記録付きの社内チェックで代替できるとか)があるもんだけど、あれは文字通りのガチ。
Re: (スコア:0)
「利権」しかボキャブラリのない痴呆はとりあえずこれを読め。
http://qiita.com/kawaz/items/f90810b9ea823b6556a8 [qiita.com]
Re: (スコア:0)
だからさぁ、公開鍵を安全に持ってくる方法を聞いてるんですけど?
通信経路上の攻撃者に鍵をすり替えられていない事をどうやって検証するの?
Re: (スコア:0)
マジでど素人です。
すり替えられた公開鍵で暗号化した場合、正しい秘密鍵では復号できない。が真なら、すり替えがないことの証明にならないのでしょうか。
正しい復号をする秘密鍵が既に漏れていない限り任意に合致する公開鍵を作れるとは思えないし、秘密鍵が漏れているなら公開鍵をすり替える必要はない。
毎回公開鍵をすり替えられてしまえば、いつまでも正しい通信が出来ないことには変わりがないのでしょうけど。
Re:SSLなんて捨てちまえ (スコア:1)
>すり替えがないことの証明にならないのでしょうか。
通信する相手が既知ならばね。
SSHの場合は、公開鍵は既知だと仮定して、公開鍵だけで暗号データのやり取りをしています。
SSLの場合、既知だと仮定するのはあまりに無理があります。
公開鍵の数が違いすぎるからです。
現状のSSLの使用方法の場合
CA証明書 -> SSLサーバ証明書
という形態になっています。SSLサーバ証明書は、CA証明書の秘密鍵で署名してあるわけですな。
で、CA証明書だけ(通常は自己署名証明書)SSLクライアント(ブラウザ)に登録する方式にしています。
SSLサーバ証明書を使用せず、公開鍵だけで行こうとした場合、一応正しい、と仮定するためには、
いままでSSLサーバ証明書に含まれていた公開鍵をすべてブラウザに登録する必要が生じます。
そうでないとSSLサーバの公開鍵すべてを無条件に信頼することになってしまうからです。
その場合のブラウザで登録する公開鍵数、100億では済まないでしょうな、、
数は見当もつかない。。
Re: (スコア:0)
フィンガープリントが正しいか確認を求められるので、仮定ではないですね。ユーザーが承認しているのです。
ただしく運用しているところは少ないでしょうが。
Re: (スコア:0)
公開鍵で暗号化する方はそれに対応する秘密鍵を持ってないので ”正しい秘密鍵では復号できない。”ことを認識できないってことは理解できますか?
つまり公開鍵で暗号化する方は公開鍵が正しいものかすり替えられたものか解りません。
そしてすり替える事ができるぐらいなので正しい公開鍵を攻撃者は持っています。
被攻撃者がすり替えられた公開鍵で暗号化すると攻撃者のみ復号できます。攻撃者が復号したものを正しい暗号鍵で再度暗号化し、
もともと被攻撃者が通信を行おうとしてた正しい通信相手に送ります。
こうなると正しい通信相手も盗聴、改竄されていることを検知することができません。
こうならないために最初に公開鍵がすり替えられていないことを保証するための電子証明です
Re: (スコア:0)
ネットバンキングを使う例で説明します。
ユーザーの端末が接続しているネットワークの管理者が悪意を持った攻撃者だったとします。
攻撃者は透過プロキシを用いて通信内容を中継し、パスワードなどを盗み見ようとします。
当然、ユーザーと銀行は相互に鍵を交換して暗号化を試みるわけです。
しかし、ユーザーが銀行に送る公開鍵、銀行がユーザーに送る公開鍵は両方とも攻撃者にすり替えられてしまいます。
攻撃者は自分の秘密鍵と対になる公開鍵をユーザーと銀行に送ります。
すると、ユーザーと攻撃者、攻撃者と銀行の間で暗号化が行われます。
攻撃者はユーザーと
Re: (スコア:0)
#2617173のど素人です。丁寧な解説のおかげで多分理解できました。
お馬鹿なんで、暗号化公開鍵を暗号化秘密鍵で暗号化して復号化公開鍵で複号化すれば安全に暗号化公開鍵をやり取りできるかも、と一瞬考えた後まったく意味が無いことに気がついたり。
鍵を百重ぐらいこの方法でラップした上で毎回使い捨てれば、根競べぐらいには持ち込めるかなあ。