Cisco EメールセキュリティのTLS検証プロセス

はじめに

この文書は次のことについて記述しています Cisco Eメールセキュリティアプライアンス(ESA)のTransport Layer Security(TLS)サーバID検証プロセス

Cisco EメールセキュリティのTLS検証プロセス

TLS検証プロセスは、基本的に2段階の検証プロセスです。

I – 証明書の検証

これには、次の検証が含まれます。

• 証明書の有効期間 – 証明書の有効期間
• 証明書チェーン発行者
• 取消し一覧等

II – サーバIDの検証

これは、サーバの提示されたID（X.509公開キー証明書に含まれる）をサーバの参照IDに照合する検証プロセスです。

背景

RFC 6125で説明されているID名の用語をそのまま使用してみましょう。  

注：提示されたIDは、サーバX.509公開鍵証明書によって提示されたIDであり、これには異なるタイプの複数の提示されたIDを含めることができます。SMTPサービスの場合は、dNSNameタイプのsubjectAltName拡張またはsubjectフィールドから派生したCN（共通名）として含まれています。

注：参照IDは、完全修飾DNSドメイン名から構成されたIDであり、クライアントでは、証明書にアプリケーションサービスが含まれていることを予期します。

一般に、クライアントはTLSセッションを開始し、クライアントは通信を認証する必要があるため、検証プロセスはTLSクライアントにとって最も重要です。これを実現するには、クライアントは提示されたIDが参照IDと一致するかどうかを確認する必要があります。重要な部分は、メール配信のためのTLS検証プロセスのセキュリティがほぼ完全にTLSクライアントに基づいていることを理解することです。

ステップ 1

サーバID検証の最初の手順は、TLSクライアントによって参照IDを決定することです。これは、TLSクライアントが受け入れ可能と見なす参照識別子のリストがアプリケーションによって異なります。また、受け入れ可能な参照識別子のリストは、サービスによって提示される識別子とは別に構築する必要があります。[rfs6125#6.2.1]

参照IDは完全修飾DNSドメイン名である必要があり、任意の入力から解析できます（これはクライアントが受け入れ、安全であると見なします）。  参照IDは、クライアントが接続しようとしているDNSホスト名である必要があります。 

受信者の電子メールドメイン名は、特定のドメインの特定のユーザにメッセージを送信することを意図してユーザによって直接表現される参照IDであり、これはユーザが接続を試みているFQDNであることの要件も満たしています。これは、SMTPサーバが同じ所有者によって所有および管理され、サーバがホストしているドメインが多すぎるセルフホストSMTPサーバの場合にのみ一貫性があります。（subjectAltName: dNSName値の1つとして）証明書に各ドメインがリストされる必要があります。実装の観点から見ると、ほとんどの認証局(CA)では、ドメイン名の数の値を25エントリ（最大100）に制限しています。これは、ホストされた環境の場合には受け入れられません。宛先SMTPサーバが何千ものドメインをホストするEメールサービスプロバイダー(ESP)について考えてみましょう。これは拡張できません。

明示的に設定された参照IDが解決策のようですが、これには制約があります。手動で各宛先ドメインの送信元ドメインに参照IDを関連付けるか、「ユーザが明示的に信頼を置き、クライアントが相互認証と整合性チェックの両方を提供する接続または関連付けを介して通信するサードパーティドメインマッピングサービスからのデータの取得」が必要だからです。[RFC6125#6.2.1]

概念的には、これは設定時に1回限りの「セキュアMXクエリ」と考えることができ、その結果はMTAに永続的にキャッシュされ、実行状態にある間のDNSの侵害から保護されます。[2]

これにより、「パートナー」ドメインのみの認証が強化されますが、一般ドメインでマッピングされていないドメインは試験に合格せず、宛先ドメイン側の設定変更（ホスト名やIPアドレスの変更など）に影響されることはありません。

ステップ 2

プロセスの次のステップは、提示されたIDを判別することです。提示されたIDは、サーバのX.509公開鍵証明書によって、タイプdNSNameのsubjectAltName拡張またはsubjectフィールドのCommon Name(CN)として提供されます。少なくとも1つのsubjectAltNameエントリを含むsubjectAltName拡張が証明書に含まれている限り、subjectフィールドを空にすることは完全に可能です。

Common Nameの使用は依然として実際には存在しますが、非推奨とみなされ、現在の推奨事項はsubjectAltNameエントリを使用することです。共通名からのIDのサポートは、下位互換性のために残っています。このような場合、まずsubjectAltNameのdNSNameを使用する必要があり、それが空の場合にのみ共通名がチェックされます。

注：共通名は、完全修飾DNSドメイン名の形式と一致する形式の文字列ではなく、サービスのためのわかりやすい文字列が含まれている可能性があるため、厳密に入力されません

両方のタイプのIDが決定された最後に、TLSクライアントは、一致を見つけるために、それぞれの参照識別子を提示された識別子と比較する必要があります。

ESA TLSの検証

ESAでは、(宛先制御ページまたはdestconfig CLIコマンドを使用して)特定のドメインへの配信時にTLSおよび証明書検証を有効にできます。TLS証明書の検証が必要な場合、AsyncOSバージョン8.0.2以降では2つの検証オプションのいずれかを選択できます。予想される検証結果は、設定したオプションによって異なります。TLSの6つの異なる設定のうち、宛先制御で使用できるものには、証明書検証を担当する2つの重要な設定があります。

1. TLSが必要 – 確認
2. TLS Required – ホストされるドメインを確認します。

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)「Preferred - Verify」のTLS検証プロセスは、(5)「Required - Verify」と同じですが、結果に基づいて実行されるアクションは、次の表に示すように異なります。オプション(6) Required - Verify Hosted Domainsの結果は(5) Required - Verifyの結果と同じですが、TLS検証フローが大きく異なります。 

TLS設定	意味
4. 推奨（検証）	Eメールセキュリティアプライアンス(ESA)からドメインのMTAへのTLSがネゴシエートされます。アプライアンスはドメイン証明書の検証を試みます。 次の 3 つの結果が考えられます。 TLS がネゴシエートされ、証明書が検証される。暗号化されたセッションによってメールが配信される。 TLS がネゴシエートされるものの、証明書は検証されない。暗号化されたセッションによってメールが配信される。 TLS 接続が確立されず、証明書は検証されない。電子メール メッセージがプレーン テキストで配信される。
5. 必須（検証）	Eメールセキュリティアプライアンス(ESA)からドメインのMTAへのTLSがネゴシエートされます。ドメイン証明書の検証が必要です。 次の 3 つの結果が考えられます。 TLS 接続がネゴシエートされ、証明書が検証される。暗号化されたセッションによって電子メール メッセージが配信される。 TLS接続はネゴシエートされますが、証明書は信頼できるCAによって検証されません。メールは配信されない。 TLS 接続がネゴシエートされない。メールは配信されない。

TLS Required - VerifyオプションとTLS Required - Verify Hosted Domainオプションの違いは、ID検証プロセスにあります。提示されたIDの処理方法と、使用できる参照識別子のタイプによって、最終結果に違いが生じます。以下の説明および文書全体の目的は、このプロセスをエンドユーザに近づけることです。このテーマに関する誤った理解や不明瞭な理解は、ユーザネットワークのセキュリティに影響を与える可能性があります。

必要なTLSの確認

提示されたIDは、まずsubjectAltName - dNSName拡張から導出され、一致がないかsubjectAltName拡張がCN-IDより存在しない場合は、「Common Name from subject」フィールドがチェックされます。

参照ID(REF-ID)リストは、受信者ドメインまたは受信者ドメインと、クライアントが接続されているIPアドレスに対して実行されたPTR DNSクエリから取得されたホスト名で構成されます。  注：この特定のケースでは、異なる参照IDが異なる提示IDチェックと比較されます。

~=は、完全一致またはワイルドカード一致を表します

提示されたID（dNSNameまたはCN-ID）は、一致するまで、受け入れられた参照IDと比較され、次にリストされている順序で並べられます。 

• subjectAltNameのdNSName拡張が存在する場合：
  • 完全一致またはワイルドカード一致は、受信者ドメインに対してのみ実行されます
    
    subjectAltNameが一致した場合の参照IDは、受信者ドメインからのみ取得されます。受信者ドメインがdNSNameエントリのいずれにも一致しない場合、それ以降の参照IDはチェックされません（DNS解決MXまたはPTRから派生したホスト名など）

• サブジェクトDNのCNが存在する場合(CN-ID):
  • 受信者ドメインに対して完全一致またはワイルドカード一致が実行される
  • 宛先サーバのIPに対して実行されたPTRクエリーから抽出されたホスト名に対して、完全一致またはワイルドカード一致が実行されます
    
    ここで、PTRレコードは、フォワーダとリゾルバ間のDNSの一貫性を維持します。ここで注意する必要があるのは、CNフィールドがPTRからのホスト名と比較されるのは、PTRレコードが存在し、このホスト名（参照アイデンティティ）の解決済みAレコード（フォワーダ）が、PTRクエリが実行された宛先サーバIPと一致するIPアドレスを返す場合だけです。
    
    A(PTR(IP)) == IP
    
    CN-IDの場合の参照IDは受信者ドメインから取得され、一致するエントリがない場合は、宛先IPのPTRレコードに対してDNSクエリが実行されてホスト名が取得されます。PTRが存在する場合、DNSの一貫性が維持されていることを確認するために、PTRから派生したホスト名のAレコードに対して追加のクエリが実行されます。それ以上の参照はチェックされません（MXクエリから派生したホスト名と同様）

要約すると、「TLS Required - Verify」オプションを使用した場合、dNSNameまたはCNと比較してMXホスト名は存在しません。DNS PTR RRは、CNについてのみチェックされ、DNSの整合性がA(PTR(IP) = IPとして保持されている場合にのみ照合されます。dNSNameとCNについては、exactとwildcardテストが実行されます。

TLS必須の確認 – ホステッドドメイン

表示されるIDは、最初にタイプdNSNameのsubjectAltName拡張から取得されます。dNSNameと承認済みの参照ID(REF-ID)の1つが一致しない場合、CNが件名フィールドに存在しても検証は失敗し、それ以上のID検証を渡すことができます。subjectフィールドから派生したCNは、証明書にdNSName型のsubjectAltName拡張が含まれていない場合にのみ検証されます。

提示されたID（dNSNameまたはCN-ID）は、一致するまで、受け入れられた参照IDと比較され、次に示す順序で並べられます。 

• subjectAltNameのdNSName拡張が存在する場合：
  
  dNSNameと、以下にリストされている承認済み参照IDの1つが一致しない場合、ID検証は失敗します
   
  • 受信者ドメインに対して完全一致またはワイルドカード一致が行われます。dNSNameの1つが受信者ドメインに一致する必要があります。
  • 厳密な一致またはワイルドカードによる一致は、SMTPROUTES (*)を使用して明示的に設定されたホスト名に対して行われます。
  • 正確な（非セキュアな）DNSクエリと受信者のドメイン名から取得されたMXホスト名に対して、ワイルドカード照合または完全一致が行われます
    
    受信者ドメインにFQDNエントリを使用して明示的に設定されたSMTPルートがなく、受信者ドメインがMXレコードからのFQDNリターンと一致しない場合（非セキュアな場合）、受信者ドメインに対するDNSクエリが使用されます。一致するエントリがない場合、それ以上のテストは実行されず、PTRレコードはチェックされません 
• サブジェクトDNのCNが存在する場合(CN-ID):

  
  CNは、dNSNameが証明書に存在しない場合にのみ検証されます。CN-IDが、承認された参照IDのリストと比較されます。
  
  

  • 受信者ドメインに対して完全一致またはワイルドカード一致が実行される
  • 正確な一致またはワイルドカードによる一致は、SMTPROUTES (*)で明示的に設定されたホスト名に対して実行されます。
  • 正確な（非セキュアな）DNSクエリと受信者のドメイン名から取得されたMXホスト名に対して、ワイルドカード照合または完全一致が行われます

明示的に設定されたSMTPROUTES

SMTPルートが設定され、提示されたIDが電子メール受信者ドメインと一致しなかった場合、すべてのFQDNルート名が比較され、一致しなかった場合は、それ以上のチェックは行われません。明示的に設定されたSMTPルートでは、MXホスト名は提示されたIDと比較されません。ここでの例外は、IPアドレスとして設定されたSMTPルートを作成することです。

明示的に設定されたSMTPルートには、次の規則が適用されます。

• 受信者ドメインのSMTPルートが完全修飾DNSドメイン名(FQDN)である場合、そのルートは参照IDと見なされます。このホスト名（ルート名）は、接続先の宛先サーバから取得した証明書から受信した提示IDと比較されます。

• 受信者ドメインに対して複数のルートが許可されます。受信側ドメインに複数のSMTPルートがある場合、宛先サーバからの証明書に提示されたIDが、接続が確立されたルートの名前と一致するまで、ルートが処理されます。リスト内のホストの優先順位が異なる場合、最も高い（0が最高、デフォルト）ホストが最初に処理されます。すべてが同じプライオリティを持つ場合、ルートのリストは、ユーザがルートを設定した順序で処理されます。

• ホストが応答しない（利用できない）か、応答したもののTLS検証が失敗した場合、リストの次のホストが処理されます。最初のホストが使用可能で、検証に合格した場合、その他のホストは使用されません。

• 複数のルートが同じIPアドレスに解決される場合、このIPへの接続は1つだけ確立され、宛先サーバによって送信される証明書から取得された提示IDは、これらのルート名のいずれかに一致する必要があります。

• 受信者ドメインに対してSMTPルートが存在するが、IPアドレスとして設定されている場合、ルートは接続を行うために引き続き使用されますが、証明書からの提示されたIDは受信者ドメインと比較され、さらにDNS/MXリソースレコードから取得されたホスト名と比較されます。

ホステッドドメインのTLS Required Verifyオプションについて説明する場合、ESAが宛先サーバに接続する方法は、TLS検証プロセスにとって重要です。これは、SMTPルートが明示的に設定されており、プロセスで考慮すべき追加の参照IDを提供するためです。

~=は、完全一致またはワイルドカード一致を表します

例

実際の事例を見てみましょう。ただし、受信者のドメインについてはexample.comを参照してください。以下では、サーバのIDを手動で確認するために必要なすべての手順について説明しました。 

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   

•   提示されたID:dNSName exist（許可された参照IDとの比較を続行）
  
  
  • 参照アイデンティティ=受信者ドメイン(example.com)がチェックされ、dNSName DNS:*.emailhosted.not、DNS:emailhosted.notに一致しない。
•   提示されたID:CNが存在します（前の提示されたIDが一致しなかったので、次の提示されたIDに進みます）
  
  
  • 参照アイデンティティ=受信者ドメイン(example.com)がチェックされ、CN *.emailhosted.not
    
    
  • reference identity = PTR(IP):PTRクエリは、TLSクライアント(ESA)が接続を確立し、証明書を受信したサーバのIPに対して実行され、このクエリは次を返します。 mx0a.emailhosted.notです。
    
    
    • このホスト名を有効な参照IDと見なすために、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.の値がCN *.emailhosted.notと比較され、一致します。

PTRドメイン名によってIDが検証され、証明書がCA署名付き証明書であるため、証明書全体が検証され、TLSセッションが確立されます。

• 提示されたID:dNSName exist（この場合、CNは処理されません）
  • reference identity = recipient domain (example.com)がチェックされ、
    はdNSName DNS:*.emailhosted.not、DNS:emailhosted.notと一致しません。
  • reference identity = FQDN(smtp route)：この受信者ドメインにはsmtproutesがありません。 
    
    追加で使用されるSMTPROUTESがないため、次のようになります。
    
    
  • reference identity = MX(recipient domain):DNS MXクエリが受信者ドメインに対して実行されます。
    および次のメッセージが返されます。mx01.subd.emailhosted.not – これはdNSName DNS:*.emailhosted.not、DNS:emailhosted.not
• 提示されたID:CNは存在しますが、dNSNameも存在するためスキップされます。