Serverless DTLS

# DTLS Listeners - Proxylity UDP Gateway Source: [https://proxylity.com/docs/listeners/dtls.html](https://proxylity.com/docs/listeners/dtls.html) DTLS Listeners add TLS\-style encryption and authentication to UDP applications without changing the datagram transport model\. Clients establish a DTLS 1\.2 or DTLS 1\.3 session with the Listener's assigned domain and port\. Proxylity decrypts authenticated application data and delivers the plaintext payload to your configured[Destinations](https://proxylity.com/docs/destinations/index.html)\. Responses from your application are encrypted and sent back through the same DTLS session\. ## When to Use DTLS Choose a DTLS Listener when your application already supports DTLS or needs encrypted UDP transport while preserving datagram boundaries\. Common examples include RADIUS, IoT protocols, real\-time telemetry, and custom request\-response protocols that cannot use a stream\-oriented TLS connection\. DTLS is also the first transport layer on Proxylity's[roadmap to WebRTC Data Channels](https://proxylity.com/articles/the-roadmap-to-browser-apps.html)\. DTLS Listeners are available today for native DTLS clients; SCTP and WebRTC signaling are separate layers and are not provided by a DTLS Listener\. ## DTLS, UDP, and WireGuard FeatureUDP ListenerDTLS ListenerWireGuard ListenerTransportPlain UDPDTLS 1\.2 or DTLS 1\.3WireGuard tunnelEncryptionApplication responsibilityTLS\-style authenticated encryptionWireGuard authenticated encryptionClient authenticationClient RestrictionsCertificate handshake or configured PSK identityRegistered peer key or open\-peer policyPayload delivered to DestinationsUDP payloadDecrypted application dataWireGuard payload; optionally decapsulatedTypical fitSimple or already\-encrypted protocolsApplications with native DTLS supportVPN clients and IP tunneling ## Authentication Options ### Server Certificate Every DTLS Listener receives a server certificate and private key managed by Proxylity\. The certificate identifies the Listener's assigned endpoint and is returned through the`DtlsServerCertificate`CloudFormation attribute\. Distribute that certificate or its trust anchor according to your client application's trust model\. Change`CertRefreshToken`when you need CloudFormation to generate a new Listener certificate\. Certificate rotation changes the certificate clients see, so coordinate trust updates before rotating production endpoints\. ### Pre\-Shared Keys For clients that use DTLS\-PSK, configure the`Psks`map\. Each map key is the client identity sent during the handshake, and each value is the corresponding base64\-encoded key\. Store PSK values in AWS Secrets Manager or another protected source rather than committing them to a template\. ## Cookie Protection Set`RequireCookies`to require the DTLS cookie exchange before the Listener performs the full handshake\. Cookies help confirm that a client can receive packets at its claimed source address and reduce amplification and resource\-exhaustion risk\. Enabling cookies adds one round trip to a new session\. It is recommended for public endpoints\. ## Session Resumption and 0\-RTT DTLS 1\.3 clients receive an encrypted session ticket after completing a handshake\. A client can present that ticket on a later connection to resume the session with fewer handshake messages\. Ticket encryption keys are managed per Listener and are not exposed through CloudFormation\. Set`AllowEarlyData`to`"true"`to let a resumed DTLS 1\.3 client send application data with its first flight\. Early data reduces latency, but applications must treat it as replayable even though Proxylity applies a shared anti\-replay filter\. Enable it only for idempotent operations such as telemetry updates; do not use 0\-RTT for one\-time commands, financial operations, or other actions that cannot safely be repeated\. `EarlyDataWindowSeconds`controls both the ticket lifetime and the replay\-filter window\. It defaults to 3600 seconds and accepts values from 1 through 604800 seconds \(seven days\)\. DTLS 1\.2 clients do not use session tickets or 0\-RTT\. ## DTLS 1\.2 Connection IDs DTLS 1\.2 clients that support Connection IDs \(CID\) can identify an established session independently of the client's IP address and UDP port\. This allows a session to continue across NAT rebinding, source\-port changes, and transitions between access networks without performing a new handshake\. CID is particularly valuable for low\-power IoT devices\. Reusing an established session avoids additional radio time, cryptographic work, and handshake latency after a device wakes, changes networks, or receives a new NAT mapping\. Clients that do not negotiate CID continue to use standard DTLS 1\.2 sessions identified by their network endpoints\. CID support must be present in the client DTLS implementation and negotiated during the handshake\. Basic connectivity tools such as`openssl s\_client`may not negotiate DTLS 1\.2 CID\. ## CloudFormation Configuration Create a DTLS Listener with`Custom::ProxylityUdpGatewayListener`and set`Protocols`to`dtls`\. DTLS cannot be combined with UDP or WireGuard on the same Listener\. ``` 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`Protocols`Set to a single value,`dtls`\.Required`RequireCookies`Requires a DTLS cookie exchange before the full handshake\.`false``Psks`Map of client identity to base64\-encoded pre\-shared key\.Empty map`AllowEarlyData`Accepts 0\-RTT application data on resumed DTLS 1\.3 sessions\.`false``EarlyDataWindowSeconds`Session\-ticket lifetime and 0\-RTT replay window, from 1 through 604800 seconds\.`3600``CertRefreshToken`Changing the value generates a new server certificate\.Not set`ClientRestrictions`Networks and domains allowed to reach the Listener\.Traffic blocked when omitted`Destinations`AWS resources that receive decrypted application data\.Empty list See the[Listener CloudFormation Reference](https://proxylity.com/docs/cloudformation/listener.html)for the complete resource definition and return values\. DTLS Listeners created before session\-ticket support was enabled must receive a CloudFormation stack update once before they can issue resumption tickets\. ## Testing a Listener OpenSSL can verify certificate\-based DTLS 1\.2 connectivity: ``` openssl s_client -dtls1_2 -connect YOUR_DOMAIN:YOUR_PORT ``` A successful handshake displays the Listener certificate and negotiated cipher\. Application protocols still need to send valid payloads after the handshake; a completed OpenSSL connection alone does not test your Destination\. ## Example: Serverless RADIUS The public[serverless RADIUS example](https://github.com/proxylity/examples/tree/main/radius)can deploy authentication transport using UDP, WireGuard, or DTLS\. It demonstrates how the same AWS application backend can accept encrypted RADIUS traffic through a DTLS Listener without operating a RADIUS server host\.