Présentation

Les DTLS Listeners de Proxylity ajoutent un chiffrement de type TLS aux applications UDP tout en conservant le modèle de transport datagramme. Le client initie une session DTLS 1.2 ou DTLS 1.3 vers le domaine et le port attribués au Listener. Proxylity déchiffre les données authentifiées, les transmet aux destinations configurées, puis renvoie les réponses chiffrées via la même session.

Fonctionnement et configuration

Chaque Listener possède un certificat serveur et une clé privée générés par Proxylity. Le certificat est exposé via l’attribut CloudFormation DtlsServerCertificate, ce qui permet de le distribuer ou d’en extraire l’ancre de confiance. La rotation du certificat s’opère en modifiant le paramètre CertRefreshToken; les clients doivent mettre à jour leur magasin de confiance avant la mise à jour en production.

RadiusDtlsListener:
  Type: Custom::ProxylityUdpGatewayListener
  Properties:
    ServiceToken: !FindInMap [ProxylityConfig, !Ref "AWS::Region", ServiceToken]
    ApiKey: !FindInMap [ProxylityConfig, Account, ApiKey]
    Name: radius-dtls
    Protocols:
      - dtls
    RequireCookies: "true"
    AllowEarlyData: "true"
    EarlyDataWindowSeconds: "3600"
    Destinations:
      - Name: radius-auth
        DestinationArn: !GetAtt RadiusAuthFunction.Arn

Pour les clients DTLS‑PSK, la map Psks associe chaque identité client à une clé pré‑partagée encodée en base64. Proxylity recommande de stocker ces clés dans AWS Secrets Manager afin d’éviter leur inclusion dans les templates CloudFormation.

Le paramètre RequireCookies active l’échange de cookies DTLS, ajoutant un aller‑retour supplémentaire au handshake mais limitant les risques d’amplification et d’épuisement de ressources. Cette option est conseillée pour les points d’accès publics.

Sécurité et performances

Les clients DTLS 1.3 reçoivent un ticket de session chiffré après le handshake. Le ticket permet la reprise de session avec moins de messages d’échange ; les clés de chiffrement du ticket sont gérées par le Listener et ne sont pas exposées via CloudFormation. En activant AllowEarlyData, le client peut transmettre des données dès le premier vol (0‑RTT). Proxylity applique un filtre anti‑replay partagé, mais la donnée doit être considérée comme réutilisable, ce qui limite l’usage aux opérations idempotentes comme la télémétrie.

Le paramètre EarlyDataWindowSeconds définit la durée de vie du ticket et la fenêtre de filtrage anti‑replay. Sa valeur par défaut est 3600 s, avec une fourchette de 1 à 604 800 s (une semaine). Les clients DTLS 1.2 ne bénéficient ni de tickets ni de 0‑RTT.

DTLS 1.2 supporte les Connection IDs (CID). Un CID permet d’identifier une session indépendamment de l’adresse IP et du port UDP du client, facilitant la continuité lors d’un changement de NAT ou de réseau. Cette fonctionnalité réduit la consommation radio, le coût cryptographique et la latence de handshake pour les appareils IoT à faible puissance. La négociation du CID dépend du client ; les outils de base comme openssl s_client ne le proposent généralement pas.

Limitations et bonnes pratiques

Un Listener ne peut pas combiner le protocole DTLS avec UDP ou WireGuard sur la même ressource ; chaque Listener doit être dédié à un seul protocole. Les Listeners créés avant l’activation du support des tickets de session nécessitent une mise à jour CloudFormation avant de pouvoir émettre des tickets de reprise.

openssl s_client -dtls1_2 -connect YOUR_DOMAIN:YOUR_PORT

Cette commande vérifie la connectivité DTLS 1.2 basée sur certificat, mais ne teste pas la logique de la destination. Les déploiements typiques, comme l’exemple serveurless RADIUS, montrent que le même backend AWS peut accepter du trafic RADIUS chiffré via DTLS sans héberger de serveur RADIUS dédié.