送信ドメイン認証・暗号化 Deep Dive!

送信ドメイン認証・暗号化 Deep Dive!
株式会社クオリティア
平野善隆
～ DMARCから MTA-STS, DANEまで全部PASSさせるまでの道のり
https://bit.ly/3pgX4Qk
Speaker Deck
#jpaawg

View Slide

自己紹介
名前平野善隆
所属株式会社クオリティア
チーフエンジニア
資格等 Licensed Scrum Master
Certified Scrum Developer
主な活動 M3AAWG
JPAAWG
IA Japan 迷惑メール対策委員会
迷惑メール対策推進協議会
メッセージング研究所(MRI)
Audax Randonneurs Nihonbashi

View Slide

メールとの関わり
1990 パソコン通信などでメールに触れる
199x ドメインを取得して近所のISPに個人のサーバーを置
かせてもらって運用開始
2000 外人さんの多い会社に転職したのでメールの漢字に
ふりがなを付けたりして遊ぶ (のちのhiragana.jp)
個人のサーバーをちゃんとしたデータセンターに移
動。imail.ne.jpというドメインを取って一攫千金を
夢見るが挫折
2004 メールの会社に入社
以降スパムフィルタ、誤送信防止製品の開発やサービス
の立ち上げ。PPAPの礎を築く。
Speaker Deck

View Slide

もくじ
• メールセキュリティの全体像
• 世界のメールセキュリティと日本の状況
• メールセキュリティチェックサイトの紹介
• 送信ドメイン認証
• メールの通信経路の暗号化
Speaker Deck

View Slide

メールセキュリティって
どこまでやったらいいの？

View Slide

メールセキュリティ技術
SPF
DKIM
誤送信
防止
無害化
Password
ZIP
Anti
Phishing Anti
SPAM
DNS
SEC
SMTP
AUTH
DANE
MTA-
STS
START
TLS
BIMI
ARC
DMARC
TLSRPT
Anti
Virus
Virus
Filter
Sand
box
安心
マーク
なんかいろいろあって
よく分からない

View Slide

何を何から守りたいのか

View Slide

何から守りたいのか
クオリティア
メール
サーバ
メール
サーバ
なりすまし
乗っ取り
盗聴
改ざん
盗難
漏洩
ウィルス
メール
サーバ
フィッシング
メール
サーバ
なりすまし

View Slide

Emailを守るための技術
•なりすまし・改ざん・フィッシング
•乗っ取り・踏み台
•盗聴・なりすまし受信
•スパム・マルウェア
•情報漏洩
SPF DKIM DMARC ARC BIMI
POP before SMTP SMTP AUTH MFA
STARTTLS MTA-STS TLSRPT DANE DNSSEC
AntiSPAM AntiVirus SandBox Active! zone
一時保留 PasswordZIP WebDownload Active! gate

View Slide

優先順位が難しい
何か基準になるものがあるといいんだけど･･･

View Slide

日本は周回遅れで滅びる！
https://weekly-economist.mainichi.jp/articles/20201103/se1/00m/020/061000c
日本だけ見てても参考にならなさそうだ・・・

View Slide

オランダの場合
https://magazine.forumstandaardisatie.nl/meting-informatieveiligheidstandaarden-begin-2020
https://www.forumstandaardisatie.nl/sites/bfs/files/rapport-meting-informatieveiligheidstandaarden-maart-2020.pdf
Meting Informatieveiligheidstandaarden overheid maart 2020
(政府情報セキュリティ基準の測定2020年3月)
遅くとも
2017年末まで
遅くとも
2018年末まで
遅くとも
2019年末まで
DNSSEC
SPF
DKIM
DMARC
STARTTLSとDANE
SPFとDMARC
厳しいポリシー

View Slide

オランダでの普及率
Het Rejk 国 (政府系??)
全体

View Slide

一方日本では
SPF
SPF
-all
DMARC
厳しい
DMARC
DNSSEC STARTTLS MTA-STS DANE
オランダ政府(※1) 94% 92% 94% 59% 93% 98% - 81%
go.jp (※2) 93% 73% 7.0% 1.5% 5.5% 58% 0% 0%
.jp (※3) 62% 11% 1.5% 0.3% 0.04% 54% 0.004%
(13件)
0.002%
(6件)
※1 オランダ政府データ (2020/03)
※2 QUALITIA独自調べ go.jp(全てではない)のうちMXのあるドメイン(サブドメインは含まない)に対する割合 N=330 (2020/11)
※3 QUALITIA独自調べ jpドメイン(全てではない)のうちMXのあるドメイン(サブドメイン含む)に対する割合 N=約32万 (2020/10)
0
20
40
60
80
100
SPF SPF(-all) DMARC 厳しいDMARC DNSSEC STARTTLS DANE
オランダ政府 go.jp .jp

View Slide

オランダ政府御用達チェックサイト

View Slide

試してみた

View Slide

散々な結果

View Slide

散々な結果 (続き)

View Slide

何から守りたいのか
•なりすまし・改ざん・フィッシング
•乗っ取り・踏み台
•盗聴・なりすまし受信
•スパム・マルウェア
•情報漏洩

View Slide

なりすまし・改ざん・
フィッシング
から守る

View Slide

なりすまし・改ざんから守る
クオリティア
メール
サーバ
メール
サーバ
メール
サーバ
なりすまし
改ざん

View Slide

•SPF
•DKIM
•DMARC
•ARC
•BIMI

View Slide

SPF
•Envelope FromとIPアドレスが正しいか
どうかを確認できる
•RFC4408 (2006/04)
•RFC7208 (2014/04)

View Slide

SPFがないとき
192.0.2.1
203.0.113.1
Env From: [email protected]
From: [email protected]
Subject: お振り込みください
いつもお世話になっております。
・・・・
振り込みね。ポチっと。
×
クオリティア

View Slide

SPFがあるとき
192.0.2.1
AR: spf=pass
・・・・
qualitia.co.jp txt “v=spf1 ip4:192.0.2.1 –all”
Envelope FromからIPをチェック
○
本物だな。振り込みっと。
クオリティア

View Slide

SPFがあるとき
192.0.2.1
203.0.113.1
AR: spf=fail
・・・・
偽物っぽいなぁ
×
クオリティア

View Slide

SPF
Deep Dive into

View Slide

SPFの書き方
example.jp TXT "v=spf1 ip4:192.0.2.1 ip4:192.0.2.32/28 –all"
送信元サーバーのIPアドレスを記述する
192.0.2.1からの許可
それ以外は不許可
example.jp TXT "v=spf1 +ip4:192.0.2.1 +ip4:192.0.2.32/28 –all"
許可するものは+。省略可能。
こんな書き方でも同じ
192.0.2.32/28からも許可

View Slide

SPFの書き方
example.jp TXT "v=spf1 include:spf.example.jp –all"
includeもできます
example.jp TXT "v=spf1 redirect:spf.example.jp"
redirectであとはおまかせ

View Slide

SPFの書き方
example.jp TXT "v=spf1 a:mail.example.jp –all"
Aレコードの内容を参照
example.jp TXT "v=spf1 mx -all"
MXレコードの内容を参照

View Slide

SPFの書き方
example.jp txt "v=spf1 a:mail.example.jp/28 –all"
CIDRも指定できます
example.jp txt "v=spf1 mx/28//64 –all"
IPv6のCIDRも指定できます

View Slide

SPFの書き方
example.jp txt "v=spf1 exist:%{i}.spf.example.jp –all"
マクロも使えます
ソースIPが192.0.2.1の場合、
192.0.2.1.spf.example.jpのAレコードが存在すればPASS

View Slide

Bounceメール送信時の注意点
Bounceメールや転送で5321.FROMが<>の場合、SPFの検証に
はHELO/EHLOの値が使用されます
普段の5321.FROM: example.jp
メールサーバー名: mail.example.jp  HELOの値
mail.example.jpのSPFレコードは書いてありますか？
mail.example.jp txt "v=spf1 a –all"

View Slide

間違ったSPFの設定例
example.jp txt "v=spf1 ip4:192.0.2.0/24 –all"
example.jp txt "v=spf1 include:_spf.google.com –all"
SPFのレコードが複数存在する
example.jp txt "v=spf1 ip4:192.0.2.0/24 include:_spf.google.com –all"
×
0.6% (N=約20万)
If the resultant record set includes more than one record,
check_host() produces the "permerror" result.
RFC7208 4.5

View Slide

example.jp txt "v=spf1 ip4:192.0.2.1 include:example.jp –all"
includeがloopしている
example.jp txt "v=spf1 ip4:192.0.2.1 –all"
×
0.3% (N=約20万)

View Slide

example.jp txt "v=spf1 a mx -all a:mail.example.com"
allが一番後ろではない
example.jp txt "v=spf1 a mx a:mail.example.com -all"
×
1.0% (N=約20万)

View Slide

example.jp txt "v=spf1 include:spf1.example.jp
include:spf2.example.jp .... –all"
spf1.example.jp txt "v=spf1 たくさんinclude"
DNSのlookupが11回以上
example.jp txt "v=spf1 ip4:192.0.2.0/24 .... –all"
×
0.9% (N=約20万)
一番多いのは90回！

View Slide

example.jp txt "v=spf1 ip:192.0.2.1 -all"
example.jp txt "v=spf1 ipv4:192.0.2.1 -all"
example.jp txt "v=spf1 ip4: 192.0.2.1 -all"
example.jp txt "v=spf1 ip4:192.0.2.1 192.0.2.2 -all"
example.jp txt "v=spf1 ip4:spf.example.jp -all"
example.jp txt "v=spf1 inciude:spf.example.jp -all"
example.jp txt "v=spf1 include:192.0.2.1 -all"
example.jp txt "v=spf1 ip4:192.0.2.1 -all MS=ms12345678"
文法間違い
×
0.5% (N=約20万)

View Slide

以外に多いSPFの書き間違い
複数のSPFレコードが存在: 1363
includeがloopしている: 730
DNSのlookupが10回以上: 3076
allが一番後ろではない: 1970
文法間違い: 1106
ptrの使用 436
計: 8681 N=212123
約4%に問題あり！

View Slide

そんな便利なSPFですが

View Slide

SPFがあっても
192.0.2.1
203.0.113.1
Env From: jiro@悪徳グループ.example
AR: spf=none
・・・・
クオリティア
Env FROMは
自分のところから

View Slide

悪徳グループのSPFで認証
192.0.2.1
203.0.113.1
AR: spf=pass
・・・・
悪徳グループ.example txt “v=spf1 ip4:203.0.113.1 –all”
SPF PASSで安心！
振り込み、ポチっと。
クオリティア
SPFも書いとこ

View Slide

SPFまとめ
•Envelope FromとIPアドレスが正しいか
どうかを確認できる
•意外と書き方を間違えるので注意
送信元IP = Envelope From = Header From
?

View Slide

DKIM

View Slide

DKIM
•ヘッダや本文に署名してなりすましを
防止できる
•ヘッダや本文に署名して改ざんを防止
できる

View Slide

DKIM-Signature: v=1;
d=qualitia.co.jp; s=s1;
h=From:Subject;
b=abcdef・・・・
・・・・
DKIMがあるとき
署名して送ります
s1._domainkey.qualitia.co.jp txt “v=DKIM1;p=ABCDEF...”
暗号化
Public Key
Private Key
hash
クオリティア

View Slide

h=From:Subject;
AR: dkim=pass
・・・・
DKIMがあるとき
安心して振り込みね。ポチっと。
複合化
Public Key
Private Key
hash
○
クオリティア

View Slide

d=qualitia.co.jp;
h=From:Subject;
・・・・
DKIMがあるとき
署名できない！
暗号化
Private Key
hash
×
クオリティア

View Slide

h=From:Subject;
Subject: 泥棒にお振り込みください
・・・・
DKIMがあるとき
署名したものを
改ざんします
Public Key
Private Key
クオリティア

View Slide

h=From:Subject;
Subject: 泥棒にお振り込みください
AR: dkim=fail
・・・・
DKIMがあるとき
改ざんされてるかも？！
複合化
Public Key
Private Key
hash
×
クオリティア

View Slide

DKIM
Deep Dive into

View Slide

デジタル署名
Hash
・元のデータを固定長のデータに変換する
・基本的に戻せない
誕生日占い
自分の誕生日、誕生月、誕生年の数字を足してください。
その数字を一桁ずつ分けた上で、全てを足しててください。
この計算を、数字が一桁になるまで続けましょう
1972年7月1日
⇨ 1972 + 7 + 1 = 1980
⇨ 1 + 9 + 8 + 0 = 18
⇨ 1 + 8 = 9
1：アイデアマン
2：平和主義
3：お祭り好き
4：保守的
5：パイオニア
6：ロマンチスト
7：インテリ
8：大物
9：エンターテイナー
md5, sha1, sha256

View Slide

デジタル署名
公開鍵暗号
・暗号化する側の鍵(秘密鍵:Private Key)と
復号するの鍵(公開鍵: Public Key)が異なる
・変換されたデータは元に戻せる
RSA, ECDSA, Ed25519, ...
公開鍵で暗号化 ➔ 秘密鍵で復号  秘密鍵を持っている人しか見えない
秘密鍵で暗号化 ➔ 公開鍵で復号  秘密鍵を持っている人が書いたことがわかる

View Slide

デジタル署名
署名
・データからHashを生成
・Hashを秘密鍵で暗号化
・これを署名として公開
・公開鍵ももちろん公開
検証
・データからHash(①)を生成
・署名を公開鍵で複合(②)
・①と②が一致するかどうか確認
Hashと公開鍵暗号の秘密鍵を使います
ぼくドラえもんです ⇨ abcde
abcde ⇨ くぁwせdrftgyふじこlp
ぼくドラえもんです (署名:くぁwせdrftgyふじこlp)
ぼくドラえもんです ⇨ abcde
くぁwせdrftgyふじこlp ⇨ abcde
abcde == abcde
Hashと公開鍵暗号の公開鍵を使います

View Slide

DKIM署名の手順
• 本文をCanonicalize  いい感じに単純にする
• 本文のHashを作成
• 本文のHashを含む仮のDKIM-Signatureを作成
• 署名するヘッダ + 仮のDKIM-Signatureを
Canonicalize
• それのHashを作成
• 暗号化
• b=に追加

View Slide

下準備
Private Key / Public Keyの作成
openssl genrsa -out private.pem 2048
openssl rsa -in private.pem -pubout
-out public.key

View Slide

署名するメール
To: [email protected]
Subject: test
test

View Slide

本文のHashを作成
本文をCanonocalize / Hashを作成
echo -n 'test¥r¥n'
| openssl sha256 -binary
| openssl base64 -e
g3zLYH4xKxcPrHOD18z9YfpQcnk/GaJedfustWU5uGs

View Slide

仮のDKIM-Signatureを作成
DKIM-Signature: a=rsa-sha256; c=relax/simple;
d=hirano.cc; s=s1; t=163777045;
h=from:to:subject;
bh=g3zLYH4xKxcPrHOD18z9YfpQcnk/GaJedfustWU5uGs; b=
Canonicalizeの方法
暗号-Hashの方法
署名者
署名日時
セレクター
署名するヘッダー本文のHash

View Slide

ヘッダのHashを作成
「ヘッダ + 仮のDKIM-Signature」の署名を作成
echo -n 'from:[email protected]¥r¥nto:[email protected]¥r¥nsubject:test¥r¥ndkim-
signature:a=rsa-sha256; c=relax/simple; d=hirano.cc; s=s1; t=163777045;
h=from:to:subject; bh=g3zLYH4xKxcPrHOD18z9YfpQcnk/GaJedfustWU5uGs; b='
| openssl sha256 -sign private.pem -binary
| openssl base64 -e
AciJkTMYYH6s2S/dvrriZlaDJ9uaAd5XjiYGSHc+95K1oFs4xmkhrQKbNwzjbYiW
KOTl3llRPydNNOmnw4LgtRbl0LCLPnOzIXbfklwq0mMGKQhTCeRIdmzJxzoKCwAF
vuWnRBTOJmFLWf4WCs1pqEpYV0SharRW8uCbW8cBGp8p0PWj2q51Fend405KImea
Odknekp9HmhgnuIKFHaLxA/KaW27h+OcUX1W7SdnXDmaEpi3uLJY/HIedxM+aZUa
sFrxzhHsZkJE74ZZMn2xRLcE7VGRB3WgKrJtZCnZ0NuXHle+Fr0KavT3DOX9vQ8x
v/dYwjhNhpwnl9jFtkGT9A==

View Slide

完成
DKIM-Signature: a=rsa-sha256; c=relax/simple;
d=hirano.cc; s=s1; t=163777045;
h=from:to:subject;
bh=g3zLYH4xKxcPrHOD18z9YfpQcnk/GaJedfustWU5uGs;
b=AciJkTMYYH6s2S/dvrriZlaDJ9uaAd5XjiYGSHc+95K1oFs4xmkhrQKbNwzjbYiW
KOTl3llRPydNNOmnw4LgtRbl0LCLPnOzIXbfklwq0mMGKQhTCeRIdmzJxzoKCwAF
vuWnRBTOJmFLWf4WCs1pqEpYV0SharRW8uCbW8cBGp8p0PWj2q51Fend405KImea
Odknekp9HmhgnuIKFHaLxA/KaW27h+OcUX1W7SdnXDmaEpi3uLJY/HIedxM+aZUa
sFrxzhHsZkJE74ZZMn2xRLcE7VGRB3WgKrJtZCnZ0NuXHle+Fr0KavT3DOX9vQ8x
v/dYwjhNhpwnl9jFtkGT9A==

View Slide

最近のDKIM事情
•RFC8301: Cryptographic Algorithm and Key Usage Update to
DomainKeys Identified Mail (DKIM) (2018/1月)
・署名も検証もrsa-sha256を使いましょう(MUST)
・rsa-sha1はやめましょう(MUST)
・署名は1024bit以上(MUST)、2048bit以上(SHOULD)
・検証は1024bit～4096bit(MUST)
※ しかし、2048bitはDNSに書けるサイズ255バイトを超えてしまう
もう、今どきいいですよね?
有効なRSA署名のうち18%の署名者が2048bitを使用
※クオリティア調べ

View Slide

最近のDKIM事情
•RFC8463: A New Cryptographic Signature Method for
DomainKeys Identified Mail (DKIM) (2018/9月)
・署名側は実装しましょう(SHOULD)
・検証側は実装必須(MUST)
・後方互換性のために署名はEd25519-SHA256と
RSA-SHA256(1024bit以上)を2つ記述する
Ed25519-SHA256を使いましょう
BASE64後のサイズが44バイトしかないのでDNSの問題もない

View Slide

DKIMのKey Rotation
•DKIMキーの
ローテーション
も必要
https://www.m3aawg.org/sites/default/files/m3aawg-dkim-key-rotation-bp-2019-03.pdf

View Slide

そんな便利なDKIMですが

View Slide

DKIMがあっても
AR: dkim=none
・・・・
Private Key
DKIMがないときと
変わらない
クオリティア
DKIMなしで
送ったらええやん

View Slide

もしかしたら？
AR: dkim=none
・・・・
あれ？クオリティアさん
普段、署名付いてるよね
Private Key
DKIMがないときと
変わらない
クオリティア
DKIMなしで
送ったらええやん

View Slide

d=悪徳グループ.example; s=aku;
h=From:Subject;
・・・・
DKIMがあっても
署名して送ります
aku._domainkey.悪徳グループ.example txt “v=DKIM1;p=ABCDEF...”
暗号化
悪徳グループの
Private Key
Private Key
hash
クオリティア

View Slide

h=From:Subject;
AR: dkim=pass
・・・・
DKIMがあっても
ポチっと。
複合化
Public Key
Private Key
hash
○
Private Key
クオリティア

View Slide

SPF DKIM の問題点
•SPFは第三者がEnvelope Fromをなりす
ましてもspf=passしてしまう
•DKIMは第三者が署名してもdkim=pass
してしまう

View Slide

DMARC

View Slide

DMARCなら
•Header Fromを基準に確認
•Header From
•Envelope From が一致することを確認
•DKIM署名者

View Slide

悪徳グループのSPFで認証 (dmarc p=none)
192.0.2.1
203.0.113.1
AR: spf=pass, dmarc=Fail
・・・・
_dmarc.qualitia.co.jp txt “v=DMARC1; p=none”
dmarc=failだわ。
×
クオリティア

View Slide

悪徳グループのSPFで認証 (dmarc p=reject)
192.0.2.1
203.0.113.1
AR: spf=pass, dmarc=Fail
・・・・
× 届かない
_dmarc.qualitia.co.jp txt “v=DMARC1; p=reject”
×
クオリティア

View Slide

h=From:Subject;
AR: dkim=pass, dmarc=fail
・・・・
悪徳グループのDKIM署名
Public Key
Private Key
×
_dmarc.qualitia.co.jp txt “v=DMARC1; p=reject”
×届かない
クオリティア

View Slide

DMARCがあれば
たとえ
SPFが正しくても、
DKIMが正しくても、
ヘッダFROMがなりすましであれば届かない
SPFやDKIMの弱いところを補完するものなので、
SPFだけ+DMARCやDKIMだけ+DMARCでも有効です

View Slide

ちょっと休憩・・・
ある時ない時
551蓬萊の常務と吉本興業のなるみが
コンビで出演してさまざまな
シチュエーションを演じ、
「551の蓬萊が、ある時～!!（笑い声）、
ない時～…（静まり返る周囲）」
のナレーションが入るスタイルを
長年続けている。
出典: フリー百科事典『ウィキペディア（Wikipedia）』

View Slide

盗聴・なりすまし受信
から守る

View Slide

盗聴から守る
クオリティア
メール
サーバ
メール
サーバ
盗聴
改ざん
盗難
盗聴から守る

View Slide

ZIP暗号化

View Slide

ZIP暗号化
クオリティア
メール
サーバ
メール
サーバ
盗聴
改ざん
盗難
パスワード

View Slide

STARTTLS

View Slide

STARTTLS
クオリティア
メール
サーバ
メール
サーバ
盗聴改ざん
メールサーバー間を暗号化する

View Slide

やってみた
あれれ。
TLSの設定をしただけでは、
まだまだ足りませんでした。

View Slide

厳しい設定
smtpd_tls_security_level = may
smtpd_tls_key_file = /etc/letsencrypt/live/example.jp/privkey.pem
smtpd_tls_cert_file = /etc/letsencrypt/live/example.jp/fullchain.pem
smtpd_tls_ciphers = high
smtpd_tls_mandatory_ciphers = high
smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtpd_tls_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
tls_high_cipherlist = EECDH+AESGCM
tls_preempt_cipherlist = yes
Postfixの場合

View Slide

もう一度挑戦！
なかなか
いい感じになりました。

View Slide

ほんとに？

View Slide

STARTTLSは
Opportunistic
=できればやる / できなければやらない

View Slide

STARTTLSがあるとき
送信
サーバ
受信
サーバ
EHLO sender.example.jp
250-recv.example.jp
250-STARTTLS
250 OK
STARTTLS
220 ready for TLS
なんやかんややり取り
ここから暗号化
STARTTLS対応
このあたりは
平文

View Slide

途中で改ざんされると
送信
サーバ
受信
サーバ
250-recv.example.jp
250-STARTTLS
250 OK
FROM: [email protected]
250-recv.example.jp
250-XXXXXXXX
250 OK
ふむふむ
TLS非対応
なのね
MITMさん
盗み放題
ちょこっと
書き換え
暗号化せずに
送りましょ
STARTTLS Downgrade Attack

View Slide

TLS Protocol Downgrade Attack
送信
サーバ
受信
サーバ
STARTTLS
220 Ready for TLS
ClientHello (TLS1.2でつなぎたいです)
TLS1.2は非対
応なのね
MITMさん
盗み放題
捨てて
しまえ
TLS1.1で
送りましょ
TLS Handshake開始

View Slide

EHLO応答を改ざんされた場合
クオリティア
メール
サーバ
メール
サーバ
盗聴改ざん
○ ○
暗号化に対応していても無意味
可可

View Slide

受信サーバーをなりすまされた場合
クオリティア
メール
サーバ
メール
サーバ
暗号化に対応していても無意味
メール
サーバ
DNS
なりすまし

View Slide

MTA-STS

View Slide

MTA-STS
•STARTTLSを必ず使う
•TLS1.2以上を使う
•証明書が有効でなければ配送しない
受信側が、送信サーバーに対して、
ようにしてもらう仕組み
RFC8461 (2018/09)

View Slide

MTA-STSがあるとき
クオリティア
メール
サーバ
メール
サーバ
暗号化に対応
していなければ送らない
_mta-sts.qualitia.co.jp. IN TXT "v=STSv1; id=20191114123000Z;"
version: STSv1
mode: enforce
mx: mx1.qualitia.co.jp
max_age: 1296000
https://mta-sts.qualitia.co.jp/.well-known/mta-sts.txt
＝盗まれない
ポリシー

View Slide

MTA-STSがあるとき
送信
サーバ
受信
サーバ
mx.example.jp
EHLO sender.example.com
250-recv.example.jp
250-STARTTLS
250 OK
STARTTLS
220 ready for TLS
Webサーバ
https://mta-sts.受信ドメイン/.well-known/mta-sts.txt
mode: enforce
mx: mx.example.jp

View Slide

改ざんされた場合でも
送信
サーバ
受信
サーバ
mx.example.jp
EHLO sender.example.com
250-recv.example.jp
250-STARTTLS
250 OK
Webサーバ
https://mta-sts.受信ドメイン/.well-known/mta-sts.txt
mode: enforce
mx: mx.example.jp
250-recv.example.jp
250-XXXXXXXX
250 OK
ふむふむ
TLS非対応
なのね終了
ちょこっと
書き換え
MITMさん

View Slide

MTA-STSの設定方法
_mta-sts.example.jp txt "v=STSv1; id=20201111010203"
受信するメールアドレス: [email protected]
受信メールサーバー: mx.example.jp
DNSの設定
version: STSv1
mode: enforce
mx: mx.example.jp
max_age: 1296000
Webの設定
https://mta-sts.example.jp/.well-known/mta-sts.txt
none
testing
enforce
*.example.jpのようにも書けます

View Slide

だがしかし
届かなかったことを知りたい

View Slide

TLS-RPT

View Slide

TLS-RPT
• MTA-STSやDANEの結果のレポートを受け取れ
ます
• RFC8460 (2018/09)
[SMTP TLS Reporting]

View Slide

TLS-RPTの設定方法
_smtp._tls.example.jp txt
"v=TLSRPTv1; rua=mailto:[email protected]"
受信メールサーバー: mx.example.jp
レポートの送り先: [email protected]
_smtp._tls.example.jp txt
"v=TLSRPTv1; rua=https://example.com/report"
レポートの送り先: https://example.com/report

View Slide

レポートの例 (問題ない場合)
{
"organization-name": "Google Inc.",
"date-range": {
"start-datetime": "2020-09-07T00:00:00Z",
"end-datetime": "2020-09-07T23:59:59Z"
},
"contact-info": "[email protected]",
"report-id": "2020-09-07T00:00:00Z_hirano.cc",
"policies": [
{
"policy": {
"policy-type": "sts",
"policy-string": [
"version: STSv1",
"mode: testing",
"max_age: 86400",
"mx: *.hirano.cc"
],
"policy-domain": "hirano.cc"
},
"summary": {
"total-successful-session-count": 5,
"total-failure-session-count": 0
}
}
]
}
成功 5通
失敗 0通

View Slide

レポートの例 (問題のある場合)
{
"organization-name": "Google Inc.",
"date-range": {
"start-datetime": "2019-10-01T00:00:00Z",
"end-datetime": "2019-10-01T23:59:59Z"
},
"contact-info": "[email protected]",
"report-id": "2019-10-01T00:00:00Z_hirano.cc",
"policies": [
{
"policy": {
"policy-type": "sts",
"policy-string": [
"version: STSv1",
"mode: testing",
"max_age: 86400",
"mx: *.hirano.cc"
],
"policy-domain": "hirano.cc"
},
"summary": {
"total-successful-session-count": 0,
"total-failure-session-count": 55
}, 失敗 55通
"failure-details": [
{
"result-type": "validation-failure",
"sending-mta-ip": "209.85.219.198",
"receiving-ip": "210.158.71.76",
"receiving-mx-hostname": "ah.hirano.cc",
"failed-session-count": 2
},
{
"result-type": "starttls-not-supported",
"sending-mta-ip": "209.85.222.201",
"receiving-ip": "210.158.71.76",
"receiving-mx-hostname": "ah.hirano.cc",
"failed-session-count": 1
},
.... 省略 ....
]
}
]
}

View Slide

MTA-STS, TLS-RPT
•STARTTLSを必ず使う
•TLS1.2以上を使う
•証明書が有効でなければ配送しない
受信側が、送信サーバーに対して、
ようにしてもらう仕組み
RFC8461 (2018/09)
レポートもある
Googleは対応済み, Microsoftは2020年Q4

View Slide

だがしかし

View Slide

なりすましの場合
クオリティア
メール
サーバ
メール
サーバ
MTA-STSを無効化
偽の
メール
サーバ
DNS

View Slide

不正な認証局
クオリティア
公開鍵証明書認証局(CA)
署名
qualitia.co.jp
qualitia.co.jp
署名
問題のある
送信者からは
正しく見える
MITMさん

View Slide

MTA-STSの問題点
• DNSの毒入れなどのなりすましに弱い
• 不正な証明書を利用したMITM攻撃に弱い

View Slide

DANE

View Slide

DANE
•DNSSECが必須
•公開鍵証明書認証局(CA)を利用しない
•使用してもよいが検証はされない
•オレオレ証明書でもOK
•RFC7671 (2015/10)
•RFC7672 (2015/10)
DNSSEC未対応の場合は、通常通り配送

View Slide

DNSSECとは？
DNSの問い合わせや応答を暗号化して守る
DNSの応答が改ざんされていないことを保証する
DNSの応答が正しい人からのものであることを保
証する
×
○
○

View Slide

DNSSECのトラストチェイン
example.jp. IN MX 10 mail.example.jp.
DNSKEY (ZSK)
DNSKEY (KSK)
DNSKEY (ZSK)
DNSKEY (KSK)
DS
署名
署名
Hashを預ける
署名
署名
DNSKEY (ZSK)
DNSKEY (KSK)
DS
署名
署名
example.jpのzone
ルートのzone
jpのzone
Hashを預ける

View Slide

DNSSECが有効かどうかの確認
https://dnsviz.net/
DNSSECが失敗したと
ころは黒くなります

View Slide

DNSSECの応答
DNSSEC非対応ドメイン DNSSEC対応ドメインなりすまされた
DNSSEC対応ドメイン
DNSSEC非対応リゾルバ回答あり回答あり回答あり
DNSSEC対応リゾルバ回答あり回答あり SERVFAIL
応答
なりすまされた場合、結果が返ってこない

View Slide

DANE
クオリティア
メール
サーバ
メール
サーバ
CAの代わりにDNSSECを信頼
DNSSEC
不要
ルートDNS
DNSSEC
信頼
_25._tcp.mx1.qualitia.co.jp. IN TLSA 3 0 1 2B73BB905F…"
mx1.qualitia.co.jp
Public KeyのHash
○
Public Key

View Slide

DANEの設定方法
openssl x509 -in cert.pem -pubkey -noout
| openssl rsa -pubin -outform DER
| openssl sha256
(stdin)= 293f3944e435835ec797acbbe52ffb1bc8e
6637879fbe62d9b6195479e01f67e
Public KeyのHashを作成

View Slide

DANEの設定方法
openssl s_client -connect mx1.example.jp:25 -starttls smtp < /dev/null
| openssl x509 -pubkey –noout
| openssl rsa -pubin -outform DER
| openssl sha256
(stdin)= 293f3944e435835ec797acbbe52ffb1bc8e
6637879fbe62d9b6195479e01f67e
はじめての設定なら、
サーバーから証明書を取り出すのもあり

View Slide

DNSに追加
_25._tcp.mx1.example.jp TLSA 3 1 1 293f3944e...
メールサーバー
メールアドレスのドメイン部分ではありません！
受信メールサーバー: mx1.example.jp
0: Hashなし
1: SHA256
2: SHA512
※TLSのKeyを入れ替えるときにはTLSAレコードを
先に書いて、DNSのキャッシュ期間が過ぎたらメー
ルサーバーの設定を新しいKeyに変更し、古いTLSA
レコードを削除します。

View Slide

DANE
DNSSECに対応していて、
TLSAレコードがあれば、
STARTTLSを必須で使用し、
PublicKeyをTLSAの値で検証します。
Microsoftの対応予定
送信側の対応2020年末まで
受信側の対応2021年末まで
(by M3AAWG General Meeting (2020/06))
TLS DANE
Arcor yes no
AOL yes no
Bund.de yes yes
Comcast yes yes
Freenet yes yes
Gmail yes no
GMX yes yes
Kabel Deutschland yes yes
O2 yes no
Outlook.com yes no
Riseup yes yes
T-Online yes no
Unitymedia yes yes
Vodafone yes yes
web.de yes yes
Yahoo yes no
https://posteo.de/en/help/to-and-from-which-other-email-providers-will-my-emails-be-encrypted

View Slide

実際に設定してみる

View Slide

実際に設定してみる
意外と高い！ DNSSECの壁！！！
親のDSレコードに自分のZoneのKeyのHashを登録する必要がある
→example.jpから見ると、親はjpなので、
JPRSのDSレコードを変更できる必要がある
→対応しているレジストラがあまり見つからない
→DNSSECのホスティングはありそうだ
→しかし、20年以上も自分で管理してきたので、自分で管理したい
ということで
クオリティアでDNSSECホスティングサービスを作っちゃいました
QUALITIA DNS で検索！

View Slide

DNSSEC + TLSA設定完了

View Slide

経路暗号化まとめ
何もなし STARTTLS MTA-STS DNSSEC DANE zip暗号化
経路上の暗号化 × ○ ○ - ○ △
STARTTLS
Downgrade攻撃 - × ○ -
○
-
TLS Protocol
Downgrade攻撃 - × ○ - △ -
偽の証明書 - × × - ○ -
なりすまし受信 × × × ○ ○ ×
○ 安全
△ 安全であるが完全ではない
× 安全ではない
- 影響を受けない

View Slide

送信者がTLSを強制
したい場合はどうするの?
だがしかし

View Slide

Require TLS

View Slide

Require TLS
RFC8689 (2019/11)
SMTPで
MAIL FROM: REQUIRETLS
ヘッダに
TLS-Required: No
と書くことで、機能をOffにできます。

View Slide

最後の壁
IPv6

View Slide

データセンターへ問い合わせ
IPv6の件、結論から申しますと「対応いたしません」となります。
理由は、設計計画の立案、作業に対する予算化、サービスメニュー見直し等
大幅な労力を要するためです。
ご要望にお応えできず、申し訳ございませんでした。
え゛ーーーーーっ
どなたか僕の個人サーバーを格安でホスティングしてください・・・

View Slide

まとめ
• DMARC 使いましょう
• STARTTLS 使いましょう
• MTA-STS 使いましょう
• DNSSEC 使いましょう
• DANE 使いましょう
• internet.nlで100点になるまでの道は険しい
• オランダすごいよ
Thank You!

View Slide

Thank you

View Slide

Overflowed Slides
今日お話しできなかった内容

View Slide

ARC

View Slide

ARCがあれば
arc=passですね。
Private Key
クオリティア
メーリングリスト
サーバ
ml.example.jp
ARC-Seal: i=1; cv=none; d=ml.example.jp;...
ARC-Message-Signature: i=1; d=ml.example.jp;
h=from:subject:dkim-signature:...
ARC-Authentication-Result: i=1; ml.example.jp;
dkim=pass; spf=pass; dmarc=pass
DKIM-Signature: v=1; d=qualitia.co.jp; b=abcdef・・・・
Subject: [○○ML:1234]久しぶりの投稿
AR: dkim=fail, arc=pass
こんにちは。おひさしぶりです。
・・・・

View Slide

ARC
•The Authenticated Received Chain Protocol
•RFC8617 (2019年7月)
•メーリングリストサーバが受信したときに
DKIM=passやARC=passであれば、
ARCとして連番付きで再署名

View Slide

BIMI

View Slide

BIMI
•DMARCがpassしたら、
送信ドメインの
管理者が指定した
ロゴを表示する
ロゴを表示
注目

View Slide

DNSSEC

View Slide

DNSSECとは？
証する
×
○
○

View Slide

DNSSECがないとき
192.0.2.1
新着メールあるかな?
ログインして確認！
DNSサーバー
メールサーバのIPは?
192.0.2.1ですよ
権威DNSサーバー
192.0.2.1ですよ
スマホのメーラーはIMAPサーバーに
定期的に新着メールを問い合わせます

View Slide

DNSSECがないとき
192.0.2.1
新着メールあるかな?
ログインして確認！
DNSサーバー
192.0.2.100ですよ
192.0.2.1ですよ
192.0.2.100ですよ
ID/パスワード
収集サーバー
192.0.2.100
192.0.2.100ですよ

View Slide

DNSSECがあるとき
192.0.2.1
DNSサーバー
なんかおかしいわ
192.0.2.1ですよ
192.0.2.100ですよメールサーバのIPは?
ID/パスワード
収集サーバー
192.0.2.100

View Slide

DNSSECの関係者
クライアント
ルートDNSサーバー
スタブリゾルバー
フルリゾルバー
フォワーダー
jpのDNSサーバー
qualitia.co.jpのDNSサーバー

View Slide

DNSSECが有効かどうかの確認 (リゾルバー)
http://www.dnssec-or-not.com/
PCが聞きに行っているフルリゾルバが
DNSSECに対応してるかどうか
VPNを使っていると、DNSSEC有効で
もこちらが表示されるかも知れません

View Slide

DNSSECが有効かどうかの確認 (サーバー)
https://dnsviz.net/
権威DNSサーバーがDNSSECに対応してるかどうか
DNSSECが失敗したと
ころは黒くなります

View Slide

dig コマンドで確認
DNSSEC非対応ドメイン
dig qualitia.co.jp
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23896
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; ANSWER SECTION:
qualitia.co.jp. 1443 IN A 54.65.37.180
DNSSEC非対応ドメイン + DNSSEC非対応リゾルバー
DNSSEC非対応ドメイン + DNSSEC対応リゾルバー
;; ANSWER SECTION:
qualitia.co.jp. 3600 IN A 54.65.37.180
同じです

View Slide

dig mail.interlingua.co.jp
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; ANSWER SECTION:
mail.interlingua.co.jp. 0 IN A 210.158.71.76
DNSSEC対応ドメイン + DNSSEC非対応リゾルバー
DNSSEC対応ドメイン + DNSSEC対応リゾルバー
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; ANSWER SECTION:
mail.interlingua.co.jp. 300 IN A 210.158.71.76
同じです
DNSSEC対応ドメインは
adフラグが付きます

View Slide

なりすまされているDNSSEC対応ドメイン
dig dnssec-failed.org
;; ANSWER SECTION:
dnssec-failed.org. 6510 IN A 69.252.80.75
DNSSEC対応ドメイン + DNSSEC非対応リゾルバー
DNSSEC対応ドメイン + DNSSEC対応リゾルバー
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 63229
DNSSEC対応リゾルバーでは
SERVFAILになります
IPは返りません
DNSSEC非対応リゾルバーは
答えを返してしまいます
adフラグはありません
VPNを使っているとご自宅のDNSサーバーから
SERVFAILを受け取っても、その後、会社のDNSサー
バーに聞きに行ってNOERRORになるかも知れません

View Slide

DNSSEC対応/非対応まとめ
DNSSEC非対応リゾルバ adフラグなし adフラグあり adフラグなし
DNSSEC対応リゾルバ adフラグなし adフラグあり adフラグなし
DNSSEC非対応リゾルバ回答あり回答あり回答あり
DNSSEC対応リゾルバ回答あり回答あり SERVFAIL
adフラグ
応答

View Slide

DNSSECとは？(再掲)
証する
×
○
○

View Slide

レコードセットの署名
•dig +dnssec interlingua.co.jp mx
interlingua.co.jp. 294 IN MX 10 mail.interlingua.co.jp.
interlingua.co.jp. 294 IN RRSIG MX 13 3 300 20200817003038 20200802230038
55501 interlingua.co.jp. g5r2rLGrbrX6aYap2p/wDgJgL/LWs18/aQRtZAKDYQxFkF6eQg0Xy0c/
pNdysOWDNRQxO/4zom+Wvb87YwYl+g==
interlingua.co.jp. 6 IN DNSKEY 256 3 13 (
6zijMNFnm5+VuhJQqRG6ehQy0aDjOXYXZmx7yTL46TKp
RI9p9cCx+aDBhzwa5eK19vCf1MiVoMqIVDBqvFoU8g==
) ; ZSK; alg = ECDSAP256SHA256 ; key id = 55501
rpYAYd2eS/tow2Be8qrAMHQkl4Lwxp5fsSPQmt9137/s
3mDX72NyvjXIdYaNcPPUEh5F4FM4iyylFtx9LS4CvA==
) ; KSK; alg = ECDSAP256SHA256 ; key id = 63661
•dig +multi interlingua.co.jp dnskey
署名
公開鍵
署名した人

View Slide

レコードセットの署名
interlingua.co.jp. 294 IN MX 10 mail.interlingua.co.jp.
interlingua.co.jp. 294 IN RRSIG MX 13 3 300 20200817003038 20200802230038
55501 interlingua.co.jp. g5r2rLGrbrX6aYap2p/wDgJgL/LWs18/aQRtZAKDYQxFkF6eQg0Xy0c/
pNdysOWDNRQxO/4zom+Wvb87YwYl+g==
署名
公開鍵
権威DNSサーバーはMXレコードセットのHashをZSK(Zone Signing Key)の秘密鍵で暗号化し、
RRSIG MXとして公開
フルリゾルバーはRRSIGをZSKの公開鍵で復号し、MXレコードセットのHashと合っているかどう
かを確認
MXレコードセットはZSKの所有者interlingua.co.jpが書いたものから改ざんされていないことがわかる

View Slide

しかし
そもそも公開鍵が偽物かも

View Slide

公開鍵も署名しないと

View Slide

公開鍵の署名
•dig +dnssec +multi interlingua.co.jp dnskey
interlingua.co.jp. 300 IN RRSIG DNSKEY 13 3 300 (
20200817003032 20200802230032 63661 interlingua.co.jp.
6GYbqK+/csGs3SW70LdxvHwAHM+AAGem6G4vK4OvrJWu
4lQesbZTVO9fXHIfkSZnx0QqppKSEt9SBhUdVF91lg== )
署名
KSKの公開鍵
ZSKの公開鍵
権威DNSサーバーはDNSKEYレコードセットのHashをKSK(Key Signing Key)の秘密鍵で暗号化し、
RRSIG DNSKEYとして公開
公開鍵はKSKの所有者interlingua.co.jpが書いたものから改ざんされていないことがわかる

View Slide

まだ、なりすませますね

View Slide

鍵のHash(DS)を親Zoneに預ける
KSKの公開鍵のHash。
DSと呼びます
KSKの公開鍵
KSK(Key Signing Key)の公開鍵のHashを親のZoneに登録しておく
•dig interlingua.co.jp ds
interlingua.co.jp. 4520 IN DS 63661 13 2
975FAD7B7EF66EEB94F2D364EE1B8A84D9F87C445655FB383A064BD4 78D726DC
このレコードはjp.のzoneに存在
interlingua.co.jpのKSKの公開鍵が改ざんされていないことをjpが保証する

View Slide

親ZoneでDSを署名
•dig +dnssec interlingua.co.jp ds
interlingua.co.jp. 4087 IN DS 63661 13 2
975FAD7B7EF66EEB94F2D364EE1B8A84D9F87C445655FB383A064BD4 78D726DC
interlingua.co.jp. 4087 IN RRSIG DS 8 3 7200 20200831174502 20200801174502
32163 jp. N8AnyWRKCGnaZmsLPhvkOoUuhKKzwNcPvATKCr4dzTCcmaWFpNDKNEU7
gddNckfgg2VxtRpvV2ZT5MPcwhWpqWM1O7p+TxX3fz3pYm/7RjoCjvK6
p5n4IdSmkHCT+9ThHD3popKUWXI/KtXkgXUCkFatkTFxt9uTJOmsXxN/ OVs=
jp. 86394 IN DNSKEY 256 3 8 (
AwEAAa9eY9Ns9TIFqb+iYkU9C7n80Y0M1L2NZcEbvmCJ
frJqQC09tA+7TJbJ7y3k5q+wtYznOpGY1v2qbeTaEbaR
vr7ZFa/OQUZbl7yE7qNDNVl7+s5/zXFq09hRWoFFaWgY
5rC75FmeVambDibge+G0yIGNsD1PsYQ/7oG3mujg+0jn
) ; ZSK; alg = RSASHA256 ; key id = 32163
•dig +multi jp dnskey
署名
公開鍵
署名した人

View Slide

これをrootまで繰り返す

View Slide

DNSSECのトラストチェイン
interlingua.co.jp. IN MX 10 mail.interlingua.co.jp.
DNSKEY (ZSK)
DNSKEY (KSK)
DNSKEY (ZSK)
DNSKEY (KSK)
DS
署名
署名
Hashを預ける
署名
署名
DNSKEY (ZSK)
DNSKEY (KSK)
DS
署名
署名
interlingua.co.jpのzone
ルートのzone
jpのzone
Hashを預ける

View Slide

Keyのロールオーバー
•DKIM署名のKeyと同じようにDNSSECのKeyも
定期的にメールオーバーする必要があります。
結構複雑なので、次回！

View Slide

送信ドメイン認証・暗号化 Deep Dive!

送信ドメイン認証・暗号化 Deep Dive!

HIRANO Yoshitaka

More Decks by HIRANO Yoshitaka

Other Decks in Technology

Featured

Transcript