SSL / TLS 101 para principiantes

Una mirada en profundidad al cifrado que asegura nuestras conexiones a internet


Si bien Netscape inventó originalmente SSL a mediados de los 90, no era obligatorio que cada sitio web instalara un certificado SSL / TLS hasta el verano de 2018 cuando Google comenzó a marcar sitios sin cifrar “No es seguro.”

Si bien Google, con su motor de búsqueda, el navegador Chrome y el sistema operativo Android, puede redefinir Internet de manera unilateral, no estaba solo en este mandato. Apple, Microsoft, Mozilla y otras partes interesadas importantes en la industria de la tecnología han tomado una decisión concertada para exigir certificados SSL / TLS y HTTPS.

El motivo es simple: sin SSL / TLS y la capacidad de conectarse de forma segura a través de HTTPS, toda la comunicación entre los sitios web y sus visitantes se intercambiaría en texto sin formato y sería fácilmente legible por un tercero..

El único inconveniente de este reciente impulso para el cifrado universal es que ha obligado a una afluencia de nuevos clientes a un mercado desconocido, que hace muy poco para hacerse menos confuso para el sitio web promedio o el propietario de un negocio..

Este artículo servirá como una guía completa de todo lo relacionado con SSL / TLS, sentaremos las bases repasando conceptos básicos como el cifrado, HTTPS y la naturaleza de las conexiones a Internet..

Con suerte, al final, se sentirá seguro al seleccionar, comprar e implementar un certificado TLS, y recuerde que si tiene alguna pregunta, puede dejarla en los comentarios a continuación..

Elementos fundacionales

Comencemos discutiendo el concepto que reside en el corazón de todo esto: cifrado.

El cifrado, en su iteración más directa, es poco más que la codificación de los datos, utilizando un cifrado o clave predeterminados, de modo que cualquier persona con la misma clave privada no pueda leerlos..

A lo largo de la historia, el cifrado de clave privada ha sido el modelo más común utilizado. En el cifrado de clave privada, ambas partes deben poseer o al menos intercambiar una clave privada que pueda usarse para cifrar y descifrar información.

Al principio, la mayoría de los cifrados que sustentaban estos criptosistemas eran primitivos, confiaban en sustituciones simples o reemplazaban palabras comunes con caracteres. Pero con el tiempo las cifras se hicieron más influenciadas por las matemáticas y crecieron en complejidad..

Por ejemplo, a mediados de la década de 1600 en Francia, el criptógrafo del rey Luis XIV creó un cifrado que estaba tan bien diseñado que no se rompió hasta 250 años después y solo parcialmente. Hasta el día de hoy, hay cientos de años de registros en los archivos franceses que nunca podrán ser descifrados.

Pero mientras históricamente el cifrado ha sido un medio para ser encubierto o clandestino, el advenimiento de Internet ha llevado el concepto a la corriente principal. Internet es omnipresente y maneja una variedad de funciones críticas. Todos los días, miles de millones de personas lo usan para acceder y enviar información confidencial, administrar sus finanzas, realizar transacciones con empresas, lo que sea..

El problema es que Internet no se diseñó completamente para adaptarse a lo que se ha convertido. Al principio, en los días en que la academia y el gobierno de los Estados Unidos desarrollaban protocolos de redes, Internet solo se veía como un mecanismo para el libre intercambio de información entre el gobierno y las instituciones académicas. En ese momento, la actividad comercial era ilegal en línea. El comercio electrónico no era una palabra que se hubiera inventado aún. Y el sitio web era más una noción geográfica.

Entonces, cuando HTTP o el Protocolo de transferencia de hipertexto se introdujo por primera vez en 1991, el hecho de que las conexiones que formó intercambiaran datos en texto sin formato no era un problema descalificador.

Las cosas son muy diferentes hoy. La información que se intercambia en línea no es investigación académica o información disponible gratuitamente, es información de identificación personal y datos confidenciales que pueden costar dinero a las personas o incluso, en algunas regiones, sus vidas. Esto requería un enfoque más seguro.

La respuesta fue encriptación.

Un problema de intercambio de claves

Un problema que históricamente ha plagado incluso los mejores sistemas criptográficos continúa persistiendo hasta nuestros días..

Lo que discutimos anteriormente, y lo que tradicionalmente ha sido el estándar para el cifrado, es el cifrado de clave privada. Esto también se denomina cifrado simétrico o cifrado bidireccional, con claves privadas que manejan las funciones de cifrado y descifrado necesarias para comunicarse.

Para que el cifrado de clave privada funcione, la clave privada debe transferirse entre las partes, o ambas partes deben poseer su propia copia. De cualquier manera, la seguridad de la clave privada era crítica para la integridad del sistema de cifrado y, como sin duda puede suponer, el intercambio de claves es un problema tan antiguo como el cifrado en sí mismo..

Luego, en la década de 1970, técnicamente dos veces diferentes, un océano entero aparte, se conceptualizó y dio vida a una nueva forma de cifrado: el cifrado de clave pública.

Mientras que el cifrado de clave privada es una función bidireccional, simétrica, con la clave privada capaz de cifrar y descifrar datos, el cifrado de clave pública es asimétrico; de una sola mano. En lugar de una sola clave privada, hay un par de claves pública-privada. La clave pública maneja el cifrado y, como su nombre lo indica, está disponible públicamente, mientras que la clave privada, que maneja el descifrado, es mantenida en secreto por su propietario. Con la clave pública, se puede cifrar un dato y enviarlo al propietario de la clave, donde solo ellos podrán descifrarlo..

Genial, pero ¿cómo es eso útil??

Bueno, el cifrado unidireccional no es ideal para cifrar conexiones a Internet, es un poco difícil comunicarse cuando una parte solo puede cifrar y la otra solo puede descifrar. No, para cifrar una conexión a Internet, necesitaría usar cifrado simétrico de clave privada..

¿Pero cómo intercambias las llaves? Especialmente en línea?

Cifrado de clave pública.

Y eso, resumido en esencia, es de lo que se trata SSL / TLS: intercambio seguro de claves.

Aquí es donde uniremos todos estos conceptos. Si desea que su comunicación con un sitio web sea privada, debe conectarse de forma segura. Si desea conectarse de forma segura con ese sitio web, debe intercambiar claves privadas simétricas para poder usarlas para comunicarse. SSL / TLS (y PKI en general) es solo un mecanismo elegante para crear e intercambiar esa clave de sesión.

Con SSL / TLS, puede autenticar el servidor u organización con el que está a punto de conectarse y asegurarse de intercambiar de manera segura las claves privadas que usará para cifrar su comunicación con la parte destinataria.

Desafortunadamente, SSL / TLS y PKI tienen una gran cantidad de terminología y partes móviles que pueden confundir fácilmente a las personas, pero estos creen el hecho de que cuando eliminas todas las matemáticas y la jerga técnica, esta es solo una solución tecnológica moderna y elegante para una época. antiguo problema: intercambio de claves.

Ahora repasemos algunos términos clave

Antes de continuar, repasemos otros términos clave. Ya presentamos HTTP, protocolo de transferencia de hipertexto, que ha sido la columna vertebral de Internet durante décadas. Pero, como comentamos, Internet evolucionó hacia algo muy diferente de cuando HTTP se publicó por primera vez en 1991..

Se necesitaba un protocolo más seguro. Por lo tanto, HTTPS.

HTTPS, que a veces se conoce como HTTP sobre TLS, utiliza cifrado para hacer que los datos que se intercambian durante una conexión sean ilegibles para cualquier persona que no sea la parte deseada. Esto es especialmente importante cuando se considera la naturaleza de una conexión a Internet moderna..

Mientras que en los primeros días de Internet una conexión era razonablemente directa, ahora las conexiones se enrutan a través de docenas de dispositivos en su camino hacia su destino final. Si alguna vez ha querido una demostración práctica de esto, abra el símbolo del sistema en su sistema operativo e ingrese el comando “tracert geekflare.com”.

Lo que verá es la ruta que su conexión recorrió en el camino a su destino. Hasta 30 saltos. Eso significa que sus datos pasan a través de cada uno de esos dispositivos antes de que lleguen al sitio web o la aplicación a la que se está conectando. Y si alguien tiene un sniffer de paquetes o algún oyente instalado en cualquiera de esos dispositivos, pueden robar cualquier información transmitida e incluso manipular la conexión en algunos casos.

Esto se llama un ataque de hombre en el medio (MITM).

Si quieres aprender sobre el ataque MITM, entonces mira este curso en línea.

Hay mucha más superficie para cubrir con las modernas conexiones a Internet de lo que se da cuenta la gran mayoría de las personas, por lo que es fundamental tener los datos cifrados durante la transmisión. No tienes idea de quién podría estar escuchando, o cuán trivialmente fácil es hacerlo.

Una conexión HTTP se realiza a través del puerto 80. Para nuestros propósitos, puede pensar en los puertos como construcciones que indican un servicio o protocolo de red. Un sitio web estándar que se sirve a través de HTTP usa el puerto 80. HTTPS generalmente usa el puerto 443. Cuando un sitio web instala un certificado, puede redirigir sus páginas HTTP a las HTTPS, y los navegadores de los usuarios intentarán conectarse de forma segura a través del puerto 443, pendiente de autenticación.

Desafortunadamente, los términos SSL / TLS, HTTPS, PKI y encriptación se usan mucho, a veces incluso se usan indistintamente, por lo que para aclarar cualquier confusión persistente, aquí hay una guía rápida:

  • SSL – Capa de sockets seguros, el protocolo de cifrado original utilizado con HTTPS
  • TLS – Transport Layer Security, el protocolo de cifrado más reciente que ha reemplazado a SSL
  • HTTPS – La versión segura de HTTP, utilizada para crear conexiones con sitios web
  • PKI – Infraestructura de clave pública, se refiere a todo el modelo de confianza que facilita el cifrado de clave pública

SSL / TLS funciona en conjunto para habilitar conexiones HTTPS. Y PKI se refiere a todo cuando alejas.

¿Entendido? No te preocupes, lo harás.

Construyendo una Infraestructura de Clave Pública

Ahora que hemos sentado las bases, alejémonos y observemos la arquitectura empleada por el modelo de confianza en el corazón de SSL / TLS.

Cuando llega a un sitio web, lo primero que hace su navegador es verificar la autenticidad del certificado SSL / TLS que el sitio le presenta. Llegaremos a lo que sucede después de que la autenticación se lleve a cabo en un par de secciones, pero vamos a comenzar discutiendo el modelo de confianza que hace posible todo esto..

Entonces, comenzaremos planteando la pregunta: ¿cómo sabe mi computadora si confiar en un certificado SSL / TLS dado??

Para responder eso, tendremos que hablar sobre PKI y los diversos elementos que lo hacen funcionar. Comenzaremos con las Autoridades de certificación y los programas raíz.

Autoridades de certificación

Una Autoridad de certificación es una organización que cumple con un conjunto de estándares predeterminados a cambio de la capacidad de emitir certificados digitales confiables.

Hay docenas de CA, tanto gratuitas como comerciales, que pueden emitir certificados de confianza.

Todos deben cumplir con un conjunto de estándares que se ha debatido y legislado a través del Foro CA / Browser, que actúa como el organismo regulador de la industria TLS. Estas normas describen cosas como:

  • Garantías técnicas que deben existir.
  • Mejores prácticas para realizar validación
  • Mejores prácticas de emisión
  • Procedimientos de revocación y plazos.
  • Requisitos de registro de certificados

Estas pautas han sido establecidas por los navegadores, junto con las AC. Los navegadores juegan un papel único en el ecosistema TLS.

Nadie puede acceder a Internet en ninguna parte sin su navegador web. Como tal, es el navegador que recibirá y validará el certificado TLS digital y luego intercambiará claves con el servidor. Entonces, dado su papel primordial, tienen una influencia considerable.

Y es importante tener en cuenta que los navegadores han sido diseñados para ser lo más escépticos posible. No confiar en nada. Esta es la mejor manera de mantener seguros a sus usuarios. Entonces, si un navegador va a confiar en un certificado digital, que puede ser mal utilizado en detrimento del usuario, necesita ciertas garantías de que quien emitió este certificado hizo su debida diligencia.

Este es el papel y la responsabilidad de las Autoridades de Certificación. Y los navegadores tampoco toleran errores. Hay un cementerio literal de antiguas AC que se han topado con los navegadores y han sido apacentadas..

Cuando una Autoridad de Certificación ha demostrado su cumplimiento con los requisitos básicos del Foro CAB y ha aprobado todas las auditorías y revisiones requeridas, puede solicitar a los diversos programas raíz que agreguen sus certificados raíz.

Programas raíz

Un programa raíz (los principales son administrados por Apple, Microsoft, Google y Mozilla) es el aparato que supervisa y facilita los almacenes raíz (a veces llamados almacenes de confianza), que son colecciones de certificados de CA raíz que residen en el sistema de un usuario. Una vez más, estas raíces son increíblemente valiosas e increíblemente peligrosas, después de todo, pueden emitir certificados digitales confiables, por lo que la seguridad es la mayor preocupación.

Es por eso que las CA casi nunca emiten directamente de los certificados de CA raíz. En cambio, hacen girar certificados raíz intermedios y los utilizan para emitir certificados de usuario final o de hoja. También pueden transferir esas raíces a Sub-CA, que son Autoridades de Certificación que no tienen sus raíces dedicadas pero que aún pueden emitir certificados con firma cruzada de sus intermediarios..

Entonces, pongamos todo esto junto. Cuando un sitio web quiere que se emita un certificado TLS, genera algo llamado Solicitud de firma de certificado (CSR) en el servidor en el que está alojado. En esta solicitud se incluyen todos los detalles que el sitio web desea incluir en el certificado. Como verá en un momento, la cantidad de información puede variar desde los detalles completos de la empresa hasta una simple identidad del servidor, pero una vez que se completa la CSR, se envía a la Autoridad de Certificación para su emisión.

Antes de emitir el certificado, la autoridad de certificación deberá realizar la diligencia debida obligatoria del Foro de CA / Navegador y validar que la información contenida en la CSR sea precisa. Una vez que se ha verificado, firma el certificado con su clave privada y lo envía de vuelta al propietario del sitio web para su instalación..

Encadenamiento de certificados

Después de que se haya instalado el certificado TLS, cada vez que alguien visite el sitio, el servidor que lo hospeda presentará el navegador del usuario con el certificado. El navegador examinará la firma digital en el certificado, la realizada por la autoridad de certificación de confianza, lo que confirma el hecho de que toda la información contenida en el certificado es precisa.

Aquí es donde entra en juego el término encadenamiento de certificados.

El navegador leerá la firma digital y subirá un enlace en la cadena; luego, verificará la firma digital en el certificado intermedio cuya clave privada se usó para firmar el certificado de hoja. Continuará siguiendo las firmas hasta que la cadena de certificados termine en una de las raíces confiables en su almacén raíz, o hasta que la cadena termine sin llegar a una raíz, en cuyo caso aparecerá un error del navegador y la conexión fallará.

Es por eso que no puede emitir y autofirmar sus certificados.

Los navegadores solo confiarán en los certificados SSL / TLS que pueden encadenar a su almacén raíz (lo que significa que fueron emitidos por una entidad confiable). Se requiere que las Autoridades de Certificación cumplan con estándares específicos para mantener su confiabilidad, e incluso entonces los navegadores son reacios a confiar en ellos..

Los navegadores no tienen tales garantías sobre los certificados autofirmados, por lo que solo deben implementarse en redes internas, detrás de firewalls y en entornos de prueba.

Tipos de certificados SSL / TLS y funcionalidad

Antes de analizar SSL / TLS en movimiento, hablemos sobre los certificados y las diversas iteraciones disponibles. Los certificados TLS son los que facilitan el protocolo TLS y ayudan a dictar los términos de las conexiones HTTPS cifradas que hace un sitio web.

Anteriormente mencionamos que la instalación de un certificado TLS le permite configurar su sitio web para realizar conexiones HTTPS a través del puerto 443. También actúa como una especie de credencial para el sitio o servidor con el que está interactuando. Volviendo a la idea de que, en el fondo, SSL / TLS y PKI son formas exquisitas de intercambio seguro de claves, el certificado SSL / TLS ayuda a notificar al navegador a quién está enviando la clave de sesión, a quién la otra parte la conexión es.

Y cuando desglosa las diversas iteraciones de los certificados SSL / TLS, es algo importante a tener en cuenta. Los certificados varían según la funcionalidad y el nivel de validación. O para decirlo de otra manera, varían según:

  • Cuántas identidades para afirmar
  • En qué puntos finales para afirmar identidad

Responder esas dos preguntas le dará una indicación bastante clara de qué tipo de certificado necesita.

Cuántas identidades para afirmar

Hay tres niveles diferentes de validación disponibles con los certificados SSL / TLS, y varían según la cantidad de información de identidad que su sitio web quiera afirmar.

  • Certificados SSL de Validación de Dominio – Afirmar identidad del servidor
  • Certificados SSL de validación de organización: afirmar identidad de organización parcial
  • Certificados SSL de validación extendida: afirme la identidad completa de la organización

Los certificados SSL de validación de dominio son, con mucho, los más populares debido a su precio y la velocidad con la que se pueden emitir. Los certificados DV SSL / TLS requieren una simple verificación de control de dominio, que se puede lograr de varias maneras diferentes, pero tan pronto como sea posible, se puede emitir el certificado. También puede obtener algunas versiones gratuitas de 30 días y 90 días, lo que sin duda ha aumentado su cuota de mercado..

La desventaja es que los certificados SSL DV afirman una identidad mínima. Y dado que casi la mitad de todos los sitios web de suplantación de identidad (phishing) ahora tienen instalado un certificado DV SSL en ellos, no necesariamente le compran mucha confianza.

Los certificados SSL de validación de organización son el tipo original de certificado SSL / TLS. También son el único tipo de certificado SSL que puede asegurar una dirección IP después de una decisión de 2016 del CAB Forum de invalidar todos los certificados SSL de la intranet. La validación de la organización requiere una investigación de negocios ligera y, por lo general, puede emitirse dentro de un día o dos, a veces más rápido. Los certificados SSL de OV afirman cierta información de la organización, pero un usuario de Internet necesitaría hacer clic en el icono del candado y buscarlo. Hoy en día, se ven muchos certificados OV SSL implementados en grandes empresas y redes corporativas, por ejemplo, para conexiones realizadas detrás de firewalls..

Debido a que ni los certificados SSL DV ni OV afirman una identidad suficiente para satisfacer a la mayoría de los navegadores, reciben un tratamiento neutral.

Los certificados SSL de validación extendida son, con mucho, los más controvertidos, ya que algunos miembros de la comunidad tecnológica consideran que se necesita hacer más para fortalecer la validación de la que dependen. Pero, EV SSL afirma la identidad máxima. Para completar la validación extendida, la Autoridad de Certificación somete a la organización a un riguroso proceso de verificación que puede llevar más de una semana en algunos casos..

Pero el beneficio es innegable: debido a que afirma una identidad suficiente, un sitio web con un certificado EV SSL recibe un tratamiento único del navegador, incluido el hecho de que su nombre aparezca en la barra de direcciones del navegador..

No hay otra forma de lograr esto, y no puede falsificarlo: la barra de direcciones EV es uno de los indicadores visuales más potentes que tenemos hoy en día..

En qué puntos finales para afirmar la identidad

La otra forma en que varían los certificados SSL / TLS es con respecto a la funcionalidad. Los sitios web han evolucionado bastante desde los primeros días de Internet con varias compañías que implementan sitios de diferentes maneras. Algunos tienen múltiples dominios para diferentes verticales de la compañía; otros usan subdominios para múltiples funciones y aplicaciones web. Algunos usan ambos.

No importa cuál sea el contexto, hay un certificado SSL / TLS que puede ayudar a asegurarlo.

Dominio único

El sitio web principal y el certificado SSL estándar son solo un dominio único. La mayoría de los certificados SSL / TLS modernos protegerán las versiones WWW y no WWW de ese dominio, pero está limitado a un solo dominio. Usted puede compara los certificados SSL aquí.

Multidominio

Certificados multidominio o los Certificados de comunicaciones unificadas (en el caso de los servidores de comunicaciones de Microsoft Exchange y Office) también existen para dar a las organizaciones la capacidad de cifrar múltiples dominios con un solo certificado. Esta puede ser una opción atractiva, ya que ahorra dinero y hace que la administración de los certificados (vencimientos / renovaciones) sea mucho más simple.

Los certificados multidominio y UCC utilizan SAN, el campo Nombre alternativo del sujeto en la CSR, para agregar dominios adicionales al certificado. La mayoría de las CA permiten hasta 250 SAN diferentes en un solo certificado. Y la mayoría de los certificados multidominio vienen con 2-4 SAN de cortesía con el resto disponible para comprar según sea necesario.

Certificados SSL comodín

Certificados SSL comodín son un tipo de certificado extremadamente útil porque pueden cifrar un número ilimitado de subdominios en el mismo nivel de la URL. Por ejemplo, si tiene un sitio web que utiliza subdominios como:

  • app.website.com
  • portal.website.com
  • usuario.website.com

Puede cifrarlos a todos con el mismo certificado Wildcard utilizando un asterisco en el campo FQDN de su CSR: * .website.com

Ahora cualquier subdominio, incluso los que aún no ha agregado, se pueden proteger con ese certificado.

Sin embargo, hay dos desventajas en los certificados comodín. La primera es que al usar la misma clave pública en algunos puntos finales, eres más vulnerable a ciertas vulnerabilidades como los ataques de Bleichenbacher.

La otra es que no hay una opción de comodín EV. Debido a la naturaleza abierta de la funcionalidad Wildcard, los navegadores no están de acuerdo con delegarles ese nivel de confianza. Si desea la barra de direcciones EV en sus subdominios, tendrá que cifrarlos individualmente o usar un certificado EV multidominio.

Comodín multidominio

Una adición relativamente nueva al ecosistema SSL / TLS, el comodín multidominio puede encriptar hasta 250 dominios diferentes, pero también puede usar un asterisco en los campos de SAN, lo que también le permite encriptar 250 dominios diferentes Y todos los que lo acompañan primero subdominios de nivel.

Otro caso de uso para el comodín multidominio es como un comodín multinivel, donde puede cifrar subdominios en múltiples niveles de la URL (un comodín estándar solo puede cifrarlos en un nivel).

Debido a la funcionalidad comodín, los comodines multidominio tampoco están disponibles en EV.

SSL / TLS en movimiento

Ahora que hemos cubierto todos los conceptos importantes que componen SSL / TLS y PKI, vamos a poner todo junto y verlo en movimiento.

Validación y Emisión

Comencemos desde el principio con un sitio web que compre un certificado SSL / TLS de una CA o revendedor. Después de la compra, el contacto de la organización que maneja la adquisición del certificado crea una Solicitud de firma de certificado en el servidor donde se instalará el certificado (el servidor que aloja el sitio web).

Junto con la CSR, el servidor también generará un par de claves pública / privada y guardará la clave privada localmente. Cuando la CA recibe la CSR y la clave pública, realiza los pasos de validación necesarios para garantizar que la información contenida en el certificado sea precisa. En general, para los certificados de autenticación empresarial (no DV), esto implica buscar información de registro y registros públicos de una organización en bases de datos gubernamentales.

Una vez que se ha completado la validación, la CA utiliza una de las claves privadas de uno de sus certificados de emisión, generalmente una raíz intermedia, y firma el certificado antes de devolverlo al propietario del sitio.

Ahora el propietario del sitio web puede tomar el certificado SSL / TLS recientemente emitido, instalarlo en su servidor y configurar el sitio web para realizar conexiones HTTPS en el puerto 443 (usando redireccionamientos 301 para enviar tráfico desde las páginas HTTP preexistentes a sus nuevos homólogos HTTPS).

Autenticación y el protocolo de enlace SSL

Ahora que el certificado SSL / TLS está instalado y el sitio web ha sido configurado para HTTPS, veamos cómo facilitará las conexiones cifradas con los visitantes del sitio..

Al llegar al sitio web, el servidor presentará el certificado SSL / TLS al navegador del usuario. El navegador del usuario realiza una serie de comprobaciones..

Primero, autenticará el certificado al ver su firma digital y seguir la cadena de certificados. También se asegurará de que el certificado no haya expirado y verificará los registros de Transparencia de certificados (CT) y las Listas de revocación de certificados (CRL). Siempre que la cadena conduzca a una de las raíces en el almacén de confianza del sistema, y ​​que sea válida, el navegador confiará en el certificado.

Ahora es tiempo de apretón de manos.

El protocolo de enlace SSL / TLS es la serie de pasos donde el cliente (usuario) y el servidor (sitio web) negocian los parámetros de su conexión segura, generan y luego intercambian claves de sesión simétricas.

Primero, van a elegir una suite de cifrado. Un conjunto de cifrado es el grupo de algoritmos y cifrados que se utilizarán para la conexión. El certificado SSL / TLS proporciona una lista de conjuntos de cifrado que admite el servidor. En general, un conjunto de cifrado incluye un algoritmo de cifrado de clave pública, un algoritmo de generación de clave, un algoritmo de autenticación de mensajes y un algoritmo de cifrado simétrico o masivo, aunque eso se ha refinado en TLS 1.3.

Al recibir la lista de cifrados admitidos, el cliente elegirá uno agradable y se lo comunicará al servidor. A partir de ahí, el cliente generará una clave de sesión simétrica, la cifrará con la clave pública y luego la enviará al servidor, que posee la clave privada necesaria para descifrar la clave de sesión.

Una vez que ambas partes tienen una copia de la clave de sesión, la comunicación puede comenzar.

Y eso es SSL / TLS.

Puede ver cómo todos los conceptos por los que pasamos anteriormente interactúan entre sí para crear un sistema sofisticado pero elegante para asegurar las conexiones a Internet. Utilizamos la criptografía de clave pública para intercambiar las claves de sesión de forma segura con la que nos comunicaremos. Se puede confiar en los certificados que afirman la identidad del servidor o de la organización debido a la infraestructura que tenemos entre las distintas CA, navegadores y programas raíz..

Y la comunicación se produce como resultado del cifrado simétrico de clave privada que desciende de los criptosistemas clásicos de la antigüedad..

Hay muchas partes móviles, pero cuando disminuyes la velocidad y las entiendes individualmente, es mucho más fácil ver cómo funciona todo junto.

Antes de ir, terminemos con algunos movimientos relacionados con SSL / TLS que puede hacer después de la instalación / configuración para aprovechar al máximo su inversión.

Después de SSL / TLS: sacar el máximo provecho de su implementación

Simplemente tener un certificado instalado y tener su sitio web configurado correctamente no significa que su sitio web sea seguro. TLS es solo un componente de una estrategia de defensa cibernética holística más amplia. Pero un componente importante, no obstante. Veamos algunas cosas que puede hacer para asegurarse de aprovechar al máximo la implementación.

Deshabilitar el soporte del servidor para protocolos antiguos

Volviendo a la conversación que tuvimos anteriormente sobre Cipher Suites, parte de la configuración de su servidor es decidir qué conjuntos de cifrado y versiones SSL / TLS admitir. Es imprescindible que desactive la compatibilidad con versiones anteriores de SSL / TLS, así como con algoritmos específicos para evitar la vulnerabilidad a varias vulnerabilidades conocidas..

SSL 2.0 y SSL 3.0 tienen más de 20 años. La mejor práctica fue desaprobar el soporte para ellos hace años, pero hasta el día de hoy, alrededor del 7% de los 100,000 principales de Alexa todavía lo permiten. Esto es peligroso porque lo expone a la eliminación de SSL y ataques de degradación como POODLE.

TLS 1.0 y TLS 1.1 también están en tiempo prestado.

Las principales compañías tecnológicas, Apple, Microsoft, Google y Mozilla, hicieron un anuncio conjunto este otoño de que dejarán de ser compatibles con TLS 1.0 y 1.1 a principios de 2020.

Las versiones de protocolo son susceptibles a vulnerabilidades como POODLE, FREAK, BEAST y CRIME (todas son siglas). TLS 1.2 ha estado fuera durante diez años y debería ser el estándar. TLS 1.3 se finalizó el verano pasado y la adopción se ha estado moviendo a un ritmo constante desde.

Además, hay algoritmos específicos que tampoco deberían usarse. DES, por ejemplo, puede romperse en cuestión de horas. RC4 es más vulnerable de lo que se creía y ya ha sido prohibido por los Estándares de Seguridad de Datos de la Industria de Tarjetas de Pago. Y finalmente, dadas las noticias de exploits recientes, ya no es recomendable utilizar RSA para el intercambio de claves..

Algoritmos / cifrados sugeridos:

  • Intercambio de claves: curva elíptica Diffie-Helman (ECDH)
  • Autenticación: Algoritmo de firma digital de curva elíptica (ECDSA)
  • Cifrado simétrico / a granel: AES 256 en modo contador de Galois (AES256-GCM)
  • Algoritmo MAC: SHA-2 (SHA384)

SSL siempre activo

En el pasado, los sitios web a veces solo migraban las páginas web que recopilan información a HTTPS, mientras que sirven al resto del sitio a través de HTTP. Esta es una mala práctica.

Además del hecho de que Google marcará esas páginas como “No seguras”, también puede exponer a los visitantes de su sitio a riesgos al hacer que sus navegadores salten de un lado a otro entre páginas cifradas y HTTP..

Debería configurar todo su sitio web para HTTPS. Esto se llama SSL siempre activo. Después de todo, no es como si estuviera pagando por página, su certificado SSL / TLS puede encriptar todo su sitio. Así que hazlo así.

Configurar un registro de autorización de autoridad de certificación (CAA)

Uno de los riesgos más importantes que presentan los certificados digitales, en general, es la emisión errónea. Si una parte que no sea usted recibe un certificado SSL / TLS para SU sitio web, puede hacerse pasar por usted y causar todo tipo de problemas..

Los registros CAA ayudan a mitigar este riesgo al restringir qué Autoridades de Certificación pueden emitir certificados digitales para su sitio web. El CA / Browser Forum requiere que las Autoridades de certificación verifiquen los registros de la CAA antes de emitir cualquier certificado. Si la CA no tiene la autorización para emitir para ese sitio, no puede hacerlo. Hacerlo se consideraría un error y generaría la ira de la comunidad de navegadores..

Agregar un registro CAA es relativamente fácil, es un registro DNS simple que se puede agregar a través de la interfaz de la mayoría de las plataformas de alojamiento. Puede restringir las CA que pueden emitir para su dominio, así como si también se pueden emitir certificados Wildcard para él..

Agregue su sitio web a la Lista de precarga de HSTS

HTTP Strict Transport Security, o HSTS, es un encabezado HTTP que obliga a los navegadores a realizar conexiones HTTPS con un sitio determinado. De esta manera, incluso si el usuario web intenta acceder a la versión HTTP de la página, solo terminará visitando la versión HTTPS. Eso es importante porque cierra la ventana a varias vulnerabilidades conocidas, como ataques de degradación y secuestro de cookies..

Desafortunadamente, un pequeño vector de ataque permanece con HSTS, por lo que debe agregar su sitio web a la lista de precarga. Por lo general, cuando un visitante llega a su sitio web, su navegador descargará el encabezado HTTP y luego lo respetará durante el tiempo que la política se haya establecido para durar. Pero en esa primera visita, antes de que se reciba el encabezado, todavía hay una pequeña abertura para un atacante.

Google ejecuta la lista de registros de precarga de HSTS y algunas de sus variaciones son utilizadas por todos los principales navegadores. Esos navegadores solo saben conectarse a través de HTTPS a cualquier sitio web que esté en la lista, incluso si nunca antes se ha visitado allí. Es posible que su sitio demore una o dos semanas en aparecer en la lista debido al hecho de que las actualizaciones de la lista se eliminan junto con los cronogramas de lanzamiento de los navegadores.

Preguntas frecuentes sobre SSL / TLS

¿Qué es un certificado X.509??

X.509 se refiere al tipo de certificado digital que se utiliza con SSL / TLS y otros tipos de PKI. X.509 es un estándar de cifrado de clave pública. Ocasionalmente verá que las empresas usan el certificado X.509 en lugar del “certificado digital” o el “certificado PKI”.

¿Por qué caducan los certificados SSL / TLS??

hay dos razones para esto.

La primera es que Internet está cambiando continuamente, los sitios web vienen y los sitios web se van. Y dado lo sensibles que son los navegadores a la hora de confiar en estos certificados, en primer lugar quieren saber que los sitios web que presentan los certificados se someten a validaciones periódicas. No es tan diferente de cómo ocasionalmente tiene que registrarse para actualizar la información de su licencia de conducir.

La otra razón es más técnica. Es más difícil proliferar las actualizaciones y los cambios técnicos cuando los certificados no caducan durante 3-5 años. Mientras que, si los certificados expiran cada 24 meses, el plazo más largo que podría estar vencido es de dos años. En 2017, la validez máxima se redujo de tres años a dos. Es probable que se acorte a 12 meses en breve..

¿Cómo se renueva un certificado SSL / TLS??

La renovación puede ser un nombre poco apropiado porque está reemplazando el certificado antiguo por uno nuevo. Hacer esto regularmente le permite mantenerse actualizado con los nuevos avances con tecnología de cifrado y garantiza que su información de validación se mantenga actualizada. Las CA solo pueden reutilizar la información de validación que se suministró inicialmente durante tanto tiempo antes de que los requisitos de línea de base los obliguen a volver a validarla.

Cuando renueve, puede conservar el mismo tipo de certificado que tenía antes, o puede optar por algo nuevo, incluso puede cambiar las CA. Lo importante es la cantidad de tiempo que le queda al certificado que vence; puede transferir hasta tres meses. Siempre que renueve antes de que caduque el certificado, puede transferir el tiempo restante y volver a utilizar cualquier información de validación que no haya expirado desde su última validación. Si dejas que caduque, comienzas desde cero.

¿Qué es la inspección HTTPS??

A muchas compañías más grandes con redes más grandes les gusta tener visibilidad sobre su tráfico. En ese sentido, HTTPS es una espada de doble filo. Protege la privacidad de las personas, pero también puede ayudar a los cibercriminales a esconderse también. Muchas organizaciones descifrarán su tráfico HTTPS en un dispositivo perimetral o una caja intermedia y luego lo enviarán en texto plano detrás de su firewall o lo volverán a cifrar y lo enviarán en su camino. Cuando no vuelve a cifrar el tráfico, se llama Terminación SSL. Cuando vuelve a cifrar, eso se llama puente SSL.

¿Qué es la descarga de SSL??

La descarga de SSL es otra práctica empresarial. A escala, realizar miles de apretones de manos y luego cifrar y descifrar todos esos datos puede gravar los recursos de una red. Por lo tanto, muchas redes más grandes descargarán las funciones SSL a otro dispositivo para que el servidor de aplicaciones pueda concentrarse en sus tareas principales. Esto a veces se conoce como equilibrio de carga.

¿Por qué mi CA me envió un certificado intermedio??

Recuerde antes cuando discutimos los programas raíz?

Very OS tiene un almacén raíz que utiliza para hacer juicios de confianza de PKI. Pero las AC no emiten certificados de usuario final de esas raíces por temor a lo que sucedería si alguna vez tuvieran que ser revocados. En cambio, hilan raíces intermedias y las eliminan. El problema es que esas raíces intermedias no residen en la tienda de confianza de un sistema.

Por lo tanto, si el sitio web no presenta el certificado intermedio junto con el certificado SSL / TLS en hoja, muchos navegadores no podrán completar la cadena de certificados y emitirán una advertencia. Algunos navegadores tienen certificados intermedios de caché, pero todavía se considera una práctica recomendada instalar cualquier intermediario junto con su certificado hoja.

¿Qué documentación necesito para un certificado SSL de validación extendida??

En la mayoría de los casos, la Autoridad de Certificación que realiza la validación extendida primero intentará acceder a la información a través de recursos de “autoridad gubernamental” disponibles públicamente.

Sin embargo, en algunos lugares, esto podría no ser posible. Sin embargo, hay algunas cosas que pueden ayudar a acelerar la validación. Si bien el número de verificaciones de validación que puede satisfacer una Carta de Opinión Profesional se ha reducido recientemente, tener un abogado o un contador con buena reputación todavía puede ayudar considerablemente.

Además, puede proporcionar una credencial comercial emitida por el gobierno o un documento de “Prueba de Derecho” que otorgue a su organización el derecho de hacer negocios con el nombre que figura en la lista. Algunos ejemplos de estos documentos son:

  • Articulos de incorporación
  • Certificados de formacion
  • Licencias de negocios / proveedores / comerciantes
  • Documentos de la carta
  • Acuerdos de asociación
  • Registro de nombre comercial o supuesto
  • Registro Mercantil

Para concluir

Espero que esto te de una idea sobre SSL / TLS. Si está interesado en aprender más, le recomendaría tomando este curso en línea.

Esta publicación fue aportada por Patrick Nohe, editor de Hashed Out por The SSL Store, un blog que cubre noticias y tendencias de ciberseguridad.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map