Preguntas frecuentes sobre HTTPS - CDN - Centro de documentación de Alibaba Cloud

HTTPS es un canal HTTP diseñado para la seguridad que ofrece una mejor protección en la transmisión de contenido a través de CDN. Además de acceder al contenido a alta velocidad, los clientes pueden navegar por el sitio web de forma más segura y eficaz. Este tema proporciona respuestas a las preguntas frecuentes sobre HTTPS.

Conceptos básicos y principios de HTTPS

¿Cuáles son los tipos comunes de ataques HTTP?

A continuación se describen los tipos comunes de ataques HTTP:

Inyección SQL: Los atacantes aprovechan las aplicaciones existentes para inyectar comandos SQL maliciosos en los motores de base de datos del backend y ejecutarlos. También pueden introducir sentencias SQL maliciosas en formularios web para obtener la base de datos de un sitio web con vulnerabilidades de seguridad, en lugar de ejecutar las sentencias SQL según lo previsto por el diseñador.
Cross-site scripting: El cross-site scripting (XSS) es uno de los métodos más comunes y básicos para atacar sitios web. Los atacantes publican datos que contienen código malicioso en páginas web. Cuando un usuario visualiza dicha página, el script específico se ejecuta con la identidad y los permisos del usuario que navega. El XSS facilita la manipulación de datos de usuario y el robo de información.
Cross-site request forgery: La falsificación de solicitudes entre sitios (CSRF) es otro ataque común. Los atacantes falsifican solicitudes de diversos maneras para imitar el comportamiento de los usuarios que envían formularios, con el fin de alterar los datos del usuario o realizar tareas específicas. Para suplantar a un usuario, los ataques CSRF y XSS suelen funcionar en conjunto, pero los atacantes también pueden utilizar otros medios, como engañar a los usuarios para que hagan clic en un enlace malicioso.
Ataque a encabezados HTTP: Al usar un navegador para ver cualquier sitio web, independientemente de las tecnologías y frameworks utilizados, interviene el protocolo HTTP. En este protocolo, existe una línea en blanco entre el encabezado de respuesta y el contenido; es decir, dos conjuntos de caracteres CRLF (0x0D 0x0A). Esta línea en blanco marca el final de los encabezados y el inicio del contenido, situación que los atacantes pueden aprovechar. Siempre que logren inyectar caracteres arbitrarios en los encabezados, este ataque puede ocurrir.
Ataque de redireccionamiento: Un ataque muy utilizado es el phishing. Por lo general, los atacantes envían a las víctimas un enlace con apariencia legítima. Cuando las víctimas visitan el enlace, se les redirige a un sitio web malicioso, lo que permite a los atacantes ganar su confianza y robar su información. Para evitarlo, deben validarse todas las operaciones de redireccionamiento a fin de impedir desvíos hacia destinos peligrosos. Una solución común es la lista de permitidos: agregue las URL de redireccionamiento legítimas a la lista de permitidos y rechace las redirecciones a dominios que no estén en ella. Otra solución son los tokens de redireccionamiento: añada un token a las URL legítimas y valídelo durante la redirección.

¿Habilitar la aceleración HTTPS consume más recursos o ralentiza el acceso?

Cuando se habilita HTTPS en el origen, el consumo de recursos de cómputo aumenta en comparación con el acceso HTTP. Este incremento proviene principalmente del cifrado y descifrado asimétrico durante el protocolo de enlace HTTPS, y el consumo de recursos crece significativamente bajo alta concurrencia. El consumo del cifrado y descifrado simétrico es básicamente el mismo que en HTTP, por lo que conviene aumentar la tasa de reutilización de sesiones. Sin embargo, acceder al origen directamente a través de HTTPS toma más tiempo que hacerlo mediante HTTP. Para contenido estático, la distribución perimetral reduce el tiempo de transmisión a costa de un tiempo adicional de protocolo de enlace, por lo que el tiempo total de acceso disminuye. Además, los recursos estáticos no necesitan obtenerse del origen, lo que reduce las interacciones con este y disminuye el consumo de recursos en el servidor de origen.

Escenarios de uso y decisiones sobre HTTPS

¿Es obligatorio HTTPS solo para el inicio de sesión en el sitio?

No. Debe analizar esto desde los siguientes aspectos:

Seguridad: Si algunas páginas usan HTTP y otras HTTPS, cuando se cargan otros recursos (como archivos JS o CSS) a través de HTTP o mediante un servicio CDN inseguro, el sitio web sigue enfrentando el riesgo de exponer información del usuario. Implementar HTTPS en todo el sitio es la forma más sencilla de prevenir este riesgo.
Rendimiento: Cuando un sitio web admite tanto HTTPS como HTTP, cambiar entre ambos protocolos requiere muchas redirecciones del lado del servidor. Cada vez que se activan estas redirecciones, la carga de la página se ralentiza.
Ecosistema web: Los navegadores favorecen el uso de HTTPS y los motores de búsqueda ofrecen un mejor soporte de indexación para sitios con HTTPS.

Ya hay HTTPS configurado en el origen. ¿Aún necesito configurar HTTPS en CDN?

HTTPS regula la interacción entre el cliente y el servidor. Antes de usar CDN, el cliente interactúa directamente con el origen, por lo que HTTPS debe configurarse allí. Después de implementar CDN, el cliente interactúa con este servicio. Si desea acceder a CDN a través de HTTPS, debe configurar un certificado HTTPS en CDN. Para obtener información sobre cómo configurar un certificado HTTPS en CDN, consulte Configure an HTTPS certificate.

Se ha actualizado el certificado HTTPS en el origen. ¿Es necesario actualizar también el certificado en CDN?

No. El certificado HTTPS en el servidor de origen y el certificado HTTPS en CDN existen de manera independiente. Actualizar el certificado en el origen no afecta al certificado HTTPS en CDN. Solo necesita actualizar el certificado HTTPS en CDN cuando el certificado configurado esté a punto de caducar o ya haya caducado. Para obtener más información, consulte Configure an HTTPS certificate.

¿Cambia el puerto de origen después de configurar un certificado HTTPS?

Configurar un certificado HTTPS para un nombre de dominio acelerado no afecta directamente al puerto de origen, pero sí lo hace indirectamente en el modo de seguimiento de protocolo. Las reglas específicas son las siguientes:

Configurar un certificado HTTPS no tiene relación directa con el puerto de origen

El certificado HTTPS solo proporciona cifrado entre el cliente y los nodos de CDN. No cambia el protocolo ni el puerto de origen entre CDN y el servidor de origen. El comportamiento del origen se controla de forma independiente mediante la configuración del protocolo de origen: cuando se establece en HTTP, CDN obtiene contenido del origen a través del puerto 80 de forma predeterminada; cuando se establece en HTTPS, CDN obtiene contenido del origen a través del puerto 443 de forma predeterminada. Esto no guarda relación con si hay un certificado configurado en el perímetro.

Cuando el protocolo de origen se configura como "follow", depende del protocolo de acceso del cliente
- Después de configurar un certificado HTTPS y habilitar la aceleración segura HTTPS, CDN admite el acceso tanto a través de HTTP como de HTTPS.
- Si el protocolo de origen se configura para seguir al cliente: cuando el cliente accede a CDN a través de HTTP, CDN obtiene contenido del origen a través del puerto 80; cuando el cliente accede a CDN a través de HTTPS, CDN obtiene contenido del origen a través del puerto 443.
Si se requiere cifrado HTTPS de extremo a extremo
- Configurar solo un certificado perimetral no es suficiente. También debe establecer el protocolo de origen como HTTPS en la configuración de origen y asegurarse de que el origen admita el acceso HTTPS.

Para obtener información sobre cómo configurar el protocolo de origen, consulte Configure the origin protocol policy.

Configuración y carga de certificados

Al cargar un certificado de terceros que contiene varios archivos .crt, ¿cómo debo cargar el certificado?

Los archivos de certificado emitidos por una autoridad de certificación intermedia contienen múltiples certificados. Debe concatenar el certificado del servidor y los certificados intermedios en un solo certificado completo antes de cargarlo.

Abra todos los archivos de certificado en formato *.PEM con un editor de texto. Coloque primero el certificado del servidor, seguido de los certificados intermedios. No debe haber líneas en blanco entre los certificados. En la mayoría de los casos, la autoridad de certificación proporciona instrucciones correspondientes al emitir el certificado. Siga dichas instrucciones.

El certificado concatenado queda de la siguiente manera:

Comportamiento de acceso y compatibilidad de HTTPS

Al configurar HSTS, después de habilitar la inclusión de subdominios, ¿necesito habilitar HSTS en los subdominios?

No necesita habilitar HSTS en los subdominios. Después de habilitar Include Subdomains, la directiva HSTS entra en vigor para todos los subdominios. Asegúrese de que cada subdominio admita el acceso HTTPS normal. De lo contrario, el subdominio dejará de ser accesible.

HTTPS ya está configurado. ¿Por qué los clientes siguen accediendo al sitio a través de HTTP?

Que un cliente acceda al sitio a través de HTTP o HTTPS depende completamente del comportamiento del cliente. Si desea forzar a los clientes a usar acceso HTTPS, habilite la redirección forzada HTTPS en CDN. Para obtener más información, consulte Configure HTTP/S redirection.

¿Por qué la mayoría de los dispositivos pueden acceder a un nombre de dominio acelerado con HTTPS, mientras que otros no?

Esto se debe principalmente a que CDN depende de SNI al procesar solicitudes HTTPS. SNI es una extensión del protocolo TLS que permite a un cliente especificar el nombre de host que desea visitar al iniciar una solicitud de conexión HTTPS.

Sin embargo, algunos clientes antiguos o con configuraciones especiales (por ejemplo, versiones antiguas de Android o iOS, Java 6 y anteriores, y algunos dispositivos IoT) podrían no admitir SNI o no enviar información SNI al iniciar solicitudes HTTPS. En este caso, los nodos de CDN no pueden determinar el sitio exacto que el cliente desea visitar y, por lo tanto, no pueden proporcionar el certificado SSL/TLS correcto. Como resultado, el intento de conexión HTTPS falla y los usuarios no pueden acceder al contenido del sitio web.

Para mejorar esta situación, se recomiendan las siguientes medidas:

Actualice el sistema del cliente: Asegúrese de que los sistemas operativos y el software en uso estén actualizados para que admitan SNI.
Actualice el firmware de dispositivos IoT: Para dispositivos IoT, compruebe e instale periódicamente las últimas actualizaciones de firmware proporcionadas por el fabricante.

Facturación de HTTPS

¿Hay cargos adicionales después de habilitar la aceleración HTTPS en CDN?

Sí. Habilitar la aceleración HTTPS en CDN activa HTTPS en el enlace entre el cliente y los nodos perimetrales de CDN. Dado que tanto el protocolo de enlace SSL como el descifrado de contenido requieren procesamiento, aumenta el consumo de recursos de CPU de los servidores de CDN. Sin embargo, el consumo de recursos en su servidor de origen no aumenta, porque el enlace entre los nodos perimetrales de CDN y su origen sigue utilizando el protocolo HTTP y no añade carga adicional a su origen.

Si adquiere diferentes tipos de certificados, se aplicarán tarifas adicionales. También puede iniciar sesión en la consola de Certificate Management Service para solicitar un certificado de prueba (edición gratuita), que es un certificado de nivel DV. Puede solicitar un certificado de prueba para cada nombre de dominio acelerado. El certificado tiene una validez de tres meses y se puede renovar automáticamente de forma gratuita. Después de configurar un certificado HTTPS, CDN factura todas las solicitudes HTTPS para ese nombre de dominio. Para obtener información sobre los cargos por solicitudes HTTPS estáticas, consulte Billing of HTTPS requests for static content.

Cuando las solicitudes coinciden con la lista de bloqueados de IP o la lista de bloqueados de User-Agent, o cuando las solicitudes devuelven 403/404, ¿se facturan las solicitudes HTTPS?

Las solicitudes HTTPS se facturan. Cuando una solicitud coincide con ciertas reglas de directiva y devuelve un código de estado 403 o 404, la solicitud recibe una respuesta correcta, por lo que se cuenta como una solicitud HTTPS. Dado que dicha solicitud no transporta ningún contenido de recurso, el tráfico facturado es muy pequeño.