Gmail 將會針對沒有加密傳輸收到的信件標示警告

前陣子在「STARTTLS 的不完整性以及大規模監控電子郵件」提到現有的標準無法確保 ESMTP 一定會啟用 STARTTLS。所以 Google 正在跟 M3AAWG 研究標準來保護這類攻擊:

First, we found regions of the Internet actively preventing message encryption by tampering with requests to initiate SSL connections. To mitigate this attack, we are working closely with partners through the industry association M3AAWG to strengthen “opportunistic TLS” using technologies that we pioneered with Chrome to protect websites against interception.

另外一方面,Google 之後也會將未透過 STARTTLS 傳輸的信件標示出來:

To notify our users of potential dangers, we are developing in-product warnings for Gmail users that will display when they receive a message through a non-encrypted connection. These warnings will begin to roll-out in the coming months.

Google 的文章可以在「New Research: Encouraging trends and emerging threats in email security」這邊看到。

我的想像是 DNSSEC + TXT record 標示,不知道會不會走這條...

STARTTLS 的不完整性以及大規模監控電子郵件

在「Don’t count on STARTTLS to automatically encrypt your sensitive e-mails」這邊提到了 STARTTLS 的問題,引用「Neither Snow Nor Rain Nor MITM ... An Empirical Analysis of Email Delivery Security」這篇論文的說明。

SMTP 裡 STARTTLS 的設計雖然可以加密,但仲所皆知,可以阻擋 EHLO 回應結果避免建立 STARTTLS 連線,而讓發送端改用傳統未加密的 SMTP 傳輸。而研究發現其實目前就有大規模的這種監控行為:

可以看到突尼西亞的監控情況遠超過想像...

目前的想法是發展一套類似 HSTS 的 Trust on first use 設計,也許在這份報告出來後可以加速催生...

把 SMTP 的 SSL certfiticate 弄起來...

網站的 SSL certificate 弄過很多次了,想說來測看看 MX host 的部份。弄好後就會像這樣,這是 Varnish 的 mailing list:

Received: from project.varnish-software.com (project.varnish-software.com [194.31.39.164])
        (using TLSv1 with cipher AES256-SHA (256/256 bits))
        (No client certificate requested)
        by home.gslin.org (Postfix) with ESMTPS id 9C2F568009A
        for ; Mon, 21 Sep 2015 08:46:30 +0800 (CST)

這是 nginx 的 mailing list 寄過來的信:

Received: from mail.nginx.com (mail.nginx.com [206.251.255.65])
        (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
        (No client certificate requested)
        by home.gslin.org (Postfix) with ESMTPS id 4A4F26801E0
        for ; Mon, 21 Sep 2015 08:25:37 +0800 (CST)

還有些 cipher 的細節晚點再看看有沒有辦法再調整好了... 因為 MX 這樣設定,這次也順便試著用 StartSSL 申請了好幾個 SSL certificate:

;; ANSWER SECTION:
gslin.org.              3600    IN      MX      20 mx20.gslin.org.
gslin.org.              3600    IN      MX      0 mx0.gslin.org.

因為有兩個 MX,所以申請了 mx0.gslin.orgmx20.gslin.org 的 SSL certificate。

接下來的設定主要是參考「Postfix TLS Support」裡面的文件,以及 Google 後找到的很多資料...

在申請到了 SSL certificate 之後要先把 intermediate certificate 合併,然後在 Postfixmain.cf 裡這樣設定:

#
smtpd_tls_cert_file = /etc/ssl/certs/mx0.gslin.org-intermediate.crt
smtpd_tls_key_file = /etc/ssl/private/mx0.gslin.org.key
smtpd_tls_received_header = yes
smtpd_tls_security_level = may

設好後就可以用「TLS Receiver Test」這個工具測試,輸入 admin@gslin.org 可以看到兩台都過了。

然後是對外送信的部份,發現 msa.hinet.net 也有支援 STARTTLS,所以 smart relay 也可以用,這部份可以透過 tcpdump -n -vvvv -A -i ppp0 host 168.95.4.211 確認。寄出來的結果會是這樣:

Received: from home.gslin.org (114-32-152-63.HINET-IP.hinet.net [114.32.152.63])
	by msr9.hinet.net (8.14.9/8.14.9) with ESMTP id t8L2l1gU006249
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO)
	for ; Mon, 21 Sep 2015 10:47:01 +0800 (CST)

而 Postfix 的設定是這樣設的:

smtp_tls_note_starttls_offer = yes
smtp_tls_security_level = encrypt
smtp_use_tls = yes

用 Require-Recipient-Valid-Since (RRVS) 解決帳號失效的問題

在「Facebook Yahoo Require-Recipient-Valid-Since SMTP Extension」這篇看到 Require-Recipient-Valid-Since (RRVS) 變成 Proposed Standard 了:「The Require-Recipient-Valid-Since Header Field and SMTP Service Extension」(RFC 7293)。

起因是從 2013 年的「yourname@yahoo.com Can Be Yours!」這篇開始的:Yahoo! 宣佈會釋出太久沒有使用的 @yahoo.com 帳號讓其他人可以註冊。

而這導致了帳號綁定問題:如果使用者先前在 Facebook 上 (或是其他服務) 有綁定 Yahoo! 帳號,而他的 Yahoo! 帳號被釋出被其他人拿走後,其他人就可以利用重設密碼的功能取得 Facebook 帳號權限。

Yahoo! 對這個問題的解法是透過 Require-Recipient-Valid-Since 處理,服務方 (像是 Facebook) 在發出重要信件時帶入 Require-Recipient-Valid-Since,要求這封信必須在某個時間點後有效,才能讓收信者看到這封信的內容。

Facebook 的人在「Protecting Facebook Accounts With New Email Standard」也提到了這個新標準。