stringtranslate.com

HTTPS

El Protocolo Seguro de Transferencia de Hipertexto ( HTTP ) es una extensión del Protocolo de Transferencia de Hipertexto (HTTP). Utiliza el cifrado para la comunicación segura a través de una red informática y se utiliza ampliamente en Internet . [1] [2] En HTTPS, el protocolo de comunicación se cifra mediante Seguridad de la Capa de Transporte (TLS) o, anteriormente, Capa de Sockets Seguros (SSL). Por lo tanto, el protocolo también se conoce como HTTP sobre TLS , [3] o HTTP sobre SSL .

Las principales motivaciones para HTTPS son la autenticación del sitio web al que se accede y la protección de la privacidad e integridad de los datos intercambiados mientras están en tránsito. Protege contra ataques de intermediarios , y el cifrado de bloques bidireccional de las comunicaciones entre un cliente y un servidor protege las comunicaciones contra escuchas y manipulaciones . [4] [5] El aspecto de autenticación de HTTPS requiere que un tercero de confianza firme certificados digitales del lado del servidor . Esta era históricamente una operación costosa, lo que significaba que las conexiones HTTPS completamente autenticadas generalmente solo se encontraban en servicios de transacciones de pago seguros y otros sistemas de información corporativa seguros en la World Wide Web . En 2016, una campaña de la Electronic Frontier Foundation con el apoyo de los desarrolladores de navegadores web llevó a que el protocolo se volviera más frecuente. [6] HTTPS ahora es utilizado con más frecuencia por los usuarios web que el HTTP original, no seguro, principalmente para proteger la autenticidad de la página en todo tipo de sitios web, cuentas seguras y mantener privadas las comunicaciones, la identidad y la navegación web del usuario.

Descripción general

URL que comienza con el esquema HTTPS y la etiqueta de nombre de dominio WWW

El esquema de Identificador Uniforme de Recursos (URI) HTTPS tiene una sintaxis de uso idéntica al esquema HTTP. Sin embargo, HTTPS indica al navegador que utilice una capa de cifrado adicional de SSL/TLS para proteger el tráfico. SSL/TLS es especialmente adecuado para HTTP, ya que puede proporcionar cierta protección incluso si solo se autentica un lado de la comunicación . Este es el caso de las transacciones HTTP a través de Internet, donde normalmente solo se autentica el servidor (mediante el examen del certificado del servidor por parte del cliente ).

HTTPS crea un canal seguro en una red insegura. Esto garantiza una protección razonable contra intrusos y ataques de intermediarios , siempre que se utilicen conjuntos de cifrado adecuados y que el certificado del servidor esté verificado y sea confiable.

Debido a que HTTPS incorpora HTTP por completo sobre TLS, se puede cifrar la totalidad del protocolo HTTP subyacente. Esto incluye la URL de la solicitud , los parámetros de consulta, los encabezados y las cookies (que a menudo contienen información de identificación sobre el usuario). Sin embargo, debido a que las direcciones de sitios web y los números de puerto son necesariamente parte de los protocolos TCP/IP subyacentes , HTTPS no puede proteger su divulgación. En la práctica, esto significa que incluso en un servidor web configurado correctamente, los espías pueden inferir la dirección IP y el número de puerto del servidor web, y a veces incluso el nombre de dominio (por ejemplo, www.example.org, pero no el resto de la URL) con el que se está comunicando un usuario, junto con la cantidad de datos transferidos y la duración de la comunicación, aunque no el contenido de la comunicación. [4]

Los navegadores web saben cómo confiar en los sitios web HTTPS en función de las autoridades de certificación que vienen preinstaladas en su software. De esta manera, los creadores de navegadores web confían en las autoridades de certificación para que proporcionen certificados válidos. Por lo tanto, un usuario debería confiar en una conexión HTTPS a un sitio web si se cumplen todas las siguientes condiciones:

El protocolo HTTPS es especialmente importante en redes inseguras y redes que pueden ser objeto de manipulación. Las redes inseguras, como los puntos de acceso Wi-Fi públicos, permiten que cualquier persona que se encuentre en la misma red local detecte paquetes de datos y descubra información confidencial que no está protegida por HTTPS. Además, se ha observado que algunas redes WLAN gratuitas y de pago alteran páginas web mediante la inyección de paquetes para publicar sus propios anuncios en otros sitios web. Esta práctica se puede explotar de forma maliciosa de muchas maneras, como inyectando malware en páginas web y robando información privada de los usuarios. [7]

El protocolo HTTPS también es importante para las conexiones a través de la red Tor , ya que los nodos Tor maliciosos podrían dañar o alterar el contenido que pasa a través de ellos de manera insegura e inyectar malware en la conexión. Esta es una de las razones por las que la Electronic Frontier Foundation y el Proyecto Tor comenzaron el desarrollo de HTTPS Everywhere [4] , que está incluido en el navegador Tor. [8]

A medida que se revela más información sobre la vigilancia masiva global y los delincuentes que roban información personal, el uso de la seguridad HTTPS en todos los sitios web se está volviendo cada vez más importante, independientemente del tipo de conexión a Internet que se utilice. [9] [10] Aunque los metadatos sobre las páginas individuales que visita un usuario pueden no considerarse confidenciales, cuando se agregan pueden revelar mucho sobre el usuario y comprometer su privacidad. [11] [12] [13]

La implementación de HTTPS también permite el uso de HTTP/2 y HTTP/3 (y sus predecesores SPDY y QUIC ), que son nuevas versiones de HTTP diseñadas para reducir los tiempos de carga, el tamaño y la latencia de las páginas.

Se recomienda utilizar HTTP Strict Transport Security (HSTS) con HTTPS para proteger a los usuarios de ataques de intermediarios, especialmente la eliminación de SSL . [13] [14]

El protocolo HTTPS no debe confundirse con el protocolo HTTP seguro (S-HTTP), poco utilizado y especificado en el RFC 2660.

Uso en sitios web

En abril de 2018 , el 33,2 % de los 1 000 000 de sitios web más populares según Alexa utilizan HTTPS como predeterminado [15] y el 70 % de las cargas de páginas (medidas por Firefox Telemetry) utilizan HTTPS. [16] En diciembre de 2022 , el 58,4 % de los 135 422 sitios web más populares de Internet tienen una implementación segura de HTTPS, [17] Sin embargo, a pesar del lanzamiento de TLS 1.3 en 2018, la adopción ha sido lenta y muchos aún permanecen en el antiguo protocolo TLS 1.2. [18]

Integración del navegador

La mayoría de los navegadores muestran una advertencia si reciben un certificado no válido. Los navegadores más antiguos, al conectarse a un sitio con un certificado no válido, presentaban al usuario un cuadro de diálogo que le preguntaba si deseaba continuar. Los navegadores más nuevos muestran una advertencia en toda la ventana. Los navegadores más nuevos también muestran de forma destacada la información de seguridad del sitio en la barra de direcciones . Los certificados de validación extendida muestran la entidad legal en la información del certificado. La mayoría de los navegadores también muestran una advertencia al usuario cuando visita un sitio que contiene una mezcla de contenido cifrado y no cifrado. Además, muchos filtros web devuelven una advertencia de seguridad cuando visitan sitios web prohibidos.

La Electronic Frontier Foundation , que opina que "en un mundo ideal, cada solicitud web podría tener como valor predeterminado HTTPS", ha proporcionado un complemento llamado HTTPS Everywhere para Mozilla Firefox , Google Chrome , Chromium y Android , que habilita HTTPS de forma predeterminada para cientos de sitios web de uso frecuente. [19] [20]

A partir de la versión 83, Firefox ha incorporado la posibilidad de obligar a un navegador web a cargar únicamente contenido HTTPS. [21] A partir de la versión 94, Google Chrome puede "utilizar siempre conexiones seguras" si se activa esta opción en la configuración del navegador. [22] [23]

Seguridad

La seguridad de HTTPS es la del TLS subyacente, que normalmente utiliza claves públicas y privadas de largo plazo para generar una clave de sesión de corto plazo , que luego se utiliza para cifrar el flujo de datos entre el cliente y el servidor. Los certificados X.509 se utilizan para autenticar el servidor (y a veces también al cliente). Como consecuencia, las autoridades de certificación y los certificados de clave pública son necesarios para verificar la relación entre el certificado y su propietario, así como para generar, firmar y administrar la validez de los certificados. Si bien esto puede ser más beneficioso que verificar las identidades a través de una red de confianza , las revelaciones de vigilancia masiva de 2013 llamaron la atención sobre las autoridades de certificación como un posible punto débil que permite ataques de intermediarios . [24] [25] Una propiedad importante en este contexto es el secreto hacia adelante , que garantiza que las comunicaciones cifradas registradas en el pasado no se puedan recuperar y descifrar si las claves secretas o las contraseñas de largo plazo se ven comprometidas en el futuro. No todos los servidores web proporcionan secreto hacia adelante. [26] [ necesita actualización ]

Para que el protocolo HTTPS sea eficaz, un sitio debe estar alojado completamente en HTTPS. Si algunos de los contenidos del sitio se cargan en HTTP (scripts o imágenes, por ejemplo), o si solo una página determinada que contiene información confidencial, como una página de inicio de sesión, se carga en HTTPS mientras que el resto del sitio se carga en HTTP simple, el usuario será vulnerable a ataques y vigilancia. Además, las cookies en un sitio servido a través de HTTPS deben tener habilitado el atributo seguro . En un sitio que contiene información confidencial, el usuario y la sesión quedarán expuestos cada vez que se acceda a ese sitio con HTTP en lugar de HTTPS. [13]

Técnico

Diferencia con HTTP

Las URL HTTPS comienzan con "https://" y utilizan el puerto 443 de forma predeterminada, mientras que las URL HTTP comienzan con "http://" y utilizan el puerto 80 de forma predeterminada.

El protocolo HTTP no está cifrado y, por lo tanto, es vulnerable a ataques de intermediarios y de espionaje , que pueden permitir a los atacantes obtener acceso a cuentas de sitios web e información confidencial, y modificar páginas web para inyectar malware o anuncios. El protocolo HTTPS está diseñado para resistir este tipo de ataques y se considera seguro contra ellos (con la excepción de las implementaciones de HTTPS que utilizan versiones obsoletas de SSL).

Capas de red

HTTP opera en la capa más alta del modelo TCP/IP (la capa de aplicación ), al igual que el protocolo de seguridad TLS (que opera como una subcapa inferior de la misma capa), que encripta un mensaje HTTP antes de su transmisión y desencripta un mensaje al llegar. Estrictamente hablando, HTTPS no es un protocolo independiente, sino que se refiere al uso de HTTP ordinario sobre una conexión SSL/TLS encriptada .

HTTPS cifra todo el contenido de los mensajes, incluidos los encabezados HTTP y los datos de solicitud/respuesta. Con la excepción del posible ataque criptográfico CCA descrito en la sección de limitaciones a continuación, un atacante debería poder descubrir, como máximo, que se está produciendo una conexión entre dos partes, junto con sus nombres de dominio y direcciones IP.

Configuración del servidor

Para preparar un servidor web para que acepte conexiones HTTPS, el administrador debe crear un certificado de clave pública para el servidor web. Este certificado debe estar firmado por una autoridad de certificación de confianza para que el navegador web lo acepte sin previo aviso. La autoridad certifica que el titular del certificado es el operador del servidor web que lo presenta. Los navegadores web generalmente se distribuyen con una lista de certificados de firma de las principales autoridades de certificación para que puedan verificar los certificados firmados por ellas.

Adquisición de certificados

Existen varias autoridades de certificación comerciales que ofrecen certificados SSL/TLS pagos de varios tipos, incluidos certificados de validación extendida .

Let's Encrypt , lanzado en abril de 2016, [27] proporciona un servicio gratuito y automatizado que entrega certificados SSL/TLS básicos a sitios web. [28] Según la Electronic Frontier Foundation , Let's Encrypt hará que cambiar de HTTP a HTTPS sea "tan fácil como emitir un comando o hacer clic en un botón". [29] La mayoría de los servidores web y proveedores de la nube ahora aprovechan Let's Encrypt, proporcionando certificados gratuitos a sus clientes.

Utilizar como control de acceso

El sistema también se puede utilizar para la autenticación de clientes con el fin de limitar el acceso a un servidor web a los usuarios autorizados. Para ello, el administrador del sitio normalmente crea un certificado para cada usuario, que el usuario carga en su navegador. Normalmente, el certificado contiene el nombre y la dirección de correo electrónico del usuario autorizado y el servidor lo comprueba automáticamente en cada conexión para verificar la identidad del usuario, posiblemente sin siquiera requerir una contraseña.

En caso de clave secreta (privada) comprometida

Una propiedad importante en este contexto es el secreto perfecto hacia adelante (PFS). Poseer una de las claves secretas asimétricas de largo plazo utilizadas para establecer una sesión HTTPS no debería facilitar la derivación de la clave de sesión de corto plazo para luego descifrar la conversación, incluso en un momento posterior. El intercambio de claves Diffie-Hellman (DHE) y el intercambio de claves Diffie-Hellman de curva elíptica (ECDHE) son en 2013 los únicos esquemas conocidos que tienen esa propiedad. En 2013, solo el 30% de las sesiones de Firefox, Opera y Chromium Browser lo usaban, y casi el 0% de las sesiones de Safari de Apple y Microsoft Internet Explorer . [26] TLS 1.3, publicado en agosto de 2018, eliminó el soporte para cifrados sin secreto hacia adelante. A febrero de 2019 , el 96,6% de los servidores web encuestados admiten alguna forma de secreto hacia adelante, y el 52,1% usará secreto hacia adelante con la mayoría de los navegadores. [30] A julio de 2023 , el 99,6 % de los servidores web encuestados admiten algún tipo de secreto hacia adelante, y el 75,2 % utilizará secreto hacia adelante con la mayoría de los navegadores. [31]

Revocación de certificado

Un certificado puede ser revocado antes de su vencimiento, por ejemplo, porque se ha comprometido la confidencialidad de la clave privada. Las versiones más nuevas de los navegadores más populares, como Firefox , [32] Opera , [33] e Internet Explorer en Windows Vista [34], implementan el Protocolo de estado de certificado en línea (OCSP) para verificar que no sea así. El navegador envía el número de serie del certificado a la autoridad de certificación o a su delegado a través de OCSP (Protocolo de estado de certificado en línea) y la autoridad responde, indicando al navegador si el certificado sigue siendo válido o no. [35] La CA también puede emitir una CRL para informar a las personas que estos certificados están revocados. Las CRL ya no son requeridas por el foro CA/Navegador, [36] sin embargo, todavía son ampliamente utilizadas por las CA. La mayoría de los estados de revocación en Internet desaparecen poco después de la expiración de los certificados. [37]

Limitaciones

El cifrado SSL (Secure Sockets Layer) y TLS (Transport Layer Security) se puede configurar en dos modos: simple y mutuo . En el modo simple, la autenticación solo la realiza el servidor. La versión mutua requiere que el usuario instale un certificado de cliente personal en el navegador web para la autenticación del usuario. [38] En ambos casos, el nivel de protección depende de la corrección de la implementación del software y de los algoritmos criptográficos en uso. [ cita requerida ]

SSL/TLS no impide la indexación del sitio por parte de un rastreador web y, en algunos casos, la URI del recurso cifrado se puede inferir conociendo únicamente el tamaño de la solicitud/respuesta interceptada. [39] Esto permite que un atacante tenga acceso al texto simple (el contenido estático disponible públicamente) y al texto cifrado (la versión cifrada del contenido estático), lo que permite un ataque criptográfico . [ cita requerida ]

Debido a que TLS opera en un nivel de protocolo inferior al de HTTP y no tiene conocimiento de los protocolos de nivel superior, los servidores TLS solo pueden presentar estrictamente un certificado para una combinación particular de dirección y puerto. [40] En el pasado, esto significaba que no era factible utilizar alojamiento virtual basado en nombres con HTTPS. Existe una solución llamada Indicación de nombre de servidor (SNI), que envía el nombre de host al servidor antes de cifrar la conexión, aunque muchos navegadores antiguos no admiten esta extensión. El soporte para SNI está disponible desde Firefox 2, Opera 8, Apple Safari 2.1, Google Chrome 6 e Internet Explorer 7 en Windows Vista . [41] [42] [43]

En la conferencia Blackhat de 2009 se presentó un tipo sofisticado de ataque de intermediario llamado SSL stripping . Este tipo de ataque derrota la seguridad proporcionada por HTTPS al cambiar el enlace por un enlace, aprovechando el hecho de que pocos usuarios de Internet realmente escriben "https" en la interfaz de su navegador: llegan a un sitio seguro haciendo clic en un enlace y, por lo tanto, se les engaña para que piensen que están usando HTTPS cuando, de hecho, están usando HTTP. El atacante luego se comunica en claro con el cliente. [44] Esto impulsó el desarrollo de una contramedida en HTTP llamada HTTP Strict Transport Security . [ cita requerida ]https:http:

Se ha demostrado que el protocolo HTTPS es vulnerable a una serie de ataques de análisis de tráfico . Los ataques de análisis de tráfico son un tipo de ataque de canal lateral que se basa en variaciones en el tiempo y el tamaño del tráfico para inferir propiedades sobre el tráfico cifrado en sí. El análisis de tráfico es posible porque el cifrado SSL/TLS cambia el contenido del tráfico, pero tiene un impacto mínimo en el tamaño y el tiempo del tráfico. En mayo de 2010, un artículo de investigación realizado por investigadores de Microsoft Research y la Universidad de Indiana descubrió que se pueden inferir datos confidenciales detallados del usuario a partir de canales laterales, como los tamaños de los paquetes. Los investigadores descubrieron que, a pesar de la protección HTTPS en varias aplicaciones web de alto perfil y de primera línea en los ámbitos de la atención sanitaria, los impuestos, las inversiones y las búsquedas web, un espía podría inferir las enfermedades/medicamentos/cirugías del usuario, sus ingresos familiares y secretos de inversión. [45]

El hecho de que la mayoría de los sitios web modernos, incluidos Google, Yahoo! y Amazon, utilicen HTTPS causa problemas a muchos usuarios que intentan acceder a puntos de acceso Wi-Fi públicos, porque una página de inicio de sesión de punto de acceso Wi-Fi de portal cautivo no se carga si el usuario intenta abrir un recurso HTTPS. [46] Varios sitios web, como NeverSSL, [47] garantizan que siempre permanecerán accesibles mediante HTTP. [48]

Historia

Netscape Communications creó HTTPS en 1994 para su navegador web Netscape Navigator . [49] Originalmente, HTTPS se usaba con el protocolo SSL . A medida que SSL evolucionó hacia Transport Layer Security (TLS), HTTPS se especificó formalmente mediante RFC 2818 en mayo de 2000. Google anunció en febrero de 2018 que su navegador Chrome marcaría los sitios HTTP como "No seguros" después de julio de 2018. [50] Esta medida fue para alentar a los propietarios de sitios web a implementar HTTPS, como un esfuerzo por hacer que la World Wide Web sea más segura.

Véase también

Referencias

  1. ^ "Asegure su sitio con HTTPS". Soporte de Google . Google Inc. Archivado desde el original el 1 de marzo de 2015 . Consultado el 20 de octubre de 2018 .
  2. ^ "¿Qué es HTTPS?". Comodo CA Limited . Archivado desde el original el 12 de febrero de 2015. Consultado el 20 de octubre de 2018. El Protocolo de transferencia de hipertexto seguro (HTTPS) es la versión segura de HTTP [...]{{cite web}}: CS1 maint: URL no apta ( enlace )
  3. ^ "Esquema de URI https". Semántica HTTP. IETF . Junio ​​de 2022. Sec. 4.2.2. doi : 10.17487/RFC9110 . RFC 9110.
  4. ^ abc «Preguntas frecuentes sobre HTTPS Everywhere». 8 de noviembre de 2016. Archivado desde el original el 14 de noviembre de 2018. Consultado el 20 de octubre de 2018 .
  5. ^ "Estadísticas de uso del protocolo predeterminado https para sitios web, julio de 2019". w3techs.com . Archivado desde el original el 1 de agosto de 2019 . Consultado el 20 de julio de 2019 .
  6. ^ "Encriptación de la Web". Electronic Frontier Foundation . Archivado desde el original el 18 de noviembre de 2019. Consultado el 19 de noviembre de 2019 .
  7. ^ "Hotel Wifi JavaScript Injection". JustInsomnia . 3 de abril de 2012. Archivado desde el original el 18 de noviembre de 2018. Consultado el 20 de octubre de 2018 .
  8. ^ The Tor Project, Inc. "¿Qué es el navegador Tor?". TorProject.org . Archivado desde el original el 17 de julio de 2013. Consultado el 30 de mayo de 2012 .
  9. ^ Konigsburg, Eitan; Pant, Rajiv; Kvochko, Elena (13 de noviembre de 2014). «Adopción del protocolo HTTPS». The New York Times . Archivado desde el original el 8 de enero de 2019. Consultado el 20 de octubre de 2018 .
  10. ^ Gallagher, Kevin (12 de septiembre de 2014). "Quince meses después de las revelaciones de la NSA, ¿por qué no hay más medios de comunicación que utilicen HTTPS?". Fundación para la Libertad de Prensa. Archivado desde el original el 10 de agosto de 2018. Consultado el 20 de octubre de 2018 .
  11. ^ "HTTPS como señal de clasificación". Blog de Google Webmaster Central . Google Inc. 6 de agosto de 2014. Archivado desde el original el 17 de octubre de 2018. Consultado el 20 de octubre de 2018. Puede hacer que su sitio sea seguro con HTTPS (Protocolo de transferencia de hipertexto seguro) [...]
  12. ^ Grigorik, Ilya; Far, Pierre (26 de junio de 2014). «Google I/O 2014: HTTPS Everywhere». Google Developers. Archivado desde el original el 20 de noviembre de 2018. Consultado el 20 de octubre de 2018 .
  13. ^ abc «Cómo implementar HTTPS correctamente». 15 de noviembre de 2010. Archivado desde el original el 10 de octubre de 2018. Consultado el 20 de octubre de 2018 .
  14. ^ "Seguridad de transporte estricta HTTP". Red de desarrolladores de Mozilla . Archivado desde el original el 19 de octubre de 2018. Consultado el 20 de octubre de 2018 .
  15. ^ "Estadísticas de uso de HTTPS en 1 millón de sitios web principales". StatOperator.com . Archivado desde el original el 9 de febrero de 2019. Consultado el 20 de octubre de 2018 .
  16. ^ "Estadísticas de Let's Encrypt". LetsEncrypt.org . Archivado desde el original el 19 de octubre de 2018. Consultado el 20 de octubre de 2018 .
  17. ^ "Qualys SSL Labs - SSL Pulse". www.ssllabs.com . 4 de diciembre de 2022. Archivado desde el original el 7 de diciembre de 2022 . Consultado el 7 de diciembre de 2022 ..
  18. ^ "TLS 1.3: La lenta adopción de un cifrado web más fuerte está fortaleciendo a los malos". Help Net Security . 6 de abril de 2020. Archivado desde el original el 24 de mayo de 2022 . Consultado el 23 de mayo de 2022 .
  19. ^ Eckersley, Peter (17 de junio de 2010). «Encrypt the Web with the HTTPS Everywhere Firefox Extension». Blog de la EFF . Archivado desde el original el 25 de noviembre de 2018. Consultado el 20 de octubre de 2018 .
  20. ^ "HTTPS Everywhere". Proyectos EFF . 7 de octubre de 2011. Archivado desde el original el 5 de junio de 2011. Consultado el 20 de octubre de 2018 .
  21. ^ "Modo solo HTTPS en Firefox". Archivado desde el original el 12 de noviembre de 2021 . Consultado el 12 de noviembre de 2021 .
  22. ^ "Administrar la seguridad de Chrome - Android - Ayuda de Google Chrome". support.google.com . Archivado desde el original el 7 de marzo de 2022 . Consultado el 7 de marzo de 2022 .
  23. ^ "Manos a la obra con el modo HTTPS-First de Chrome". Techdows . 19 de julio de 2021. Archivado desde el original el 7 de marzo de 2022 . Consultado el 7 de marzo de 2022 .
  24. ^ Singel, Ryan (24 de marzo de 2010). «Law Enforcement Appliance Subverts SSL» (Dispositivo de aplicación de la ley subvierte SSL). Wired . Archivado desde el original el 17 de enero de 2019. Consultado el 20 de octubre de 2018 .
  25. ^ Schoen, Seth (24 de marzo de 2010). «New Research Suggests That Governments May Fake SSL Certificates» (Una nueva investigación sugiere que los gobiernos pueden falsificar certificados SSL). EFF . Archivado desde el original el 4 de enero de 2016. Consultado el 20 de octubre de 2018 .
  26. ^ ab Duncan, Robert (25 de junio de 2013). «SSL: interceptado hoy, descifrado mañana». Netcraft . Archivado desde el original el 6 de octubre de 2018. Consultado el 20 de octubre de 2018 .
  27. ^ Cimpanu, Catalin (12 de abril de 2016). «Let's Encrypt se lanzó hoy y actualmente protege 3,8 millones de dominios». Softpedia News. Archivado desde el original el 9 de febrero de 2019. Consultado el 20 de octubre de 2018 .
  28. ^ Kerner, Sean Michael (18 de noviembre de 2014). "Let's Encrypt Effort tiene como objetivo mejorar la seguridad en Internet". eWeek.com . Quinstreet Enterprise. Archivado desde el original el 2 de abril de 2023. Consultado el 20 de octubre de 2018 .
  29. ^ Eckersley, Peter (18 de noviembre de 2014). «Lanzamiento en 2015: una autoridad de certificación para cifrar toda la Web». Electronic Frontier Foundation . Archivado desde el original el 18 de noviembre de 2018. Consultado el 20 de octubre de 2018 .
  30. ^ Qualys SSL Labs . «SSL Pulse». Archivado desde el original (3 de febrero de 2019) el 15 de febrero de 2019. Consultado el 25 de febrero de 2019 .
  31. ^ "Qualys SSL Labs - SSL Pulse". www.ssllabs.com . Consultado el 4 de septiembre de 2023 .
  32. ^ "Política de privacidad de Mozilla Firefox". Mozilla Foundation . 27 de abril de 2009. Archivado desde el original el 18 de octubre de 2018. Consultado el 20 de octubre de 2018 .
  33. ^ "Opera 8 lanzado en FTP". Softpedia . 19 de abril de 2005. Archivado desde el original el 9 de febrero de 2019 . Consultado el 20 de octubre de 2018 .
  34. ^ Lawrence, Eric (31 de enero de 2006). «Mejoras de seguridad HTTPS en Internet Explorer 7». Microsoft Docs . Archivado desde el original el 24 de octubre de 2021. Consultado el 24 de octubre de 2021 .
  35. ^ Myers, Michael; Ankney, Rich; Malpani, Ambarish; Galperin, Slava; Adams, Carlisle (20 de junio de 1999). "Online Certificate Status Protocol – OCSP". Grupo de trabajo de ingeniería de Internet . doi :10.17487/RFC2560. Archivado desde el original el 25 de agosto de 2011. Consultado el 20 de octubre de 2018 .
  36. ^ "Requisitos básicos". Foro CAB. 4 de septiembre de 2013. Archivado desde el original el 20 de octubre de 2014. Consultado el 1 de noviembre de 2021 .
  37. ^ Korzhitskii, N.; Carlsson, N. (30 de marzo de 2021). "Estados de revocación en Internet". Medición pasiva y activa . Apuntes de clase en informática. Vol. 12671. págs. 175–191. arXiv : 2102.04288 . doi :10.1007/978-3-030-72582-2_11. ISBN 978-3-030-72581-5.
  38. ^ "Administrar certificados de cliente en dispositivos Chrome – Ayuda de Chrome para empresas y educación". support.google.com . Archivado desde el original el 9 de febrero de 2019 . Consultado el 20 de octubre de 2018 .
  39. ^ Pusep, Stanislaw (31 de julio de 2008). «The Pirate Bay un-SSL» (PDF) . Archivado (PDF) del original el 20 de junio de 2018. Consultado el 20 de octubre de 2018 .
  40. ^ "SSL/TLS Strong Encryption: FAQ" (Cifrado fuerte SSL/TLS: preguntas frecuentes). apache.org . Archivado desde el original el 19 de octubre de 2018. Consultado el 20 de octubre de 2018 .
  41. ^ Lawrence, Eric (22 de octubre de 2005). «Próximas mejoras de HTTPS en Internet Explorer 7 Beta 2». Microsoft . Archivado desde el original el 20 de septiembre de 2018. Consultado el 20 de octubre de 2018 .
  42. ^ "Indicación del nombre del servidor (SNI)". dentro de la cabeza de aebrahim . 21 de febrero de 2006. Archivado desde el original el 10 de agosto de 2018 . Consultado el 20 de octubre de 2018 .
  43. ^ Pierre, Julien (19 de diciembre de 2001). «Browser support for TLS server name indicator» (Compatibilidad del navegador con la indicación del nombre del servidor TLS). Bugzilla . Fundación Mozilla. Archivado desde el original el 8 de octubre de 2018 . Consultado el 20 de octubre de 2018 .
  44. ^ "sslstrip 0.9". Archivado desde el original el 20 de junio de 2018 . Consultado el 20 de octubre de 2018 .
  45. ^ Shuo Chen; Rui Wang; XiaoFeng Wang; Kehuan Zhang (20 de mayo de 2010). "Fugas de canal lateral en aplicaciones web: una realidad hoy, un desafío mañana". Microsoft Research . Simposio IEEE sobre seguridad y privacidad 2010. Archivado desde el original el 22 de julio de 2018 . Consultado el 20 de octubre de 2018 .
  46. ^ Guaay, Matthew (21 de septiembre de 2017). «Cómo forzar la apertura de la página de inicio de sesión de una red Wi-Fi pública». Archivado desde el original el 10 de agosto de 2018. Consultado el 20 de octubre de 2018 .
  47. ^ "NuncaSSL".
  48. ^ "NeverSSL". Archivado desde el original el 1 de septiembre de 2018. Consultado el 20 de octubre de 2018 .
  49. ^ Walls, Colin (2005). Software integrado: los trabajos. Newnes. pág. 344. ISBN 0-7506-7954-9Archivado desde el original el 9 de febrero de 2019 . Consultado el 20 de octubre de 2018 .
  50. ^ "Una web segura llegó para quedarse". Blog de Chromium . Archivado desde el original el 24 de abril de 2019. Consultado el 22 de abril de 2019 .

Enlaces externos