Durante la lettura dei contenuti dei file pcap ho notato che alcuni URL sembrano essere visibili nonostante siano HTTPS. Questi si verificano principalmente all'interno di payload che contengono anche URL cert, ma vedo anche URL HTTPS all'interno di quelli che sembrano essere payload HTTP.
Qualcuno può dire in modo definitivo se gli URL HTTPS sono veramente mantenuti segreti?
Sono preoccupato di questo perché voglio inserire alcuni parametri nell'URL e non voglio che siano facilmente scoperti.
Con HTTPS il percorso e la stringa di query dell'URL sono crittografati, mentre il nome host è visibile all'interno dell'handshake SSL come testo semplice se il client utilizza l'indicazione del nome del server (SNI). Tutti i client moderni utilizzano SNI perché questo è l'unico modo per avere diversi host con i propri certificati dietro lo stesso indirizzo IP.
Il resto dell'URL (ad esempio tutto tranne il nome host) verrà utilizzato solo all'interno della connessione crittografata. Quindi in teoria è nascosto all'attaccante a meno che la crittografia stessa non venga compromessa (compromettendo la chiave privata, gli attacchi man-in-the-middle ecc.). In pratica un utente malintenzionato potrebbe avere modi indiretti per ottenere informazioni sulla parte rimanente dell'URL:
Ma nella maggior parte dei casi sei abbastanza sicuro con HTTPS, almeno molto più sicuro che con un semplice HTTP.
Sia le intestazioni HTTP (contenenti l'URL richiesto) che i dati dell'applicazione in HTTPS sono crittografati.
Puoi vedere il nome host richiesto, perché i browser lo inviano in Indicazione del nome del servizio durante handshake, in modo che il server possa scegliere il certificato SSL corrispondente.
Usando wireshark, sarai in grado di scoprire il nome host, come menzionato da alcune altre risposte, a causa di SNI. Inoltre, sarai in grado di vedere alcune parti dei certificati. Gli URL https che hai visto erano probabilmente gli URL di CRL s o OCSP s.
Se qualcuno può ottenere i tuoi URL camminando sul tuo sito e confrontare le dimensioni delle pagine restituite con le dimensioni di ciò che viene restituito nella pagina crittografata, potrebbero formulare ipotesi su quale pagina ha chiamato il tuo programma. Ma, come vuoi mettere alcuni parametri nell'URL e nasconderli, questo non è un grande vettore di attacco nel tuo caso. Se il tuo URL è https://my.server/api?user=scott&password=tiger&highscore=12345 e la tua API restituisce sempre pagine tra 1000 e 1010 byte, vedere 1007 byte restituiti non aiuterà nessuno a determinare utente o password o come inserire un punteggio.
TUTTAVIA
link fiddler , charles oppure mitmproxy reindirizza il traffico a se stesso, presenta un certificato falso al client, decrittografa il traffico, lo registra, lo crittografa nuovamente e lo invia al sito originale.
Se il client si affida al truststore del sistema operativo, l'utente malintenzionato potrà inserire il proprio certificato nel truststore e il client non noterà nulla. I README degli strumenti di cui sopra hanno istruzioni su come fare questo.
Quindi, se si attiva https per impedire la decrittografia, è necessario verificare se il certificato restituito dal server è corretto prima di inviare effettivamente l'URL. Controlla come blocco dei certificati funziona per il tuo sistema operativo / linguaggio di programmazione e utilizza gli strumenti sopra riportati per assicurarti che il tuo client rilevi un falso certificato e non inviare l'URL prima di pubblicarlo.
È possibile eseguire analisi del traffico eseguendo la scansione del sito Web e confrontando le dimensioni dei pacchetti, ecc. A seconda della quantità di contenuto dinamico presente o delle immagini referenziate da URL è possibile ottenere una comprensione molto accurata di quali URL sono stati visitati.
La presentazione SSL Traffic Analysis Attacks - Vincent Berg (YouTube) lo spiega e ha alcune dimostrazioni funzionali.
È possibile che l'attaccante abbia accesso al client, per una panoramica vedere: link
Ad esempio su Java-Client un agente come jSSLKeylog può essere collegato per intercettare e registrare il presunto contenuto / URL crittografato. Se il PreMaster-Secret di una comunicazione può essere ottenuto con qualsiasi mezzo nel processo, la comunicazione crittografata catturata può essere decodificata in seguito.