論より証拠ということで、ラッパーである stunnel を用いて、TLS を利用してみよう。
% cat pop3-tls-client client=yes pid= verify=0 foreground=yes debug=debug [10985] accept=127.0.0.1:12345 connect=pop.example.com:110 protocol=pop3 % stunnel pop3-tls-clinet |
上記の例と変わったのは最後の2行である。
ここでローカルホストの 12345 番ポートへ接続すると、pop.example.com の 110 番ポートに暗号路が確立された状態で接続される。
% telnet 127.0.0.1 12345 S: +OK IIJ POP3 Server (pop.example.com) starting. <14663.1200725428@pop.example.com> C: CAPA S: +OK Capability list follows S: . |
証拠としては弱いが、“CAPA” コマンドに“STLS”が返って来てないので、TLS で暗号化されていると分る。心配なら、tcpdump などで中身が覗き込めるか検査してみてもいいだろう。
先ほどの通信例とこの通信例を見比べてほしい。前者からサーバの最初の挨拶だけを“:”に置き換え、そしてここが重要なのだが、残りの平文“|”の部分を削れば後者になる。この意味するところが分るだろうか?
それはつまり、SSL ラッパーに今削った部分を喋らせれば、TLS ラッパーになるということだ。
TLS の設計のキモは、状態の遷移ではなく、セッションのやり直しである。TLS によって暗号通信が開始された後は、アプリケーションプロトコルが再び最初から始まるのだ。
上記の例では、POP クライアントは最初の“CAPA”コマンドからやり直していることが分るだろう(POP が分りにくければ、SMTP で考えてみるとよい。SMTP であれば、“EHLO”コマンドからやり直す)。
最初からやり直すということは、すなわち、既存のサーバやクライアントを改良せずとも、そのまま利用できるということだ。
クライアント側の SSL ラッパーを TLS ラッパーに改造するには、以下の作業を加えればよい。
“START TLS”コマンドは、アプリケーションプロトコルごとに異なる。だからこそ、“stunnel”の設定ファイルには“protocol”を指定して、どのアプリケーションプロトコルかを指示する必要がある。
サーバ側の SSL ラッパーを TLS ラッパーに改造するには、以下の点においてクライアント側よりも複雑である。
以下に、実装機能一覧を処理する例を示す。
なお、stunnel バージョン 4.20 では、これらを実装できてない。
重要なプロトコルに対する SSL ポートの割当状況を以下に示す。
表1 重要なプロトコルに対する SSL ポートの割当状況
プロトコル |
通常ポート |
SSLポート |
HTTP | 80 |
443 |
POP | 110 |
995 |
IMAP | 143 |
993 |
SMTP | 25 |
割当なし |
このように、SMTP にだけ SSL 用のポートが割り当てられていない。歴史的に言えば、465 番が割り当てられていたが取り消され、465 番は igmpv3lite というプトロコルに割り当てられた。
著者は割当機関である IANA に対し「ISP として困るので割り当てて欲しい」と申請したが、拒否された。理由は「IETF は SSL を推奨していないから」だそうである。
現在、465 番を SMTP の SSL ポートとして利用している ISP/ASP は多い。現実問題として困ることは起きないと思うが、正式ではないことを知っておくのもよいだろう。
《PREV》 |