Gli URL HTTPS sono crittografati?

Tutti gli URL sono crittografati quando si utilizza la crittografia TLS / SSL (HTTPS)? Mi piacerebbe sapere perché voglio che tutti i dati degli URL siano nascosti quando utilizzi TLS / SSL (HTTPS).

Se TLS / SSL ti offre la crittografia dell’URL totale, non devo preoccuparti di hide le informazioni riservate dagli URL.

Sì, la connessione SSL è tra il livello TCP e il livello HTTP. Il client e il server prima stabiliscono una connessione TCP crittografata sicura (tramite il protocollo SSL / TLS) e quindi il client invierà la richiesta HTTP (GET, POST, DELETE …) su quella connessione TCP crittografata.

Dal momento che nessuno ha fornito una cattura di fili, eccone uno.
Nome server (la parte del dominio dell’URL) è presentato nel pacchetto ClientHello , in testo semplice .

Quanto segue mostra una richiesta del browser per:
https://i.stack.imgur.com/path/?some=parameters&go=here

ClientHello SNI Vedi questa risposta per maggiori informazioni sui campi della versione TLS (ce ne sono 3 – non versioni, campi che contengono ciascuno un numero di versione!)

Da https://www.ietf.org/rfc/rfc3546.txt :

3.1. Indicazione del nome del server

[TLS] non fornisce un meccanismo per un client per comunicare a un server il nome del server che sta contattando. Potrebbe essere opportuno che i client forniscano queste informazioni per facilitare connessioni sicure ai server che ospitano più server “virtuali” a un singolo indirizzo di rete sottostante.

Per fornire il nome del server, i clienti POSSONO includere un’estensione di tipo “nome_server” nel client (esteso) ciao.

In breve:

  • FQDN (la parte del dominio dell’URL) ClientHello MAY essere trasmesso in chiaro all’interno del pacchetto ClientHello se si utilizza l’estensione SNI

  • Il resto dell’URL ( /path/?some=parameters&go=here ClientHello /path/?some=parameters&go=here ) non ha business all’interno di ClientHello poiché l’URL della richiesta è una cosa HTTP (OSI Layer 7), quindi non verrà mai visualizzato in un handshake TLS (Layer 4 o 5). Questo verrà in seguito in GET /path/?some=parameters&go=here HTTP/1.1 richiesta HTTP, DOPO che il canale TLS sicuro è stato stabilito.

SINTESI

Il nome di dominio può essere trasmesso in chiaro (se l’estensione SNI viene utilizzata nell’handshake TLS) ma l’URL (percorso e parametri) è sempre crittografato.

Come già sottolineato dalle altre risposte , gli “URL” https sono effettivamente crittografati. Tuttavia, la tua richiesta / risposta DNS al momento della risoluzione del nome di dominio probabilmente non lo è, e, naturalmente, se stai usando un browser, anche i tuoi URL potrebbero essere registrati.

L’intera richiesta e risposta è crittografata, incluso l’URL.

Si noti che quando si utilizza un Proxy HTTP, esso conosce l’indirizzo (dominio) del server di destinazione, ma non conosce il percorso richiesto su questo server (ad esempio, la richiesta e la risposta sono sempre crittografate).

Sono d’accordo con le risposte precedenti:

Per essere espliciti:

Con TLS, la prima parte dell’URL ( https://www.example.com/ ) è ancora visibile mentre costruisce la connessione. La seconda parte (/ herearemygetparameters / 1/2/3/4) è protetta da TLS.

Tuttavia ci sono una serie di motivi per cui non si dovrebbero inserire parametri nella richiesta GET.

Innanzitutto, come già menzionato da altri: – perdita attraverso la barra degli indirizzi del browser – perdite attraverso la cronologia

In aggiunta a ciò si verifica una perdita di URL attraverso il referente http: l’utente vede il sito A su TLS, quindi fa clic su un collegamento al sito B. Se entrambi i siti sono su TLS, la richiesta al sito B conterrà l’URL completo dal sito A in il parametro di riferimento della richiesta. E l’amministratore del sito B può recuperarlo dai file di registro del server B.)

Un’aggiunta alla risposta utile di Marc Novakowski: l’URL è memorizzato nei log del server (ad esempio, in / etc / httpd / logs / ssl_access_log), quindi se non si desidera che il server mantenga le informazioni più a lungo termine, non metterlo nell’URL.

Sì e no.

La porzione di indirizzo del server NON è crittografata poiché viene utilizzata per impostare la connessione.

Questo potrebbe cambiare in futuro con SNI e DNS crittografati, ma dal 2018 entrambe le tecnologie non sono comunemente in uso.

Il percorso, la stringa di query ecc. Sono crittografati.

Nota per le richieste GET l’utente sarà comunque in grado di tagliare e incollare l’URL fuori dalla barra degli indirizzi, e probabilmente non vorrai inserire informazioni riservate che possano essere viste da chiunque guardi lo schermo.

Una terza parte che sta monitorando il traffico può anche essere in grado di determinare la pagina visitata esaminando il traffico e confrontandolo con il traffico di un altro utente quando visita il sito. Per esempio se ci fossero solo 2 pagine su un sito, una molto più grande dell’altra, allora il confronto delle dimensioni del trasferimento dati direbbe quale pagina hai visitato. Ci sono modi in cui questo potrebbe essere nascosto alla terza parte, ma non sono normali comportamenti del server o del browser. Vedi ad esempio questo articolo di SciRate, https://scirate.com/arxiv/1403.0297 .

In generale, altre risposte sono corrette, praticamente però questo documento mostra che le pagine visitate (ad es. URL) possono essere determinate in modo abbastanza efficace.

Collegamento alla mia risposta su una domanda doppia . Non solo l’URL è disponibile nella cronologia dei browser, ma i registri sul lato server vengono anche inviati come intestazione HTTP Referer che, se utilizzi contenuti di terze parti, espone l’URL a fonti esterne al tuo controllo.

Non puoi sempre contare sulla privacy dell’URL completo. Ad esempio, come accade a volte nelle reti aziendali, i dispositivi forniti come il PC aziendale sono configurati con un certificato radice “attendibile” extra in modo che il browser possa tranquillamente fidarsi di un controllo proxy (man-in-the-middle) del traffico https . Ciò significa che l’URL completo è esposto per l’ispezione. Questo di solito viene salvato in un log.

Inoltre, le tue password sono anche esposte e probabilmente registrate e questo è un altro motivo per utilizzare password singole o cambiare frequentemente le tue password.

Infine, il contenuto della richiesta e della risposta è esposto anche se non altrimenti criptato.

Un esempio della configurazione di ispezione è descritto da Checkpoint qui . In questo modo è ansible impostare anche un “internet café” vecchio stile utilizzando i PC in dotazione.

Sebbene ci siano già alcune buone risposte, la maggior parte di esse si sta concentrando sulla navigazione del browser. Sto scrivendo questo nel 2018 e probabilmente qualcuno vuole sapere della sicurezza delle app mobili.

Per le app mobili , se controlli entrambe le estremità dell’applicazione (server e app), finché usi HTTPS sei sicuro . iOS o Android verificheranno il certificato e attenueranno i possibili attacchi MiM (che sarebbe l’unico punto debole in tutto questo). È ansible inviare dati sensibili tramite connessioni HTTPS che verranno crittografati durante il trasporto . Solo la tua app e il server conosceranno tutti i parametri inviati tramite https.

L’unico “forse” potrebbe essere se il client o il server sono stati infettati da software dannoso in grado di visualizzare i dati prima di essere inclusi in https. Ma se qualcuno è infettato da questo tipo di software, avrà accesso ai dati, indipendentemente da ciò che si usa per trasportarli.

Inoltre, se stai creando un’API ReSTful, i problemi di fuga del browser e di riferimento HTTP sono per lo più mitigati in quanto il client potrebbe non essere un browser e potresti non avere persone che fanno clic sui link.

Se questo è il caso, raccomanderei oAuth2 login per ottenere un token al portatore. Nel qual caso gli unici dati sensibili sarebbero le credenziali iniziali … che dovrebbero probabilmente essere comunque in una richiesta di posta