¿Por qué toda organización debería conocer las diferencias clave entre HTTP y HTTPS?

Puntos Clave

• HTTPS es HTTP protegido con cifrado TLS/SSL; HTTP envía cada solicitud y respuesta como texto plano y legible.
• Los navegadores han marcado las páginas HTTP sin cifrar como "No seguras" desde Chrome 68 en julio de 2018, y esa presión sobre los sitios no cifrados no ha hecho más que aumentar desde entonces.
• TLS 1.3 (RFC 8446, publicado en agosto de 2018) es la versión actual del protocolo; TLS 1.0 y 1.1 fueron declarados oficialmente obsoletos por el RFC 8996 en marzo de 2021.
• La propuesta SC081v3 del Foro CA/Browser reduce la validez máxima de los certificados públicos de 398 días a 47 días para el 15 de marzo de 2029, en reducciones graduales que comienzan el 15 de marzo de 2026.
• Gestionar el tráfico de producción a través de HTTP genera riesgos empresariales reales: interceptación de datos, penalizaciones en el posicionamiento SEO, advertencias del navegador al finalizar la compra e iniciar sesión, y deficiencias en el cumplimiento normativo.
• La automatización del ciclo de vida de los certificados, y no una migración única, es lo que mantiene segura a una organización a medida que los periodos de validez se reducen.

Publicado: marzo de 2022. Actualizado: agosto de 2026. Revisado por el equipo de seguridad y PKI de Encryption Consulting.

¿Cuál es la diferencia entre HTTP y HTTPS?

HTTP (Protocolo de Transferencia de Hipertexto) es el conjunto de reglas que los navegadores y servidores utilizan para solicitar y entregar páginas web, y envía esos datos como texto plano. HTTPS (Protocolo de Transferencia de Hipertexto Seguro) es HTTP transmitido dentro de una conexión TLS (Seguridad de la Capa de Transporte), el sucesor moderno de SSL (Capa de Sockets Seguros), por lo que las mismas solicitudes y respuestas se cifran durante la transmisión. La diferencia visible es la URL y el candado: las direcciones HTTP comienzan con http:// y muestran un candado desbloqueado o faltante, mientras que las direcciones HTTPS comienzan con https:// y muestra un candado cerrado junto a la URL.

Una autoridad de certificación (CA) , como DigiCert, Sectigo o Let's Encrypt, es la tercera parte de confianza que verifica la identidad del propietario de un dominio y emite el certificado SSL/TLS que vincula una clave pública a dicho dominio. Durante el protocolo de enlace TLS , el servidor presenta el certificado, el cliente lo verifica con una cadena de CA de confianza y ambas partes establecen una clave de sesión simétrica mediante cifrado asimétrico. Todo lo que se envía posteriormente se cifra con esa clave de sesión, razón por la cual una conexión HTTPS resiste los ataques de intermediario (Man-in-the-Middle) que sí tendrían éxito con una conexión HTTP sin cifrado. Para obtener una explicación más detallada de la mecánica del protocolo de enlace, consulte nuestra guía específica sobre el protocolo de enlace TLS ; para conocer los fundamentos de los certificados, consulte qué es HTTPS y en qué se diferencia de HTTP en nuestro Centro de Educación.

¿Cuándo se convirtió HTTPS en el estándar web?

HTTPS no se convirtió en el protocolo predeterminado de la noche a la mañana. Es el resultado de una década de esfuerzos por parte de los proveedores de navegadores, la IETF y el CA/Browser Forum, y esos esfuerzos siguen vigentes hoy en día a través del calendario de validez de certificados que se describe a continuación.

• 2012: El protocolo HTTP Strict Transport Security (HSTS) se publicó como RFC 6797, lo que proporciona a los sitios web una forma de indicar a los navegadores que solo se conecten a través de HTTPS.
• 2014: Google anunció HTTPS como una señal de clasificación ligera en la Búsqueda, lo que otorga a los sitios cifrados una pequeña ventaja en el SEO.
• Julio 2018: Chrome 68 comenzó a marcar todas las páginas HTTP simples como "No seguras" en la barra de direcciones, un hito que impulsó a la mayoría de los sitios públicos restantes a migrar.
• Agosto 2018: TLS 1.3 se publicó como RFC 8446, la versión del protocolo que se utiliza actualmente.
• Marzo 2021: El RFC 8996 declaró formalmente obsoletos los protocolos TLS 1.0 y TLS 1.1, prohibiendo su uso en nuevas implementaciones y marcando como no conformes a cualquier servidor que aún los ofreciera.
• 2025 a 2029: La propuesta SC081v3 del Foro CA/Browser reduce la validez máxima de los certificados públicos de 398 días a 47 días para el 15 de marzo de 2029, con reducciones intermedias a 200 días (marzo de 2026) y 100 días (marzo de 2027).

¿Qué tecnologías y sistemas se ven afectados por el cambio de HTTP a HTTPS?

Todo sistema que finaliza o reenvía tráfico web necesita un certificado válido y compatibilidad con TLS, no solo el sitio web de marketing público. Esto incluye servidores web y proxies inversos, balanceadores de carga y CDN, API internas y microservicios (a menudo protegidos con TLS mutuo), puntos finales de IoT y administración de dispositivos, paneles de administración internos y paneles de control que los equipos consideran "seguros" por no ser accesibles al público, backends de aplicaciones móviles y pasarelas de correo que dependen de STARTTLS. Una migración de HTTP a HTTPS que solo cubra el sitio web principal, dejando los servicios internos, las API o los puntos finales de IoT en HTTP, sigue exponiendo a la organización.

¿Qué le sucede a su organización si no utiliza HTTPS?

Mantenerse en el protocolo HTTP simple genera un coste empresarial cuantificable, no solo una brecha de seguridad teórica.

• Impacto SEO: HTTPS ha sido un factor de posicionamiento de Google desde 2014, y la advertencia de "No seguro" que ahora muestran las páginas HTTP sin cifrar reduce la tasa de clics y el tiempo de permanencia, incluso cuando una página aún se posiciona bien.
• Advertencias del navegador: Chrome, Firefox y Edge etiquetan las páginas y formularios HTTP como "No seguros", lo que mina la confianza del visitante justo en el momento de iniciar sesión, completar una compra o enviar un formulario de contacto.
• Intercepción de datos: Cualquier sesión HTTP es legible y modificable durante la transmisión, por lo que las credenciales, los detalles de pago y otra información de identificación personal (PII) enviada a través de HTTP pueden ser interceptadas mediante un ataque de intermediario (Man-in-the-Middle).
• Exposición al cumplimiento: La norma PCI DSS exige un cifrado robusto para los datos de los titulares de tarjetas en tránsito, y normativas como el RGPD consideran el cifrado como una medida de seguridad básica para los datos personales. El uso de HTTP sin cifrar en un formulario que recopila cualquiera de estos datos constituye una clara violación del cumplimiento normativo.

¿Cómo audita el estado HTTP/HTTPS y la validez del certificado de su sitio web?

Auditar la cobertura HTTPS significa comprobar todos los nombres de host accesibles, no solo la página de inicio.

1. Rastrea todo el dominio y todos los subdominios conocidos para cualquier URL que aún se sirva en http://.
2. Verifique la validez del certificado, la autoridad de certificación emisora, la robustez de la clave (RSA de 2048 bits como mínimo o ECC) y la fecha de vencimiento de cada certificado encontrado.
3. Confirme que HSTS esté habilitado y, cuando corresponda, que incluya subdominios y que se haya enviado a la lista de precarga de HSTS.
4. Realizar pruebas para detectar contenido mixto, es decir, páginas HTTPS que aún cargan imágenes HTTP, scripts o iframes.
5. Verifique que las redirecciones de HTTP a HTTPS utilicen una única redirección 301 en lugar de una cadena de redirecciones de múltiples saltos.
6. Revise cómo se emiten y renuevan actualmente los certificados. Los certificados gestionados manualmente son la principal causa de interrupciones no planificadas, y ese riesgo aumenta drásticamente a medida que los periodos de validez se reducen a 47 días.

¿Cómo se migra de HTTP a HTTPS?

1. Realizar un inventario de todos los dominios, subdominios y servicios internos actualmente accesibles a través de HTTP.
2. Obtenga un certificado SSL/TLS válido de una CA de confianza para cada uno; un certificado gratuito. Generador de RSC puede generar la solicitud de firma de certificado necesaria para iniciar ese proceso.
3. Instale y configure TLS 1.3, manteniendo TLS 1.2 solo como alternativa, y desactive TLS 1.0 y TLS 1.1.
4. Redirigir todas las solicitudes HTTP a HTTPS mediante redirecciones 301.
5. Habilite HSTS para evitar intentos de degradación del protocolo.
6. Detecta y corrige las referencias de contenido mixto para que ninguna página HTTPS cargue un subrecurso HTTP.
7. Actualiza los enlaces internos, los mapas del sitio y las etiquetas canónicas para que apunten a las versiones HTTPS de cada página.
8. Automatice la detección, emisión y renovación de certificados en lugar de realizar un seguimiento manual de las fechas de vencimiento. Con un período de validez de 47 días, el seguimiento manual no es viable a escala operativa.

Registro de actualización

• Agosto 2026: Actualizado con el calendario de validez de certificados de 47 días del CA/Browser Forum, el estado actual de TLS 1.3 y RFC 8996, una lista de verificación de detección, una lista de verificación de migración, una tabla comparativa, una sección de limitaciones y una sección de preguntas frecuentes.
• Marzo 2022: Publicación original.

HTTP vs. HTTPS: Comparación lado a lado

Atributo	HTTP	HTTPS
Cifrado	Ninguno; los datos se envían como texto plano.	Cifrado TLS (TLS 1.3 actual), verificado mediante un certificado SSL/TLS.
Puerto predeterminado	puerto 80	puerto 443
Se requiere certificado	No	Sí, emitido por una autoridad de certificación de confianza.
impacto SEO	No aporta beneficios en el posicionamiento; las advertencias de "No seguro" pueden reducir la tasa de clics.	Señal de clasificación desde 2014; sin advertencia de seguridad del navegador.
Tratamiento del navegador	Etiqueta "No seguro" en Chrome, Firefox y Edge.	Icono de candado cerrado, de confianza por defecto
Integridad de datos	Vulnerable a la interceptación y a la alteración durante el transporte.	Cifrado y autenticado de extremo a extremo.

Limitaciones

• HTTPS cifra los datos en tránsito. No protege los datos que están en reposo en el servidor, en una base de datos o en una copia de seguridad.
• Un certificado válido no es prueba de legitimidad. Los sitios de phishing obtienen habitualmente un certificado SSL/TLS válido y gratuito, por lo que el icono del candado confirma que la conexión está cifrada, no que el sitio sea de confianza.
• Una configuración incorrecta de TLS, como por ejemplo conjuntos de cifrado débiles o un certificado caducado que el navegador aceptó silenciosamente mediante una anulación, puede generar una falsa sensación de seguridad que resulta peor que la ausencia total de cifrado.
• Los periodos de validez de los certificados se reducen cada vez más (47 días en marzo de 2029), lo que convierte la gestión de certificados, que antes era una tarea manual ocasional, en un requisito de automatización.
• HTTPS cumple con uno de los muchos controles. Por sí solo, no satisface completamente PCI DSS, GDPR ni marcos de cumplimiento similares, que requieren medidas de seguridad adicionales más allá del cifrado de la transmisión.

¿Qué recomendaría Encryption Consulting?

Considere la migración a HTTPS como el punto de partida, no como el destino final. El verdadero riesgo que corren la mayoría de las organizaciones hoy en día no es "todavía tenemos una página en HTTP", sino "no tenemos un inventario fiable de todos los certificados de los que dependemos y estamos a punto de enfrentarnos a un período de validez que se reduce a 47 días". CertSecure Manager automatiza la detección, emisión, renovación y revocación de certificados en todo su entorno, de modo que los certificados se rotan según un cronograma en lugar de gestionarse en una hoja de cálculo. Para las organizaciones que necesitan una infraestructura de clave pública (PKI) gestionada en la nube en lugar de administrar su propia autoridad de certificación, PKI como servicio gestiona directamente la emisión y la administración del ciclo de vida. Si está empezando, nuestra herramienta gratuita Generador de CSR crea una solicitud de firma de certificado con el formato adecuado en minutos. Encryption Consulting cuenta con las certificaciones ISO/IEC 27001:2022 y SOC 2, por lo que los mismos controles que recomendamos para el ciclo de vida de sus certificados son los que nosotros mismos aplicamos.

Conclusión

HTTP y HTTPS parecen diferenciarse solo en una letra, pero esa letra representa toda la capa de confianza de la web moderna: cifrado, autenticación e integridad para cada solicitud y respuesta. Toda organización, independientemente de su tamaño, tiene un incentivo directo para implementar HTTPS en todas partes y tratar la gestión de certificados como una disciplina operativa continua en lugar de una tarea de configuración única, especialmente ahora que el calendario de validez del CA/Browser Forum reduce la duración máxima de los certificados a 47 días para 2029. El uso de cifrado y certificados digitales es fundamental tanto para las conexiones a través de internet como dentro de la red interna de una organización. Los sistemas de seguridad como la Infraestructura de Clave Pública (PKI) proporcionan a los usuarios y dispositivos de una organización los certificados que necesitan para identificarse y comunicarse de forma segura. Para saber cómo Encryption Consulting puede ayudarle a configurar y automatizar la PKI en su organización, visite www.encryptionconsulting.com.

Preguntas frecuentes

¿HTTPS es simplemente HTTP con un certificado instalado? No exactamente. HTTPS es HTTP ejecutándose dentro de una conexión cifrada TLS. El certificado es lo que permite al navegador verificar la identidad del servidor y establecer esa conexión cifrada, pero el cifrado, el protocolo de enlace y el intercambio de claves de sesión son lo que realmente garantiza la seguridad del tráfico, no el archivo de certificado por sí solo.

¿Ralentiza HTTPS un sitio web? El protocolo de enlace TLS añade una pequeña latencia a la primera conexión, normalmente unos pocos milisegundos con TLS 1.3 y hardware moderno, y este coste se reutiliza en las solicitudes posteriores mediante la reanudación de la sesión. En la práctica, las ventajas de SEO y confianza que ofrece HTTPS compensan esta mínima sobrecarga, y HTTP/2, que la mayoría de los navegadores requieren HTTPS, suele hacer que un sitio HTTPS sea más rápido en general que su equivalente HTTP.

¿Puede un sitio de phishing usar HTTPS? Sí. Una autoridad de certificación verifica que el solicitante del certificado controle el dominio, no que el dominio en sí sea confiable ni que la organización que lo respalda sea legítima. Un candado cerrado confirma que la conexión está cifrada; no indica quién está al otro lado, por lo que HTTPS nunca debe considerarse una señal de confianza independiente.

¿Qué sucede si un certificado caduca? Los navegadores bloquean el acceso con una advertencia visible, las API y los servicios conectados fallan por completo, y la interrupción se prolonga hasta que se emite e implementa un nuevo certificado. A medida que la duración de los certificados se reduce a 47 días según el calendario del CA/Browser Forum, el seguimiento manual de las renovaciones se convierte en una de las principales causas de interrupciones evitables, por lo que la gestión automatizada del ciclo de vida de los certificados cobra mayor importancia cada año.

¿Los sistemas internos, no públicos, también necesitan HTTPS? Sí. Los paneles de administración internos, las API y el tráfico entre servicios son objetivos comunes una vez que un atacante logra acceder a la red, y el uso de HTTP sin cifrar implica que las credenciales y los tokens de sesión viajan sin cifrar a través de la red interna. Los sistemas internos deben cumplir con los mismos requisitos de certificado y TLS que cualquier sistema accesible al público.

Referencias

• Foro CA/Navegador. Votación SC081v3: Introducir un calendario para la reducción de los períodos de validez y reutilización de datos (11 de abril de 2025). cabforum.org
• IETF. RFC 8446: Protocolo de seguridad de la capa de transporte (TLS) versión 1.3 (agosto de 2018). datatracker.ietf.org
• IETF. RFC 8996: Rechazo de TLS 1.0 y TLS 1.1 (marzo de 2021). ietf.org
• IETF. RFC 6797: Seguridad de transporte estricta HTTP (HSTS) (noviembre de 2012). datatracker.ietf.org
• Google. Un hito para la seguridad de Chrome: marcar HTTP como "no seguro" (2018). blog.google