Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
Webserver -> CDN -> Users
From user perspective they reach the website via HTTPS.
Question: How does this work?
A content delivery network must have access to the content, so it can optimize delivery through caching, compression etc. With true end-to-end encryption between the browser and the web server it is not possible that the CDN in between gets access to the content. Therefore the CDN itself must be that endpoint of the encryption, i.e. the connection is only secured between browser and CDN and the CDN has access to the unencrypted data from client and server. If the connection between CDN and server is then encrypted again or if is unencrypted depends on the setup and you will find both cases in practice.
Note that a load balancer is different from a CDN because it does not need access to the content. Therefore it can simply pass through the TLS connection to the server, so you get end-to-end security. But in practice load balancers are often combined with SSL offloading so that you don't have end-to-end security again. But since load balancers are (contrary to CDN) usually in the same local network as the servers this is not that much of a problem.
A CDN needs to decrypt content and cache it unencrypted (compression is another story). If you're using a CDN for static content, only files like CSS, PNG, etc. will be delivered from the CDN, but not dynamic data like the login credentials. Most CDN (like KeyCDN) let you choose whether the connection between the origin server and the CDN should be encrypted as well. The setup will then look like this:
Origin Server --HTTP(S)--> CDN(cached unencrypted) --HTTP(S)--> User
The diagram is erroneous. The webserver serves a page, and the web client fetches all available resource on the page. The cdn can/maybe have https as its transport. Usually you would not utilise server side rendering of the page which would then mean the webserver itself uses the cdn. No the cdn cannot sniff the traffic in the traditional sense, but can, if it wanted, to do whatever javascript and dom manipulation allows it to do. But to do so would risk the ire of the developers and the cdn's reputation.
The diagram should be:
user <- webserver 1.1 user <- webserver ( server side rendering of content ) <- CDN
user <- CDN ^ |---- webservers
The javascript engine on the client does whatever javascript gets loaded.
To elaborate, unfortunately the ascii art is not so clear, user GET/POST request first retrieves a page from the webserver, and the page tells the browser which other resources to obtain. Some of the URI is located on the CDN, others elsewhere. Traditionally javascript libraries are hosted by cdns. But web pages can also be rendered and loaded on the server before being served, so this might be a vector for compromise.
As Steffen Ulrich pointed out, with true end-to-end encryption, it would be impossible for the CDN to get its hands on the content. That is why CDNs in general store the content unencrypted and then it's up to the client to decide whether the content will be served to the user via HTTP or HTTPS. If the customer chooses HTTPS, the CDN then becomes one of the endpoints of the encryption.
Also, please keep in mind that CDNs are mainly used to delivering publically available content, which gets cached and then redistributed from CDN's servers - e.g. images,videos, CSS or Javascript files. Those are (generally speaking) assets which are available to anyone and they ought to be available to everyone - in this case, there is no point in 'eavesdropping' or 'sniffing the traffic' as OP asked.
