È possibile annusare gli URL HTTPS? [duplicare]

TL; DR Un utente malintenzionato non può vedere nulla oltre il dominio.

Struttura di una richiesta HTTP

HTTP funziona inviando due cose a un sito web: il metodo e headers . I metodi più comuni sono GET , POST e HEAD , che recupera una pagina, trasferisce dati o richiede solo intestazione di risposta, rispettivamente. TLS crittografa l'interezza del traffico HTTP, incluse le intestazioni e il metodo. In HTTP, il percorso nell'URL viene inviato insieme al corpo dell'intestazione. Prendi questo esempio, con wget che carica la pagina foo.example.com/some/page.html :

GET /some/page.html HTTP/1.1
User-Agent: Wget/1.19.1 (linux-gnu)
Accept: */*
Accept-Encoding: identity
Host: foo.example.com

Il server risponderà quindi con un codice di stato HTTP, alcuni headers del proprio e facoltativamente alcuni dati (come HTML). Un esempio, dando un reindirizzamento 301 e un testo semplice come risposta, può essere:

HTTP/1.1 301 Moved Permanently
Date: Wed, 27 Dec 2017 04:42:54 GMT
Server: Apache
Location: https://bar.example.com/new/location.html
Content-Length: 56
Content-Type: text/plain

Thank you Mario, but our princess is in another castle!

Il che direbbe al cliente che la posizione corretta è altrove.

Queste sono le intestazioni inviate direttamente al sito su TCP. TLS funziona su un livello diverso, rendendo tutto ciò crittografato. Ciò include la pagina a cui stai accedendo con il metodo GET . Tieni presente che, sebbene l'intestazione Host si trovi anche nel corpo dell'intestazione e quindi sia crittografata, l'host può comunque essere ottenuto tramite rDNS cerca l'indirizzo IP, o selezionando SNI , che trasmette il dominio in testo semplice.

Struttura di un URL

https://foo.example.com/some/page.html#some-fragment
| proto |    domain    |     path     |  fragment  |

• proto - Ci sono solo due protocolli in uso comune, HTTP e HTTPS.
• dominio : il dominio è example.com e *.example.com , rilevabile con rDNS o SNI.
• percorso : il percorso è completamente crittografato e può essere letto solo dal server di destinazione.
• frammento : il frammento è visibile solo al browser web e non viene trasmesso.

Che cosa può vedere un utente malintenzionato

Quindi cosa può vedere un utente malintenzionato se esegui una richiesta tramite HTTPS? Prendiamo la richiesta ipotetica precedente dal punto di vista di un intercettatore passivo sulla rete. Se volessi sapere a cosa stai accedendo, ho solo opzioni limitate:

• Vedo che fai una richiesta web crittografata con HTTPS che va a 203.0.113.98 .
• Vedo che la porta di destinazione è 443, che so è usata per HTTPS.
• eseguo una ricerca rDNS e vedo che l'IP viene utilizzato per example.com e example.org .
• Guardo il record SNI e vedo che ti stai connettendo a foo.example.com .

Questo è tutto quello che potevo fare. Non sarei in grado di vedere il percorso che stai richiedendo, o anche quale metodo stai usando, a corto di analisi euristiche in base alle dimensioni dei dati inviati e ricevuti, chiamato attacchi di analisi del traffico . Per un servizio di grandi dimensioni come Wikipedia, non avrei idea di quale articolo stai visualizzando basandomi sull'analisi dei soli dati non criptati.

Una nota importante sui referer sui browser più vecchi

Anche se HTTPS crittografa il percorso a cui si sta accedendo, se si fa clic su un collegamento ipertestuale all'interno di quel sito che va a una pagina non crittografata, il percorso completo potrebbe essere trapelato nell'intestazione referer . Questo è non più il caso per molti browser più recenti, ma i browser più vecchi o non conformi potrebbero ancora avere questo comportamento, così come i siti web che impostano il metatag referer HTML5 per inviare sempre le informazioni. Un esempio inviato non crittografato da un client per passare da https://example.com/private/details.html a http://example.org/public/page.html in questo caso potrebbe essere:

GET /public/page.html
Referer: https://example.com/private/details.html
User-Agent: Wget/1.19.1 (linux-gnu)
Accept: */*
Accept-Encoding: identity
Host: example.org

Pertanto, la navigazione da una pagina HTTPS a una pagina HTTP può perdere l'URL completo (escluso il frammento) della pagina precedente, quindi tieni questo a mente.

La risposta ingenua è no: l'URL è crittografato nel flusso TLS. Ma quella risposta ignora una grande quantità di informazioni rilevanti.

Supponiamo che sia Wikipedia. Quanto dura una richiesta HTTP GET per https://en.wikipedia.org/wiki/Cryptography rispetto a https://en.wikipedia.org/wiki/Information_security , assumendo che tutti i campi di intestazione siano uguali? Se riesci a misurare la lunghezza di una richiesta, che probabilmente verrà presentata in un singolo record TLS, puoi probabilmente distinguerli.

Questo non aiuta a distinguere una richiesta per l'articolo sulla crittografia dall'articolo sulla coreografia, naturalmente. Inoltre, non aiuta se il client TLS aggiunge abilmente del padding, ignorato dal server, al record TLS per arrotondarlo a un multiplo di alcune dimensioni del blocco. Ma la Wikipedia inglese ha un articolo molto più lungo sulla crittografia che sulla coreografia. Quindi, anche se gli endpoint coprono i loro record TLS fino a 16384 byte massimi, puoi probabilmente distinguere l'articolo sulla crittografia dall'articolo sulla coreografia.

C'è una complicazione dal tuo punto di vista come l'attaccante: il client può utilizzare lo stesso flusso TLS per molte richieste e molte risposte. Ma probabilmente saranno tutti a tempo in una raffica mentre la vittima carica una singola pagina con CSS, immagini, JavaScript, ecc. incorporati, e poi diventa silenziosa mentre la vittima legge la pagina. La tempistica e il numero di queste richieste fornisce un'altra variabile sulla quale è possibile discriminare la pagina che stavano cercando.

Tutte queste variabili possono essere inserite in un modello probabilistico di pagine- Ecco un esempio , sollevato dal < a href="https://www.freehaven.net/anonbib/" title="Documenti selezionati di Haven gratuiti in anonimato"> anonimato bibliografia . Sconfiggere quell'esempio non significa che la distribuzione dei dati che un utente malintenzionato sulla rete impara per una pagina è indistinguibile da un'altra pagina, solo che quel particolare distinguo non è altrettanto efficace.

Quindi sei, come intercettatore, garantito per poter leggere l'URL fuori dal filo? No: è crittografato nel flusso TLS (a meno che non venga scelto il codice NULL!), Quindi nella migliore delle ipotesi lo si può dedurre da altre variabili osservabili con dipendenze probabilistiche su di esso.

D'altra parte, è la vittima garantita che il suo URL è nascosto da un intercettatore? No: ci sono molte variabili che dipendono dall'URL che un utente malintenzionato può essere in grado di dedurre informazioni succose, come la malattia a trasmissione sessuale di cui stai leggendo alla Mayo Clinic.

(Si noti che qualsiasi cosa nel frammento di un URL - la parte dopo il segno # in https://en.wikipedia.org/wiki/Cryptography#Terminology - non viene trasmessa affatto nella richiesta HTTP GET, a meno che non ci sia qualche script nella pagina che attiva il traffico di rete diverso in base al frammento di URL.)

L'URL, come dici tu, si trova all'interno di intestazioni HTTP che sono, come il corpo HTTP, all'interno del flusso TLS, il che significa che sono crittografate. Puoi ricavare il nome server annusando le richieste DNS prima della richiesta HTTPS, ma potresti non ottenere risultati, se il nome è già presente nella cache locale, ad esempio.

Anche l'URL viene crittografato mentre si utilizza il metodo di comunicazione TLS. Non c'è modo di scoprire il contenuto o l'URL della risorsa sniffando il traffico HTTPS sicuro. Tuttavia, le best practice sulla sicurezza consigliano di non inviare informazioni sensibili tramite stringhe di query HTTP. Il motivo è che può essere memorizzato nella cache del browser o connesso ai server.