アカウント名:
パスワード:
サーバ側に公開鍵登録してっていう依頼ならそりゃ平文で送るなは正しい。(HTTP、FTPでの転送って意味だよ)それぞれの「理由」が書いてないので公開することを嫌がる事を批判する事がおかしい
公開鍵は、紙で手渡しが原則だろうw
それぞれの理由を考えてみた「公開鍵が盗聴される恐れがある」…「盗聴さえる恐れ」ならなんだってあるだろう。「公開鍵を平文で送るな」…平文で送れば、盗聴で検知され、別の公開鍵に置き換えられることをいってないか?「公開鍵をそのままサーバに保管するな」…「そのまま」が暗号なしの手順で送るなって意味じゃないのか?「公開鍵だけ送るのでは復号ができない」…「公開鍵だけ」送られてきても、貴方のものか検証できないって意味じゃないの?「公開鍵を公開したくない」…それは「お前に」公開したくないだけじゃないのかw
「盗聴さえる恐れ」改竄されてるヨ!
転送方法に関わりなく、盗まれようと流出しようと問題はないです。PKIの仕組みを勉強した方が良いのでは?
どういう意図で、公開したくないと言ったのかが解らないため、真意はわかりませんが、
例えば、乱数的に生成されたURLを発行し、それを知る人物しかアクセスできないことで、第三者によるアクセスを防ごうとするシステムがあるように、公開鍵を隠すことで、通信を開始できないようにするという考え方もあるのではないのでしょうか?
公開暗号方式自体が安全だとしても、実装が本当に安全であるかは判らない訳で、(現実で起こった例と挙げるとすれば、TLSの仕様が(実用面ではともかくとしてセキュリティ面で)問題なかったとしても、その実装でHeartbleedのような脆弱性が発見された)「通信を開始できる人間を限定することで、そのような脆弱性をつつかれる可能性を減らす」という考え方はあるのではないでしょうか?
それなら、公開鍵の隠匿なんて雑な方法じゃなく、クライアント証明書でいいんじゃないの?
という考えは、公開暗号方式の仕組みの知識があっても、使われた方の知識がなければ要求・提案できないし、
公開したくないと言った人が仕組みしか知っていなかった可能性はあるのだから、「理由」を聞いて、提案しないといけないんじゃないの?
差し替えられたら問題があるからでは?
改ざん、なりすましの危険が無い通信路を確保できれば平文で盗聴されようが問題無いですよね。面と向かって大声でとか
> (HTTP、FTPでの転送って意味だよ)って条件説明されてるのに
暗号化では改ざんの検出は出来ません署名を使います
全体的に公開鍵と証明書がごっちゃになってる。証明書ならそのまま送っていい。受けた側が検証できる。生の公開鍵ならまず安全な通信路を確保する必要がある。
ルート証明書やオレオレ証明書など他の証明書で検証可能な署名のついていない証明書は普通にあるし、証明書は公開鍵に付加情報をつけられるコンテナに過ぎないと考えたほうがいいかと。
それなら公開鍵をそのまま送られても信用できないって話になるんでないの?
公開鍵を平文で送って改竄されたらどうすんの?KPI云々以前に俺は「サーバに公開鍵登録して」っていうパターンって言ってんだけど。
> 改竄されたら
ユーザ認証は別にするんですよね?
ならば、どのみち改ざんされた公開鍵とペアの秘密鍵では、ログインできないだけなので単純にもう一回公開鍵を送ればいいだけでは。
そういう問題ではない?
だいたいの人はSSHは公開鍵オンリーで認証通しちゃわない?なので改ざん公開鍵を設置されちゃうと悪意のある人がログインできてしまうな。
まぁ、平文で送ってauthorized_keysに追加するとかいうケースは考えにくいけど。
> 公開鍵を平文で送って改竄されたらどうすんの?
そりゃ別の信頼できる方法でfingerprintを伝えて改竄を検知するにきまってるじゃないですか。だから平文で送っても何の問題もありませんよ。
暗号化したところで、その暗号鍵を信頼できる方法で受け渡さないと意味がないわけで、暗号鍵を安全に渡す方法がもしもあるのであれば、その方法を使ってfingerprintを伝えれば済む話です。暗号化する必要なんてありません。
逆にfingerprintを安全に渡す方法がないのであれば、暗号鍵を安全に渡す方法もないわけで、暗号化したところで無意味ですね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
物事のやり方は一つではない -- Perlな人
背景によるとしか (スコア:0)
サーバ側に公開鍵登録してっていう依頼ならそりゃ平文で送るなは正しい。
(HTTP、FTPでの転送って意味だよ)
それぞれの「理由」が書いてないので公開することを嫌がる事を批判する事がおかしい
Re:背景によるとしか (スコア:1)
公開鍵は、紙で手渡しが原則だろうw
それぞれの理由を考えてみた
「公開鍵が盗聴される恐れがある」…「盗聴さえる恐れ」ならなんだってあるだろう。
「公開鍵を平文で送るな」…平文で送れば、盗聴で検知され、別の公開鍵に置き換えられることをいってないか?
「公開鍵をそのままサーバに保管するな」…「そのまま」が暗号なしの手順で送るなって意味じゃないのか?
「公開鍵だけ送るのでは復号ができない」…「公開鍵だけ」送られてきても、貴方のものか検証できないって意味じゃないの?
「公開鍵を公開したくない」…それは「お前に」公開したくないだけじゃないのかw
Re: (スコア:0)
「盗聴さえる恐れ」改竄されてるヨ!
Re: (スコア:0, フレームのもと)
転送方法に関わりなく、盗まれようと流出しようと問題はないです。
PKIの仕組みを勉強した方が良いのでは?
酔っぱらった状態での意見だけど (スコア:1)
どういう意図で、公開したくないと言ったのかが解らないため、真意はわかりませんが、
例えば、乱数的に生成されたURLを発行し、それを知る人物しかアクセスできないことで、
第三者によるアクセスを防ごうとするシステムがあるように、
公開鍵を隠すことで、通信を開始できないようにするという考え方もあるのではないのでしょうか?
公開暗号方式自体が安全だとしても、実装が本当に安全であるかは判らない訳で、
(現実で起こった例と挙げるとすれば、TLSの仕様が(実用面ではともかくとしてセキュリティ面で)問題なかったとしても、
その実装でHeartbleedのような脆弱性が発見された)
「通信を開始できる人間を限定することで、そのような脆弱性をつつかれる可能性を減らす」
という考え方はあるのではないでしょうか?
Re: (スコア:0)
それなら、公開鍵の隠匿なんて雑な方法じゃなく、クライアント証明書でいいんじゃないの?
Re:酔っぱらった状態での意見だけど (スコア:1)
という考えは、公開暗号方式の仕組みの知識があっても、
使われた方の知識がなければ要求・提案できないし、
公開したくないと言った人が仕組みしか知っていなかった可能性はあるのだから、
「理由」を聞いて、提案しないといけないんじゃないの?
Re: (スコア:0)
差し替えられたら問題があるからでは?
Re: (スコア:0)
Re: (スコア:0)
改ざん、なりすましの危険が無い通信路を確保できれば平文で盗聴されようが問題無いですよね。
面と向かって大声でとか
Re: (スコア:0)
> (HTTP、FTPでの転送って意味だよ)
って条件説明されてるのに
Re: (スコア:0)
暗号化では改ざんの検出は出来ません
署名を使います
Re: (スコア:0)
全体的に公開鍵と証明書がごっちゃになってる。
証明書ならそのまま送っていい。受けた側が検証できる。
生の公開鍵ならまず安全な通信路を確保する必要がある。
Re: (スコア:0)
ルート証明書やオレオレ証明書など他の証明書で検証可能な署名のついていない証明書は普通にあるし、
証明書は公開鍵に付加情報をつけられるコンテナに過ぎないと考えたほうがいいかと。
Re: (スコア:0)
それなら公開鍵をそのまま送られても信用できないって話になるんでないの?
Re: (スコア:0)
公開鍵を平文で送って改竄されたらどうすんの?
KPI云々以前に俺は「サーバに公開鍵登録して」っていうパターンって言ってんだけど。
Re: (スコア:0)
> 改竄されたら
ユーザ認証は別にするんですよね?
ならば、どのみち改ざんされた公開鍵とペアの秘密鍵では、ログインできないだけなので
単純にもう一回公開鍵を送ればいいだけでは。
そういう問題ではない?
Re: (スコア:0)
だいたいの人はSSHは公開鍵オンリーで認証通しちゃわない?
なので改ざん公開鍵を設置されちゃうと悪意のある人がログインできてしまうな。
まぁ、平文で送ってauthorized_keysに追加するとかいうケースは考えにくいけど。
Re: (スコア:0)
> 公開鍵を平文で送って改竄されたらどうすんの?
そりゃ別の信頼できる方法でfingerprintを伝えて改竄を検知するにきまってるじゃないですか。
だから平文で送っても何の問題もありませんよ。
暗号化したところで、その暗号鍵を信頼できる方法で受け渡さないと意味がないわけで、
暗号鍵を安全に渡す方法がもしもあるのであれば、その方法を使ってfingerprintを伝えれば済む話です。
暗号化する必要なんてありません。
逆にfingerprintを安全に渡す方法がないのであれば、暗号鍵を安全に渡す方法もないわけで、
暗号化したところで無意味ですね。