Webserver -> CDN -> Users
Dal punto di vista dell'utente, raggiungono il sito web tramite HTTPS.
Domanda: come funziona?
Una rete di content delivery deve avere accesso al contenuto, in modo che possa ottimizzare la consegna attraverso la cache, la compressione ecc. Con la vera crittografia end-to-end tra il browser e il server web non è possibile che il CDN tra accesso al contenuto. Pertanto, il CDN stesso deve essere l'endpoint della crittografia, ovvero la connessione è protetta solo tra browser e CDN e il CDN ha accesso ai dati non crittografati da client e server. Se la connessione tra CDN e server viene di nuovo crittografata o se non è crittografata dipende dalla configurazione e in pratica troverai entrambi i casi.
Si noti che un bilanciatore del carico è diverso da un CDN perché non ha bisogno di accedere al contenuto. Pertanto può semplicemente passare attraverso la connessione TLS al server, in modo da ottenere una sicurezza end-to-end. Ma in pratica i bilanciatori del carico sono spesso combinati con lo scaricamento SSL in modo da non avere di nuovo la sicurezza end-to-end. Ma dal momento che i bilanciatori del carico sono (contrariamente a CDN) di solito nella stessa rete locale dei server, questo non è un gran problema.
Un CDN deve decrittografare il contenuto e memorizzarlo nella cache in modo non criptato (la compressione è un'altra storia). Se stai utilizzando un CDN per contenuti statici, solo i file come CSS, PNG, ecc. Verranno forniti dal CDN, ma non i dati dinamici come le credenziali di accesso. La maggior parte dei CDN (come KeyCDN ) consente di scegliere se la connessione tra il server di origine e il CDN deve essere crittografata. L'installazione sarà quindi simile a questa:
Origin Server - HTTTP (S) - > CDN (cache non crittografata) --HTTP (S) - > Utente
Il diagramma è errato. Il server web serve una pagina e il web client recupera tutte le risorse disponibili sulla pagina. Il cdn può / può avere https come suo trasporto. Di solito non si utilizza il rendering lato server della pagina, il che significherebbe che il server web stesso utilizza il cdn. No, il cdn non può annusare il traffico nel senso tradizionale, ma può, se lo desidera, fare tutto ciò che javascript e dom manipulation gli permettono di fare. Ma farlo rischierebbe l'ira degli sviluppatori e la reputazione del cdn.
Il diagramma dovrebbe essere:
utente < - server web 1.1 utente < - server web (rendering lato server del contenuto) < - CDN
utente < - CDN ^ | ---- webservers
Il motore javascript sul client esegue qualunque javascript venga caricato.
Per elaborare, sfortunatamente l'arte ascii non è così chiara, la richiesta GET / POST dell'utente recupera prima una pagina dal server web e la pagina indica al browser quali altre risorse ottenere. Alcuni URI si trovano sul CDN, altri altrove. Tradizionalmente le librerie javascript sono ospitate da cdns. Ma le pagine Web possono anche essere visualizzate e caricate sul server prima di essere pubblicate, quindi questo potrebbe essere un vettore di compromesso.
Come ha sottolineato Steffen Ulrich, con una vera crittografia end-to-end, sarebbe impossibile per il CDN mettere le mani sul contenuto. Questo è il motivo per cui i CDN in generale archiviano il contenuto non criptato e quindi spetta al cliente decidere se il contenuto verrà offerto all'utente tramite HTTP o HTTPS. Se il cliente sceglie HTTPS, il CDN diventa uno degli endpoint della crittografia.
Inoltre, tieni presente che i CDN vengono principalmente utilizzati per fornire contenuti disponibili pubblicamente, che vengono memorizzati nella cache e quindi ridistribuiti dai server di CDN, ad es. immagini, video, file CSS o Javascript. Quelli sono beni (in generale) che sono disponibili a chiunque e dovrebbero essere disponibili per tutti - in questo caso, non c'è motivo di "intercettare" o "sniffare il traffico" come richiesto dall'OP.
Leggi altre domande sui tag tls