022.2 Lección 1

En las comunicaciones web, es fundamental distinguir entre los protocolos de texto simple y los protocolos de cifrado de transporte. Los protocolos de texto simple envían datos en un formato legible, lo que significa que los actores maliciosos pueden interceptar y ver fácilmente la información. HTTP (protocolo de transferencia de hipertexto) es un protocolo de texto simple, en el que todos los datos se transmiten sin ningún tipo de cifrado, lo que los deja vulnerables a escuchas y manipulaciones.

HTTP define cómo los clientes web (por ejemplo, los navegadores) se comunican con los servidores web. Como protocolo de capa de aplicación, HTTP es independiente de los protocolos subyacentes de capa de transporte o de capa de sesión (<<fig.22.2.1> >). Sin embargo, en su forma original, HTTP transmite datos como texto simple, encapsulado en segmentos de transporte (como TCP) sin cifrado, lo que lo hace susceptible a la interceptación.

El cifrado de transporte ofrece una solución codificando los datos durante la transmisión y convirtiéndolos en un formato ilegible. Incluso si los datos son interceptados, ya que no se pueden decodificar sin las claves de descifrado correctas. Este enfoque garantiza la confidencialidad e integridad de los datos, evitando el acceso y la modificación no autorizados. El protocolo de seguridad de la capa de transporte (TLS) es el más utilizado para el cifrado de transporte y proporciona la base para la versión segura de HTTP, conocida como HTTPS.

A medida que Internet evolucionó para gestionar transacciones comerciales y confidenciales, surgió la necesidad de un protocolo que protegiera estos datos. El protocolo Secure Sockets Layer (SSL), introducido en la década de 1990, cumplía esa función, pero desde entonces ha sido reemplazado por su sucesor, el protocolo Transport Layer Security (TLS). TLS sigue siendo el estándar para proteger la comunicación entre clientes y servidores a través de canales inseguros.

TLS se compone de varios elementos clave, incluidos protocolos de cifrado, certificados digitales para la verificación de la identidad del servidor y dos protocolos TLS principales: el protocolo TLS handshake y el protocolo TLS record. Estos componentes funcionan juntos para proporcionar una conexión segura entre el cliente y el servidor (<<fig.22.2.2> >).

El protocolo de enlace TLS es responsable de la autenticación inicial entre el cliente y el servidor, durante la cual intercambian claves criptográficas y acuerdan un algoritmo de cifrado. El protocolo de enlace TLS garantiza que la conexión sea segura antes de que se intercambien datos de la aplicación. Para que la autenticación sea correcta, el servidor debe presentar un certificado digital firmado por una autoridad de certificación (CA) de confianza, que confirme su identidad.

TLS también incluye el protocolo de registro TLS, que encapsula protocolos de nivel superior y proporciona privacidad e integridad de los datos. La privacidad se logra mediante el cifrado simétrico, mientras que la integridad de los datos se garantiza mediante la incorporación de un Código de autenticación de mensajes (MAC) para detectar manipulaciones durante la transmisión. Este enfoque de doble capa garantiza que las comunicaciones sigan siendo privadas y seguras.

HTTPS, o Protocolo seguro de transferencia de hipertexto, es simplemente HTTP que se ejecuta sobre TLS (<<fig.22.2.3> >). El propósito de HTTPS es proteger los datos transmitidos entre el navegador de un visitante y un servidor web; cifrándolos y verificando la identidad del servidor.

Cuando un visitante solicita acceso a un sitio web mediante HTTPS, el servidor presenta un certificado digital X.509 al navegador. Este certificado, emitido por una autoridad de certificación (CA) de confianza, autentica la identidad del servidor. Una vez verificado, el navegador establece una conexión segura mediante cifrado simétrico, a menudo facilitado por métodos de intercambio de claves como Diffie-Hellman o Elliptic Curve Diffie-Hellman (ECDH).

La principal ventaja de HTTPS es que proporciona confidencialidad, integridad y autenticación para las comunicaciones web. Los datos transmitidos a través de HTTPS están protegidos contra la interceptación o la manipulación, y la identidad del servidor se verifica para evitar que los visitantes interactúen sin saberlo con sitios web maliciosos.

Los navegadores modernos ofrecen indicadores visuales, como un icono de candado en la barra de direcciones, para mostrar que un sitio web utiliza HTTPS. Sin embargo, si el certificado está vencido, mal configurado o no es de confianza, los navegadores pueden mostrar mensajes de advertencia para informar a los visitantes sobre posibles riesgos de seguridad. Estas advertencias ayudan a prevenir ataques como las intercepciones de intermediarios, ya que alertan a los visitantes cuando la conexión puede verse comprometida.

El cambio de HTTP a HTTPS ha sido impulsado por la creciente demanda de privacidad y seguridad en la web. La mayoría de los navegadores y motores de búsqueda ahora priorizan los sitios web habilitados para HTTPS, lo que refleja la importancia de la comunicación segura en el panorama digital actual.

El puerto predeterminado para la comunicación HTTPS es TCP 443, mientras que HTTP utiliza TCP 80. La diferencia en los números de puerto permite a los servidores distinguir entre tráfico seguro e inseguro. Cuando un navegador solicita una página web a través de HTTPS, la conexión inicial implica el protocolo de enlace TLS, durante el cual se autentica la identidad del servidor y se intercambian las claves de cifrado.

Una vez que se completa el protocolo de enlace TLS, el navegador envía la primera solicitud HTTP y todos los intercambios de datos posteriores se cifran, lo que garantiza que la información confidencial, como las credenciales de inicio de sesión o los detalles de pago, permanezca segura durante toda la sesión.

Muchos sitios web están configurados para redirigir automáticamente a los visitantes de HTTP a HTTPS para garantizar conexiones seguras. Por ejemplo, si un visitante solicita http://www.example.com, el servidor puede redirigirlo a https://www.example.com, lo que garantiza que la comunicación esté cifrada y sea segura.

La autenticación del servidor HTTPS se basa en certificados digitales, específicamente certificados X.509, para verificar la identidad del servidor. Cuando un visitante ingresa una URL, el navegador recupera el certificado digital del servidor, que contiene la clave pública y la información de identidad. Este certificado está firmado por una autoridad de certificación (CA) confiable, lo que garantiza que el servidor sea legítimo.

Los certificados X.509, también conocidos como certificados SSL o TLS, vinculan una clave pública a la identidad del servidor, denominada Sujeto (o Subject en inglés) del certificado. La firma digital de la CA confirma la validez de esta vinculación, que se almacena en el campo "signatureValue" del certificado.

El estándar X.509 define la estructura de los certificados digitales. La versión 3 (X.509v3) introdujo la posibilidad de agregar extensiones a los certificados, lo que permite incluir información adicional, como nombres alternativos para el servidor.

La extensión de Nombre alternativo del sujeto o Subject Alternative Name (SAN) en inglés, permite que un certificado asocie varias identidades, como nombres DNS o direcciones IP, con el mismo servidor. Esta flexibilidad es crucial para los servidores que operan bajo varios nombres de dominio o direcciones IP, ya que permite que un certificado cubra todas las identidades relevantes.

El proceso de verificación de un certificado implica comparar el Asunto o el Nombre alternativo del sujeto con la identidad del servidor. Si se encuentra una coincidencia, el certificado se considera válido. También se pueden utilizar comodines, como *.example.com, para hacer coincidir varios subdominios, lo que proporciona una mayor flexibilidad en la gestión de certificados.

Los certificados son emitidos por CA intermedios, que forman parte de una cadena de confianza que conduce a una CA raíz de confianza. El navegador verifica la cadena de confianza haciendo coincidir el campo Emisor(Issuer) de cada certificado con el Asunto del siguiente certificado de la cadena, y llega finalmente a una CA raíz de confianza.

Los certificados tienen un período de validez definido, que indica el tiempo que el certificado es válido. Si un certificado se ve comprometido antes de su vencimiento, la CA puede revocarlo y publicar su número de serie en una Lista de revocación de certificados (CRL). Los navegadores utilizan las CRL para verificar el estado del certificado y asegurarse de que no haya sido revocado.

Los servidores HTTPS suelen estar configurados para redirigir automáticamente el tráfico HTTP a HTTPS. Por ejemplo, si un navegador de Internet envía una solicitud a la siguiente URL, especificando HTTP:

El servidor HTTPS redirigiría al cliente a una URI que especifique HTTPS, como:

Cuando un navegador web se conecta a un sitio web mediante HTTPS, realiza varias comprobaciones de validez esenciales en el certificado X.509 del sitio web para garantizar que la conexión sea segura y confiable. Estas comprobaciones verifican la autenticidad del certificado, confirman la identidad del sitio web y protegen a los visitantes de posibles amenazas de seguridad, como ataques de intermediarios (man-in-the-middle). El navegador realiza una serie de pasos para evaluar la validez del certificado.

El formato de los certificados de clave pública está definido por el estándar X.509, que se publicó por primera vez en 1988. El formato de certificado X.509 versión 3 (v3), que se desarrolló en 1996, extiende el formato agregando disposiciones para campos de "Extensiones" adicionales (<<fig.22.2.4> >).

El campo Asunto del certificado de clave pública identifica el servidor HTTPS asociado con la clave pública almacenada en el campo Información de clave pública del sujeto (Subject Public Key Info). El campo Extensiones puede transmitir datos como información adicional de identificación del sujeto.

La extensión Subject Alternative Name de la especificación X. 509 permite vincular identidades adicionales al sujeto del certificado. Las opciones de Subject Alternative Name pueden incluir un nombre de host DNS, una dirección IP y más.

El nombre del sujeto puede incluirse en el campo Sujeto, en la extensión Nombre alternativo del sujeto o en ambos. Si hay una extensión SAN de tipo Nombre DNS, se utiliza como identificador del servidor. De lo contrario, se utiliza como identidad el campo Nombre común (Common Name) más específico del campo Sujeto del certificado.

Si hay más de una identidad de un tipo específico en el certificado (por ejemplo, más de un campo Nombre DNS), se considera aceptable una coincidencia en cualquier campo del conjunto. Los nombres pueden contener el carácter comodín * (asterisco) para que coincida con cualquier componente o fragmento de componente de nombre de dominio. Por lo tanto, si el URI es https://www.example.com/~carol/home.html y el certificado del servidor contiene *.basket.com, abcd.com y *.example.com como opciones de Nombre DNS, hay una coincidencia aceptable: el nombre *.example.com coincide con www.example.com. Ese nombre comodín no coincidiría con basket.carol.example.com porque este último nombre de dominio contiene un componente adicional.

De manera similar, c*.com coincide con carol.com porque el asterisco puede coincidir con un fragmento de un componente, pero no coincide con basket.com.

Si el campo de host del URI incluye una dirección IP, como https://8.8.8.8, en lugar de un nombre de host, el cliente verifica el campo Dirección IP de la extensión Nombre alternativo del sujeto. El campo Dirección IP debe estar presente en el certificado y debe coincidir exactamente con la dirección IP del URI.

A continuación, el navegador comprueba la cadena de confianza del certificado. Verifica que el certificado haya sido emitido y firmado por una autoridad de certificación (CA) de confianza. Esto implica rastrear la cadena del certificado desde el certificado del sitio web, pasando por los certificados intermedios, hasta una CA raíz de confianza, que está incluida en el almacén de certificados raíz preinstalado del navegador. Si algún certificado de esta cadena no es válido o ha sido emitido por una CA no confiable, el navegador marca la conexión como insegura y advierte al visitante.

Otra comprobación crítica es la relativa al período de validez del certificado. Cada certificado X.509 especifica un período de validez, definido por los campos notBefore y notAfter. El navegador compara la fecha y la hora actuales con este período de validez. Si el certificado ha expirado o aún no es válido, el navegador alerta al visitante sugiriendo que la conexión puede no ser segura. Este proceso garantiza que los certificados se renueven periódicamente para mantener una comunicación segura.

Además, los navegadores realizan comprobaciones para determinar si la CA ha revocado el certificado. Esto se hace a través de métodos como consultar una lista de revocación de certificados (CRL) o usar el protocolo de estado de certificados en línea (OCSP). Si el certificado ha sido revocado debido a razones como una clave comprometida o una emisión incorrecta, el navegador advierte al visitante que el certificado ya no es confiable y que la conexión puede ser insegura.

El navegador también valida la firma digital del certificado para confirmar que no ha sido alterado desde su emisión. Esto implica verificar la firma criptográfica de la CA emisora. Si la firma no se verifica, sugiere que el certificado puede haber sido alterado o falsificado, lo que lleva al navegador a bloquear la conexión para garantizar la seguridad del visitante.

Por último, los navegadores revisan los campos de extensión o uso de claves dentro del certificado. Estos campos especifican los propósitos previstos del certificado, como la autenticación del servidor o la firma de código. El navegador se asegura de que el certificado se esté utilizando de acuerdo con estos propósitos definidos. Si el certificado se está utilizando para un propósito fuera del ámbito permitido, el navegador emite una advertencia al visitante.

Estas comprobaciones garantizan colectivamente la seguridad de las comunicaciones web al validar la autenticidad, la integridad y el uso adecuado de los certificados X.509. Si alguna de estas comprobaciones falla, el navegador muestra una advertencia de seguridad o un mensaje de error, que aconseja al visitante proceder con precaución o evitar el sitio web por completo. Este riguroso proceso de validación desempeña un papel fundamental en el mantenimiento de la fiabilidad de las interacciones en línea y ayuda a evitar que entidades maliciosas se hagan pasar por sitios web legítimos.

Determinar si un sitio web está encriptado es un paso crucial para garantizar una comunicación segura entre el navegador del visitante y el servidor del sitio web. Los sitios web encriptados utilizan HTTPS, que proporciona encriptación a través del protocolo TLS, lo que garantiza que los datos intercambiados entre el visitante y el sitio permanezcan privados y protegidos contra escuchas o manipulaciones.

Para determinar si un sitio web está encriptado, los visitantes pueden basarse en algunas señales visuales que ofrecen los navegadores web. El indicador más común es el icono del candado que aparece en la barra de direcciones del navegador a la izquierda de la URL. Si el sitio web utiliza HTTPS, el candado aparecerá cerrado o bloqueado, lo que indica que la conexión es segura. En algunos navegadores, al hacer clic en el icono del candado se mostrará información más detallada sobre el cifrado del sitio web, como el tipo de cifrado que se utiliza y la autoridad de certificación que lo emite.

Además del candado, la URL en sí es otro indicador de si un sitio está cifrado. Los sitios web seguros comienzan con https://, mientras que los sitios no cifrados usan http://. La presencia de https:// indica que la conexión está protegida por cifrado TLS. Algunos navegadores también pueden resaltar esto cambiando el color de la barra de direcciones cuando se establece una conexión segura.

Cuando un sitio web no utiliza cifrado, los navegadores modernos suelen mostrar un mensaje de advertencia para informar a los visitantes de los posibles riesgos. Por ejemplo, cuando un visitante intenta acceder a un sitio mediante HTTP simple (sin cifrado), el navegador puede mostrar un mensaje como “No seguro” en la barra de direcciones. En algunos casos, los navegadores pueden mostrar una advertencia más destacada, alertando al visitante de que la “conexión no es privada” y aconsejándole que evite introducir información confidencial, como contraseñas o números de tarjetas de crédito. Los navegadores como Google Chrome, Mozilla Firefox y Microsoft Edge han sido cada vez más estrictos a la hora de marcar los sitios web no cifrados, especialmente en las páginas en las que se pide a los visitantes que envíen información personal.

Si la configuración HTTPS de un sitio web no es válida o está configurada de forma incorrecta, los navegadores muestran mensajes de advertencia adicionales. Por ejemplo, si un sitio tiene un certificado “vencido”, “mal configurado” o “no confiable”, el navegador puede mostrar un mensaje de advertencia de página completa con una descripción del problema. Mensajes como “Su conexión no es privada” o “Potencial riesgo de seguridad a futuro” indican que el certificado ha vencido, ha sido revocado o está firmado por una CA no confiable. Estas advertencias suelen recomendar que los visitantes regresen a un lugar seguro y no continúen visitando el sitio, aunque a menudo ofrecen una opción para continuar por cuenta y riesgo del visitante.

Para determinar si un sitio web está cifrado, es necesario comprobar los indicadores visuales como el icono del candado y la URL con el símbolo https://. Los navegadores también muestran advertencias claras cuando un sitio no es seguro, lo que garantiza que los visitantes estén informados de los posibles riesgos asociados con las conexiones no cifradas o mal configuradas. Comprender estos mensajes del navegador es esencial para navegar de forma segura y evitar la exposición a amenazas de seguridad.