メール配送とHTTP/TLSについて学習した話(SPF・DKIM・DMARC・HSTSまで)
はじめに
情報処理安全確保支援士試験の対策として、電子メールの配送の仕組みとなりすまし対策(SPF/DKIM/DMARC)、そしてHTTP・Cookie・TLSまわりの知識を学習したのでまとめます。
メールの構成要素
電子メールの送受信は、複数の要素(エージェント)が連携して行われている。
送信の流れ
- メールソフトである**MUA(Mail User Agent)**から送られてきたメールを、**MSA(Mail Submission Agent)**が認証する
- **MTA(Mail Transfer Agent)**がメールを中継し、宛先のメールサーバへ送る
受信の流れ
- MTAが**MDA(Mail Delivery Agent)**へメールを配送する
- MDAはメールをメールボックスに格納する
- **MRA(Mail Retrieval Agent)**が、MUAからの受信要求に応じてメールボックスからメールを取り出し、届ける
POPとIMAP
| プロトコル | 概要 | 特徴 |
|---|---|---|
| POP | メールボックスからメールをダウンロードして閲覧する | ダウンロード後はサーバ側のメールを消去するため、サーバのストレージを空けられる。一方で、別の端末からは同じメールを見られなくなる |
| IMAP | メールをダウンロードせず、サーバ上のメールを直接確認する | 複数端末から同じメールを閲覧できる一方、サーバ側の負荷が高くなりやすい |
SMTP
電子メールを送信するためのプロトコルで、TCP/25番ポートを利用する。MUAからMSAへメールを送信する際などに使用される。
エンベロープアドレスとヘッダアドレス
- エンベロープアドレス:実際のメール配送(宛先の決定)に使われるアドレス
- ヘッダアドレス:メールヘッダ内に記載されるテキスト情報で、配送そのものには関与しない
OP25B(Outbound Port 25 Blocking)
自ネットワークから外部ネットワークへの、ポート25番宛ての通信を遮断する対策。
- 迷惑メールを送りにくくする効果がある
- マルウェアに感染したPCが外部のメールサーバへ直接メールを送りつける挙動も遮断できる、というセキュリティ対策の側面もある
- デメリット:正規の外部メールサーバへの送信も遮断されてしまう。これは**サブミッションポート(587番)**を使うことで回避できる
SPF(Sender Policy Framework)
受信側メールサーバが、送信元メールサーバの正当性をIPアドレスで検証する技術。
- 受信側は、送信元ドメインのDNSサーバに対してSPFレコードを問い合わせる
- 取得したSPFレコードに記載されたIPアドレスと、実際にメールを送ってきたサーバのIPアドレスを照合する
SPFレコードの記述例
v=spf1 ip4:x.x.x.x -all
-
v=spf1:SPFのバージョン -
ip4:x.x.x.x:正規の送信元として許可するIPv4アドレス -
-all:上記で指定した以外からの送信は不正と判定する
DKIM(DomainKeys Identified Mail)
デジタル署名によって送信元ドメインを認証する技術。
- 送信側は、デジタル署名を付けた状態でメールを送信する
- 受信側は、送信元ドメインのDNSサーバにDKIMレコードを問い合わせて公開鍵を取得する
- 取得した公開鍵で署名を復号し、検証する
SPFとの違い
- SPFは送信元IPアドレスを公開するだけで運用できる
- DKIMは公開鍵暗号方式を利用するため、鍵管理(PKI)の整備が必要でサーバ負荷も高くなる分、SPFよりセキュア
- DKIMレコードはTTLの設定により、数分程度で情報が期限切れになる
DMARC(Domain-based Message Authentication, Reporting, and Conformance)
SPF・DKIMによる送信元ドメイン認証に失敗したメールをどう扱うか、送信元ドメイン側がポリシーとしてDNS経由で公開する技術。
- SPF・DKIMで認証に失敗したメールはDMARCの判定に回される
- 受信側はDNSサーバにDMARCレコードを問い合わせ、記載されたポリシーに従って処理する
-
None:そのまま通す -
Quarantine:迷惑メールフォルダへ振り分ける -
Reject:受信を拒否する
-
DMARCレコードの主な項目
-
v:バージョン番号 -
p:認証失敗時の動作(ポリシー) -
rua:認証結果レポートの送付先
HTTP
WebサーバとWebブラウザの間で、HTML等の情報をやり取りするためのプロトコル。クライアントからのリクエストメッセージと、サーバからのレスポンスメッセージで構成される。
- 従来のHTTP/2まではトランスポート層にTCPを利用していたが、HTTP/3ではUDPを利用するようになった
主なHTTPメソッド
| メソッド | 概要 |
|---|---|
| GET | URLの一部にデータを含めてリクエストする |
| POST | 送りたいデータをボディ部に含めてリクエストする |
| CONNECT | プロキシサーバに対してトンネリングを要求する |
主なステータスコード
| コード帯 | 意味 |
|---|---|
| 200番台 | リクエスト成功(OK) |
| 300番台 | リダイレクト(複数の候補が存在する、恒久的に移転した等) |
| 400番台 | クライアント側のエラー(認証が必要、ファイルが見つからない等) |
| 500番台 | サーバ側のエラー |
代表例:200(成功)、300(複数の候補が存在)、301(恒久的な移転)、401(要ユーザ認証)、404(ファイルが見つからない)、500(サーバ内部エラー)
HTTPメッセージの構造
リクエストライン(またはステータスライン)
HTTPヘッダ
(空行)
HTTPボディ
主なHTTPヘッダ
リクエスト側
| ヘッダ | 内容 |
|---|---|
| Authorization | 認証情報 |
| User-Agent | クライアントのブラウザに関する情報 |
| Referer | どのページから遷移してきたかの情報 |
| Cookie | Cookie情報 |
レスポンス側
| ヘッダ | 内容 |
|---|---|
| Set-Cookie | サーバからクライアントへCookie情報を送信する |
| Location | リダイレクト先のURL |
| Server | レスポンスを生成したサーバのソフトウェア情報 |
Cookie
WebサーバとWebブラウザの間で状態(セッション情報など)を管理する仕組み。Cookieを利用することで、複数リクエストにまたがる連続的な情報管理が可能になる。
- クライアントがWebサーバにアクセスすると、サーバは
Set-CookieでCookie情報(セッションIDなど)をクライアントへ渡す - ブラウザ側はそのCookieを保存し、次回以降のアクセス時に一緒に送信する
- サーバはCookie情報をもとにユーザを識別する
Cookieの主な属性
| 属性 | 内容 |
|---|---|
| Expires | Cookieの有効期限を指定する |
| Secure | HTTPS通信のときだけCookie情報を送信する |
| HttpOnly | JavaScriptからのCookieアクセスを禁止し、クロスサイトスクリプティング対策とする |
TLS
データを暗号化して安全に送受信するための技術。以下の機能を持つ。
- 暗号化機能
- サーバ認証
- クライアント認証
- 改ざん検出機能
通信開始時にはTLSハンドシェイクを行う必要がある。
SSL/TLS化の効果
セキュリティ向上だけでなく、SEO対策としての効果も期待できるとされている。
TLSアクセラレータ
HTTPSでは多数のクライアントとのTLS通信が発生するため、Webサーバの負荷が高くなりやすい。TLSアクセラレータを導入し、暗号化・復号の処理をアクセラレータ側で行い、WebサーバとはHTTP(平文)で通信することで、Webサーバ自体の負荷を軽減できる。
HSTS(HTTP Strict Transport Security)
Webブラウザに対して、HTTPS接続を強制させる仕組み。サーバがレスポンスにStrict-Transport-Securityヘッダを付けて応答することで、以降のアクセスをHTTPSに強制する。
- 問題点:初回アクセス時のHTTP通信そのものは制限できない
- また、有効期限が切れるたびに、再び初回のHTTP通信が発生してしまう
- HSTSプリロードリストにドメインを登録しておけば、初回アクセスからHTTPSを強制できる
おわりに
SPF/DKIM/DMARCは似た名前で混同しがちでしたが、「IPアドレスで見るか(SPF)」「署名で見るか(DKIM)」「失敗時にどう扱うかのポリシー(DMARC)」と役割を分けて覚えると整理しやすいと感じました。引き続き学習を進めていきます。