SSL/TLSは、HTTPと組み合わせられることが多いですが、MySQLにもSSL経由の接続オプションがあるように、本来はプロトコルと独立して適用可能なものです¹。

どうやってTLS通信に入る？

「最初からSSL/TLSの通信路しか用意しない」という手段を別にすれば、何かしらの方法でSSLありとなしの通信を区別する必要があります。

HTTPSでは、HTTPが80番ポートを使うのに対して、HTTPSでは443番を使うようにしてあるので、区別は明らかです。

ただ、ポート番号をSSL/非SSLで2倍消費していくと大変というような事情もあって、同じポートでまずは平文で接続を行い、プロトコル内のコマンドの1つにSSL導入の役割を持たせて、それで切り替える、というような手法があります。これがSTARTTLSです。

STARTTLSの利点・欠点

STARTTLSでは、すでに標準化しているポートで、「SSLあり/なしを同じように待ち受けられる」という点がメリットとなります。

一方で、SSLへのアップグレードまでは平文で通信が行われるため、そこで第三者が妨害すれば平文のまま通信が行われてしまう、というデメリットがあります（最初からSSL通信が行われる場合、鍵を解読できない中間者の介入は接続失敗となり、以降の通信は続きません）。

実例

FTPS

FTPS²では、あまり「STARTTLS」と銘打たれることはありませんが、「Explicitモード」といって、ふつうにFTPで接続してからAUTHコマンドでSSL接続に切り替えるようになっています。別にFTPS用ポートを開いておく「Implicitモード」は、正式なRFCに載らないこととなりました。

なお、多くの場合、FTPクライアント側の設定で、SSL接続に失敗した場合「そのまま平文のFTPを続ける」か「接続しない」かを選ぶことができるようになっています。

SMTPでのSTARTLS

STARTTLSの実装としていちばん有名なのが、SMTPに対して適用するものです。最近はSTARTTLSが使えるように設定されたメールサーバも多く、GmailでもTLSなしで届いたメールには壊れた鍵のアイコンが出るようになっています。

もともと、SMTPが「シンプルメール転送プロトコル」の略であるように、メールの送信は「バケツリレー式」と呼ばれるような、幾つものサーバを経由したものでした。これでは1ホップだけTLSをかけたところで、全体のセキュリティ向上にはあまり資さないものでした。

ただ、インターネット上ではバケツリレー式でなく、直接受信アドレスのあるサーバに接続するのが一般的となってきたことなどもあり、比較的地位が向上している感はあります。

ただ、ホップ間の暗号化という制約はそのままなので、サーバ～サーバ間のDKIMや、ユーザー間でのS/MIMEなど、より上位からの暗号技術適用も依然として有用です。

もっとも、SNIやALPNなどのように、通信プロトコル側で必要な機能のために、TLSの拡張がなされる例もあります。 ↩
「SFTP」という似た名前のものがありますが、こちらはSSHの上でFTPを行うというもので、まったくの別物です。 ↩