アプリ層プロトコルのセキュア化 ─ HTTPS・SMTPS・IMAPS・FTPS・SFTP

学習目標

本講を終えると、以下を達成できるようになります。

• 古典アプリ層プロトコルが そのままでは平文 という共通の弱点を持ち、TLS でそれを覆い隠す方針が広がった経緯を述べられる
• Implicit TLS(専用ポートで最初から TLS)と STARTTLS(平文セッションを途中から TLS に昇格)の違いを説明できる
• 主要なセキュア化版のポート番号(HTTPS 443 / SMTPS 465 / Submission+STARTTLS 587 / POP3S 995 / IMAPS 993 / FTPS 990 など)を区別できる
• SFTP は FTPS とまったくの別物(SSH 上の独自プロトコル / 22 番)であることを正確に説明できる
• openssl s_client を使って TLS の中で平文プロトコルを手打ちでき、観察したい目的に応じて telnet と使い分けられる
• メールの SPF / DKIM / DMARC が、送信元ドメインのなりすまし対策としてどこを検証するか説明できる
• HSTS、MTA-STS、DANE、OAuth2 など 「TLS だけでは守れない領域」 を埋める現代の追加対策の位置づけを述べられる

このレッスンの目次

なぜアプリ層を「セキュア化」する必要があったか

TLS(第25回)はこの3つを 「暗号化 + メッセージ認証 + サーバ認証(PKI)」 でまとめて解決するために設計されました。だから対策の基本パターンは 「既存の平文プロトコルの下に TLS を1段挟む」 ── これだけ。アプリ側の仕様は基本そのままで、TCP の代わりに TLS 越しの TCP を使うように差し替える、というだけのことです。

Implicit TLS と STARTTLS ─ 被せ方の2方式

シーケンスで比較

図の見方:Implicit は「TLS 専用ポート」を1つ用意して綺麗に分離。STARTTLS は「平文版とポートを共有」して同じ入り口から段階的に暗号化する。後者は移行時の互換性に強い反面、初期の平文部に「STARTTLS を消す中間者攻撃(STRIPTLS)」のリスクがあり、近年は 強制 STARTTLS(対応していない接続を即切断)で防御するのが標準。

HTTPS ─ Implicit TLS の代表例(443)

HTTPS のポート構成

メール系のセキュア化 ─ TLS化と送信元ドメイン認証

SMTP のポート3兄弟 ── 25 / 465 / 587 の使い分け

こぼれ話: 465 は一度 IANA から「使うな」と言われた歴史があり、その後 587 + STARTTLS が推されて主流になりました。しかし STARTTLS のダウングレード攻撃や運用上の煩雑さから、近年(RFC 8314, 2018) 465(Implicit) を再評価 し「Implicit と Submission(587) を併用するのが望ましい」とされています。一周回って Implicit が見直されたわけです。

POP3 / IMAP の TLS 版

送信元ドメイン認証 ─ SPF / DKIM / DMARC

SMTP-AUTH は 「投函してきた利用者が正規ユーザか」 を見る仕組みです。一方、受信側に届いたメールが 名乗っているドメインから本当に来たのか を見るには、SPF / DKIM / DMARC を使います。たとえば「example.com から来た」と見えるメールが、実際には別の場所から勝手に送られていないかを確認するための仕組みです。

受信側MTAは何を順番に見るか

1. SPF: SMTP 接続元 IP が、MAIL FROM のドメインで許可された送信元かを DNS の TXT レコードで確認する。
2. DKIM: メールに付いた DKIM-Signature を読み、DNS で公開鍵を取得して署名を検証する。
3. DMARC: 利用者に見える From: のドメインと、SPF/DKIM の合格ドメインが整合しているかを見る。
4. 最終処置: 送信ドメインのポリシーに従い、通常配送・隔離・拒否などを決める。

FTPS ─ FTP に TLS を被せた拡張

なぜ平文 FTP をそのまま使わないのか

FTP は RFC 959 の時代の設計で、ユーザ名・パスワード・ファイル本体を 暗号化せずに 流します。学習用に telnet で観察しやすい反面、インターネット越しの本番運用では危険です。

整理: FTP の 制御接続とデータ接続 という設計はプロトコルとして重要ですが、安全に使う話は別です。現代では「FTP の考え方を知る」と「平文 FTP を運用で使う」は分けて考えます。

FTPS の難しさ ─ 制御接続が暗号化されると NAT/FW が悩む

平文 FTP では、NAT 機器が ALG(Application Layer Gateway) として制御接続の PORT や PASV コマンドを 盗み見て データ接続のポートを事前に開けてやる、という運用がありました。FTPS では制御接続も暗号化されるので、ALG が中身を読めなくなる ── 結果、Active モードのデータ接続が NAT 越しでうまく中継されない問題が起きやすくなります。

運用上の解決策はだいたい1つに収束していて、「Passive モード固定」+「サーバ側で動的ポート範囲を狭く明示開放」+「クライアント側 NAT は問題なし」。それでも FTP は徐々に新規採用が減り、後述の SFTP や HTTPS 配信に置き換わっていきました。

SFTP / SCP ─ 名前は似ているが 系統が違う

3者の比較

なぜ SFTP は FTPS より楽か

• FTP のような 制御 + データの二本立てが不要 ── 1本の SSH コネクションで完結する
• NAT 越えが普通の SSH と同じ感覚で済む
• SSH 鍵認証が使える ── パスワードを送らずに済む
• サーバ運用が楽 ── sshd を立てるだけで動く(専用デーモン不要)

現代のファイル転送は何を選ぶか

「ファイルを送る」と言っても、配布・同期・バックアップ・クラウド連携では向いた方式が違います。生の FTP を新規に選ぶ場面はかなり少なく、次のように目的別に選ぶのが現代的です。

つながる知識: 1980年代の FTP は「制御とデータを分ける」発想、1990年代以降の HTTP は「1本の接続にまとめる」発想、SSH 系の SFTP/rsync は「暗号化された1本のトンネルに入れる」発想です。プロトコルの形は、その時代のネットワーク事情をかなり正直に映します。

openssl s_client で TLS の中を覗く ─ telnet の HTTPS 版

基本形

# HTTPS(443)に接続して TLS の中を平文として開く
$ openssl s_client -crlf -connect example.com:443

(TLS ハンドシェイクのログがズラっと流れた後…)
GET / HTTP/1.1
Host: example.com

(空行)
HTTP/1.1 200 OK
...

-crlf オプションは「Enter キーを CRLF に変換」するためのもの。telnet と同じ感覚で HTTP を打てます。

STARTTLS 版(SMTP / IMAP / POP3)

STARTTLS で昇格するタイプのサーバには、-starttls オプションで「最初の STARTTLS までを openssl が代行」してくれます。

# SMTP Submission(587)を STARTTLS で TLS 化して開く
$ openssl s_client -crlf -starttls smtp -connect smtp.example.com:587

# IMAP の STARTTLS
$ openssl s_client -crlf -starttls imap -connect imap.example.com:143

# POP3 の STLS
$ openssl s_client -crlf -starttls pop3 -connect pop.example.com:110

# FTP の AUTH TLS(明示モード)
$ openssl s_client -crlf -starttls ftp -connect ftp.example.com:21

証明書を確認する用途にも便利

# 期限・SAN・発行者などを取り出す
$ openssl s_client -connect example.com:443 -servername example.com </dev/null \
    | openssl x509 -text -noout

サーバ証明書のフィールドが読めるので、X.509 の中身(第25回で学んだ Subject、SAN、Issuer、有効期限) を実物で確認できます。本物の運用調査でもよく使う手筋です。

現代の運用 ─ TLS だけでは守れない領域を埋める

HSTS(HTTP Strict Transport Security)

サーバが応答ヘッダで Strict-Transport-Security: max-age=31536000; includeSubDomains と宣言すると、ブラウザは 「このドメインは今後1年間、HTTP を試さず必ず HTTPS で接続する」 と覚えます。STRIPTLS 攻撃やリダイレクト経路の盗聴を封じる効果があります。Chrome / Firefox には HSTS preload list という「最初から HSTS 扱いするドメイン名簿」もあり、Google / GitHub などはここに登録済み。

MTA-STS / DANE(メール送信の TLS 強制)

メール MTA 間(25/tcp + STARTTLS)は、相手サーバが STARTTLS に対応していなければ 平文に落ちる ── これが昔から悩みでした。MTA-STS(RFC 8461)はサーバ側が DNS と HTTPS で「私の MX は必ず TLS で来てね」と宣言する仕組みで、対応 MTA は STARTTLS 失敗時に 送信そのものを中止 します。DANE(DNSSEC + TLSA レコード)も同種の TLS 強制策ですが、DNSSEC が前提となるため普及は MTA-STS よりやや遅め。

OAuth2(SMTP/IMAP の認証強化)

大手メールプロバイダ(Gmail、Outlook 365 など)は、SMTP-AUTH や IMAP のパスワード認証から OAuth2 アクセストークン 認証への移行を進めています。背景は (1) パスワードを各クライアントに保存させたくない、(2) 段階的なアクセス権限管理(スコープ)、(3) 多要素認証(MFA)との統合容易性。telnet で対話できる SMTP-AUTH PLAIN とは別世界の認証フローになっています。

HTTPS Everywhere の文化

2010 年代後半から、ブラウザベンダ・SEO・Let's Encrypt(無料証明書) の3つが噛み合って、「個人サイトでも HTTPS が当たり前」 という空気が一気に作られました。Mozilla の HTTPS-Only Mode、Chrome の 「HTTPS にアップグレードを試行」 設定など、ブラウザは 平文への回帰を能動的に阻止 する方向に進化しています。

まとめと用語チェック

用語チェック

確認問題