[connect24h:00398] Re: 話題提供 8/11

[hamamoto <hamamoto@xxxxxxxxxxx>]

はまもとです。

On Sun, 13 Aug 2000 01:01:40 +0900
Mitsuyuki Fukuyama <fuku@xxxxxxxxxxx> wrote:

> 福山と申します。

はじめまして。

> > > ●メール暗号化に新展開―定番サーバーSSL使う
> > > http://biztech.nikkeibp.co.jp/wcs/show/leaf?CID=onair/biztech/inet/108565
> > > http://nnw.nikkeibp.co.jp/cgi-bin/nnw-topics.cgi?option=view&sn=36
> > すいません。紹介して何なんですが、よくこの内容を読んでみたらこの記事の
> > 内容、変ですね。信じないようにしてください。
> 
> 後学のために、具体的に何が変だと感じられたのか教えてもらえませんか ?

サードパーティリレーの防止にはTLSが導入されたsendmail 8.11.0を導入せよ
と読めますが、サードパーティリレーを防止できるというsendmailの認証はTLS
の機能ではなくSMTP AUTHです。

SMTP AUTHは8.10.xで導入された機能なので、8.11.0の新機能という言い方は
おかしい。しかも、SMTP AUTHというキーワードが出てこない。暗号化のTLSと
SMTP AUTHの認証機能がごっちゃになっているみたいです。

●SMTP AUTH in sendmail 8.10 
http://www.sendmail.org/%7Eca/email/auth.html

しかもTLSで暗号化するにはサーバとクライアントの両方がTLS対応しないと
いけないはずですが、表記の文ではサーバさえsendmail 8.11.0にすれば、み
んな幸せになれると読めてしまいます。これもちょっとおかしい点ですね。

暗号化のメリットにしても、メールサーバにはsendmail、qmailという選択肢
があるわけですから、サーバ側で暗号化に対応というよりは、IPSecなどのプ
ロトコルレベルの暗号化のほうが楽で良いんじゃないかと思う今日このごろ
です。

セキュリティを考えた場合、暗号化は諸刃の剣で、暗号化されてしまうと通
信中に何が行われているか、侵入検知システムでパケットをチェックできな
くなってしまいます。その場合、侵入検知システム側であらかじめ暗号をデ
コードできるしくみを考える必要があり、そういう意味でも雑多なアプリレ
ベルでの暗号化よりは、プロトコルレベルでの一括暗号化のほうが都合が良
いですね。

ここら当たりの実装方法について、どなたかご存知ありませんかねぇ。今、
セキュアサイトの構築のため、実装方法を考えているんですよね。


+---------------------------------------------------------------------
| はまもと
| ■常時接続の宴
| http://www.hicat.ne.jp/home/hamamoto/
| インターネット常時接続の経験とノウハウを気楽に話し合うための場所です
| ■24 時間常時接続メーリングリスト開催中
| http://www.hicat.ne.jp/home/hamamoto/ml/connect24h.html
+----------------------------------------------------------------------