Proxylity lleva DTLS al UDP serverless sobre AWS
Proxylity acaba de documentar los DTLS Listeners, una nueva capa para su UDP Gateway serverless en AWS que añade cifrado y autenticación estilo TLS al tráfico UDP sin alterar el modelo de datagramas. Los listeners soportan DTLS 1.2 y DTLS 1.3, exponen el certificado del servidor vía CloudFormation y entregan el payload ya descifrado a una función Lambda u otro destino configurado.
La pieza importa porque UDP, a diferencia de TCP, no tiene una capa de cifrado universalmente adoptada. Para una startup que envía telemetría IoT, opera RADIUS o piensa en WebRTC, eso significaba hasta hoy mantener servidores propios con stunnel, openssl o túneles VPN solo para cifrar lo que ya entra por UDP. Los DTLS Listeners eliminan ese host dedicado.
Qué es DTLS y por qué un founder debería entenderlo
DTLS (Datagram Transport Layer Security) es la versión de TLS adaptada a UDP: misma criptografía y autenticación por certificados o PSK, pero conservando la semántica de datagrama. Es lo que usan por defecto protocolos como WebRTC, OpenVPN en modo UDP, RADIUS sobre TLS o CoAP con DTLS en IoT.
👥 ¿Quieres ir más allá de la noticia?
En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.
👥 Unirme a la comunidadLa diferencia práctica frente a TLS sobre TCP es importante para productos en tiempo real:
- Sin retransmisiones implícitas. UDP no reenvía paquetes perdidos; DTLS tampoco. Si tu aplicación ya asume esa semántica (telemetría, gaming, VoIP), DTLS encaja sin reescrituras.
- Sin handshake orientado a stream. El handshake puede completarse en pocos mensajes, lo que ayuda en redes IoT de baja potencia.
- Cifrado autenticado. El protocolo garantiza confidencialidad e integridad, igual que TLS.
Proxylity lo describe como un Listener intermedio que descifra el datagrama y lo entrega limpio al destino, de forma que la Lambda receptora solo ve la carga útil de la aplicación.
Qué incluye el DTLS Listener de Proxylity
La documentación oficial (proxylity.com) detalla cuatro bloques clave:
- Autenticación dual. Cada listener recibe un certificado y clave privada gestionados por Proxylity y expuestos vía el atributo
DtlsServerCertificatede CloudFormation. Para dispositivos sin PKI, hay un mapaPskscon identidad y clave base64 por cliente, pensado para leerse desde AWS Secrets Manager y no hardcodearse en la plantilla. - Protección contra amplificación. El flag
RequireCookiesobliga al intercambio de cookies DTLS antes del handshake completo, confirmando que el cliente puede recibir paquetes en la dirección que declara. Es la misma defensa que usa el propio estándar DTLS para mitigar ataques de reflexión y se recomienda para endpoints públicos. - Resumption y 0-RTT. Los clientes DTLS 1.3 reciben un session ticket cifrado tras el handshake y, si
AllowEarlyDataestá activo, pueden enviar datos de aplicación en el primer vuelo. Proxylity aplica un filtro anti-replay compartido configurable conEarlyDataWindowSeconds(por defecto 3600 segundos, hasta 604800, una semana). Solo debe habilitarse para operaciones idempotentes: telemetría, sí; comandos únicos o financieros, no. - Connection IDs de DTLS 1.2. Los clientes que negocian CID pueden reanudar la sesión tras un cambio de NAT o de red sin repetir handshake, lo que ahorra radio, cómputo criptográfico y latencia en dispositivos IoT que duermen y migran entre redes.
El Listener se declara como Custom::ProxylityUdpGatewayListener en CloudFormation con Protocols: [dtls] y no puede mezclarse con UDP plano o WireGuard en el mismo recurso.
Qué significa esto para tu startup
El movimiento cierra una de las grietas más molestas del stack serverless en AWS. API Gateway se centra en HTTP/WebSocket y AWS lanzó Lambda en 2014 (AWS Serverless Application Repository explained, TechTarget); sin embargo, UDP cifrado seguía obligando a operar infraestructura propia. Para un equipo pequeño, eso son servidores que parchear, certificados que rotar y NAT que mantener despierto 24/7.
Tres impactos directos:
- IoT y telemetría sin cajas mágicas. Dispositivos DTLS-PSK pueden hablar directo contra una Lambda, sin gateway dedicado. Reduce el coste operativo por mensaje y elimina el servidor que se cae el domingo a las 3 de la mañana.
- RADIUS y AAA como producto. El repositorio público proxylity/examples/radius muestra cómo autenticar RADIUS sobre UDP, WireGuard o DTLS contra el mismo backend. Si tu startup vende acceso a WiFi, VPN gestionada o autenticación para ISPs, es una base lista para reventar el time-to-market.
- Hoja de ruta hacia WebRTC Data Channels. Proxylity sitúa DTLS como el primer peldaño hacia canales de datos en navegador. Si tu producto termina en una app web con voz, vídeo o P2P, el mismo listener te deja ir de IoT al navegador sin reescribir la capa de transporte.
Acciones concretas que puedes tomar esta semana
- Audita tu tráfico UDP actual. Haz un inventario de qué servicios internos exponen UDP plano (RADIUS, DNS interno, syslog, métricas, MQTT). Cualquiera de ellos es candidato a DTLS Listener y reduce superficie de ataque sin añadir un servidor.
- Monta un piloto RADIUS o telemetría con PSK. Despliega el ejemplo de Proxylity, mueve la clave a Secrets Manager y valida latencia y throughput. Si tu volumen es de miles de mensajes por segundo por dispositivo, mide el coste de Lambda vs. tu host actual antes de migrar producción.
- Diseña tu modelo de certificados desde ya. Aunque hoy uses PSK, planifica la rotación con
CertRefreshTokeny la distribución del trust anchor. Coordinar la rotación de certificados en producción es donde la mayoría de equipos tropieza cuando saltan de prototipo a escala.
Fuentes
👥 ¿Quieres ir más allá de la noticia?
En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.
👥 Unirme a la comunidad
