General

SSL (y su sucesor, TLS ) es un protocolo que opera directamente sobre TCP (aunque también hay implementaciones para protocolos basados en datagramas como UDP). De esta manera, los protocolos en capas superiores (como HTTP) se pueden dejar sin cambios mientras que s hasta proporcionar una conexión segura. Debajo de la capa SSL, HTTP es idéntico a HTTPS.

Cuando usa SSL / TLS correctamente, todo lo que un atacante puede ver en el cable es a qué IP y puerto está conectado, aproximadamente la cantidad de datos que está enviando y qué cifrado y compresión se utilizan. También puede terminar la conexión, pero ambas partes sabrán que la conexión ha sido interrumpida por un tercero.

En el uso típico, el atacante también podrá averiguar a qué nombre de host se está conectando (pero no el resto de la URL): aunque HTTPS en sí mismo no expone el nombre de host, su navegador normalmente necesitará realizar una solicitud de DNS primero para averiguar a qué dirección IP enviar la solicitud.

Alto -descripción del nivel del protocolo

Después de construir una conexión TCP, el cliente inicia el protocolo de enlace SSL. El cliente (que puede ser un navegador o cualquier otro programa como Windows Update o PuTTY) envía una serie de especificaciones:

• qué versión de SSL / TLS está ejecutando,
• qué ciphersuites quiere utilizar, y
• qué métodos de compresión que quiere usar.

El servidor identifica la versión de SSL / TLS más alta admitida tanto por él como por el cliente, elige un conjunto de cifrado de una de las opciones del cliente (si admite una) y, opcionalmente, elige un método de compresión.

Una vez realizada la configuración básica, el servidor envía su certificado. Este certificado debe ser de confianza para el propio cliente o una parte en la que el cliente confíe. Por ejemplo, si el cliente confía en GeoTrust, entonces el cliente puede confiar en el certificado de Google.com porque GeoTrust certificado criptográficamente de Google.

Después de verificar el certificado y estar seguro de que este servidor realmente es quien dice ser (y no un hombre en el medio), se intercambia una clave. Esta puede ser una clave pública, una » PreMasterSecret » o simplemente nada, según el conjunto de cifrado elegido. Ahora, tanto el servidor como el cliente pueden calcular la clave para cifrado simétrico ^{¿por qué no PKE?} . El cliente le dice al servidor que a partir de ahora, todas las comunicaciones serán cifradas, y envía un mensaje encriptado y autenticado al servidor.

El servidor verifica que la MAC (utilizada para la autenticación) sea correcta y que el mensaje se pueda descifrar correctamente. Luego devuelve un mensaje, que el cliente verifica como bien.

El apretón de manos ha finalizado y los dos hosts pueden comunicarse de forma segura. Para obtener más información, consulte technet.microsoft.com/en-us/library/cc785811 y en.wikipedia .org / wiki / Secure_Sockets_Layer .

Para cerrar la conexión, se utiliza una «alerta» close_notify. Si un atacante intenta terminar la conexión terminando la conexión TCP (inyectando un paquete FIN), ambas partes sabrán que la conexión se terminó incorrectamente. Sin embargo, la conexión no puede verse comprometida por esto, simplemente interrumpida.

Algunos detalles más

¿Por qué puede confiar en Google.com confiando en GeoTrust?

Un sitio web quiere comunicarse con usted de forma segura. Para demostrar su identidad y asegurarse de que no es un atacante, debe tener la « clave pública del servidor. Sin embargo, difícilmente puede almacenar todas las claves desde todos los sitios web del mundo, la base de datos sería enorme y las actualizaciones tendrían que ejecutarse cada hora.

La solución para esto son las Autoridades de certificación, o CA, para abreviar.Cuando instaló su sistema operativo o navegador, probablemente venía con una lista de CA confiables. Esta lista se puede modificar a voluntad; puede eliminar en quienes no confía, agregar a otros o incluso crear su propia CA (aunque será el único que confíe en esta CA, por lo que no es de mucha utilidad para un sitio web público). En esta lista de CA, la clave pública de la CA también se almacena.

Cuando el servidor de Google le envía su certificado, también menciona que está firmado por GeoTrust. Si confía en GeoTrust, puede verificar (utilizando la clave pública de GeoTrust) que GeoTrust realmente firmó el certificado del servidor. Para firmar un certificado usted mismo, necesita la clave privada, que solo GeoTrust conoce. De esta manera, un atacante no puede firmar un certificado por sí mismo y afirmar incorrectamente que es Google.com. Cuando el certificado ha sido modificado incluso por un bit, el signo será incorrecto y el cliente lo rechazará.

Entonces, si conozco la clave pública, el servidor puede probar su identidad?

Sí. Normalmente, la clave pública se cifra y la clave privada se descifra. Cifre un mensaje con la clave pública del servidor, envíelo, y si el servidor puede repetir el mensaje original, simplemente demostró que obtuvo la clave privada sin revelar la clave.

Por eso Es muy importante poder confiar en la clave pública: cualquiera puede generar un par de claves pública / privada, también un atacante. ¡No querrás terminar usando la clave pública de un atacante!

Si una de las CA en las que confía está comprometida, un atacante puede usar la clave privada robada para firmar un certificado para cualquier sitio web que desee. Cuando el atacante puede enviar un certificado falsificado a su cliente, firmado por él mismo con la clave privada de una CA en la que usted confía, su cliente no sabe que la clave pública es falsa, firmada con una clave privada robada.

¡Pero una CA puede hacerme confiar en cualquier servidor que quieran!

Sí, y ahí es donde viene la confianza Debe confiar en la CA para que no haga certificados como les plazca. Sin embargo, cuando organizaciones como Microsoft, Apple y Mozilla confían en una CA, la CA debe tener auditorías; otra organización las revisa periódicamente para asegurarse de que todo sigue funcionando de acuerdo con a las reglas.

La emisión de un certificado se realiza si, y solo si, el registrante puede demostrar que es propietario del dominio para el que se emite el certificado.

¿Qué es esta MAC para la autenticación de mensajes?

Cada mensaje está firmado con un llamado Código de autenticación de mensajes , o MAC para abreviar. Si aceptamos una clave y un cifrado hash, puede verificar que mi mensaje proviene de mí y yo puedo verificar que su mensaje proviene de usted.

Por ejemplo, con la clave » la grapa correcta de la batería del caballo » y el mensaje » ejemplo «, Puedo calcular el MAC » 58393 «. Cuando te envío este mensaje con el MAC (ya conoces la clave), puedes realizar el mismo cálculo y hacer coincidir el MAC calculado con el MAC que te envié.

Un atacante puede modificar el mensaje pero no conoce la clave. No puede calcular la MAC correcta y sabrá que el mensaje no es auténtico.

Al incluir un número de secuencia al calcular la MAC, puede eliminar la reproducción ataques . SSL hace esto.

Dijiste que el cliente envía una clave, que luego se usa para configurar cifrado simétrico. ¿Qué impide que un atacante la use?

La clave pública del servidor sí. Dado que hemos verificado que la clave pública realmente pertenece al servidor y a nadie más, puede cifrar la clave usando la clave pública. Cuando el servidor la recibe, puede descifrarla con la clave privada. Cuando alguien más la recibe, no puede descifrarla.

Por eso también importa el tamaño de la clave: Cuanto mayor sea la clave pública y privada, más difícil será descifrar la clave que el cliente envía al servidor.

Cómo descifrar SSL

En resumen :

• Intente si el usuario ignora las advertencias del certificado;
• La aplicación puede cargar datos desde un canal no cifrado (por ejemplo, HTTP), que se puede manipular;
• Una página de inicio de sesión desprotegida que se envía a HTTPS puede modificarse para que se envíe a HTTP;
• Las aplicaciones no parcheadas pueden ser vulnerable a exploits como BEAST y CRIME;
• Recurrir a otros métodos como h como un ataque físico;
• Explote canales laterales como la longitud del mensaje y el tiempo tomado para formar el mensaje;
• Espere ataques cuánticos .

Ver también: Un esquema con muchos vectores de ataque contra SSL por Ivan Ristic ^(png)

En detalle:

No existe una simple y directa camino; SSL es seguro cuando se hace correctamente. Sin embargo, un atacante puede intentarlo si el usuario ignora las advertencias de certificados , lo que rompería la seguridad instantáneamente. Cuando un usuario hace esto, el atacante no necesita una clave privada de una CA para falsificar un certificado, simplemente tiene que enviar un certificado propio.

Otra forma sería mediante una falla en el aplicación (del lado del servidor o del cliente). Un ejemplo sencillo son los sitios web: si uno de los recursos utilizados por el sitio web (como una imagen o un script) se carga a través de HTTP, la confidencialidad ya no se puede garantizar. Aunque los navegadores no envíe el encabezado HTTP Referer cuando solicite recursos no seguros desde una página segura ( source ), aún es posible que alguien que esté escuchando el tráfico adivine dónde «visitando desde; por ejemplo, si saben que las imágenes X, Y y Z se utilizan en una página, pueden adivinar que estás visitando esa página cuando vean que tu navegador solicita esas tres imágenes a la vez. Además, al cargar Javascript, toda la página puede verse comprometida. Un atacante puede ejecutar cualquier script en la página, modificando, por ejemplo, a quién se destinará la transacción bancaria.

Cuando esto sucede (se carga un recurso a través de HTTP), el navegador muestra una advertencia de contenido mixto: Chrome , Firefox , Internet Explorer 9

Otro truco para HTTP es cuando la página de inicio de sesión no está protegida y se envía a una página https. » Genial, » el desarrollador probablemente pensó, » ahora ahorro la carga del servidor y la contraseña aún se envía cifrada. » El problema es sslstrip , una herramienta que modifica la página de inicio de sesión insegura para que envía en algún lugar para que el atacante pueda leerlo.

También ha habido varios ataques en los últimos años, como la vulnerabilidad de renegociación TLS , sslsniff , BEAST y, muy recientemente, DELITO . Sin embargo, todos los navegadores comunes están protegidos contra todos estos ataques, por lo que estas vulnerabilidades no representan ningún riesgo si está ejecutando un navegador actualizado.

Por último, pero no menos importante, puede recurrir a otros métodos para obtener la información que SSL le niega obtener. Si ya puede ver y alterar la conexión del usuario, puede que no sea tan difícil reemplazar una de sus descargas .exe con un keylogger, o simplemente atacar físicamente a esa persona. La criptografía puede ser bastante segura, pero los humanos y el error humano sigue siendo un factor débil. Según este documento de Verizon , el 10% de las violaciones de datos involucraron ataques físicos (consulte la página 3), por lo que » Ciertamente es algo a tener en cuenta.

Comentarios

• Me interesaría un poco más de explicación para » se intercambia una clave » por la clave simétrica. ¿Cómo es posible que alguien con un rastreador de paquetes no pueda acceder?
• @Yehosef ¡Buena pregunta! Olvidé explicar eso en mi respuesta. Mirando a su alrededor, resulta que en realidad hay una pregunta dedicada a esto: security.stackexchange.com/q/6290/10863
• @ Iwazaru Todos los CA hacen esto desde el primer día. El objetivo de un certificado es proporcionar la clave pública para un dominio determinado y el objetivo de firmarlo para demostrar que realmente es la clave correcta para el dominio. Deje que ‘ s Encrypt esté haciendo exactamente lo que debería hacer: verificar que usted es propietario del dominio y firmar su certificado (con su clave) si puede probarlo. Ahora todos los que confían en Let ‘ s Encrypt, que es prácticamente todos los navegadores, confiarán en ese certificado.
• Er, no. De hecho, TLS se acaba de implementar sobre TCP.
• Encontré este proceso gráfico de protocolo de enlace SSL , muy claro.

Dado que el concepto general de SSL ya se ha cubierto en algunas otras preguntas (por ejemplo, este y aquél ), esta vez iré por los detalles. Los detalles son importantes. Esta respuesta va a ser algo detallada.

Historial

SSL es un protocolo con una larga trayectoria y varias versiones.Los primeros prototipos provienen de Netscape cuando estaban desarrollando las primeras versiones de su navegador insignia, Netscape Navigator (este navegador eliminó Mosaic en los primeros tiempos de las guerras de navegadores, que todavía están en auge, aunque con nuevos competidores). La versión 1 nunca se ha hecho pública, por lo que no sabemos cómo se veía. La versión 2 de SSL se describe en un borrador que se puede leer allí ; tiene una serie de debilidades, algunas de ellas bastante serias, por lo que está en desuso y las implementaciones de SSL / TLS más nuevas no lo admiten (mientras que las antiguas están desactivadas por defecto). No hablaré más de la versión 2 de SSL, excepto como referencia ocasional.

La versión 3 de SSL (que llamaré «SSLv3») era un protocolo mejorado que todavía funciona en la actualidad y es ampliamente compatible. Aunque sigue siendo propiedad de Netscape Communications (o de quien sea que lo posea actualmente), el protocolo se ha publicado como un «RFC histórico» ( RFC 6101 ). Mientras tanto, el protocolo se ha estandarizado, con un nuevo nombre para evitar problemas legales; el nuevo nombre es TLS .

Hasta ahora se han producido tres versiones de TLS, cada una con su RFC dedicado: TLS 1.0 , TLS 1.1 y TLS 1.2 . Son internamente muy similares entre sí y con SSLv3, hasta el punto de que una implementación puede admitir fácilmente SSLv3 y las tres versiones de TLS, siendo común al menos el 95% del código. Aún así, internamente, todas las versiones están designadas por un número de versión con el formato major.minor ; SSLv3 es entonces 3.0, mientras que las versiones TLS son, respectivamente, 3.1, 3.2 y 3.3. Por lo tanto, no es de extrañar que TLS 1.0 a veces se llame SSL 3.1 (y tampoco es incorrecto). SSL 3.0 y TLS 1.0 difieren solo en algunos detalles minuciosos. TLS 1.1 y 1.2 aún no son ampliamente compatibles, aunque hay un impulso para eso, debido a posibles debilidades (ver más abajo, para el «ataque BEAST»). SSLv3 y TLS 1.0 son compatibles «en todas partes» (incluso IE 6.0 los conoce).

Contexto

SSL tiene como objetivo proporcionar un túnel bidireccional seguro para datos arbitrarios. Considere TCP , el conocido protocolo para enviar datos a través de Internet. TCP trabaja sobre los «paquetes» IP y proporciona un túnel bidireccional para bytes; funciona para los valores de cada byte y los envía a dos flujos que pueden funcionar simultáneamente. TCP maneja el arduo trabajo de dividir los datos en paquetes, reconocerlos, volver a ensamblarlos en su orden correcto, mientras elimina los duplicados y reenvía los paquetes perdidos. Desde el punto de vista de la aplicación que usa TCP, solo hay dos flujos y los paquetes son invisibles; en particular, las transmisiones no se dividen en «mensajes» (depende de la aplicación tomar sus propias reglas de codificación si desea tener mensajes, y eso es precisamente lo que HTTP lo hace).

TCP es confiable en presencia de «accidentes», es decir, errores de transmisión debido a hardware inestable, congestión de la red, personas con teléfonos inteligentes que caminan fuera del alcance de una estación base determinada , y otros eventos no maliciosos. Sin embargo, un individuo malintencionado (el «atacante») con algún acceso al medio de transporte podría leer todos los datos transmitidos y / o alterarlos intencionalmente, y TCP no protege contra eso. SSL.

SSL asume que funciona sobre un protocolo similar a TCP, que proporciona un flujo confiable; SSL no implementa la reemisión de paquetes perdidos y cosas por el estilo. El atacante es se supone que está en el poder para interrumpir la comunicación por completo de una manera inevitable (por ejemplo, puede cortar los cables) por lo que el trabajo de SSL es:

• detectar alteraciones (el atacante no debe poder alterar los datos silenciosamente );
• garantizar la confidencialidad de los datos el atacante no debe obtener conocimiento de los datos intercambiados).

SSL cumple estos objetivos en gran medida (pero no absoluta).

Registros

SSL tiene capas y la capa inferior es el protocolo de registro . Los datos que se envían en un túnel SSL se dividen en registros . A través del cable (el socket TCP subyacente o el medio similar a TCP), un registro se ve así:

HH V1:V2 L1:L2 data

donde:

• HH es un solo byte que indica el tipo de datos en el registro.Se definen cuatro tipos: change_cipher_spec (20), alert (21), handshake (22) y application_data ( 23).
• V1: V2 es la versión del protocolo, en dos bytes. Para todas las versiones definidas actualmente, V1 tiene el valor 0x03, mientras que V2 tiene el valor 0x00 para SSLv3, 0x01 para TLS 1.0, 0x02 para TLS 1.1 y 0x03 para TLS 1.2.
• L1: L2 es la longitud de data, en bytes (la convención big-endian es utilizado: la longitud es 256 * L1 + L2). La longitud total de data no puede exceder los 18432 bytes, pero en la práctica, ni siquiera puede alcanzar ese valor.

Así que un registro tiene cinco encabezado de bytes, seguido de un máximo de 18 kB de datos. data es donde se aplican el cifrado simétrico y las comprobaciones de integridad. Cuando se emite un registro, se supone que tanto el emisor como el receptor deben acordar qué algoritmos criptográficos se aplican actualmente y con qué claves; este acuerdo se obtiene mediante el protocolo de negociación, que se describe en la siguiente sección. La compresión, si la hay, también se aplica en ese punto.

En todos los detalles, la construcción de un registro funciona así:

• Inicialmente, hay algunos bytes para transferir ; estos son datos de la aplicación o algún otro tipo de bytes. Esta carga útil consta de un máximo de 16384 bytes, pero posiblemente menos (una carga útil de longitud 0 es legal, pero resulta que a Internet Explorer 6.0 no le gusta eso en absoluto ) .
• La carga útil se comprime con cualquier algoritmo de compresión acordado actualmente. La compresión tiene estado y, por lo tanto, puede depender del contenido de registros anteriores. En la práctica, la compresión es «nula» (sin ninguna compresión) o «Desinflar» ( RFC 3749 ), a este último se le muestra actualmente cortés pero firmemente la salida puerta en el contexto web, debido al reciente ataque CRIME . La compresión tiene como objetivo acortar los datos, pero necesariamente debe expandirlos ligeramente en algunas situaciones desfavorables (debido al principio de casillero ). SSL permite una expansión de 1024 bytes como máximo. Por supuesto, la compresión nula nunca se expande (pero tampoco se acorta); Deflate se expandirá como máximo 10 bytes si la implementación es buena.
• La carga útil comprimida se protege contra alteraciones y se cifra. Si los algoritmos actuales de encriptación e integridad son «nulos», entonces este paso es una no operación. De lo contrario, se agrega una MAC , luego algo de relleno (según el algoritmo de cifrado) y el resultado se cifra. Estos pasos nuevamente inducen cierta expansión, que el estándar SSL limita a 1024 bytes adicionales (combinado con la expansión máxima del paso de compresión, esto nos lleva a los 18432 bytes, a los que debemos agregar el encabezado de 5 bytes).

El MAC es, generalmente, HMAC con una de las funciones hash habituales (principalmente MD5, SHA-1 o SHA-256) (con SSLv3, este no es el «verdadero» HMAC sino algo muy similar y, hasta donde sabemos, tan seguro como HMAC). El cifrado utilizará un cifrado de bloque en modo CBC o el cifrado de flujo RC4 . Tenga en cuenta que, en teoría, podrían emplearse otros tipos de modos o algoritmos, por ejemplo, uno de estos ingeniosos modos que combinan el cifrado y las comprobaciones de integridad; incluso hay algunos RFC para eso . Sin embargo, en la práctica, las implementaciones implementadas aún no las conocen, por lo que sí las conocen HMAC y CBC. Fundamentalmente, la MAC se calcula primero y se agrega a los datos, y el resultado se cifra. Esto es MAC-then-encrypt y en realidad no es una muy buena idea . El MAC se calcula sobre la concatenación de la carga útil (comprimida) y un número de secuencia, de modo que un atacante diligente no pueda intercambiar registros.

Handshake

El apretón de manos es un protocolo que se reproduce dentro del protocolo de grabación. Su objetivo es establecer los algoritmos y claves que se utilizarán para los registros. Consiste en mensajes . Cada mensaje de reconocimiento comienza con un encabezado de cuatro bytes, un byte que describe el tipo de mensaje, luego tres bytes para la longitud del mensaje (convención big-endian). Los sucesivos mensajes de protocolo de enlace se envían con registros etiquetados con el tipo «protocolo de enlace» (el primer byte del encabezado de cada registro tiene valor 22).

Tenga en cuenta las capas: los mensajes de protocolo de enlace, completos con cuatro- encabezado de bytes, luego se envían como registros, y cada registro también tiene su propio encabezado. Además, se pueden enviar varios mensajes de reconocimiento dentro del mismo registro, y un mensaje de reconocimiento dado se puede dividir en varios registros.Desde el punto de vista del módulo que construye los mensajes de protocolo de enlace, los «registros» son solo una secuencia en la que se pueden enviar bytes; es ajeno a la división real de esa secuencia en registros.

Apretón de manos completo

Inicialmente, el cliente y el servidor «acuerdan» el cifrado nulo sin MAC y compresión nula. Esto significa que el registro que enviarán primero se enviará como texto sin cifrar y sin protección.

El primer mensaje de un apretón de manos es un ClientHello. Es el mensaje mediante el cual el cliente manifiesta su intención de hacer algo de SSL. Tenga en cuenta que «cliente» es un papel simbólico; significa «la parte que habla primero». Sucede que en el contexto HTTPS, que es HTTP-dentro-SSL-dentro-TCP, las tres capas tienen una noción de «cliente» y «servidor», y todos están de acuerdo (el cliente TCP es también el cliente SSL y el cliente HTTP), pero eso es una especie de coincidencia.

El mensaje ClientHello contiene:

• el protocolo máximo versión que el cliente desea admitir;
• el «cliente aleatorio» (32 bytes, de los cuales se supone que 28 se generan con un generador de números criptográficamente fuerte);
• el » ID de sesión «(en caso de que el cliente desee reanudar una sesión en un apretón de manos abreviado, consulte a continuación);
• la lista de» conjuntos de cifrado «que el cliente conoce, ordenados por preferencia del cliente;
• la lista de algoritmos de compresión que el cliente conoce, ordenados por preferencia del cliente;
• algunas extensiones opcionales.

A conjunto de cifrado es un identificador simbólico de 16 bits para un conjunto de cifrado c algoritmos. Por ejemplo, el paquete de cifrado TLS_RSA_WITH_AES_128_CBC_SHA tiene el valor 0x002F y significa que «los registros utilizan cifrado HMAC / SHA-1 y AES con una clave de 128 bits, y el intercambio de claves se realiza mediante cifrado una clave aleatoria con la «clave pública RSA» del servidor.

El servidor responde al ClientHello con un ServerHello que contiene:

• la versión del protocolo que el cliente y el servidor utilizarán ;
• el «servidor aleatorio» (32 bytes, con 28 bytes aleatorios);
• el ID de sesión para esta conexión;
• el conjunto de cifrado que se utilizará;
• el algoritmo de compresión que se utilizará;
• opcionalmente, algunas extensiones.

El apretón de manos completo se ve así:

 Client Server ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data 

(Este esquema se ha copiado descaradamente del RFC.)

Vemos ClientHello y ServerHello. Luego, el servidor envía algunos otros mensajes, que dependen del conjunto de cifrado y algún otro parámetro rs:

• Certificado: el certificado del servidor, que contiene su clave pública. Más sobre eso a continuación. Este mensaje casi siempre se envía, excepto si el paquete de cifrado exige un protocolo de enlace sin un certificado.
• ServerKeyExchange: algunos valores adicionales para el intercambio de claves, si lo que hay en el certificado no es suficiente. En particular, los conjuntos de cifrado «DHE» utilizan un intercambio de claves efímero Diffie-Hellman , que requiere ese mensaje.
• CertificateRequest: un mensaje solicitando que el cliente también se identifique con un certificado propio. Este mensaje contiene la lista de nombres de anclajes de confianza (también conocidos como «certificados raíz») que el servidor utilizará para validar el certificado del cliente.
• ServerHelloDone: un mensaje de marcador (de longitud cero) que dice que el servidor ha terminado, y el cliente ahora debería hablar.

El cliente debe responder entonces con:

• Certificado: el certificado del cliente, si el servidor solicitó uno. Existen sutiles variaciones entre versiones (con SSLv3, el cliente debe omitir este mensaje si no tiene certificado; con TLS 1.0+, en la misma situación, debe enviar un Certificate mensaje con una lista vacía de certificados).
• ClientKeyExchange: la parte del cliente del intercambio de claves real (por ejemplo, algún valor aleatorio cifrado con la clave RSA del servidor).
• CertificateVerify: a firma digital calculada por el cliente sobre todos los mensajes de protocolo de enlace anteriores. Este mensaje se envía cuando el servidor solicitó un certificado de cliente y el cliente cumplió. Así es como el cliente le demuestra al servidor que realmente «posee» la clave pública que está codificada en el certificado que envió.

Luego, el cliente envía un ChangeCipherSpec mensaje, que no es un mensaje de protocolo de enlace: tiene su propio tipo de registro, por lo que se enviará en un registro propio.Su contenido es puramente simbólico (un solo byte de valor 1). Este mensaje marca el punto en el que el cliente cambia a la suite de cifrado y las claves recién negociadas. Los registros posteriores del cliente se cifrarán.

El mensaje Finalizado es una suma de comprobación criptográfica calculada sobre todos los mensajes de protocolo de enlace anteriores (tanto del cliente como del servidor). Dado que se emite después de ChangeCipherSpec, también está cubierto por la verificación de integridad y el cifrado. Cuando el servidor recibe ese mensaje y verifica su contenido, obtiene una prueba de que efectivamente ha hablado con el mismo cliente todo el tiempo. Este mensaje protege el protocolo de enlace de alteraciones (el atacante no puede modificar los mensajes de protocolo de enlace y aún así obtener el mensaje Finished correcto).

El servidor finalmente responde con su propio ChangeCipherSpec luego Finished. En ese momento, el apretón de manos finaliza y el cliente y el servidor pueden intercambiar datos de la aplicación (en registros cifrados etiquetados como tales).

Para recordar: el cliente sugiere pero el servidor elige . La suite de cifrado está en manos del servidor. Se supone que los servidores corteses deben seguir las preferencias del cliente (si es posible), pero pueden hacer lo contrario y algunos realmente lo hacen (por ejemplo, como parte de la protección contra BEAST).

Apretón de manos abreviado

En el protocolo de enlace completo, el servidor envía un «ID de sesión» (es decir, un grupo de hasta 32 bytes) al cliente. Más adelante, el cliente puede regresar y enviar el mismo ID de sesión como parte de su ClientHello. Esto significa que el cliente aún recuerda el conjunto de cifrado y las claves del protocolo de enlace anterior y le gustaría reutilizar estos parámetros. Si el servidor también recuerda el conjunto de cifrado y las claves, entonces copia ese ID de sesión específico en su ServerHello, y luego sigue el protocolo de enlace abreviado :

 Client Server ClientHello --------> ServerHello [ChangeCipherSpec] <-------- Finished [ChangeCipherSpec] Finished --------> Application Data <-------> Application Data 

El protocolo de enlace abreviado es más corto: menos mensajes, no negocio de criptografía asimétrica y, lo más importante, latencia reducida . Los navegadores web y los servidores hacen mucho eso. Un navegador web típico abrirá una conexión SSL con un apretón de manos completo, luego hará apretones de manos abreviados para todas las demás conexiones al mismo servidor: las otras conexiones que abre en paralelo, y también las conexiones posteriores al mismo servidor. De hecho, los servidores web típicos cerrarán las conexiones después de 15 segundos de inactividad, pero recordarán sesiones (el conjunto de cifrado y las claves) durante mucho más tiempo (posiblemente durante horas o incluso días).

Intercambio de claves

Hay varios algoritmos de intercambio de claves que SSL puede utilizar. Esto lo especifica el conjunto de cifrado; cada algoritmo de intercambio de claves funciona con algunos tipos de claves públicas de servidor. Los algoritmos de intercambio de claves más comunes son:

• RSA: la clave del servidor es de tipo RSA. El cliente genera un valor aleatorio (el » secreto pre-maestro «de 48 bytes, de los cuales 46 son aleatorios) y lo cifra con la clave pública del servidor. No hay ServerKeyExchange.
• DHE_RSA: la clave del servidor es de tipo RSA, pero se usa solo para firma. El intercambio de claves real utiliza Diffie-Hellman. El servidor envía un mensaje ServerKeyExchange que contiene los parámetros DH (módulo, generador) y una clave pública DH recién generada; además, el servidor firma este mensaje. El cliente responderá con un mensaje ClientKeyExchange que también contiene una clave pública DH recién generada. El DH proporciona el «secreto pre-maestro «.
• DHE_DSS: como DHE_RSA, pero el servidor tiene una clave DSS (» DSS «también se conoce como «DSA» ). DSS es un algoritmo de solo firma.

Los algoritmos de intercambio de claves menos utilizados incluyen:

• DH: la clave del servidor es de tipo Diffie-Hellman (estamos hablando de un certificado que contiene un DH clave). Esto solía ser «popular» de manera administrativa (el gobierno federal de los Estados Unidos ordenó su uso) cuando la patente RSA aún estaba activa (esto fue durante el siglo anterior). A pesar del impulso burocrático, nunca se implementó tan ampliamente como RSA.
• DH_anon: como las suites DHE, pero sin la firma del servidor. Este es un conjunto de cifrado sin certificado. Por construcción, es vulnerable a ataques Man-in-the-Middle , por lo que rara vez se habilita.
• PSK: claves previamente compartidas conjuntos de cifrado. El intercambio de claves solo simétrico, basado en un secreto compartido preestablecido.
• SRP: la aplicación del protocolo SRP que es un Protocolo de intercambio de claves autenticadas con contraseña . El cliente y el servidor se autentican entre sí con respecto a un secreto compartido, que puede ser una contraseña de baja entropía (mientras que PSK requiere un secreto compartido de alta entropía). Muy ingenioso. Todavía no es ampliamente compatible.
• Una clave RSA efímera: como DHE pero con un par de claves RSA recién generado. Dado que generar claves RSA es costoso, esta no es una opción popular y se especificó solo como parte de los conjuntos de cifrado de «exportación» que cumplían con las regulaciones de exportación de EE. UU. Anteriores a 2000 sobre criptografía (es decir, claves RSA de 512 bits como máximo). Nadie hace eso hoy en día.
• Variantes de los algoritmos DH* con curvas elípticas . Muy a la moda. Debería volverse común en el futuro.

Certificados y autenticación

Los certificados digitales son recipientes para claves asimétricas. Están destinados a resolver la distribución de claves. Es decir, el cliente quiere usar la clave pública del servidor. El atacante intentará que el cliente use la clave pública del atacante . Por lo tanto, el cliente debe tener una forma de asegurarse de que está usando la clave correcta.

Se supone que SSL usa X.509 . Este es un estándar para certificados. Cada certificado está firmado por una autoridad de certificación . La idea es que el cliente conozca inherentemente las claves públicas de un puñado de CA (estos son los «anclajes de confianza» o «certificados raíz»). Con estas claves, el cliente puede verificar la firma calculada por una CA sobre un certificado que ha sido emitido al servidor. Este proceso se puede extender de forma recursiva: una CA puede emitir un certificado para otra CA (es decir, firmar la estructura del certificado que contiene el nombre y la clave de la otra CA). Una cadena de certificados que comienza con una CA raíz y termina con el certificado del servidor, con certificados de CA intermedios en el medio, cada certificado se firma con relación a la clave pública que está codificada en el certificado anterior, se llama, sin imaginación, a cadena de certificados .

Por lo tanto, se supone que el cliente debe hacer lo siguiente:

• Obtener una cadena de certificados que termine con el certificado del servidor. Se supone que el Certificate mensaje del servidor contiene, precisamente, dicha cadena.
• Validar la cadena, es decir, verificar todos los firmas y nombres y los diversos bits X.509. Además, el cliente debe comprobar el estado de revocación de todos los certificados de la cadena, que es complejo y pesado (los navegadores web ahora lo hacen, más o menos, pero es un desarrollo reciente).
• Verifique que el nombre del servidor deseado esté escrito en el certificado del servidor. Debido a que el cliente no solo desea usar una clave pública validada, también quiere usar la clave pública de un servidor específico . Consulte RFC 2818 para obtener detalles sobre cómo se hace esto en un contexto HTTPS .

El modelo de certificación con certificados X.509 a menudo ha sido criticado, no realmente por motivos técnicos, sino por razones político-económicas. Concentra el poder de validación en manos de unos pocos jugadores. , que no necesariamente tienen buenas intenciones, o al menos no siempre competentes . De vez en cuando, se publican propuestas para otros sistemas (p. ej., Convergencia o

Después la larga presentación de SSL en la respuesta anterior , vamos con las cosas divertidas, a saber:

Ataques a SSL

Ha habido muchos ataques a SSL, algunos basados en errores de implementación, otros en verdaderas debilidades del protocolo.

Hay que recordar que si bien SSL es uno de los protocolos más atacados (ya que tiene un perfil muy alto: una aplicación exitosa a SSL se ve muy bien en el resumen de un artículo de investigación), SSL también es uno de los protocolos más reparados .Debe considerarse robusto precisamente porque todas las formas conocidas de atacar los protocolos de transporte se han probado en SSL, y SSL se ha parcheado cuando corresponde.

Reversión de la versión

En los primeros días de SSLv3, SSLv2 todavía se usaba ampliamente y, por lo tanto, los clientes solían enviar mensajes, que simplemente indicaban que SSLv3 también era compatible; el servidor tomaría la pista y respondería en SSLv3 + dialecto (consulte el Apéndice E de RFC 2246 para obtener más detalles). Dado que SSLv2 tenía debilidades, lo mejor para el atacante era hacer arreglos para que un cliente y un servidor, ambos conociendo SSLv3, se comunicaran entre sí utilizando SSLv2. Esto se denomina ataque de reversión de versión . El concepto también se extiende formalmente a versiones posteriores.

Se han agregado Kludges para detectar intentos de reversión. Para las reversiones de regreso a SSLv2, un cliente que conoce SSLv3 + debe emplear un relleno especial para el paso de encriptación RSA (SSLv2 solo admite el intercambio de claves basado en RSA): en PKCS # 1 , se supone que los datos que se van a cifrar se rellenan con una cantidad de bytes aleatorios; Se supone que un cliente compatible con SSLv3 configura cada uno de los últimos ocho bytes de relleno en el valor fijo 0x03. Luego, el servidor verifica estos bytes; si se encuentran los ocho 0x03, lo más probable es que se intente una reversión y el servidor rechace el intento (un cliente solo con SSLv2 tiene una probabilidad de solo 255 ^-8 de usar dichos bytes de relleno por pura falta de suerte, por lo que los falsos positivos ocurren a un ritmo insignificante).

Para las reversiones a una versión anterior de SSL / TLS, pero no anterior a SSLv3, se agregó otro kludge: en el secreto previo al maestro de 48 bytes que el cliente encripta con la clave RSA del servidor, los primeros dos bytes no son aleatorios, pero deben ser iguales a la «versión máxima de protocolo admitida» que el cliente escribió primero en su ClientHello mensaje. Desafortunadamente, algunos clientes se equivocaron y este kludge solo funciona con un intercambio de claves basado en RSA, por lo que la protección contra la reversión es muy limitada. Afortunadamente, SSLv3 + tiene otra protección mucho más poderosa contra retrocesos, que es que los mensajes de protocolo de enlace se combinan cuando se compilan los mensajes Finished. Este pro protege contra las reversiones a menos que la «versión anterior» sea tan débil que el atacante pueda romper por completo todo el cifrado antes de que finalice el apretón de manos. Esto aún no ha sucedido (SSLv3 todavía es razonablemente sólido).

Conjuntos de cifrado débiles

Algunas de las suites de cifrado estándar son intencionalmente débiles de alguna manera. Hay:

• algunos conjuntos de cifrado sin cifrado en absoluto, solo verificación de integridad, p. Ej. TLS_RSA_WITH_NULL_SHA;
• algunos conjuntos de cifrado con cifrado de 40 bits, como TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (conjuntos de cifrado destinados a cumplir las estrictas reglas de exportación de EE. UU. del siglo pasado (estas regulaciones se eliminaron principalmente al final de la era de Bill Clinton);
• algunos conjuntos de cifrado con cifrado de 56 bits, como TLS_RSA_WITH_DES_CBC_SHA. DES de 56 bits se puede romper con tecnología existente , pero eso sigue siendo un poco difícil para un aficionado (incluso un estudiante aburrido con acceso a unos cientos de máquinas universitarias ), por lo que tiendo a calificar DES de 56 bits como «fuerza media».

Esto abre el camino a una variante de ataques de reversión de versiones, en los que el atacante obliga al cliente y al servidor a estar de acuerdo en un conjunto de cifrado débil, la idea es que el atacante modifique la lista de conjuntos de cifrado anunciada por el cliente. Esto es factible para el atacante si el conjunto de cifrado seleccionado es tan débil que puede romperlo para volver a calcular un Finished mensaje. En realidad, el MAC utilizado en SSLv3 + (incluso cuando se basa en MD5) es lo suficientemente robusto para evitar eso. Así que no hay ninguna preocupación real aquí. Además, mi opinión es que cualquier debilidad real aquí es cuando un cliente o un servidor acepta utilizar un conjunto de cifrado débil.

Por defecto, los navegadores web modernos no permiten el uso de conjuntos de cifrado tan débiles.

Robo de clave privada

Si una conexión SSL utiliza intercambio de claves RSA, y un atacante guarda una copia de los registros, y luego más tarde (posiblemente meses después, posiblemente inspeccionando todas las copias de seguridad en discos duros o cintas desechados) obtiene una copia de la clave privada, luego puede desentrañar el apretón de manos y descifrar los datos.

Perfect Forward Secrecy trata de contrarrestar esto «más adelante». Lo obtienes usando los conjuntos de cifrado DHE. Con un conjunto de cifrado DHE, la clave privada real que podría usarse para desentrañar el protocolo de enlace es la clave efímera Diffie-Hellman, no la clave privada RSA (o DSS) del servidor.Al ser efímero, solo existía en RAM y nunca se escribía en el disco duro; como tal, debería ser mucho más resistente al robo ulterior.

Entonces, la lección es: como regla, intente usar un conjunto de cifrado DHE si es posible. Aún debe tener en cuenta sus copias de seguridad y no permitir que se filtre su clave privada, pero, al menos, las suites DHE hacen que dicha filtración sea un problema un poco menor, especialmente si ocurre después del final de la vida útil de la clave (es decir, el certificado correspondiente no es ya es válido).

Problemas de certificados

Todo el negocio de los certificados es un punto sensible en SSL.

Técnicamente, SSL es bastante independiente de X.509. Las cadenas de certificados se intercambian como manchas opacas. En algún momento, el cliente debe usar la clave pública del servidor, pero el cliente es libre de «conocer» esa clave de la forma que crea conveniente. En algunos escenarios específicos donde se puede usar SSL, el cliente ya conoce el servidor «s clave pública (codificada en el código) y simplemente ignora el certificado enviado por el servidor. No obstante, en el caso común de HTTPS, el cliente realiza la validación de la cadena de certificados del servidor como se describe en X.509 ( léalo a expensas de su cordura; ha sido advertido).

Esto produce una serie de vectores de ataque, por ejemplo:

• La validación implica verificar que los certificados siguen siendo válidos en la fecha actual. ¿Cómo sabe la máquina cliente la fecha actual? Con su reloj interno, y posiblemente hablando con servidores NTP (en ¡de una manera bastante desprotegida!). El cliente podría estar apagado por varios minutos, horas, días, incluso años (lo he visto) y, hasta cierto punto, un atacante poderoso podría forzarlo manipulando mensajes NTP. Esto permitiría que el atacante utilice certificados obsoletos que han sido revocados hace años. Tenga en cuenta un hecho divertido: el «cliente aleatorio» y el «servidor aleatorio» de SSL deben contener 28 bytes aleatorios y la fecha y hora locales (más de 4 bytes). Esta inclusión del tiempo estaba destinado a ser parte de una solución alternativa contra los ataques basados en el tiempo. No tengo conocimiento de ninguna implementación que realmente lo verifique.

• Hasta alrededor de 2003, la implementación de la validación de certificados en Internet Explorer / Windows no procesaba la extensión «Restricciones básicas» adecuadamente. El efecto neto fue que cualquiera con un certificado de 100 € podía actuar como CA y emitir «certificados» con nombres y claves elegidos arbitrariamente.

• X .509 incluye una función de contención de daños llamada revocación : se trata de publicar una lista de certificados desterrados, que se ven bien, criptográficamente hablando, pero que no deben ser confiables (p. Ej., Su clave privada fue robada o contienen un nombre erróneo). La revocación funciona solo en la medida en que las partes involucradas (es decir, los navegadores) acepten descargar listas de revocación gigantescas (que pueden tener varios megabytes de longitud) o ponerse en contacto con servidores OCSP . Los navegadores modernos ahora lo hacen, pero un poco a regañadientes, y muchos aceptarán conectarse de todos modos si no pueden obtener la información del estado de revocación de manera oportuna (porque el usuario humano no es paciente). La situación general mejora con los años, pero con bastante lentitud.

• Algunas CA raíz cometieron algunos errores en el pasado (por ejemplo, Comodo y DigiNotar). Esto resultó en la emisión de certificados falsos (el nombre es www.microsoft.com pero la clave privada no está en manos de Microsoft en absoluto …). Se descubrieron estos errores y se revocaron los certificados, pero aún así surgen algunas preguntas incómodas (por ejemplo, ¿hay otra CA que tuvo tales problemas pero no los reveló o, lo que es peor, nunca los notó?).

X.509 es un conjunto muy complejo de algoritmos, tecnologías, especificaciones y comités, y es muy difícil hacerlo bien. Intentar decodificar certificados X.509 «a mano» en un lenguaje de programación desprotegido como C es una manera fácil de obtener desbordamientos de búfer.

Bleichenbacher Attacks

Daniel Bleichenbacher encontró en 1998 un buen ataque contra RSA. Cuando encripta un dato con RSA (como ocurre con el mensaje ClientKeyExchange en SSL), los datos que se van a cifrar deben rellenar para para hacer una secuencia de bytes de la misma longitud que el módulo RSA. El relleno consiste principalmente en bytes aleatorios, pero hay un poco de estructura (en particular, los primeros dos bytes después del relleno deben ser 0x00 0x02).

Tras el descifrado (en el servidor, entonces), el relleno debe ser encontrado y eliminado. Sucede que, en ese momento, cuando el servidor descifró pero obtuvo un relleno no válido (los bytes 0x00 0x02 no estaban allí), lo informó con un mensaje de alerta (según la especificación SSL), mientras que un relleno válido resultó en el servidor usa el valor aparentemente descifrado y continúa con el apretón de manos.

Este tipo de cosas se conocen como oráculo de relleno . Permite a un atacante enviar una secuencia arbitraria de bytes como si fuera un secreto previo al maestro cifrado, y saber si el descifrado de esa secuencia produciría un relleno válido o no. Esa es una mera información de 1 bit, pero es suficiente para recuperar la clave privada con unos pocos millones de solicitudes (con cadenas «encriptadas» hábilmente diseñadas).

Solución alternativa: cuando el descifrado da como resultado una padding, el servidor sigue usando un secreto pre-maestro aleatorio. El protocolo de enlace fallará más adelante, con los mensajes Finished. Todas las implementaciones actuales de SSL hacen eso.

El oráculo de relleno contraataca

Otra área donde se encontró un oráculo de relleno es en el registros en sí mismos. Considere el cifrado CBC y HMAC. Los datos a cifrar primero se cifran en MAC y luego el resultado se cifra. Con el cifrado CBC, los datos que se cifrarán deben tener una longitud que sea un múltiplo del tamaño del bloque (8 bytes para 3DES, 16 bytes para AES). Entonces se aplica algo de relleno, con cierta estructura.

En ese momento (el ataque fue descubierto por Vaudenay en 2002), cuando una implementación SSL estaba procesando una recepción d, devolvió distintos mensajes de alerta para estas dos condiciones:

• Tras el descifrado, no se encontró una estructura de relleno válida.
• Tras el descifrado, se encontró un relleno válido, pero luego se verificó la MAC y no coincidió.

Este es un oráculo de relleno y se puede utilizar para recuperar algunos datos cifrados. Requiere un atacante activo, pero no es tan difícil. Vaudenay lo implementó y se extendió al caso en el que una implementación SSL modificada devolvió el mismo mensaje de alerta en ambos casos, pero tardó más en regresar en el segundo caso, debido al tiempo que se tarda en volver a calcular el MAC (una buena demostración de un ataque de tiempo ).

Debido a que la gente nunca aprende, la implementación de Microsoft de SSL utilizada en ASP.NET fue aún sin parchear en 2010 (¡ocho años después!) cuando Rizzo y Duong reimplementaron el ataque de Vaudenay y construyeron una demostración que recuperó las cookies HTTP.

Ver esta página para algunas sugerencias. Debe tenerse en cuenta que si SSL hubiera utilizado encriptar-luego-MAC , tales problemas se habrían evitado (los registros defectuosos se habrían rechazado a nivel MAC, antes incluso considerando el descifrado).

BEAST

El ataque BEAST es nuevamente de Duong y Rizzo, y, nuevamente, es una nueva versión de un ataque más antiguo (de Philip Rogaway en 2002). Para hacerse una idea, considere CBC . En este modo de funcionamiento, cada bloque de datos se somete primero a XOR con el resultado del cifrado del bloque anterior; y ese es el resultado del XOR que está encriptado. Esto se hace para «aleatorizar» los bloques y evitar las fugas que se encuentran con el modo ECB. Dado que el primer bloque no tiene un bloque «anterior», debe haber un Vector de inicialización (IV), que juega el papel del bloque anterior para el primer bloque.

Resulta que si un atacante puede controlar parte de los datos que se van a cifrar, y también puede predecir el IV que se utilizará, entonces puede convertir la máquina de cifrado en otro descifrado Oracle y utilizarlo para recuperar algunos otros datos cifrados (que el atacante no elige). Sin embargo, en SSLv3 y TLS 1.0, el atacante puede predecir el IV de un registro: es el último bloque de el registro anterior. Por lo tanto, el atacante debe poder enviar algunos datos en la transmisión, con el fin de «empujar» los datos del objetivo, en un punto donde la implementación construyó y envió el registro anterior (generalmente cuando 16 kB vale de datos se han acumulado), pero no se comenzó a construir el siguiente.

TLS 1.1+ está protegido contra eso porque en TLS 1.1 (y versiones posteriores), se usa un IV aleatorio por registro. Para SSLv3 y TLS 1.0, una solución es enviar registros de longitud cero: es decir, registros con una carga útil de longitud cero, pero con un MAC y relleno y cifrado, y el MAC se calcula a partir de una clave secreta y sobre la secuencia. número, por lo que desempeña el papel de un generador de números aleatorios. Desafortunadamente, IE 6.0 se ahoga con registros de longitud cero. Otras estrategias implican una división 1 / n-1 (un registro de n bytes se envía como dos registros, uno con un solo byte de carga útil y el otro con el resto de n-1 ).

Otra solución es forzar el uso de un conjunto de cifrado que no sea CBC cuando sea posible: el servidor selecciona un conjunto de cifrado basado en RC4 si hay uno en la lista de conjuntos de cifrado enviados por el cliente, incluso si el cliente hubiera preferido un conjunto de cifrado basado en CBC. Esta herramienta puede decirle si un servidor determinado aparentemente actúa así.(Nota: BEAST es un ataque al cliente , pero, al seleccionar un paquete de cifrado RC4, el servidor puede proteger a un cliente descuidado).

Consulte esta página para algunas sugerencias. Si bien TLS 1.1 es de 2006, el ataque BEAST puede obligar a los proveedores de navegadores a actualizar finalmente.

CRIME

Como en cualquier franquicia de Hollywood, Duong y Rizzo publicaron en 2012 la secuela de la secuela. CRIME explota una filtración que se teorizó hace años, pero que solo se demostró vívidamente en la demostración que publicaron recientemente. CRIME explota la compresión, en la misma configuración que el ataque BEAST (el atacante puede enviar algunos datos propios en una conexión SSL, donde también se envían datos de destino interesantes, como una cookie). En términos generales, el atacante pone en sus datos un valor potencial para la cadena de destino y, si coincide, la compresión hace que los registros resultantes sean más cortos. Consulte esta pregunta para obtener un análisis (precognitivo).

El CRIMEN se evita al no usar la compresión de nivel TLS, que es lo que hacen los navegadores ahora. Internet Explorer e IIS nunca implementaron la compresión de nivel TLS en primer lugar (por una vez, el descuido salvó el día); Firefox y Chrome lo implementaron y desactivaron este verano (fueron advertidos por Duong y Rizzo, quienes son bastante responsables en su actividad).

CRIME muestra por qué escribí, cerca del comienzo de mi Explicaciones de SSL :

SSL cumple estos objetivos en gran medida (pero no en forma absoluta).

De hecho, el cifrado filtra la longitud de los datos cifrados. No se conoce una buena solución contra eso. Y la longitud por sí sola puede revelar muchas cosas. Por ejemplo, cuando observamos con un monitor de red una conexión SSL, podemos detectar los «apretones de manos adicionales» dentro del flujo (porque el primer byte de cada registro identifica el tipo de datos en el registro y no está cifrado); con las longitudes de los registros, es bastante fácil ver si el cliente proporcionó un certificado o no.

Poodle

( edit: esta sección ha sido agregada el 2014-10-15)

El ataque «Poodle» explota una falla que es específica de SSL 3.0 con suites de cifrado basadas en CBC. Se basa en una característica de SSL 3.0 que a menudo se pasa por alto: la mayoría de los bytes de relleno se ignoran. En TLS 1.0, el relleno (bytes agregados en un registro para que la longitud sea compatible con el cifrado CBC, que solo procesa bloques completos) está completamente especificado; todos los bytes deben tener un valor específico y el destinatario lo comprueba. En SSL 3.0, el contenido de bytes de relleno se ignora, lo que permite a un atacante realizar alteraciones que pasan desapercibidas en su mayoría. La alteración afecta solo a los datos no aplicativos, pero se puede usar como un oráculo de descifrado de una manera vagamente similar a BEAST.

Se pueden leer más detalles en este answer .

El futuro

Los seres humanos nunca aprenden. Hay mucha presión para agregar extensiones ingeniosas a SSL por muchas razones que siempre se ven bien al principio, pero pueden inducir problemas adicionales.

Considere, por ejemplo, SSL FalseStart . Básicamente, se trata de que el cliente envíe los datos de su aplicación justo después de haber enviado su Finished mensaje (en un apretón de manos completo), sin esperar el Finished mensaje del servidor. Esto reduce la latencia, lo cual es bueno y bien intencionado. Sin embargo, cambia la situación de seguridad: antes de recibir el mensaje Finished del servidor, este último solo se autentica implícitamente (el cliente aún no tiene pruebas de que el servidor previsto estuviera realmente involucrado en todo; solo sabe que todo lo que envíe será legible solo por el servidor previsto). Esto puede tener impactos; por ejemplo, un atacante podría emular el servidor hasta ese punto y obligar, por ejemplo, al cliente a utilizar un conjunto de cifrado basado en CBC o compresión TLS. Por lo tanto, si un cliente implementa FalseStart, disminuye la efectividad de las medidas de protección contra BEAST y CRIME, ya que de otro modo podría ser ejecutado por el servidor.

(Google deshabilitó FalseStart esta primavera, aparentemente debido a problemas de compatibilidad con algunos servidores. De todos modos, la «reducción de latencia del 30%» se veía extraña, porque FalseStart tendría alguna influencia solo en los apretones de manos completos, no en los apretones de manos abreviados, así que no » cree en estos supuestos beneficios; al menos no en esa magnitud).

Comentarios

• La cantidad de esfuerzo que dedicas a proporcionar buena información a través de este sitio es realmente loco y extremadamente admirable. Muy apreciado.
• Vea también tools.ietf.org / html / rfc7457