【51CTO.com快譯】眾所周知，由于SMTP以純文本的形式發(fā)送電子郵件，那么任何人都可以通過攔截以獲知郵件的內(nèi)容。面對這樣的風(fēng)險，我們需要通過適當(dāng)?shù)泥]件安全協(xié)議，來增強安全性。一般而言，郵件安全協(xié)議是一些用來保護電子郵件免受外界干擾的協(xié)議架構(gòu)。由于最早的簡單郵件傳輸協(xié)議(Simple Mail Transfer Protocol，SMTP)本身并不內(nèi)置任何的安全機制，因此我們需要添加其他的安全協(xié)議，為郵件的收發(fā)保駕護航。

[[256364]]

如今市面上有許多能夠與SMTP配合的安全協(xié)議。下面，我們?yōu)槟偨Y(jié)了七大安全協(xié)議，讓我們來一起討論一下它們的原理，以及如何為郵件的傳輸提供安全保障。

1. 用SSL和TLS保護郵件安全

安全套接字層(Secure Sockets Layer，SSL)和其后續(xù)版本--安全傳輸層協(xié)議(Transport Layer Security，TLS)是最常見的電子郵件安全協(xié)議，它們可以保證電子郵件在互聯(lián)網(wǎng)上的安全傳輸。

SSL和TLS都屬于應(yīng)用層協(xié)議。在互聯(lián)網(wǎng)的環(huán)境中，它們可以被用于在兩個通信應(yīng)用程序之間提供基本的保密性與數(shù)據(jù)完整性。在郵件安全的應(yīng)用場景中，應(yīng)用層通過提供一套安全的框架(即：一組規(guī)則)，給同屬于應(yīng)用層協(xié)議的SMTP“加持”，以保護用戶的電子郵件在網(wǎng)上的正常通信。

值得注意的是，SSL已于2015年開始被完全棄用了，我們現(xiàn)在常用的應(yīng)該是它的后繼版本--TLS。TLS為程序之間的網(wǎng)絡(luò)通信(當(dāng)然也包括SMTP協(xié)議)提供了額外的隱私保護與安全性。

因此，當(dāng)您的郵件客戶端發(fā)送或接收消息時，它使用傳輸控制協(xié)議(Transmission Control Protocol，郵件客戶端使用TCP來連接到郵件服務(wù)器上)，來啟動與郵件服務(wù)器的“握手”通信。

在握手的過程中，郵件客戶端和服務(wù)器相互驗證安全性和加密設(shè)置，為郵件傳輸做好準(zhǔn)備。該握手過程的工作原理如下：

1) 客戶端向郵件服務(wù)器發(fā)送“hello”，其中包括加密的類型、和所兼容的TLS版本。

2) 服務(wù)器端使用服務(wù)器的TLS數(shù)字證書和本身的公鑰予以響應(yīng)。

3) 客戶端驗證發(fā)過來的證書信息。

4) 客戶端使用服務(wù)器的公鑰生成共享密鑰(Shared Secret Key，也稱為預(yù)主密鑰Pre-Master Key)，并將其發(fā)送給服務(wù)器。

5) 服務(wù)器解密，以獲得共享密鑰。

6) 客戶端和服務(wù)器端可以使用共享密鑰來加密要傳輸?shù)臄?shù)據(jù)，在本例中，該數(shù)據(jù)正是用戶的電子郵件。

TLS既重要又普遍，因為絕大多數(shù)郵件服務(wù)器和客戶端，都會使用它來為電子郵件提供基礎(chǔ)性的加密。

Opportunistic TLS和Forced TLS

Opportunistic TLS是一種協(xié)議命令，它被用于告訴郵件服務(wù)器，當(dāng)前的郵件客戶端需要將現(xiàn)有的連接轉(zhuǎn)換為安全的TLS連接。

有時候，您的郵件客戶端將會使用純文本的連接方式，而并非遵守上述提到的握手過程，來創(chuàng)建安全連接。那么Opportunistic TLS將會嘗試通過采用TLS握手的方式創(chuàng)建安全隧道。不過，握手過程一旦失敗，Opportunistic TLS則會退回到純文本的連接方式，并只能發(fā)送未經(jīng)加密的電子郵件。

Forced TLS是一種協(xié)議的配置，它強制所有的郵件往來都使用安全的TLS標(biāo)準(zhǔn)。也就是說，沒有使用該標(biāo)準(zhǔn)的郵件根本無法被發(fā)送出去。

2.數(shù)字證書

數(shù)字證書是一種加密工具，它能夠以加密的方式來保護電子郵件。此處的數(shù)字證書恰好會在公鑰加密的過程中被用到。當(dāng)然，如果您對公鑰加密不太熟悉的話，請參見“人人都應(yīng)了解的十個加密術(shù)語”一文中的第7、8部分。

數(shù)字證書會保證用戶使用預(yù)定義的公共密鑰，向?qū)Ψ桨l(fā)送加密后的電子郵件。因此，數(shù)字證書就像護照一樣，與用戶的在線身份相綁定?？梢?，其主要用途就是為了驗證發(fā)方身份。

顯然，當(dāng)您擁有某個數(shù)字證書時，您的公鑰可供任何想給您發(fā)送加密郵件的人訪問與使用。他們使用您的公鑰來加密文檔，而您在收到后，可以用自己的私鑰對其進行解密。

另外，數(shù)字證書不僅限于個人使用。企業(yè)、政府組織、電子郵件服務(wù)器、甚至任何其他的數(shù)字實體，都可以使用數(shù)字證書來標(biāo)識和驗證各種在線的身份。

3.用發(fā)送方策略框架實現(xiàn)域名欺騙保護

發(fā)送方策略框架(Sender Policy Framework，SPF)是一種理論上可以防止域名欺騙的認(rèn)證協(xié)議。它引入了額外的安全檢查，使得郵件服務(wù)器能夠確定郵件是否來自真正的域名(如makeuseof.com)，或是有人冒用了該域名。

由于域名一般都可以被用來定位和跟蹤所有者，因此為了不被列入黑名單，各種黑客和垃圾郵件的投放者都會定期試著去滲透目標(biāo)系統(tǒng)、或欺騙目標(biāo)用戶。通過讓正規(guī)的域名發(fā)送各種惡意郵件，他們會讓毫無戒心的用戶更容易去點擊、或打開惡意的附件。

總的說來，發(fā)送方策略框架具有三個核心的要素：基本框架、身份驗證方法、以及傳遞信息所專用的郵件頭部。

4. DKIM保護郵件安全

域名密鑰識別郵件(Domain Keys Identified Mail，DKIM)是一種防篡改的協(xié)議，它可以確保您的郵件在傳輸過程中的安全性。DKIM使用數(shù)字簽名來檢查電子郵件是否由特定的域名所發(fā)出。此外，它會檢查是否確由該域名授權(quán)后發(fā)送。在此，我們可以認(rèn)為它是SPF的一種擴展。

在實際操作中，我們可以輕松地使用DKIM來開發(fā)各種針對域名的黑名單和白名單。

5. DMARC

這款重要的電子郵件安全協(xié)議叫作：基于域的消息驗證、報告和一致性(Domain-Based Message Authentication, Reporting & Conformance，DMARC)。DMARC是一種驗證系統(tǒng)，它通過驗證SPF和DKIM標(biāo)準(zhǔn)，來防止源自域名的欺詐活動。DMARC雖然能夠有效地遏制域名類欺騙，但是其目前的采用率并不高。

DMARC是通過檢查“header from”的地址，來提供欺騙防護的。其工作原理如下：

• 在SPF檢查期間，事先定義好了“envelope from”的域名，然后將“header from”域名與“envelope from”域名相比對。
• 將“header from”域名與DKIM簽名所發(fā)現(xiàn)的“d= domain name”相比對。

DMARC能夠指導(dǎo)郵件服務(wù)商如何去處置任何傳入的郵件。如果某個電子郵件無法通過SPF的檢查、和/或DKIM的身份驗證，則會被直接拒絕。DMARC是一種能夠讓各種規(guī)模的域名免受名稱欺騙的技術(shù)。當(dāng)然，它也并非是“百發(fā)百中”的。

6.用S/MIME實現(xiàn)端到端加密

安全的多功能互聯(lián)網(wǎng)郵件擴展(Secure/Multipurpose Internet Mail Extensions，S/MIME)是一種支持長距離的端到端加密協(xié)議。S/MIME會在發(fā)送郵件之前對其進行加密。不過它并不對發(fā)件人、收件人或電子郵件頭部的其他部分進行加密。當(dāng)然，也只有對應(yīng)的收件人才能解密您所發(fā)出的郵件。

郵件客戶端在實現(xiàn)S/MIME時需要持有相應(yīng)的數(shù)字證書。如今，雖然大多數(shù)的郵件客戶端都能夠支持S/MIME協(xié)議，但是您在實施之前還是檢查一下選定的應(yīng)用程序和郵件服務(wù)提供商。

7.PGP和OpenPGP

優(yōu)良保密協(xié)議(Pretty Good Privacy，PGP)是另一種長距離的端到端加密協(xié)議。不過，您更可能會用到的是其對應(yīng)的開源版本--OpenPGP。

由于是開源的，因此OpenPGP能夠得到持續(xù)的更新，而且您會在許多應(yīng)用程序和服務(wù)中找到它。與S/MIME一樣，第三方(區(qū)別于發(fā)送方與接收方)仍然可以訪問到郵件中諸如：發(fā)件人和收件人信息之類的元數(shù)據(jù)。

您可以參照如下的鏈接在自己的系統(tǒng)中啟用OpenPGP的相關(guān)安全設(shè)置：

• Windows：Gpg4Win，請參見https://www.gpg4win.org/
• macOS：GPGSuite，請參見https://gpgtools.org/
• Linux：GnuPG，請參見https://www.gnupg.org/
• Android：OpenKeychain，請參見https://www.openkeychain.org/
• iOS：請參見http://www.pgpeverywhere.com/

可見，每一種系統(tǒng)和應(yīng)用在OpenPGP的實現(xiàn)上略有不同。根據(jù)其開源的屬性，不同的開發(fā)人員在不同的平臺上通過OpenPGP協(xié)議，實現(xiàn)了對于郵件的加密、和對于數(shù)據(jù)的可靠保護。

原文標(biāo)題：7 Common Email Security Protocols Explained，作者：Gavin Phillips

【51CTO譯稿，合作站點轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】