Un poco de contexto:
Tengo este punto final detrás de un ALB de AWS. Hago terminación SSL en el ALB. Para mi sorpresa, cuando observé la métrica client_tlsnegotiation_error_count para el ALB, noté una cantidad sustancial de intentos de conexión fallidos debido a errores de negociación de TLS, tal vez alrededor del 5% del tráfico total, pero esta estimación podría estar equivocada por un margen sustancial. / p>
La mayoría de los clientes son una sección transversal promedio de los dispositivos móviles actuales que se usan actualmente en los Estados Unidos.
El ALB está configurado con la política TLS predeterminada que proporciona Amazon:
| ssl-enum-ciphers:
| TLSv1.0:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| compressors:
| NULL
| cipher preference: server
| TLSv1.1:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| compressors:
| NULL
| cipher preference: server
| TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| compressors:
| NULL
| cipher preference: server
|_ least strength: A
Desafortunadamente, los ALB no proporcionan registros de errores, por lo que no pude identificar directamente por qué algunos clientes están fallando en la negociación de SSL.
En su lugar, introduje la terminación SSL más profundamente en la pila, a la interfaz de Nginx, y reemplazé el ALB con un ELB simple basado en TCP. Ahora las conexiones al puerto 443 se reenvían directamente a Nginx para la negociación de SSL.
He configurado Nginx con exactamente las mismas versiones de protocolo y cifrados como ALB:
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA';
ssl_prefer_server_ciphers on;
He verificado con nmap y obtengo la misma lista ssl-enum-ciphers de Nginx.
Ahora en el registro de errores de Nginx obtengo muchas líneas como esta:
SSL_do_handshake() failed (SSL: error:140A1175:SSL routines:ssl_bytes_to_cipher_list:inappropriate fallback) while SSL handshaking
Todavía no es muy informativo, así que ejecuté tcpdump en el puerto 443 en las instancias de Nginx. Como se esperaba, hay una cantidad de errores de SSL como este:
Secure Sockets Layer
TLSv1 Record Layer: Alert (Level: Fatal, Description: Inappropriate Fallback)
Content Type: Alert (21)
Version: TLS 1.0 (0x0301)
Length: 2
Alert Message
Level: Fatal (2)
Description: Inappropriate Fallback (86)
En esa misma secuencia TCP hay este paquete de saludo del cliente:
Secure Sockets Layer
TLSv1 Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 165
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 161
Version: TLS 1.0 (0x0301)
Random
GMT Unix Time: Jun 7, 2050 12:50:05.000000000 PST
Random Bytes: da03ff7045a5f76e78edf61c097c75e4e141df6649ef1861...
Session ID Length: 0
Cipher Suites Length: 28
Cipher Suites (14 suites)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_RC4_128_SHA (0xc007)
Cipher Suite: TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
Cipher Suite: TLS_FALLBACK_SCSV (0x5600)
Compression Methods Length: 1
Compression Methods (1 method)
Compression Method: null (0)
Extensions Length: 92
Extension: renegotiation_info
Type: renegotiation_info (0xff01)
Length: 1
Renegotiation Info extension
Renegotiation info extension length: 0
Extension: server_name
Type: server_name (0x0000)
Length: 27
Server Name Indication extension
Server Name list length: 25
Server Name Type: host_name (0)
Server Name length: 22
Server Name: [REDACTED]
Extension: Extended Master Secret
Type: Extended Master Secret (0x0017)
Length: 0
Extension: SessionTicket TLS
Type: SessionTicket TLS (0x0023)
Length: 0
Data (0 bytes)
Extension: Application Layer Protocol Negotiation
Type: Application Layer Protocol Negotiation (0x0010)
Length: 26
ALPN Extension Length: 24
ALPN Protocol
ALPN string length: 5
ALPN Next Protocol: h2-16
ALPN string length: 8
ALPN Next Protocol: spdy/3.1
ALPN string length: 8
ALPN Next Protocol: http/1.1
Extension: ec_point_formats
Type: ec_point_formats (0x000b)
Length: 2
EC point formats Length: 1
Elliptic curves point formats (1)
EC point format: uncompressed (0)
Extension: elliptic_curves
Type: elliptic_curves (0x000a)
Length: 8
Elliptic Curves Length: 6
Elliptic curves (3 curves)
Elliptic curve: secp256r1 (0x0017)
Elliptic curve: secp384r1 (0x0018)
Elliptic curve: secp521r1 (0x0019)
Es un poco desconcertante porque el intercambio de mensajes criptográficos utiliza TLS 1.0, que el servidor definitivamente admite, y el cliente también debería ser compatible.
He visto discusiones en línea que dicen que la presencia de la suite de cifrado TLS_FALLBACK_SCSV es una indicación de que esta conexión fallida está relacionada con las medidas de seguridad anti-POODLE, y es probable que la comunicación se vuelva a intentar. ¿Es eso correcto?
En su mayor parte, lo que estoy tratando de hacer es encontrar las respuestas a estas preguntas:
-
¿Esto es malo? ¿Si es así por qué? (¿Cuáles son las cosas que necesitan los clientes que el punto final no proporciona)?
-
Si no está mal, ¿por qué obtenemos este flujo constante de errores SSL?
Es un poco difícil buscar el archivo de captura e intentar correlacionar el protocolo de enlace SSL fallido con otras conexiones exitosas, ya que el ELB enmascara las IP de origen. Puede haber una forma de confiar en el encabezado del protocolo PROXY para identificar las IP, pero tendré que averiguar cómo hacerlo.