Si hago clic en el pequeño icono de candado en Chrome, dice que el sitio en cuestión está usando TLS v1. También verifiqué utilizando openssl y pude acceder al sitio utilizando TLS1, SSL2 y SSL3. Por lo que entiendo SSL2 no es seguro. En base a esto, parece que el sitio podría ser golpeado usando cualquiera de los tres.
¿Qué determina la versión de SSL / TLS que se utilizará al acceder a un sitio seguro desde un navegador web?
Como dice @Terry, el cliente sugiere , el servidor elige . Hay detalles:
El formato genérico del primer mensaje del cliente (el ClientHello ) indica la versión más alta admitida, y implícitamente afirma que todas las versiones anteriores son compatibles, lo cual no es necesariamente cierto. Por ejemplo, si el cliente admite TLS 1.2, indicará "max version: 1.2". Pero el servidor puede entonces elegir usar una versión anterior (por ejemplo, TLS 1.0), que el cliente no necesariamente quiere usar.
Los clientes modernos han tomado la costumbre de intentarlo varias veces. Por ejemplo, un cliente puede enviar primero un ClientHello indicando "TLS 1.2", y, si algo (algo) falla, lo intenta de nuevo con un ClientHello indicando "TLS 1.0". Los clientes hacen eso porque hay servidores TLS no conformes y mal implementados que pueden hacer TLS 1.0 pero rechazan los mensajes ClientHello que contienen "TLS 1.2".
Una consecuencia divertida es que un atacante activo podría forzar a un cliente y servidor a usar una versión anterior (por ejemplo, TLS 1.0) incluso cuando ambos admiten una versión de protocolo más reciente, cerrando por la fuerza la conexión inicial. Esto se llama un "ataque de reversión de versión". No es crítico siempre que el cliente y el servidor nunca acepten usar una versión de protocolo definitivamente débil (y TLS 1.0 todavía sea razonablemente sólido). Sin embargo, esto implica que un cliente y un servidor no pueden tener una garantía de que están usando la "mejor" versión de protocolo posible, siempre que el cliente implemente una política de "intentar nuevamente" (si el cliente no implementó dicho "intento de nuevo", entonces el ataque de retroceso se evitaría, pero algunos sitios web serían aparentemente inaccesibles).
El mensaje ClientHello para SSL 2.0 tiene un formato muy distinto. Cuando un cliente desea admitir tanto SSL 2.0 como algunas versiones posteriores, debe enviar un ClientHello especial que sigue el formato SSL 2.0 y especifica que "por cierto, también conozco SSL 3.0 y TLS 1.0". Esto se describe en el apéndice E de RFC 2246 . Los clientes SSL modernos (navegadores web) ya no lo hacen (creo que IE 6.0 todavía lo hizo, pero no IE 7.0).
RFC 4346 (TLS 1.1) especifica que dichos mensajes en formato SSLv2 ClientHello serán " eliminado "en algún momento y debe evitarse. RFC 5246 (TLS 1.2) indica más claramente que los clientes NO DEBEN admitir SSL 2.0, y por lo tanto no deberían tener motivo para enviar dichos mensajes ClientHello . RFC 6176 ahora prohíbe SSL 2.0 en total.
Ahora, un RFC no es una ley: no vas a la cárcel porque no admites ningún RFC en particular. Sin embargo, el RFC sigue brindando orientación y, por lo tanto, ilustra de alguna manera cuál será el estado de las cosas en el futuro cercano (o lejano).
En la práctica:
ClientHello mensajes, y se conectarán con SSL 3.0, TLS 1.0, TLS 1.1 o TLS 1.2, dependiendo de lo que el servidor parezca admitir (pero, debido a la "prueba de nuevo "política, un atacante activo puede imponer una versión anterior a una versión anterior. ClientHello , siempre que ese mensaje ClientHello sea un SSLv3 + ClientHello disfrazado. Aún desea desactivar el soporte SSL 2.0 en su servidor (no necesariamente el formato SSLv2 ClientHello , sino el soporte SSL 2.0 real), aunque solo sea para relaciones públicas.
Deberías leer sobre el proceso de reconocimiento de TLS.
Para resumir brevemente, el cliente (que en este caso es el navegador) envía un mensaje ClientHello al servidor. Este contiene la versión TLS máxima que admite, así como una lista de conjuntos de cifrado que admite en orden de preferencia. El servidor decide qué versión de TLS y la suite de cifrado desea utilizar para la conexión TLS e informa al cliente respondiendo con un ServerHello . Lo ideal sería seleccionar la versión TLS más alta y el conjunto de cifrado más sólido, pero la especificación TLS no lo garantiza. El servidor es libre de usar lo que quiera de la lista provista por el cliente.
Cuando un cliente desea enviar datos a un servidor utilizando SSL / TLS, primero debe pasar por un protocolo de enlace para autenticarse con el servidor. Este handshake comienza con el "ClientHello", donde el cliente envía al servidor una versión de SSL o TLS que admite, los cifrados admitidos y otros datos de la sesión. En versiones anteriores de SSL (versión 2), fue posible interceptar este paquete de intercambio y modificar la lista de cifrados admitidos para que solo contenga cifrados débiles. Esto ya no es posible ya que SSLv3 utiliza un hash en la parte final del protocolo de enlace, donde el hash del cliente y del servidor compara los mensajes enviados y recibidos.
Todos los navegadores modernos admiten SSLv3 hasta TLSv1.2, pero utilizarán la versión más alta admitida por un servidor. Un intermediario no puede modificar directamente los paquetes enviados en el apretón de manos, pero un intermediario puede interceptar y eliminar ciertos paquetes. Al engañar al navegador para que piense que el servidor no admite una versión dada de SSL / TLS, un atacante puede degradar la versión negociada. Puede ver cómo se hace visitando la publicación reciente de Praetorian : Ataque de downgrade del protocolo TLS del hombre en el medio
¿Por qué alejarse de SSLv3 ahora?
Si bien SSLv3 incluyó mitigaciones especiales para evitar ataques de degradación del protocolo, no es necesariamente el protocolo ideal para usar. SSLv3 tiene diferencias criptográficas significativas, lo que podría dar lugar a debilidades que demuestren aún más por qué TLSv1.2 debería ser el estándar actual. Los cifrados y los cifrados de autenticación acordados, así como los mecanismos de intercambio de claves, difirieron significativamente en nuestras pruebas de degradación de protocolo. En el ejemplo anterior, TLSv1.2 usa criptografía de curva elíptica (ECC) junto con el modo de contador para AES, mientras que SSLv3 usa el cifrado RC4 más antiguo y RSA.
Algunos pueden preguntar por qué esto es necesario. En su charla de Black Hat de 2013, Alex Stamos habló sobre el estado actual y el futuro de la criptografía. Argumentó que uno de los peligros radica en la posibilidad de romper claves antiguas o mecanismos de intercambio de claves en algún momento en el futuro. En el caso de RSA, los criptógrafos y matemáticos han logrado avances significativos en el problema de la factorización. Diffie-Hellman (DH) se basa en el problema del logaritmo discreto para la seguridad criptográfica, y aunque no existe un algoritmo eficiente utilizado para calcular registros discretos, el tiempo de ejecución de los algoritmos de logaritmo discreto ha disminuido significativamente en el último año. Como comentó Stamos, una vez que RSA o DH falla, la firma del código se interrumpirá y los ataques a SSL / TLS serán muy frecuentes.
En resumen, un ataque activo en una conexión puede resultar en una menor seguridad criptográfica. Los clientes y servidores pueden evitar que esto suceda si solo se admiten versiones más recientes de TLS. Además, los clientes deben responder correctamente a los apretones de manos fallidos. Actualmente, muchos navegadores optan por la interoperabilidad sobre la seguridad, lo que hace factibles los ataques de degradación del protocolo. Estos cambios requerirán tiempo y esfuerzo significativos. Los navegadores tendrían que volver a implementar aspectos de cómo manejan los apretones de manos. La compatibilidad hacia atrás puede romperse en algunos casos. Sin embargo, eventualmente tendremos que requerir el uso de versiones más recientes de TLS compatibles con ECC. ¿Por qué no hacer el empuje ahora y prevenir futuros ataques?
Lea otras preguntas en las etiquetas web-application tls