Re: ssl example, wclient failed in checking certificate
In article <YAS.04Oct7185651@kirk.is.tsukuba.ac.jp>,
yas@is.tsukuba.ac.jp (Yasushi Shinjo) writes:
In article <YAS.04Oct7185651@kirk.is.tsukuba.ac.jp>,
yas@is.tsukuba.ac.jp (Yasushi Shinjo) writes:
> 新城@筑波大学情報です。こんにちは。
>
> In article <squ8yak82p4.fsf@stellar.co.jp>
> manmos@stellar.co.jp (Hideo "Sir MaNMOS" Morishita) writes:
> > > (1) ファイル−>ルート認証局−>中間認証局−>サーバの証明書
> > > (2) ファイル−>サーバの証明書
> > すみません、この最初の「ファイル」は何を差すのでしょう?特に2番目。
>
> 「ファイル」というのは、サーバの証明書がローカル・ファイルに
> 入っているという意味です。ルート認証局を信用するといっても、
> 結局は、ローカル・ファイルを信用して、それに含まれている証明
> 書を信用するという意味になります。
なるほど、PGPだとかの考え方ですね。
> > 認証局証明書をダイナミックにとってくることはそんなにないのですが、サー
> > バ証明書は接続の度にやってきますよね。
>
> サーバの証明書は、接続の時に取って来なくても、構わないと思い
> ました。つまり、ローカル・ファイルから読込んだものを使うわけ
> です。
>
> SSL では、プロトコル上、サーバの証明書は必ず送らないといけな
> いんですか。何度も同じものを送るのは無駄のような気がするんで
> すが。
一応SSLv3、TLSv1のプロトコル上は
client hello ->
<- server hello
server_key_exchange
server hello done
client key ex ->
.
.
.
というプロトコルも考えられなくはないのですが(この場合だとサーバの公開
鍵は"temporary"とされていますので「信用がない」状態となります。実装上
どうするかなので、固定してしまうこともできはするでしょうが。)、OpenSSL
でそういう実装になっているかどうかは、調べていません。(あったような気
はします。)
通常はserver helloのあとに(server)certificateがあります。ちなみにその
あと、certificate_requestを続けるとクライアントの認証も証明書ベースで
行うこととなります。この実装はOpenSSLにもあります。
まあ、無駄と言えば無駄なんでしょうけど、回線も速くなってきたことだし、
精々2KByteの証明書を送ることくらい(そして、サーバ側だけの認証だけなら)
多対多の暗号通信では、それが一番ユーザの負担が少ない方法だと評価できま
す。
ipsecのIKE(旧Oakley)は、DHでやろうとしたみたいですが、証明書ベースじゃ
ないこともあって、結局駄目になりましたし。IKE2ではPKI(TLSv1)の採用を考
えているグループもあります。
> > わたしゃ、認証屋でPKI屋じゃないんだが…
>
> 認証屋ですか。どんな仕事なんですか。PKIも得意そうな響きなん
> ですが。
実はRADIUS屋です。もう、10年やってます。(DIAMETERもやらないこともない
ですがSCTPが標準でカーネルのサポートがないと世に出せない。)
authenticationだけではなく、authorizationとaccountingもかなり考慮にい
れる話が、仕事としては多いのです。PKI(X.509)だとauthorizationに当たる
部分はせいぜい(extended)key usageくらいしかないですよね。
PKIもEAPとかで利用しますので、PKI屋さんとかと議論を交すことがあるので
す。そういう意味ではPKI屋さんとは近い位置にはいます。一応ietfのpkix の
話は追い掛けてはいますし。
> In article <squ655o82cd.fsf@stellar.co.jp>
> manmos@stellar.co.jp (Hideo "Sir MaNMOS" Morishita) writes:
> > それこそ、sshなんかは、「俺様が能動的に接続にいったサーバから帰ってき
> > た公開鍵やねんから、(初回はユーザに確認にはいきこそすれ)そんなん、信用
> > してええやん」って世界ですよね。
> >
> > そういう意味で(sshで2回目以降の接続)の(2)なのでしょうか?
>
> いいえ。ssh で考えると、接続する前に、安全な方法で
> known_hosts にサーバの公開鍵を登録してしまうという方法です。
> こうすれば、1回目から安全です。
公開鍵の「信用の仕方」の一つですね。「公開鍵は違うセッションでとってく
る」という。
しかし、前述したようにSSLのようにhttpsなどで、使われる世界ではPKIがベ
ストによりちかいのかなぁと思います。popやimap位なら接続するサーバも限
られていますので、公開鍵を別に持つという選択もあるのですが、sshにpopを
のせた設定をしても、やはり、普通のユーザには受け入れがたいようです。
ただ、そろそろ、サーバの認証だけでなく、個人の認証にPKI使うようになっ
てくるんでしょうけど、紛失と失効が地獄だろうなぁと…expireを短くして個
人用の証明書はcrlださないってサービスもあるみたいですが。
特に電子申請を個人で行うためには「電子印鑑証明」って形で、地方公共団体
(都道府県レベルくらい)で認証局をやる必要があると思っています。実際大阪
府のデータセンタが新設されるときに、そこで何をやるかってののアイデアは
何かないかって話があったときに、そういう話はしたのですが、無視されまし
た。
--
___ わしは、山吹色のかすてーらが大好きでのぅ
[[o o]] ふぉっふぉっふぉ
'J' 森下 お代官様 MaNMOS 英夫@ステラクラフト
PGP Finger = CD EA D5 A8 AD B2 FE 7D 02 74 87 52 7C B7 39 37
Fnews-brouse 1.9(20180406) -- by Mizuno, MWE <mwe@ccsf.jp>
GnuPG Key ID = ECC8A735
GnuPG Key fingerprint = 9BE6 B9E9 55A5 A499 CD51 946E 9BDC 7870 ECC8 A735