サーバーレスDTLS

DTLSリスナー DTLSリスナーは、データグラム転送モデルを維持したまま、UDPアプリケーションにTLSスタイルの暗号化と認証を追加します。クライアントは、リスナーに割り当てられたドメインとポートでDTLS 1.2またはDTLS 1.3セッションを確立します。Proxylityは、認証されたアプリケーションデータを復号し、プレーンテキストのペイロードを設定された宛先に配信します。アプリケーションからの応答は暗号化され、同じDTLSセッションを通じて返送されます。 DTLSを使用するタイミング アプリケーションがすでにDTLSをサポートしている場合、またはデータグラム境界を維持しながら暗号化されたUDPトランスポートが必要な場合にDTLSリスナーを選択してください。一般的な例としては、RADIUS、IoTプロトコル、リアルタイムテレメトリ、ストリーム指向のTLS接続を使用できないカスタムリクエスト/レスポンスプロトコルなどがあります。DTLSは、ProxylityのロードマップにおけるWebRTCデータチャネルの最初のトランスポートレイヤーでもあります。DTLSリスナーは、ネイティブDTLSクライアント向けに本日提供されています。SCTPおよびWebRTCシグナリングは別レイヤーであり、DTLSリスナーでは提供されません。 DTLS、UDP、およびWireGuard | Feature | UDP Listener | DTLS Listener | WireGuard Listener | |---|---|---|---| | Transport | Plain UDP | DTLS 1.2 or DTLS 1.3 | WireGuard tunnel | | Encryption | Application responsibility | TLS-style authenticated encryption | WireGuard authenticated encryption | | Client authentication | | Certificate handshake or configured PSK identity | Registered peer key or open-peer policy | | Payload delivered to Destinations | UDP payload | Decrypted application data | WireGuard payload; optionally decapsulated | | Typical fit | Simple or already-encrypted protocols | Applications with native DTLS support | VPN clients and IP tunneling | 認証オプション サーバー証明書 すべてのDTLSリスナーは、Proxylityによって管理されるサーバー証明書と秘密鍵を受け取ります。証明書は、リスナーに割り当てられたエンドポイントを識別し、DtlsServerCertificate CloudFormation属性を通じて返されます。クライアントアプリケーションの信頼モデルに従って、その証明書またはそのトラストアンカーを配布してください。CloudFormationが新しいリスナー証明書を生成する必要がある場合は、CertRefreshTokenを変更してください。証明書のローテーションはクライアントが見る証明書を変更するため、本番環境のエンドポイントをローテーションする前に、信頼の更新を調整してください。 事前共有鍵 DTLS-PSKを使用するクライアントの場合、Psksマップを設定します。各マップキーは、ハンドシェイク中に送信されるクライアントIDであり、各値は対応するbase64エンコードされたキーです。PSK値は、テンプレートにコミットするのではなく、AWS Secrets Managerまたはその他の保護されたソースに保存してください。 Cookie保護 リスナーが完全なハンドシェイクを実行する前にDTLS Cookie交換を要求するには、RequireCookiesを要求に設定してください。Cookieは、クライアントが主張する送信元アドレスでパケットを受信できることを確認するのに役立ち、増幅およびリソース枯渇のリスクを軽減します。Cookieを有効にすると、新しいセッションに1回のラウンドトリップが追加されます。公開エンドポイントに推奨されます。 セッション再開と0-RTT DTLS 1.3クライアントは、ハンドシェイク完了後に暗号化されたセッションチケットを受け取ります。クライアントは、後でそのチケットを提示することで、より少ないハンドシェイクメッセージでセッションを再開できます。チケットの暗号化キーはリスナーごとに管理され、CloudFormationを通じて公開されることはありません。AllowEarlyDataを「true」に設定すると、再開されたDTLS 1.3クライアントが最初のフライトでアプリケーションデータを送信できるようになります。早期データは遅延を削減しますが、Proxylityが共有のアンチリプレイフィルターを適用しても、アプリケーションはそれを再生可能として扱う必要があります。冪等な操作（テレメトリ更新など）にのみ有効にし、一度きりのコマンド、金融取引、または安全に繰り返せないその他のアクションには0-RTTを使用しないでください。EarlyDataWindowSecondsは、チケットの有効期間とリプレイフィルターウィンドウの両方を制御します。デフォルトは3600秒で、1秒から604800秒（7日間）までの値を許容します。DTLS 1.2クライアントはセッションチケットまたは0-RTTを使用しません。 DTLS 1.2 Connection IDs Connection IDs（CID）をサポートするDTLS 1.2クライアントは、クライアントのIPアドレスとUDPポートに関係なく、確立されたセッションを識別できます。これにより、セッションはNATの再バインディング、送信元ポートの変更、アクセスネットワーク間の遷移を、新しいハンドシェイクを実行することなく継続できます。CIDは、低電力IoTデバイスにとって特に価値があります。確立されたセッションを再利用することで、デバイスがスリープ解除、ネットワーク変更、または新しいNATマッピングを取得した後の追加の無線時間、暗号化処理、およびハンドシェイク遅延を回避できます。CIDをネゴシエートしないクライアントは、ネットワークエンドポイントによって識別される標準のDTLS 1.2セッションを引き続き使用します。CIDサポートは、クライアントのDTLS実装に存在し、ハンドシェイク中にネゴシエートされる必要があります。openssl s_clientのような基本的な接続ツールは、DTLS 1.2 CIDをネゴシエートしない場合があります。 CloudFormation構成 Custom::ProxylityUdpGatewayListenerを使用してDTLSリスナーを作成し、Protocolsをdtlsに設定します。DTLSは、同じリスナーでUDPまたはWireGuardと組み合わせることはできません。 RadiusDtlsListener: Type: Custom::ProxylityUdpGatewayListener Properties: ServiceToken: !FindInMap [ProxylityConfig, !Ref "AWS::Region", ServiceToken] ApiKey: !FindInMap [ProxylityConfig, Account, ApiKey] Name: radius-dtls Description: Encrypted RADIUS authentication endpoint Protocols: - dtls RequireCookies: "true" AllowEarlyData: "true" EarlyDataWindowSeconds: "3600" ClientRestrictions: Networks: - 203.0.113.0/24 Destinations: - Name: radius-auth DestinationArn: !GetAtt RadiusAuthFunction.Arn Role: Arn: !GetAtt ProxylityDestinationRole.Arn Outputs: DtlsEndpoint: Value: !Sub "${RadiusDtlsListener.Domain}:${RadiusDtlsListener.Port}" DtlsServerCertificate: Value: !GetAtt RadiusDtlsListener.DtlsServerCertificate PSK Configuration DeviceDtlsListener: Type: Custom::ProxylityUdpGatewayListener Properties: ServiceToken: !FindInMap [ProxylityConfig, !Ref "AWS::Region", ServiceToken] ApiKey: !FindInMap [ProxylityConfig, Account, ApiKey] Protocols: - dtls RequireCookies: "true" Psks: sensor-fleet: !Sub "{{resolve:secretsmanager:${DtlsPskSecret}:SecretString}}" ClientRestrictions: Networks: - 198.51.100.0/24 Destinations: - Name: telemetry DestinationArn: !GetAtt TelemetryFunction.Arn Role: Arn: !GetAtt ProxylityDestinationRole.Arn Properties PropertyDescriptionDefault ProtocolsSet to a single value, dtls.Required RequireCookiesRequires a DTLS cookie exchange before the full handshake.false PsksMap of client identity to base64-encoded pre-shared key.Empty map AllowEarlyDataAccepts 0-RTT application data on resumed DTLS 1.3 sessions.false EarlyDataWindowSecondsSession-ticket lifetime and 0-RTT replay window, from 1 through 604800 seconds.3600 CertRefreshTokenChanging the value generates a new server certificate.Not set ClientRestrictionsNetworks and domains allowed to reach the Listener.Traffic blocked when omitted DestinationsAWS resources that receive decrypted application data.Empty list Listener CloudFormation Referenceで完全なリソース定義と戻り値を確認してください。 DTLSリスナーは、セッションチケットサポートが有効になる前に作成された場合、再開チケットを発行できるようになる前に、一度CloudFormationスタックの更新を受ける必要があります。 リスナーのテスト OpenSSLで証明書ベースのDTLS 1.2接続を確認できます。 openssl s_client -dtls1_2 -connect YOUR_DOMAIN:YOUR_PORT ハンドシェイクが成功すると、リスナー証明書とネゴシエートされた暗号が表示されます。アプリケーションプロトコルは、ハンドシェイク後に有効なペイロードを送信する必要があります。OpenSSL接続が完了しただけでは、宛先をテストしたことにはなりません。 例：サーバーレスRADIUS 公開されているサーバーレスRADIUSの例では、UDP、WireGuard、またはDTLSを介した認証トランスポートをデプロイできます。これは、同じAWSアプリケーションバックエンドが、RADIUSサーバーホストを運用することなく、DTLSリスナーを介して暗号化されたRADIUSトラフィックを受け入れることができる方法を示しています。