Stai mescolando concetti che contrastano modelli di minacce molto diversi e quindi la domanda è difficile da rispondere.
Supponiamo che un ipotetico percorso di connessione sia simile a questo:
A <-> B <-> C <-> D <-> E <-> F
con
-
A
è il cliente,
-
B
è un WiFi pubblico a cui sei connesso,
-
C
è l'ISP del provider WiFi,
-
D
e E
essendo salti intermedi tra ISP e
-
F
è il tuo target a cui A
sta connettendo.
VPN
Una VPN stabilisce un tunnel sicuro tra la tua macchina e il punto finale del tunnel, non più . Nel percorso di esempio, questo coprirà B e C, forse D. Ciò ha diversi vantaggi se non ti fidi del tuo ISP locale; forse perché quell'ISP è un WiFi pubblico o altrimenti inaffidabile e si prevede che annusi il tuo traffico:
- Se si utilizza HTTP, può essere solo sniffato (e modificato) dal provider VPN in poi,
- Se utilizzi HTTPS, le tue query DNS non possono essere sniffate (da
B
o C
), nascondendo così (da quelle) quali siti stai visitando.
In ogni caso, non nasconderai le tue query DNS dal tuo provider VPN o dal suo ISP.
Un ulteriore vantaggio è lo pseudonimato; non perdi l'indirizzo IP assegnato dall'ISP, ma quello del provider VPN, aggiungendo un ulteriore livello di depseudonymization per identificarti.
HTTPS con blocco della chiave pubblica
Public Key Pinning (principalmente) sconfigge due minacce che potrebbero interagire:
- Un uomo nel mezzo (
B
, C
, D
o E
) che spezzerebbe la connessione altrimenti sicura tra A
e F
,
-
Un'autorità di certificazione rouge che crea i certificati per 1. essere in grado di presentarti ed essere convalidata correttamente.
Una minaccia secondaria a questo sarebbe che una CA disonesta potrebbe essere installata nel tuo trust store (ad esempio proxy di HTTPS utilizzati nelle grandi organizzazioni per ispezionare attivamente le connessioni HTTPS per le minacce, ma di solito sono considerate OK.
La Public Key Pinning può quindi sconfiggere i MITM che possono (per qualsiasi ragione) presentare certificati (altrimenti) validi per interrompere la comunicazione. Ciò consentirebbe a B
, C
, D
o E
(non reciprocamente esclusivi) di leggere e / o modificare il traffico HTTPS.
Conclusione
Un client che utilizza HPKP (correttamente) è ragionevolmente sicuro, anche se riduce l'usabilità: i proxy HTTPS menzionati prima renderebbero impossibile la comunicazione quando sarebbe altrimenti possibile. In questi casi, le VPN di solito non sono permesse, quindi una VPN non migliorerebbe l'usabilità lì.
A
tuttavia guadagna pseudonimia verso F
usando una VPN, ma probabilmente è sfidata da una funzione di autenticazione all'interno dell'applicazione.