¿Qué tan implementado es TLS con cifrado ECDHE?

7

Microsoft implementó un parche para Windows 2012 R2 y Windows 8.1 que agrega los siguientes cifrados.

Cipher suite                      Exchange  Encryption  Hash
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384     DH  AES         SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256     DH  AES         SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384         RSA AES         SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256         RSA AES         SHA256

Falta ECDHE (note el primer conjunto de letras en el nombre del cifrado después de TLS _) *. Los refunfuños sobre esta falta de soporte de ECDHE también se mencionan en el CERT hilo del foro

Pregunta

  • ¿Hay alguna encuesta TLS que escanee el soporte de cifrado TLS en los sitios web para ECDHE?
  • ¿Qué tan ampliamente soportado es ECDHE en el cliente?

Según el historial de Microsoft, es posible que no prioricen el soporte de ECDHE hasta que sea ampliamente utilizado por los servidores o los navegadores web. Espero utilizar esta información para estimar si / cuando MSFT puede incluir dicho soporte en SChannel.

* Aparte: ¿por qué quiero ECDHE? Porque es más rápido.

    
pregunta random65537 05.06.2014 - 19:37
fuente

4 respuestas

5

El año pasado (mayo de 2013), realicé un experimento contactando servidores SSL al azar: me estaba conectando al puerto 443 de direcciones IPv4 aleatorias y, si recibía una respuesta, mi cliente participó en una serie de apretones de manos abortados para averiguar qué paquetes de cifrado eran realmente compatibles con el servidor. Probé unos cuantos millones de direcciones y encontré unos 13000 servidores que hablaban SSL / TLS a través del puerto 443.

De estos, aproximadamente 7.5% admitía un conjunto de cifrado ECDHE.

Cuidado con los detalles:

  • Esto fue hace un año. Las cosas pueden haber cambiado desde entonces.
  • Mi cliente no envió ninguna extensión reclamando soporte para ninguna curva elíptica específica. Sólo reclamaba el apoyo "genérico" de ECDHE. Esto puede haber evitado que algunos servidores intenten los conjuntos de cifrado ECDHE. En ese sentido, mi figura puede ser una subestimación.
  • Un corolario es que "el soporte ECDHE" no se puede declarar de forma realmente genérica. Muchas implementaciones de ECC están limitadas a algunos tipos de curvas, la mayoría de las cuales pueden procesar solo un par de curvas específicas (las curvas NIST estándar P-256 y P-384, llamadas "suite B") .
  • Hay varias formas de tomar medidas de muestreo. Mi código estaba usando direcciones IPv4 aleatorias, por lo que no solo encontraba sitios web, sino también muchos sistemas como módems / enrutadores domésticos. Encuestas SSL existentes publicadas, como que una usa los "1 millones de servidores web más importantes" de Alexa ; esto favorece una noción de "importancia económica" que puede o no corresponder a lo que usted desea. Concentrarse en los "sitios principales" elimina los servidores SSL no mantenidos y, de hecho, los módems y enrutadores domésticos, lo que debería aumentar el soporte de ECDHE. De hecho, esa encuesta (desde principios de 2014) encuentra que un enorme 21.6% de estos "sitios principales" son compatibles con las suites de cifrado ECDHE.

Como nota al margen, debo decir que en la mayoría de los casos, es improbable que el aumento de rendimiento implícito por ECDHE (sobre DHE) sea relevante. Se necesitan muchas conexiones por segundo a un servidor web básico para ver la diferencia (estamos hablando de cientos por segundo aquí). Otro punto importante es que obtiene el aumento de rendimiento al admitir los conjuntos de cifrado ECDHE, y configurar su cliente o servidor para que prefiera dichos conjuntos de cifrado cuando sea posible; no es necesario que deje de admitir conjuntos de cifrado que no sean ECC para obtener ese supuesto bono de velocidad. En ese sentido, la decisión de habilitar los conjuntos de cifrado ECDHE no necesita estar respaldada por cifras sobre quién los apoya y quién no; solo puedes activarlos y usarlos de manera oportunista.

    
respondido por el Thomas Pornin 23.06.2014 - 17:47
fuente
2

Lo extraño es que Microsoft ofrece GCM y ECDHE, pero no ambos junto con la certificación RSA. Los únicos cifrados AES-GCM con ECDHE están vinculados a ECDSA. De lo contrario, GCM solo está disponible con DHE_RSA.

La lista se puede encontrar en KB2929781 o en La herramienta IISCrypto lo muestra. IE11 parece tener las mismas restricciones.

Realmente desearía que implementaran TLS_ECDHE_RSA_WITH_AS_Vac_CAP_SHA256 y TLS_ECDHE_RSA_WITH_AITH_AES_256_GPM_SHA384Pacces en el campo de juego de la naturaleza, como por ejemplo GWS hace).

    
respondido por el eckes 04.11.2014 - 23:58
fuente
1

EDITAR: hay una nueva encuesta de qualys para clientes:

Capacidades del agente de usuario

Se necesita TLS 1.2 para ECDHE (afaik), pero tener habilitado TLS 1.2 no significa necesariamente que ECDHE esté disponible.

para obtener una descripción general de la configuración ssl de alexa top 1 millón es posible que desee consultar ssl pulse @ qualys

  

SSL Pulse es un panel de control continuo y global para monitorear la calidad del soporte SSL en el millón de sitios web principales. SSL Pulse se basa en la tecnología de evaluación de SSL Labs, que se centra en auditar el ecosistema de SSL, crear conciencia y proporcionar herramientas y documentación a los propietarios de sitios web para que puedan mejorar sus implementaciones de SSL

para clientes: todo lo que encontré (y conozco): la mayoría de los navegadores modernos implementan ECDHE, lo que significa probablemente chrome y firefox y las versiones más recientes de safari y es decir (pero no estoy seguro).

también debe ofrecer DHE para habilitar PFS en navegadores más antiguos. La versión TLS utilizada puede depender de la versión de sistema operativo utilizada.

    
respondido por el that guy from over there 05.06.2014 - 19:47
fuente
0

Algunas estadísticas de telemetría de Firefox . El enlace apunta a las estadísticas de uso para la variable SSL_CIPHER_SUITE_FULL para firefox 32, mostrando qué suite se usa realmente para la conexión entre el lanzamiento de firefox 32 (principios de septiembre de 2014) y hoy (principios de noviembre de 2014). Sus valores se definen en el código fuente de Firefox . Hervidos tenemos:

  • 48% de conexiones usando TLS_RSA_*

  • 45% de conexiones usando TLS_ECDHE_*

  • 7% de conexiones usando TLS_DHE_*

respondido por el user10008 05.11.2014 - 00:34
fuente

Lea otras preguntas en las etiquetas