Cisco電子郵件安全的TLS驗證程式

簡介

本檔案說明 思科郵件安全裝置(ESA)的傳輸層安全(TLS)伺服器身份驗證過程

Cisco電子郵件安全的TLS驗證程式

TLS驗證過程實際上是一個兩階段驗證過程：

I -證書驗證

這涉及驗證：

• 證書有效期-證書有效期
• 憑證鏈結簽發者
• 撤銷清單等。.

II -伺服器辨識驗證

這是針對伺服器參照辨識驗證伺服器呈現辨識（包含在X.509公開金鑰憑證中）的程式。

背景

讓我們繼續使用RFC 6125中描述的身份名稱術語。  

注意：呈現標識是由伺服器X.509公鑰證書呈現的識別符號，該證書可以包含多個不同型別的呈現識別符號。對於SMTP服務，它包含為dNSName型別的subjectAltName副檔名，或者包含為派生自主題欄位的CN（公用名）。

注意：參考標識是從完全限定的DNS域名構造的識別符號，客戶端期望證書中含有應用服務。

驗證過程對TLS客戶端來說最為重要，因為通常客戶端會發起TLS會話，而客戶端需要驗證通訊。要達到此目的，客戶端需要驗證提供的標識是否與參考標識匹配。重點在於瞭解TLS驗證過程的安全性幾乎完全基於TLS客戶端。

步驟1

伺服器身份驗證的第一步是透過TLS客戶端確定參考身份。這取決於TLS客戶端認為哪些參考識別符號清單是可接受的。此外，可接受的參考識別符號清單必須獨立於服務提供的識別符號而構建。[rfs6125#6.2.1]

引用標識必須是完全限定的DNS域名，並且可以從任何輸入進行解析（這對客戶端來說是可接受的，並且被認為是安全的）。  參考標識必須是客戶端嘗試連線的DNS主機名。 

收件人電子郵件域名是參考標識，由使用者直接表示，用於表示向特定域中的特定使用者傳送消息的意圖，這也符合作為使用者試圖連線的FQDN的要求。只有在自行託管的SMTP伺服器中，SMTP伺服器由同一所有者擁有和管理，並且伺服器未託管過多域的情況下，它才會保持一致。因為每個網域都需要列在憑證中（作為subjectAltName： dNSName值之一）。從實施角度來看，大多數證書頒發機構(CA)將域名值的數量限制為最少25個（最多100個）。這在託管環境中不被接受，讓我們考慮一下電子郵件服務提供程式(ESP)，其中目標SMTP伺服器託管成千上萬個域。這根本無法擴展。

明確配置的參考標識似乎是答案，但這會施加一些限制，因為需要手動將參考標識與每個目標域的源域相關聯，或「從第三方域對映服務獲取資料，在該服務中，使用者已明確表示信任，並且客戶端透過連線或關聯進行通訊，以提供相互驗證和完整性檢查」。[RFC6125#6.2.1]

從概念上講，在配置時這可以視為一次性的「安全MX查詢」，其結果永久快取在MTA上，以防止在運行狀態下受到任何DNS危害。[2]

這只能為「合作夥伴」域提供更強的身份驗證，但對於尚未對映的通用域，該身份驗證不會透過考試，而且也不能避免目標域側配置更改（例如主機名或IP地址更改）。

第二步

該過程的下一步是確定呈現標識。呈現的標識由伺服器X.509公鑰證書提供，作為dNSName型別的subjectAltName副檔名或作為subject欄位中找到的公用名(CN)。其中subject欄位是完全可以接受的，只要證書包含至少包含一個subjectAltName條目的subjectAltName副檔名。

雖然公用名稱的使用仍在實踐中，但會被視為已棄用，並且目前建議使用subjectAltName專案。對公用名標識的支援將保持向後相容性。在這種情況下，應首先使用subjectAltName的dNSName，並且僅當它是空的，才會檢查公用名。

注意：公用名不是強型別化的，因為公用名可能包含服務的人性友好字串，而不是形式與完全限定DNS域名匹配的字串

最後，當確定了兩種型別的身份時，TLS客戶端需要將其每個參考識別符號與所提供的識別符號進行比較，以便找到匹配。

ESA TLS驗證

ESA允許在傳送到特定域時啟用TLS和證書驗證(使用目標控制頁面或destconfig CLI命令)。如果需要TLS證書驗證，則從AsyncOS版本8.0.2起，您可以選擇兩個驗證選項之一。預期的驗證結果可能因配置的選項而異。TLS有6種不同的設定，可在目標控制下使用，其中有兩個重要設定負責證書驗證：

1. 需要TLS -驗證
2. 需要TLS -驗證託管域。

CLI: destconfig 

Do you want to use TLS support?

1. No

2. Preferred

3. Required

4. Preferred - Verify

5. Required - Verify

6. Required - Verify Hosted Domains 

[6]> 

選項(4)「首選-驗證」的TLS驗證過程與(5)「必需-驗證」相同，但根據結果採取的操作有所不同，如下表所示。選項(6)必需-驗證託管域的結果與(5)必需-驗證但TLS驗證流完全不同。 

TLS設定	意義
4. 首選（驗證）	TLS從郵件安全裝置協商到域的MTA。裝置會嘗試驗證域證書。 有三種可能的結局： 將協商TLS並驗證證書。郵件透過加密會話傳送。 已協商TLS，但未驗證證書。郵件透過加密會話傳送。 未建立TLS連線，因此未驗證憑證。電子郵件訊息以純文字傳送。
5. 必要（驗證）	TLS從郵件安全裝置協商到域的MTA。需要驗證域證書。 有三種可能的結局： 將協商TLS連線並驗證證書。電子郵件訊息會透過加密工作階段傳送。 TLS連線是經過協商的，但證書未經受信任的CA驗證。郵件未送達。 TLS連線不會交涉。郵件未送達。

需要TLS -驗證和需要TLS -驗證託管域選項之間的區別位於身份驗證過程中。處理呈現標識的方式以及允許使用何種型別的參考識別符號對最終結果有影響。以下說明及整份檔案的目的都是為了讓使用者更接近此程式。由於不正確或不清楚瞭解此主題可能會對使用者網路造成安全影響。

需要TLS驗證

呈現的標識首先從subjectAltName - dNSName副檔名派生，如果沒有匹配項或subjectAltName副檔名不存在，則選中CN-ID - Common Name from subject欄位。

參考身份(REF-ID)清單由收件人域或收件人域構成，並從針對客戶端所連線的IP地址運行的PTR DNS查詢派生主機名。  注意：在此特定情況下，不同的參考標識與不同的呈現標識檢查相比較。

~=表示完全匹配或萬用字元匹配

呈現標識（dNSName或CN-ID）會與接受的參考標識進行比較，直到其匹配且按下列順序排列為止。 

• 如果subjectAltName的dNSName副檔名存在：
  • 僅對收件人域執行完全匹配或萬用字元匹配
    
    在subjectAltName匹配的情況下引用標識僅從收件人域派生。如果收件者網域不符合任何dNSName專案，則不會檢查進一步的參考身分辨識（例如，衍生自DNS解析MX或PTR的主機名稱）

• 如果主題DN的CN存在(CN-ID)：
  • 對收件人域執行完全匹配或萬用字元匹配
  • 根據從對目標伺服器的IP執行的PTR查詢中派生的主機名執行完全匹配或萬用字元匹配
    
    其中PTR記錄保留了轉發器和解析器之間的DNS一致性。此處需要提及是，僅當存在PTR記錄時，才會將CN欄位與PTR中的主機名進行比較，並且用於此主機名的已解析A記錄（轉發器）返回與執行PTR查詢的目標伺服器IP匹配的IP地址。
    
    A(PTR(IP))==IP
    
    如果CN-ID是從收件人域派生的，並且當不存在匹配時，會對目標IP的PTR記錄執行DNS查詢以獲取主機名。如果PTR存在，將對從PTR派生的主機名上的A記錄執行額外的查詢，以確認DNS一致性已保留！不檢查其他引用（如從MX查詢派生的主機名）

總之，使用「需要TLS -驗證」選項時，沒有MX主機名與dNSName或CN相比，僅檢查CN的DNS PTR RR，並且僅在保留DNS一致性時匹配A(PTR(IP)) = IP，同時執行dNSName和CN的精確和萬用字元測試。

需要TLS驗證-託管域

呈現的標識首先從dNSName型別的subjectAltName擴展派生。如果dNSName與其中一個接受的參照標識(REF-ID)之間沒有匹配，則無論主題欄位中是否存在CN，驗證都會失敗，並且可以透過進一步的標識驗證。僅當證書不包含任何dNSName型別的subjectAltName副檔名時，才會驗證從主題欄位派生的CN。

回想一下，呈現的標識（dNSName或CN-ID）與接受的參考標識進行比較，直到其匹配且按下列順序排列為止。 

• 如果subjectAltName的dNSName副檔名存在：
  
  如果dNSName與下列其中一個接受的參照辨識不匹配，則辨識驗證失敗
   
  • 對收件人域執行完全匹配或萬用字元匹配： dNSName之一必須與收件人域匹配
  • 使用SMTPROUTES (*)對明確配置的主機名執行完全匹配或萬用字元匹配
  • 根據MX主機名進行完全匹配或萬用字元匹配，該主機名派生自（不安全）針對收件人域名的DNS查詢
    
    如果收件者網域未明確設定具有FQDN專案的SMTP路由，且收件者網域不符合MX記錄傳回的FQDN，則會針對收件者網域使用不安全的DNS查詢。如果沒有匹配項，則不執行進一步測試，不會檢查任何PTR記錄 
• 如果主題DN的CN存在(CN-ID)：

  
  僅當證書中不存在dNSName時，才會驗證CN。將CN-ID與下面接受的參照標識清單進行比較。
  
  

  • 對收件人域執行完全匹配或萬用字元匹配
  • 完全匹配或萬用字元匹配將針對SMTPROUTES (*)中明確配置的主機名進行
  • 根據MX主機名進行完全匹配或萬用字元匹配，該主機名派生自（不安全）針對收件人域名的DNS查詢

明確配置的SMTPROUTES

如果配置了SMTP路由，並且顯示的標識與電子郵件收件人域不匹配，則會比較所有FQDN路由名稱，如果不匹配，則不會進行進一步檢查。使用明確配置的SMTP路由時，不會將MX主機名與提供的標識進行比較。此處的例外情況是生成設定為IP地址的SMTP路由。

以下規則適用於顯式配置的SMTP路由：

• 當收件人域存在SMTP路由且它是完全限定DNS域名(FQDN)時，該路由被視為引用標識。此主機名（路由名稱）與從證書收到的來自其指向的目標伺服器的呈現的標識進行比較。

• 允許一個收件人域使用多個路由。如果收件者網域有多個SMTP路由，則會處理這些路由，直到來自目的地伺服器之憑證的辨識碼與建立連線的路由名稱相符。如果清單上的主機具有不同的優先順序，則首先處理優先順序最高（0為最高且為預設值）的主機。如果所有路由的優先順序都相同，則路由清單將按使用者設定路由的順序進行處理。

• 如果主機沒有回應（無法使用）或回應但TLS驗證失敗，則會處理清單中的下一個主機。當第一台主機可用並透過驗證時，其他主機則不會使用。

• 如果多個路由解析為相同的IP地址，則僅建立與此IP的一個連線，且從目標伺服器傳送的證書中派生的呈現身份必須與其中一個路由名稱匹配。

• 如果收件人域存在SMTP路由，但路由仍被配置為IP地址，則仍使用該路由進行連線，但來自證書的呈現身份會與收件人域進行比較，並進一步與從DNS/MX資源記錄派生的主機名進行比較。

當我們討論託管域的TLS要求驗證選項時，ESA如何與目標伺服器連線對於TLS驗證過程非常重要，因為明確配置的SMTP路由提供在此過程中要考慮的額外參考標識。

~=表示完全匹配或萬用字元匹配

範例

讓我們從現實生活中舉一個例子，但是對於收件人域：example.com。下面我嘗試介紹手動驗證伺服器身份所需的所有步驟。 

example.com -> IN MX mx01.subd.emailhosted.not.
example.com -> IN MX mx02.subd.emailhosted.not.

mx01.subd.emailhosted.not. -> IN A 192.0.2.1
mx02.subd.emailhosted.not. -> IN A 192.0.2.2

192.0.2.1 -> IN PTR mx0a.emailhosted.not.
192.0.2.2 -> IN PTR mx0b.emailhosted.not.

mx0a.emailhosted.not. -> IN A 192.0.2.1
mx0b.emailhosted.not. -> IN A 192.0.2.2

注意：在這種情況下，MX主機名和revDNS名稱不匹配

$ echo QUIT |openssl s_client -connect mx0a.emailhosted.not:25 -starttls smtp 2>/dev/null| openssl x509 -text | grep -iEo 'DNS:.*|CN=.*'

CN=thawte SHA256 SSL CA
CN=*.emailhosted.not
DNS:*.emailhosted.not, DNS:emailhosted.not 

echo QUIT |openssl s_client -connect mx0b.emailhosted.not:25 -starttls smtp 2>/dev/null| openssl x509 -text | grep -iEo 'DNS:.*|CN=.*'

CN=thawte SHA256 SSL CA
CN=*.emailhosted.not
DNS:*.emailhosted.not, DNS:emailhosted.not   

•   呈現標識：dNSName exist（繼續與允許的引用標識進行比較）
  
  
  • 參照辨識=收件者網域(example.com)已核取，且與dNSName DNS：*.emailhosted.not、DNS：emailhosted.not不相符
•   呈現的標識：CN存在（繼續下一個呈現的標識，與上一個標識一樣，沒有匹配）
  
  
  • 參照辨識=收件者網域(example.com)已核取，且不符合CN *.emailhosted.not
    
    
  • 參考標識= PTR(IP)：對TLS客戶端(ESA)已建立連線並收到證書的伺服器的IP執行PTR查詢，並且此查詢返回： mx0a.emailhosted.not.
    
    
    • 檢查DNS一致性，以將此主機名視為有效的參考標識：
      
      
      存在一致性：A(PTR(IP)) = IP
      
      

      mx01.subd.emailhosted.not. -> IN A 192.0.2.1
      
      PTR(IP):      192.0.2.1  -> IN PTR  mx0a.emailhosted.not.
      A(PTR(IP)):   mx0a.emailhosted.not. -> IN A 192.0.2.1
      

    • mx0a.emailhosted.not.的值將與*.emailhosted.notcn進行比較，兩者在匹配。

PTR域名會驗證身份，由於證書是CA簽名的證書，它將驗證整個證書並建立TLS會話。

• 呈現標識：dNSName存在（因此在這種情況下不會處理CN）
  • 參照辨識=收件者網域(example.com)已核取，且
    與dNSName DNS：*.emailhosted.not、DNS：emailhosted.not不匹配
  • 參考辨識= FQDN(smtp route) -此收件者網域沒有smtproutes 
    
    由於未額外使用SMTPROUTES：
    
    
  • 參考身份= MX（收件人域） -對收件人域執行DNS MX查詢
    和返回：mx01.subd.emailhosted.not -這與dNSName DNS：*.emailhosted.not、DNS：emailhosted.not不匹配
• 呈現的標識：CN存在，但由於dNSName也存在，因此會跳過。