Fíjate ahora mismo en la barra de direcciones de tu navegador. Es casi seguro que la dirección del sitio web empiece por «https» y muestre un pequeño candado; si no fuera así, tu navegador probablemente te avisaría antes de permitirte continuar. Esa letra extra, la «s», ha transformado silenciosamente la web. Esa pequeña «s» significa «seguro», y es mucho más importante de lo que la gente cree. Este blog ofrece una comparación sencilla entre HTTP y HTTPS: en qué se diferencian realmente, por qué es importante y dónde residen los verdaderos matices.
HTTP frente a HTTPS: resumen rápido
Aquí va la respuesta breve antes de entrar en detalles. HTTP y HTTPS son el mismo protocolo. Los mismos métodos, los mismos encabezados, los mismos códigos de estado y la misma estructura de URL. Una solicitud HTTPS es, byte a byte, la solicitud HTTP que habría sido; simplemente se transmite de forma diferente. HTTPS es HTTP transportado dentro de una sesión de TLS , por lo que la definición es tan sencilla: un esquema, un puerto predeterminado y una instrucción para completar el protocolo de enlace TLS antes de utilizar HTTP. Lo que TLS añade son tres propiedades, no solo el cifrado.
Confidencialidad: los datos se transmiten cifrados. Cualquier persona que se encuentre en la ruta ve un texto cifrado que es indistinguible del ruido, en lugar de tu solicitud en texto legible.
Integridad: TLS utiliza cifrado autenticado, lo que significa que cualquier modificación en un registro falla la autenticación y la conexión se interrumpe, en lugar de entregar silenciosamente el contenido alterado.
Autenticación: el servidor presenta un certificado digital que vincula su clave pública al nombre del servidor que has introducido, encadenándolo a un punto de confianza que tu navegador ya tenía.
Podría decirse que este último es el aspecto más importante. Sin él, un atacante que se encuentre en la ruta simplemente establece una conexión cifradacontigoy otra independiente con el origen, y la confidencialidad no sirve de nada.
Puerto 80 frente a puerto 443
Un puerto es un número que indica a qué programa de un equipo va dirigido el tráfico de red. Cuando el tráfico de red llega a la «puerta» de tu ordenador, comprueba el puerto que lleva y se lo comunica al ordenador, que a su vez lo redirige al programa adecuado. Los navegadores web utilizan el puerto 80 para conectarse a los servidores web a través del Protocolo de Transferencia de Hipertexto (HTTP). El protocolo HTTPS utiliza el puerto 443, donde la conexión está cifrada y el servidor está autenticado. Cuando un navegador necesita una conexión segura, cambia automáticamente a la ruta cifrada, siempre y cuando el servidor tenga instalado un certificado válido.
Texto sin formato frente a texto cifrado
HTTP es un protocolo de texto sin formato que deja al descubierto todo lo que circula por la red: encabezados, cookies, cuerpo del mensaje, etc., lo que significa que resulta relativamente fácil para alguien interceptar y leer los datos en tránsito y conocer todo lo que se ha enviado durante la comunicación. No es adecuado para nada que requiera confidencialidad. Además, HTTP expone a los usuarios a servidores no autenticados que pueden contener malware u otras amenazas. HTTPS, por el contrario, cifra la comunicación y autentifica el servidor. Aunque un atacante capture el tráfico, el contenido cifrado aparecerá como un galimatías incomprensible a menos que disponga de la clave de descifrado correcta.
Cómo puedes saberlo
La forma más sencilla de comprobarlo es fijarse en la URL. Un sitio web seguro empieza por «https» y muestra un icono de candado junto a la barra de direcciones. Si haces clic en ese candado, podrás ver los detalles del certificado, incluyendo quién lo ha emitido y cuándo caduca.
En la terminal, también puedes supervisar todo lo que está abierto en ese momento y pasa por un puerto. Por ejemplo, para el puerto 443,
ss -tnp estado establecido «( dport = :443 o sport = :443 )»
Una breve historia: cómo la web pasó a ser segura por defecto
El protocolo HTTP fue el primero en aparecer y, durante años, fue el estándar predeterminado sin cifrado de la web. Con el tiempo, se le fueron añadiendo medidas de seguridad, y los elementos que hicieron posible el protocolo HTTPS se fueron incorporando por etapas.
La era del texto sin formato
En los inicios de la web, los datos circulaban a la vista de todos. El protocolo HTTP transmitía las páginas y los envíos de formularios como texto legible, en el sentido de que cualquiera que capturara los paquetes podía desplazarse por una sesión del mismo modo que se desplaza por un documento. Se trataba de una decisión de diseño, no de un descuido. El protocolo original de Tim Berners-Lee tenía un único método y carecía de encabezados; recuperaba documentos de hipertexto de servidores de física para un público compuesto por físicos. Los primeros tiempos se regían por la tradición académica de la apertura, sin temor a los malintencionados. El cifrado habría supuesto una carga innecesaria para hacer frente a una amenaza que aún no existía.
Lo que echó por tierra esa suposición no fue un fallo del protocolo HTTP, sino el comercio y el temor al malware. En cuanto la web empezó a transmitir números de tarjetas de crédito y credenciales de inicio de sesión, el hecho de que «cualquiera en la ruta pudiera leerlos» dejó de ser una característica neutra. Además, era importante sentirse seguro al visitar una página web, sabiendo que la entidad al otro lado era exactamente quien decía ser.
Desde Netscape SSL hasta los tiempos actuales TLS
Netscape desarrolló el protocolo « SSL » en la década de los noventa para cifrar y proteger las comunicaciones por Internet.
- SSL La versión 1.0 nunca se lanzó debido a problemas de seguridad.
- La versión 2.0 salió al mercado en 1995 con muchos fallos.
- En 1996 se lanzó la versión 3.0, que incorporaba importantes mejoras.
- Posteriormente, el Grupo de Trabajo de Ingeniería de Internet (IETF) elaboró el documento « TLS » como sucesor: « TLS », versión 1.0 en 1999, versión 1.2 en 2008 y versión 1.3, finalizada en 2018.
- En 2020, el protocolo « SSL » quedó totalmente en desuso, y los protocolos « TLS » v1.2 y v1.3 pasaron a ser los que seguían utilizándose, aunque la gente sigue diciendo de forma coloquial «SSL ».
Para ver la comparación completa entre SSL y TLS, echa un vistazo a nuestra guía «HTTPS Everywhere».
Los navegadores modernos ahora incorporan medidas de seguridad de forma predeterminada. Chrome, Firefox, Edge y otros utilizan HTTPS de forma predeterminada y señalan las páginas no seguras, por lo que un sitio web que solo utilice HTTP genera cada vez más una advertencia en lugar de cargarse sin avisar. Esta configuración predeterminada se ha convertido, por así decirlo, en un sistema «por capas».
- La primera de estas capas se refiere al comportamiento de la barra de direcciones: por ejemplo, al escribir keyfactor.com, se redirige ahttps://www.keyfactor.com.
- La segunda se refiere a la mejora de la navegación: si haces clic en el enlacehttp://www.keyfactor.com, o en uno incrustado en una página, se vuelve a intentar de forma silenciosa a través de HTTPS, con un plan alternativo de texto sin cifrar si la mejora falla.
- La tercera opción es el modo «HTTPS-First»: en este caso se prescinde de la alternativa de reserva y se muestra una página de advertencia completa. El usuario aún puede continuar, pero debe indicar explícitamente que desea hacerlo.
El modelo de amenazas: lo que ocurre realmente en el protocolo HTTP sin cifrar
La razón por la que los navegadores insisten tanto en el uso de HTTPS no es meramente estética. El protocolo HTTP sin cifrar presenta vulnerabilidades reales que pueden ser objeto de ataques.
Escuchas y interceptaciones
En las conexiones HTTP no seguras, cualquier persona situada en la ruta de la red puede interceptar los mensajes entre el navegador y el servidor y leerlos en texto sin cifrar. Las conexiones cifradas codifican esa comunicación hasta que el destinatario previsto la descifra, por lo que quien la intercepte no verá nada útil, lo cual es especialmente importante si la comunicación contiene información de identificación personal, datos confidenciales, contraseñas, etc.
Ataques de tipo «hombre en el medio»
Cuando visitas una página web, tu navegador envía una solicitud y el servidor devuelve una respuesta. Sin protección, esa interacción es vulnerable a los ataques de «hombre en el medio», en los que un actor malintencionado intercepta los datos en tránsito y puede extraerlos o alterarlos. Por ejemplo, si inicias sesión en un portal de banca online y alguien intercepta ese tráfico, tus credenciales podrían quedar expuestas, lo que podría dar lugar a un robo de identidad o a pérdidas económicas.
La confianza, el phishing y la necesidad de una infraestructura de clave pública
El cifrado es solo la mitad de la historia. Un certificado válido emitido por una autoridad de certificación (CA) de confianza también autentica el servidor, lo que demuestra que el sitio es quien dice ser. Si un sitio web solicita información confidencial y no tiene certificado, no se debe confiar en esa conexión para enviar datos privados. La autenticación del servidor demuestra que un certificado pertenece al dominio que aparece en la barra de direcciones, no que ese dominio sea el que el usuario pretendía visitar. El phishing se aprovecha de esa brecha, ya que un atacante que registre un dominio muy similar al original puede obtener un certificado válido para él y presentar una conexión totalmente autenticada a un sitio en el que el usuario, en realidad, no confía. Por lo tanto, el protocolo HTTPS protege tanto la confidencialidad del intercambio como la identidad del sitio. Para obtener más información sobre las Autoridades de Certificación, consulta nuestraguía específica sobre las CA o lee nuestroanálisis en profundidad sobre la PKIpara tener una perspectiva más amplia de la infraestructura de confianza.
La amenaza futura: cosechar ahora, descifrar más tarde
También existe un riesgo de futuro. El cifrado actual es seguro frente a los ordenadores clásicos, pero no frente a ordenadores cuánticos lo suficientemente potentes, cuya materialización es probable que se produzca en los próximos 5 a 15 años. Esto ha suscitado preocupación por los ataques (HNDL), en los que los adversarios registran el tráfico cifrado en la actualidad con la intención de descifrarlo más adelante, una vez que las capacidades cuánticas hayan madurado.
Para protegerse contra esto, el sector está apostando por la criptografía poscuántica, que funciona en ordenadores normales, pero seguirá siendo resistente a los ataques incluso después de que se construyan potentes ordenadores cuánticos. Parte de esta migración criptográfica consiste en sustituir el intercambio tradicional de claves por mecanismos resistentes a los ataques cuánticos en futuras versiones de TLS.
Lo que el protocolo HTTPS sigue sin ocultar
Aquí viene la parte sincera que a menudo se pasa por alto: el protocolo HTTPS protege elcontenidode tus solicitudes, pero no te hace invisible. El cifrado oculta lo que envías y recibes, de modo que quien lo intercepte solo vea caracteres sin sentido; sin embargo, hay varias señales que quedan al descubierto.
Metadatos que permanecen visibles
La dirección IP de destino sigue siendo visible, ya que la red tiene que enrutar tu tráfico a algún sitio. En muchas configuraciones, el nombre de dominio también queda expuesto a través de las consultas « DNS », y el nombre del servidor se envía al inicio de la conexión. Es posible que un observador no pueda leer tus mensajes, pero a menudo puede saber con qué servicio te estás comunicando.
Patrones de tráfico
El volumen y el momento en que se produce el tráfico pueden revelar información por sí mismos. Ciertos patrones característicos, como el ritmo de una transmisión de vídeo o la estructura de una secuencia de inicio de sesión, pueden dar pistas sobre lo que está ocurriendo, incluso cuando la carga útil está cifrada.
Lo que el cifrado no puede solucionar
El cifrado protege los datos en tránsito, pero no en los extremos de la comunicación. Un dispositivo comprometido, un programa malicioso en tu ordenador o una página web maliciosa que cuente con un certificado perfectamente válido quedan fuera del alcance de HTTPS. El candado confirma que la conexión está cifrada y que el certificado es válido; no garantiza las intenciones de quien se encuentre al otro lado.
Cuándo sigue siendo aceptable el HTTP sin cifrar
El HTTP sin cifrar no es incorrecto en todos los casos. Siguen existiendo algunos casos legítimos y de bajo riesgo, aunque las recomendaciones sensatas se van reduciendo cada vez más.
Contextos no sensibles, internos o aislados
Las herramientas internas y el desarrollo local, en los que no se transmiten datos privados, pueden funcionar a través de HTTP sin mayor preocupación. El tráfico dirigido a tu propio ordenador nunca pasa por una red, por lo que no hay ningún interceptor del que preocuparse. Esta es también la razón por la que los certificados de validación de dominio, el tipo más básico y rápido de emitir, están destinados a sitios web personales o internos, en lugar de a sitios web empresariales públicos que recopilan datos.
También hay un aspecto de principios en el que HTTP es correcto por diseño. Algunos objetos firmados conservan su propia integridad independientemente de cómo se transmitan, por lo que servirlos a través de HTTP es una decisión deliberada y no un atajo. Además, ciertos pasos iniciales, como la redirección inicial desde una dirección «http://» a «https://», deben iniciarse en el puerto 80 antes de que exista una conexión segura.
Por qué el concepto de «aceptable» se está reduciendo
La lista de casos en los que se acepta el uso de HTTP es cada vez más reducida, y por buenas razones. Los ajustes predeterminados de los navegadores ahora marcan el HTTP sin cifrar como «no seguro», independientemente del contenido. Los certificados son ahora gratuitos y se renuevan automáticamente a través del protocolo ACME, que cuenta ya con una amplia compatibilidad en varias plataformas PKI, como EJBCA, por lo que la vieja excusa de que los certificados son caros o requieren gestión manual ya no es válida. Asimismo, la «red interna de confianza» es una suposición menos sólida de lo que solía ser, ya que el enfoque de «confianza cero» considera que ninguna ubicación de la red es intrínsecamente segura. Para cualquier contenido público o que maneje datos de usuarios, HTTPS es el estándar y la opción esperada.
Cómo Keyfactor ayudarte Keyfactor
El protocolo HTTPS solo funciona cuando los certificados que lo respaldan son válidos y fiables, y ahí es precisamente donde muchas organizaciones tienen dificultades. La presión es cada vez mayor: el CA/Browser Forum ha acordado reducir la vigencia de los certificados a un máximo de 200 días para 2026, 100 días para 2027 y tan solo 47 días para 2029. Si no se renueva a tiempo, el sitio web puede dejar de funcionar, los usuarios pierden la confianza y tu nivel de seguridad se ve afectado. El seguimiento manual no puede adaptarse a ese ritmo.
Keyfactor Ayuda a los equipos a mantener todos los sitios web en HTTPS sin interrupciones del servicio. EJBCA proporciona la plataforma para crear los certificados de los que depende TLS , mientras que Bouncy Castle ofrece una pila completa de TLS para desarrolladores. En cuanto al descubrimiento, AgileSec localiza los activos criptográficos y los certificados en todo su entorno, para que nada quede oculto en un punto ciego. Keyfactor Command gestiona los certificados en toda la empresa, realizando un seguimiento de las fechas de caducidad y automatizando el aprovisionamiento y la renovación, de modo que la proliferación de múltiples certificados y las caducidades inesperadas pasan a ser cosa del pasado. Juntos cubren la automatización del ciclo de vida de los certificados, la PKI y el descubrimiento criptográfico, y ayudan a los equipos a prepararse para la era poscuántica a medida que evolucionan los estándares.
¿Tienes dudas sobre HTTP y HTTPS? Tenemos las respuestas.
¿Cuál es la principal diferencia entre HTTP y HTTPS?
HTTP envía datos en texto sin cifrar a través del puerto 80, por lo que pueden ser interceptados y leídos. HTTPS añade cifrado a través del puerto 443, codificando los datos de forma que solo el servidor y el navegador de destino puedan leerlos. HTTPS también autentifica la identidad del servidor.
¿Es HTTPS simplemente HTTP con cifrado?
HTTPS es HTTP transmitido a través de una conexión cifrada y autenticada. Esa capa aporta confidencialidad, autenticación del servidor e integridad de los datos, características que el HTTP sin cifrar no ofrece.
¿Cómo puedo saber si una página web utiliza HTTPS?
Fíjate en la barra de direcciones. La URL de una página web segura empieza por «https» y muestra un icono con forma de candado. Al hacer clic en el candado, podrás ver los detalles del certificado de la página web.
¿Por qué los navegadores me avisan de los sitios web que utilizan HTTP?
Porque los datos que se transmiten por HTTP pueden ser interceptados y leídos en texto sin cifrar. Navegadores como Chrome utilizan ahora HTTPS de forma predeterminada y señalan las páginas no seguras para proteger a los usuarios contra el espionaje y el phishing.
¿El protocolo HTTPS oculta todo lo que hago en Internet?
No. El protocolo HTTPS cifra el contenido de tus solicitudes, pero siguen siendo visibles datos como la dirección IP de destino, el dominio que visitas, así como el volumen y la duración del tráfico. Además, no puede proteger un dispositivo que ya haya sido comprometido.
¿Está bien utilizar HTTP sin cifrar en algún caso?
En el caso de herramientas internas aisladas o de desarrollo local que no manejen datos confidenciales, el uso deHTTP puede ser aceptable. Para cualquier sitio web público o que recopile datos de los usuarios, HTTPS es la opción estándar y la que se espera que se utilice.
¿Ayuda el protocolo HTTPS al SEO?
Sí. El protocolo HTTPS es una señal positiva para el posicionamiento, y un certificado válido mejora la confianza de los usuarios; ambos factores favorecen la visibilidad en los buscadores.
¿Por qué es fiable el protocolo HTTPS?
Un certificado SSL/TLS emitido por una autoridad de certificación de confianza acredita la identidad del sitio web y permite el cifrado. El navegador verifica dicho certificado mediante una cadena de confianza que se remonta hasta una raíz de confianza.
