| TCP/IP群 |
|---|
| アプリケーション層 |
|
| トランスポート層 |
| カテゴリ |
| インターネット層 |
| カテゴリ |
| リンク層 |
| カテゴリ |
STARTTLS(スタート・ティーエルエス)は、平文の通信プロトコルを暗号化通信に拡張する方法のひとつ。Opportunistic TLS(日和見TLS)あるいはExplicit TLS(明示的TLS)とも呼ばれる。
暗黙のTLS(またはSSL。以下単にTLS)では、暗号化通信のために専用のポートを割り当てなければならない。STARTTLSを利用すれば、専用のポート番号を割り当てずに、途中から平文の通信を暗号化通信に切り替えることができる。
TLSはアプリケーション中立である。例えば、TLS 1.2の仕様書である RFC 5246 では以下のように述べられている。
TLSの利点の一つは、アプリケーションプロトコルから独立していることである。上位層のプロトコルから見てTLSは透過的である。しかしTLSは、標準では、セキュリティをどのように実装するかまでは規定していない。ハンドシェイクをどう始めるか、交換された電子証明書をどう解釈するかは、TLSより上位のレイヤの設計と実装に委ねられている[1]。
| プロトコル | 用途 | RFC | 通常ポート (STARTTLS) | SSL | SSLポート |
|---|---|---|---|---|---|
| SMTP | 電子メール送信 | RFC 3207 | 25/587 | SMTPS | 465 |
| POP3 | 電子メール受信 | RFC 2595 | 110 | POP3S | 995 |
| IMAP | 電子メール受信 | RFC 2595 | 143 | IMAPS | 993 |
| NNTP | ネットニュース | RFC 4642 | 119/433 | NNTPS | 563 |
| LDAP | ディレクトリ・サービス | RFC 4511 | 389 | LDAPS | 636 |
| FTP | ファイル転送 | RFC 4217 | 21 | FTPS | 990 |
| XMPP | インスタントメッセンジャー | RFC 4217 | 5222 | 5223 |
このうち、POP3、IMAP、SMTPについては、RFC 8314 でSTARTTLSよりもImplicit TLS(暗黙のTLS、個別のポートを使用)の使用が推奨となっている。
TLSを使う方法は、TLSと同レイヤで動作するその他のプロトコルと同様であり、複数のTLSライブラリ実装でサポートされている。 TLSのSMTP拡張 (RFC 3207) で、クライアント(以下ではCとする)とサーバ(以下ではSとする)がセキュアなセッションを開始するまでのやりとりは、例えば次のようになる[2]。
S: <TCPポート25番で接続要求を待つ> C: <接続をオープンする> S: 220 mail.example.org ESMTP service ready C: EHLO client.example.org S: 250-mail.example.org offers a warm hug of welcome S: 250 STARTTLS C: STARTTLS S: 220 Go ahead C: <TLSネゴシエーションを開始> C & S: <TLSのネゴシエーション> C & S: <ネゴシエーションの結果を確認> C: EHLO client.example.org[注釈 1] …
最後のEHLOコマンドはセキュアチャネルを通じて送られる。SMTP認証を利用する場合[注釈 2]は、セキュアチャネルが開かれた後であれば、サーバからの応答をAUTH PLAINで送信しても問題ない。
2011年10月現在、STARTTLSをメール送信のために提供しているフリーメールサービスにはGmail[3]とiCloud[4]がある。
両エンドが1対1でセッションを構築するTLSをメールの通信に利用しても、間欠的な通信や他のサーバによる中継を前提とした電子メール[5]では、ホップ間のセキュリティは確保することができるものの、
など、電子メールの完全性や機密性の担保、送信者認証などはいずれも実現することができない[10]。電子メールに対してこれらの保護を適用するには、S/MIMEなど、上位層で行うことが必要となる[11]。
Eric Rescorla、齋藤孝道、古森貞、鬼頭利之(訳)、2003、『マスタリングTCP/IP SSL/TLS編』、オーム社 ISBN 978-4274065422
未登録
IPFS未登録
📡 0ピア
N=1
CRITICAL
PQS B78