Webserver -> CDN -> Users
Desde la perspectiva del usuario, llegan al sitio web a través de HTTPS.
Pregunta: ¿Cómo funciona esto?
Una red de entrega de contenido debe tener acceso al contenido, de modo que pueda optimizar la entrega a través del almacenamiento en caché, la compresión, etc. Con un verdadero cifrado de extremo a extremo entre el navegador y el servidor web, no es posible que entre el CDN Acceso al contenido. Por lo tanto, la propia CDN debe ser ese punto final del cifrado, es decir, la conexión solo se protege entre el navegador y la CDN y la CDN tiene acceso a los datos no cifrados del cliente y el servidor. Si la conexión entre el CDN y el servidor se encripta nuevamente o si no se encripta, depende de la configuración y encontrará ambos casos en la práctica.
Tenga en cuenta que un equilibrador de carga es diferente de un CDN porque no necesita acceso al contenido. Por lo tanto, simplemente puede pasar a través de la conexión TLS al servidor, de modo que obtenga seguridad de extremo a extremo. Pero en la práctica, los equilibradores de carga a menudo se combinan con la descarga de SSL para que no tenga seguridad de extremo a extremo otra vez. Pero como los balanceadores de carga están (a diferencia de CDN) generalmente en la misma red local que los servidores, esto no es un gran problema.
Un CDN necesita descifrar el contenido y guardarlo en caché sin cifrar (la compresión es otra historia). Si está utilizando un CDN para contenido estático, solo los archivos como CSS, PNG, etc. se entregarán desde el CDN, pero no datos dinámicos como las credenciales de inicio de sesión. La mayoría de los CDN (como KeyCDN ) le permiten elegir si la conexión entre el servidor de origen y el CDN también debería estar encriptada. La configuración se verá así:
Servidor de origen --HTTP (S) - > CDN (sin cifrar en caché) --HTTP (S) - > Usuario
El diagrama es erróneo. El servidor web sirve una página y el cliente web obtiene todos los recursos disponibles en la página. El cdn puede / puede tener https como su transporte. Por lo general, no utilizaría la representación del lado del servidor de la página, lo que significaría que el servidor web utiliza el cdn. No, el cdn no puede oler el tráfico en el sentido tradicional, pero puede, si así lo desea, hacer lo que javascript y la manipulación de dominios le permitan. Pero hacerlo arriesgaría la ira de los desarrolladores y la reputación de la cdn.
El diagrama debe ser:
usuario < - servidor web 1.1 usuario < - servidor web (representación del contenido del lado del servidor) < - CDN
usuario < - CDN ^ | ---- servidores web
El motor de javascript en el cliente hace lo que javascript se carga.
Para elaborar, desafortunadamente el arte ascii no es tan claro, la solicitud GET / POST del usuario primero recupera una página del servidor web, y la página le dice al navegador qué otros recursos debe obtener. Algunos de los URI se encuentran en el CDN, otros en otros lugares. Tradicionalmente las bibliotecas de javascript son alojadas por cdns. Pero las páginas web también pueden representarse y cargarse en el servidor antes de ser servidas, por lo que este podría ser un vector para el compromiso.
Como señaló Steffen Ulrich, con el verdadero cifrado de extremo a extremo, sería imposible para la CDN hacerse con el contenido. Es por eso que los CDN en general almacenan el contenido sin cifrar y luego el cliente es quien decide si el contenido se enviará al usuario a través de HTTP o HTTPS. Si el cliente elige HTTPS, el CDN se convierte en uno de los puntos finales del cifrado.
Además, tenga en cuenta que los CDN se utilizan principalmente para entregar contenido público, que se almacena en caché y luego se redistribuye desde los servidores de CDN, por ejemplo. Imágenes, videos, archivos CSS o Javascript. Esos son (en general) activos que están disponibles para todos y deberían estar disponibles para todos, en este caso, no tiene sentido "espiar" o "rastrear el tráfico" como pidió OP.
Lea otras preguntas en las etiquetas tls