Get best of the week

Una introducción a TLS para Patrik Patrick (Parte 1)

Como ya sabrás, este es Patrick. Es una estrella de mar, lo que significa que es posible, sin insultarlo, decir que sus manos están creciendo desde un solo lugar. Patrick también es muy práctico e inmediatamente olvida todo lo que no necesita, pero si necesita algo, quiere saberlo (¡porque lo necesita!). Spoiler: aquí Patrick está tratando de hacer un apretón de manos TLS.



Este artículo está escrito para Patrick y personas como él. Nació de una presentación que se mostró por primera vez en nuestra Plesk TechTalk educativa interna, donde los empleados de forma accesible comparten información entre ellos sobre tecnologías, procesos y soluciones interesantes. Por lo tanto, las imágenes de este artículo se verán como diapositivas :) El autor del texto original del informe es el administrador del programa Plesk Ruslan Kosolapov .

Por lo general, todo el material TLS cubre algunos aspectos pequeños, pero no el panorama general. Esto no es muy práctico y Patrick tiene dolor de cabeza por esto. Aquí todo será diferente: brevemente, aplicable "en la vida cotidiana" y de la forma más exhaustiva posible.

¿Qué es TLS y por qué es para Patrick?


TLS (Transport Layer Security) es un protocolo de protección de la capa de transporte. Es necesario para que nadie pueda "escucharlo" y encontrar información importante (con mayor frecuencia contraseñas, si hablamos de trabajar en la red). Y también para protegerse de la falsificación y modificación del tráfico durante la transmisión. Es en estas dos cosas que radica el propósito de TLS.

Para mayor claridad, consideremos el apretón de manos TLS como una llamada a Patrick SpongeBob. Durante una llamada, alguien puede espiar la conversación (pararse al lado de Patrick o encenderla en el medio de la línea), y generalmente Bob Esponja puede no estar en el otro extremo; todos estos problemas son relevantes. Y para resolverlos, Patrick quiere usar TLS.

En resumen, el apretón de manos de nivel superior se ve así:

Patrick: Quiero usar TLS, las versiones de cifrado son tal y tal.
Bob Esponja: Ok, usemos versiones cifradas tal y tal.

Después de eso, Bob Esponja envía el certificado, Patrick lo verifica, dice que todo está bien, la clave de sesión está lista (en realidad hay dos de ellos, pero no importa). ¿Por qué usar una clave de sesión en lugar del cifrado asimétrico? Porque es más rápido. Después de eso, comienzan a hablar un idioma incomprensible para el descifrado. Por lo tanto, todo está protegido.

Todo parece ser simple. Cómo funciona en hardware no es tan importante para nosotros. Pero si comienzas a pensar, ¡y Patrick comienza a pensar! - Eso plantea la pregunta de cómo generalmente estamos de acuerdo en que usaremos TLS? Después de todo, una vez no había TLS, pero solo había protocolos ordinarios: SMTP, HTTP. ¿Cómo decir lo que se necesita en TLS? Y aquí, en nuestra industria, todo es como siempre: ¡hay muchas maneras!

Al principio, querían usar un puerto específico, lo que implicaría el uso de TLS en él. ¿Cuáles son las desventajas de esto? ¿Y por qué entonces apareció el método explícito (explícito) para comenzar una sesión TLS? Hay varias razones:

  1. Necesita muchos puertos, y los puertos son algo que no desea gastar. Porque cuanto más hay, más difícil es configurar el firewall.
  2. El servidor puede ignorar esto: se ha conectado al puerto 443 y no hay TLS allí, solo HTTP sin ningún HTTPS.
  3. Antes de establecer la conexión, no puede averiguar si el servidor TLS es compatible o no.

Todo esto condujo a la aparición de un método explícito: cuando nos conectamos a un puerto normal y luego actualizamos nuestra sesión a TLS. Para diferentes servicios, el protocolo tiene diferentes comandos, por ejemplo, para SMTP hay un comando separado a nivel del protocolo SMTP: STARTTLS . HTTP también tiene ese chiste, se llama Upgrade: TLS / 1.0 . A nivel de protocolo, es más fácil entender si un servidor TLS es compatible o no.

Detengámonos un poco más en los diferentes tipos de conexiones y cómo están las cosas con TLS para ellos.

Conectar: ​​HTTP


Todo sería fácil si, como siempre, no hubiera matices. En el caso de HTTP, los crecientes requisitos de seguridad proporcionan una evolución constante del proceso de trabajo con TLS. Al principio hubo una redirección a HTTPS, y esto se hizo simplemente en el encabezado. Esto dejó un vacío para las vulnerabilidades, por lo que a Google se le ocurrió HSTS (HTTP Strict Transport Security). Este es un encabezado en la respuesta HTTP que le dice al navegador: "recuerde que cuando venga a este dominio, vaya directamente a HTTPS, incluso si la persona le dijo que vaya a HTTP". Por lo tanto, no hay redirección y todo sucede mucho más seguro. Además, Google tiene otra iniciativa: puede dejar una solicitud para que su sitio se agregue a la lista de Google Chrome "Siempre use HTTPS", independientemente de los encabezados.

Brevemente: HSTS resuelve la redirección de vulnerabilidades HTTP a HTTPS, por lo que casi todos los navegadores admiten HSTS, lo cual es bueno.

Connect: exótico (nuevas versiones de HTTP y no solo)


En HTTP / 2, las cosas son buenas con TLS: siempre se usa (ya que ahora se hacen los navegadores). Además, TLS en HTTP / 2 debe ser nuevo, es decir, tener la versión 1.2+.

Muy probablemente, muy pronto Google venderá el uso generalizado de HTTP / 3, ahora es adoptado por el estándar IANA. La historia de su aparición y desarrollo es bastante confusa; Lo principal para recordar a Patrick:

  • HTTP / 3 siempre es TLS 1.3+.
  • HTTP / 3 se basa en QUIC: es un protocolo sobre UDP que, según Google, es mejor que TCP. En realidad, antes de que finalmente se aprobara el nombre HTTP / 3, el protocolo se llamaba HTTP-over-QUIC.

Todavía hay un protocolo SCTP interesante, que se utiliza principalmente en telecomunicaciones. Por encima, se utilizan tanto TLS como DTLS (este es TLS para UDP).

Brevemente: en 2 años, QUIC (es decir, HTTP / 3) se usará en todas partes, pero ahora ya debería haber HTTP / 2 en todas partes, pero en realidad no está en todas partes.

Conectar: ​​correo


Muchos clientes creen que debería haber TLS en el puerto 587, pero también hay matices aquí: alguien espera TLS de forma predeterminada y alguien espera una solicitud STARTTLS explícita del cliente. Debido a esto, varias combinaciones de servidor de correo y cliente de correo a veces causan efectos no deseados. Por ejemplo, un cliente ingresa al puerto 587, esperando que haya TLS, mientras el servidor espera a que el cliente solicite explícitamente STARTTLS . Al no haber recibido nada, el cliente regresa al puerto 25. El resultado es un cambio silencioso a una conexión SMTP insegura. Al probar y desarrollar, vale la pena recordar sobre tales efectos de las combinaciones cliente-servidor. Autodiscaver tiene varias opciones para especificar TLS: cómo debería ser, qué se espera y qué hacer. Muchos clientes de correo entienden estas cosas.

Brevemente: con el soporte TLS en servidores de correo y clientes de correo, todo está bien en general, pero en casos especiales puede haber problemas y las extensiones TLS no son muy compatibles.

Conectar: ​​FTP


Poco se puede decir aquí. El principal problema es SNI (esto es cuando diferentes dominios están en la misma IP). En el nivel FTP, el nombre de dominio no se transfiere. En una versión explícita, no puede funcionar, porque no hay ningún lugar para escribirlo. Hay varias opciones de solución: algunas ofrecen, por lo tanto, otras, aún no se ha adoptado una solución general, no hay un estándar.

Brevemente: hay algún tipo de soporte TLS para FTP (FTPS, SFTP, un análogo de FTP implementado a través de SSH), pero algunos aspectos no están cubiertos debido a las limitaciones técnicas del propio FTP.

Apretón de manos TLS


Entonces, ahora sabemos cómo iniciar la comunicación usando TLS en diferentes conexiones, y Patrick pudo comunicar su deseo a Bob Esponja. Una vez que han acordado que usarán TLS, se produce TLS Handshake. Su resultado debería ser un acuerdo entre el cliente y el servidor sobre cómo lo cifran todo. Además, el cliente debe asegurarse de que el servidor es el que se necesita. A veces, el servidor también verifica al cliente (pero con mucha menos frecuencia).

Cifrados y versiones


Como ya se mencionó, el primer paso es elegir qué versión de TLS y qué cifrados se utilizarán para el cifrado. Por lo general, el cifrado se ve así:



el conjunto de cifrado está en el registro de la IANA, y en el protocolo TLS en forma binaria es solo su ID. Como puede ver en la figura, aquí no solo está (y no solo) el cifrado, sino también su modo de funcionamiento y otros detalles necesarios para el apretón de manos TLS. Patrick no necesita entrar en detalles. Todo lo que es importante en esta etapa es recordar que estas letras son buenas (y el resto son malas):

  • DHE
  • ECDhe
  • AES128
  • AES256
  • RSA
  • Ecdsa
  • Cbc
  • Gcm
  • SHA256
  • SHA383
  • CHACHA20
  • POLY1308

Imagen para recordar buenas cifras:



si es difícil de recordar, hay buenos servicios que pueden informarle al respecto, por ejemplo, un servicio de Mozilla ssl-config.mozilla.org .



Puede ver de inmediato dónde y cómo se admite: esto es lo que los chicos de Mozilla están tratando de seguir.

Un detalle interesante: el cliente transfiere los cifrados en orden de prioridad según sus preferencias, pero el servidor se queda con la decisión: selecciona el cifrado que parece ser el mejor de la lista de clientes admitidos.

Ambas partes también indican la versión máxima admitida del protocolo; en este caso, Patrick es más avanzado que SpongeBob.

En realidad certificado


Junto con la respuesta "Hagámoslo así", el servidor envía su certificado o certificados, puede haber muchos de ellos.

¿Qué es un certificado? Esta es una relación de información (tema), la mayoría de las veces es el nombre de un dominio u organización, y una clave pública (clave pública). Es decir, el certificado dice: "Amigo, mi clave pública es así. Ahora, con su ayuda, acordaremos las claves de sesión ". Además, con su ayuda, puede verificar la firma de los certificados u otra cosa. Es decir, en principio, sería posible utilizar no certificados, sino registros donde se indica esta relación. Y, de hecho, los pasos en esta dirección continúan, porque el mecanismo de la Autoridad de Certificación se considera no muy bueno, simplemente no hay nada más.

Por lo tanto, el certificado es la estructura de 'Asunto: clave pública' más la firma de ese ishyuer (el emisor en transliteración al ruso se ve horrible, pero el sinónimo más cercano aquí no está muy cerca en contexto al "emisor") que este certificado fue emitido. Ishüyer también tiene un certificado y la conexión de alguien con algo. Puede verificar que el certificado sea correcto tomando la clave pública del ishyuere y verificando la firma. Como resultado, nada puede ser falsificado aquí.

Repasemos el certificado y veamos qué problemas puede tener.



En primer lugar, el número de serie implica unicidad solo dentro de los límites del ishyuere, aunque algunos softwares consideran que es único en todo el universo. Afortunadamente, la mayoría de las veces, es realmente completamente único.

El certificado también indica qué algoritmos se usan para el cifrado y la firma: RSA o ECDSA, es decir, qué criptografía usar para trabajar con esta clave pública. La principal diferencia entre RSA y ECDSA es que el principio matemático de ECDSA se basa en curvas elípticas, y RSA es simplemente números naturales, por lo que es más lento y se usan claves enormes (3-4 mil) para evitar que se rompa. . Y para ECDSA, una clave de 300 bits es suficiente y funciona más rápido. Por lo tanto, muchos están cambiando a ECDSA: el apretón de manos en sí es pesado y quiero reducirlo. Se puede solicitar ECDSA al emitir un certificado, y si el buscador lo respalda, lo hará por usted. Pero la firma del certificado depende de la clave privada que tenga actualmente ishuiur y no de si solicitó ECDSA o RSA.Por lo tanto, los navegadores pueden mostrar que uno está en la firma y el otro en la clave pública, y no hay que tener miedo si la firma no es ECDSA.

¿Cómo obtener un certificado?


En resumen, así:

Patrick le dice a la Autoridad de Certificación: Necesito un certificado. Esta persona (u organización) verifica si es Patrick. Los cheques pueden ser muy diferentes. Por supuesto, Patrick como cliente puede no tener un certificado, pero si el servidor no tiene un certificado, entonces no habrá TLS. Se verifica si todo está indicado correctamente en la solicitud del certificado, si Patrick realmente posee el tema para el que está solicitando un certificado. Esto lo hacen los centros superiores de la Autoridad de Certificación: personas condicionales en las que todos creen. Para emitir un certificado, debe elaborar una CSR (solicitud de firma de certificado, una solicitud de certificado).



Esta es también una estructura, con la cual es bastante difícil trabajar, porque hay pocos servicios que le permiten configurar, especificar, verificar y ver todo.

Total, generamos un par de clave pública: clave privada, pero solo damos lo público y ocultamos lo privado. Luego generamos una Solicitud de firma de certificado y la firmamos con nuestra clave privada. Enviamos todo esto a la autoridad de certificación, y comienza la verificación. Puede ser diferente, para los certificados especialmente interesantes existen procedimientos difíciles especiales, pero nos detendremos en el caso general.

RR CAA



Existe un problema tal que las personas que todos creen que a veces no son muy buenas. Una de las razones por las que Symantec se ha convertido en parte de DigiCert es porque (Symantec) emitió certificados sin preguntar a los propietarios del dominio. No puede hacer esto, fue insultante para todos, pero sobre todo para Symantec, porque tenía que vender su negocio. Para hacer que el servidor sea menos dependiente de camaradas tan inescrupulosos, existe algo como CAA RR, un registro en DNS que dice a quién le permite el propietario emitir certificados para su dominio. Esta característica también está en Plesk, se usa poco hasta ahora, aproximadamente como DNSSec, pero no obstante. Todas las autoridades de certificación acordaron verificar esta entrada y si dice que esta autoridad de certificación no se puede emitir, dirá: "no aprobó la validación, está escrita en CAA RR,que no puedo escribir un certificado para usted ", y no lo escribiré. Si no hay entrada, entonces puedes. Ahora Google está impulsando la iniciativa para que los clientes verifiquen el certificado que recibieron para cumplir con los registros de CAA RR. El debate aún está en curso.

Además, CAA RR desde el momento en que ampliamos su soporte en Plesk al indicar los métodos de validación (es decir, también puede indicar aquí por qué método valida que este dominio es suyo) y el URI de la cuenta (Identificador uniforme de recursos). Popular entre los usuarios, Plesk Let's Encrypt ya es compatible con todo esto (¡bien hecho!).

Todo esto funciona para cualquier tipo de certificado, y dado que hablaremos de las diferencias más adelante, es hora de hablar sobre los tipos con más detalle.

Tipos de certificado


Hay tres de ellos:

Validación de dominio


El tema es un dominio, es decir, aquí solo lo verificamos. Anteriormente, cuando no había validadores automáticos, la validación se realizaba principalmente por correo electrónico a través del servicio Whois. Esto se consideró razón suficiente para creer que usted es el propietario de este dominio. Luego pensaron en revisar el DNS: le escribieron por correo electrónico: "y agreguen tal y tal registro al DNS". Posteriormente aparecieron los métodos automáticos (hablaremos un poco más sobre ACME).

Validación de la organización


En el campo "asunto", además del nombre de dominio, también se indica el nombre de la organización. La verificación consiste en validar si el dominio pertenece a esta organización y si la persona que recibió el certificado trabaja allí. Cómo se hace esto: buscan organizaciones en los registros, llaman, piden que se haga algo (el teléfono resultó correcto, la persona correcta respondió, lo que significa que lo más probable es que todo esté bien).

Validación extendida


Igual que OV, solo que más frío. Aquí todo está muy regulado: un documento de 40 páginas en el espíritu de "en el párrafo 5.6.8 debería ser el siguiente: ...", etc. Se controlan muchas cosas: el país, el departamento (si se indica en la solicitud) y, a veces, una persona especial incluso se va a ver con los ojos. ¿Cuál es la diferencia práctica? Casi todos los navegadores han dejado de distinguir entre OV y DV, y esto es malo, porque en este caso no se muestra el nombre de la organización. Como resultado, nadie se molesta en crear un dominio aliepxress.ru, dibujar la misma página y robar tarjetas de crédito. Y será absolutamente legítimo crear dicho dominio y obtener un certificado DV en él.

Ejemplo con EV: el nombre de la organización es visible aquí, por lo que si alguien roba algo, el usuario sabrá que se trata de la corporación Valve Corp, y registrar la corporación es algo más difícil que el dominio (más controles).



Sin embargo, todo llega al punto en que EV dejará de ser diferente, en dispositivos móviles ya no es visible y debe presionar un botón separado, y también en Safari. Google Chrome todavía se mantiene (UPD - ¡ya no! Tuve que hacer una pantalla desde IE). La argumentación de aquellos que no muestran: "si estás preocupado, haz clic y mira", pero nadie presiona naturalmente.

Obtención de un certificado: automatización


Ahora hablemos sobre la recepción automática de certificados DV. Para mayor claridad, veamos cómo lo hace nuestro Let's Encrypt favorito. Generalmente tiene buena documentación, si alguien está interesado, e incluso en ruso.

CUMBRE


ACME (Automatic Certificate Management Environment) es un protocolo diseñado para automatizar y estandarizar el proceso de obtención de un certificado.

¿Cómo prueba ACME que eres propietario de un dominio? Usted dice: Quiero un certificado e indicar el tipo de validación automática, por ejemplo, ACME HTTP-01. Let's Encrypt le pide que coloque los datos en un archivo, y si pudiera poner los archivos en su dominio (y Let's Encrypt podría recogerlos desde allí a través de HTTP), probablemente sea su propietario. Ahora este enfoque es criticado, incluso de Google, porque no protege contra el phishing. Es decir, con la validación manual, es probable que el dominio aliepxress.ru suscite sospechas, pero Let's Encrypt hasta ahora no sabe cómo (o puede, pero mal).

Desafío DNS


Además de ACME, también hay un desafío de DNS. Por ejemplo, le dicen: ingrese un registro txt en su zona DNS, coloque los datos en él. Hay otras formas, pero no comunes, y una se canceló por completo, porque resultó ser vulnerable. Lo que tenemos en Plesk: los certificados comodín (que solo se pueden escribir utilizando el desafío DNS) no funcionan para muchas personas, porque muy a menudo Plesk no administra las zonas DNS y la extensión del dominio Let's Encrypt no puede automatizar la creación de un registro en la zona DNS .

Dos palabras más sobre Let's Encrypt


Un aspecto importante al trabajar con los certificados Let's Encrypt son los límites. En caso de duda (o sospecha de que se han logrado), es mejor seguir el enlace: letsencrypt.org/docs/rate-limits

A veces se actualizan. Hay límites obvios que las personas olvidan: la mayoría de las veces, a juzgar por las solicitudes de soporte, se enfrentan a un límite de 100 nombres de dominio en el certificado. Let's Encrypt también tiene un servidor provisional y hay más límites, pero dichos certificados se consideran no confiables y para el navegador son similares a los autofirmados. En la práctica, con un límite de 100 nombres, rara vez llegan a nosotros (a pesar de que los sitios en Plesk tienen un total de 1,300,000 certificados Let's Encrypt). La mediana, según nuestras estadísticas, es de 20 nombres por certificado. Entonces, si algo no funciona, mira, tal vez se haya alcanzado el límite. Let's Encrypt tiene buenos informes de errores y, por lo general, puedes entender lo que sucedió.

¿Que sigue?


Entonces, después de recibir el certificado, el servidor transmite los datos clave de la sesión; esto es lo que se utilizará para el cifrado. Si el servidor considera que es necesario autenticar al cliente (por ejemplo, el acceso está abierto solo a un cierto círculo de personas), puede preguntar: el cliente, ¿quién es usted? Y luego el cliente deberá enviar su certificado. Después de recibir el mensaje ServerHelloDone, el cliente se da cuenta de que es hora de verificar los certificados y trabajar con las claves.

Todo lo que hablamos antes de que TLS 1.3 pase por un canal abierto, y cualquiera puede ver todas estas cosas. Hay varios ataques interesantes que puedes leer sobre ti.
En la segunda serie del artículo, aprenderemos cómo el cliente verifica el certificado.

More articles:


All Articles