Gli URL HTTPS sono crittografati?

1021

Tutti gli URL sono crittografati quando si utilizza la crittografia TLS / SSL (HTTPS)? Vorrei sapere perché desidero nascondere tutti i dati URL quando si utilizza TLS / SSL (HTTPS).

Se TLS / SSL ti fornisce la crittografia URL totale, non devo preoccuparmi di nascondere informazioni riservate dagli URL.

ssl  https  httprequest 
— Daniel Kivatinos
fonte
76
Probabilmente è una cattiva idea inserire comunque dati riservati nell'URL. Verrà visualizzato anche nell'indirizzo del browser male, ricordi? Alla gente non piace se la loro password è visibile a chiunque capiti di dare un'occhiata allo schermo. Perché pensi di dover inserire dati riservati nell'URL?
— jalf
43
Gli URL sono anche memorizzati nella cronologia del browser e nei registri del server - se volessi che il mio nome e la mia password fossero memorizzati da qualche parte, non sarebbe in questi due posti.
— Piskvor lasciò l'edificio il
47
Ad esempio, supponiamo che io visiti https://somewhere_i_trust/ways_to_protest_against_the_government/. Quindi l'URL contiene dati riservati, vale a dire il suggerimento che sto prendendo in considerazione di protestare contro il mio governo.
— Steve Jessop,
42
Mi ponevo questa domanda quando facevo una richiesta HTTP da un'app nativa (non basata su browser). Immagino che questo potrebbe interessare gli sviluppatori di app mobili. In questo caso, i commenti sopra (anche se veri) sono irrilevanti (nessun url visibile, nessuna cronologia di navigazione), rendendo la risposta, per la mia comprensione semplice: "Sì, è crittografato".
— DannyA
23
Per coloro che pensano che una volta che sei HTTPS nessuno sa dove stai andando, leggi prima: il nome host del server (ad esempio esempio.com) sarà comunque trapelato a causa di SNI . Questo non ha assolutamente nulla a che fare con il DNS e la perdita si verificherà anche se non si utilizza il DNS o si utilizza il DNS crittografato.
— Pacerier,

Risposte:

913

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

— Marc Novakowski
fonte
98
Vale ancora la pena notare la cosa menzionata da @Jalf nel commento sulla domanda stessa. I dati URL verranno inoltre salvati nella cronologia del browser, che potrebbe non essere sicuro a lungo termine.
— Michael Ekstrand,
20
Non solo GET o POST. Può anche essere DELETE, PUT, HEAD o TRACE.
4
Sì, potrebbe essere un problema di sicurezza per la cronologia di un browser. Ma nel mio caso non sto usando il browser (anche il post originale non menzionava un browser). Utilizzo di una chiamata https personalizzata dietro le quinte in un'app nativa. È una soluzione semplice per assicurarsi che la connessione sever della tua app sia sicura.
— zingle-dingle,
28
Si noti tuttavia che la risoluzione DNS dell'URL probabilmente non è crittografata. Quindi qualcuno che annusa il tuo traffico potrebbe ancora vedere il dominio a cui stai tentando di accedere.
— ChewToy,
21
SNI interrompe la parte "host" della crittografia SSL degli URL. Puoi testarlo tu stesso con WireShark. C'è un selettore per SNI, oppure puoi semplicemente rivedere i tuoi pacchetti SSL quando ti colleghi all'host remoto.
— cmouse
654

Dal momento che nessuno ha fornito una cattura del filo, eccone uno.
Il nome del server (la parte del dominio dell'URL) è presentato nel ClientHellopacchetto, in testo semplice .

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

ClientHello SNI Vedi questa risposta per ulteriori 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 nome server

[TLS] non fornisce un meccanismo per un client per comunicare a un server il nome del server che sta contattando. Potrebbe essere desiderabile che i clienti 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 client POSSONO includere un'estensione di tipo "nome_server" nel ciao (esteso) del client.


In breve:

  • L'FQDN (la parte del dominio dell'URL) PUO ' essere trasmesso in chiaro all'interno del ClientHellopacchetto se viene utilizzata l'estensione SNI

  • Il resto dell'URL ( /path/?some=parameters&go=here) non ha attività commerciali ClientHellopoiché l'URL della richiesta è una cosa HTTP (OSI Layer 7), quindi non verrà mai visualizzato in un handshake TLS (Layer 4 o 5). Ciò verrà successivamente in una GET /path/?some=parameters&go=here HTTP/1.1richiesta HTTP, DOPO che il canale TLS sicuro è stato stabilito.


SINTESI

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


AGGIORNAMENTO MARZO 2019

Grazie carlin.scott per averne parlato .

Il payload nell'estensione SNI può ora essere crittografato tramite questo progetto di proposta RFC . Questa funzionalità esiste solo in TLS 1.3 (come opzione e spetta ad entrambe le estremità implementarla) e non esiste retrocompatibilità con TLS 1.2 e versioni precedenti.

CloudFlare lo sta facendo e puoi leggere di più sugli interni qui - Se il pollo deve venire prima dell'uovo, dove lo metti?

In pratica ciò significa che invece di trasmettere il nome di dominio completo in testo normale (come mostra la cattura di Wireshark), ora è crittografato.

NOTA: si tratta dell'aspetto della privacy più di quello della sicurezza poiché una ricerca DNS inversa può comunque rivelare l'host di destinazione previsto.

— evilSnobu
fonte
37
Risposta perfetta, con spiegazione completa dalla A alla Z. Adoro la sintesi. Ha reso la mia giornata @evilSnobu
— oscaroscar il
4
Risposta perfetta, voto positivo! Considera comunque la parte client poiché la cronologia del browser potrebbe essere una perdita. Tuttavia, per quanto riguarda il livello di trasporto, i parametri URL sono crittografati.
— Jens Kreidler,
2
Potresti voler aggiornare questa risposta con il fatto che TLS 1.3 crittografa l'estensione SNI, e la più grande CDN sta facendo proprio questo: blog.cloudflare.com/encrypted-sni Naturalmente uno sniffer di pacchetti potrebbe semplicemente fare una ricerca reverse-dns per gli indirizzi IP a cui ti stai connettendo.
— carlin.scott,
@evilSnobu, ma nome utente: password parte del nome utente: password@domain.com è crittografata, giusto? Quindi è sicuro trasmettere dati sensibili in url usando https.
— Maksim Shamihulau,
1
Sono crittografati sul filo (durante il trasporto) ma se una delle due estremità (utente o server) registra l'URL in un file di testo semplice e non disinfetta le credenziali ... ora è una conversazione diversa.
— evilSnobu,
159

Come hanno già sottolineato le altre risposte , gli "URL" https sono effettivamente crittografati. Tuttavia, la tua richiesta / risposta DNS durante la risoluzione del nome di dominio probabilmente non lo è e, naturalmente, se stavi utilizzando un browser, anche i tuoi URL potrebbero essere registrati.

— Zach Scrivena
fonte
21
E la registrazione degli URL è importante poiché esistono hack di Javascript che consentono a un sito completamente non correlato di verificare se un determinato URL è presente nella cronologia o meno. Puoi rendere un URL non indovinabile includendo una stringa casuale longish in esso, ma se si tratta di un URL pubblico, l'autore dell'attacco può dire che è stato visitato e che se ha un breve segreto al suo interno, un utente malintenzionato potrebbe forzare a velocità ragionevole.
— Steve Jessop,
8
@SteveJessop, ti preghiamo di fornire un link a "Gli
— Pacerier
6
@Pacerier: data degli hack ovviamente, ma quello di cui stavo parlando in quel momento erano cose come stackoverflow.com/questions/2394890/… . Nel 2010 è stato molto importante indagare su questi problemi e perfezionare gli attacchi, ma al momento non lo sto seguendo.
— Steve Jessop,
2
@Pacerier: altri esempi: webdevwonders.com/… , webdevwonders.com/…
— Steve Jessop
1
Puoi usare OpenDNS con il suo servizio DNS crittografato. Lo uso sul mio Mac, ma ho riscontrato che la versione di Windows non funziona correttamente. È stato un po 'di tempo fa, quindi ora potrebbe funzionare bene. Per Linux ancora niente. opendns.com/about/innovations/dnscrypt
— SPRBRN
101

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 (ovvero la richiesta e la risposta sono sempre crittografate).

— Peter Štibraný
fonte
1
La totalità della richiesta. Il nome host viene inviato in chiaro. Tutto il resto è crittografato.
— Sam Sirry,
98

Sono d'accordo con le risposte precedenti:

Per essere espliciti:

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

Tuttavia, esistono diversi motivi per cui non è necessario inserire parametri nella richiesta GET.

In primo luogo, come già menzionato da altri: - perdita attraverso la barra degli indirizzi del browser - perdita nella storia

Inoltre, si verifica una perdita di URL tramite il referer http: l'utente visualizza 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 dal sito B può recuperarlo dai file di registro del server B.)

— Tobias
fonte
3
@EJP Non hai capito cosa sta dicendo Tobias. Sta dicendo che se fai clic su un link sul sito A che ti porterà al sito B, il sito B otterrà l'URL di riferimento. Ad esempio, se sei su siteA.com?u=username&pw=123123 , quindi siteB.com (che è collegato alla pagina di siteA.com) riceverà " siteA.com?u=username&pw=123123 " come riferimento URL, inviato a siteB.com all'interno di HTTPS dal browser. Se questo è vero, è molto male. È vero Tobias?
— trusktr,
9
@EJP, il dominio è visibile a causa della SNI utilizzata da tutti i browser Web moderni. Vedi anche questo diagramma dell'EFF che mostra che chiunque può vedere il dominio del sito che stai visitando. Non si tratta della visibilità del browser. Riguarda ciò che è visibile agli intercettatori.
— Buge,
10
@trusktr: i browser non devono inviare un'intestazione di riferimento dalle pagine HTTPS. Questo fa parte della specifica HTTP .
— Martin Geisler,
8
@MartinGeisler, la parola chiave è "dovrebbe". Ai browser non interessa molto di "should" (al contrario di "must"). Dal tuo link: "consiglio vivamente che l'utente sia in grado di selezionare se inviare o meno il campo Referer. Ad esempio, un client browser potrebbe avere un interruttore di attivazione / disattivazione per la navigazione aperta / anonima, che abiliterebbe / disabiliterebbe rispettivamente l'invio di Referente e Da informazioni " . Ops, che è esattamente quello che ha fatto Chrome. Tranne Chrome perde il Referrer anche se sei in modalità di navigazione in incognito .
— Pacerier,
48

Un'aggiunta alla risposta utile di Marc Novakowski: l'URL è memorizzato nei registri sul server (ad es. In / etc / httpd / logs / ssl_access_log), quindi se non si desidera che il server mantenga le informazioni più a lungo termine, non inserirlo nell'URL.

— Rhodri Cusack
fonte
34

Sì e no.

La parte dell'indirizzo del server NON è crittografata poiché viene utilizzata per impostare la connessione.

Ciò potrebbe cambiare in futuro con SNI e DNS crittografati, ma a partire dal 2018 entrambe le tecnologie non sono comunemente utilizzate.

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 dalla barra degli indirizzi e probabilmente non vorrai inserire informazioni riservate che possono essere visualizzate da chiunque guardi lo schermo.

— Soapbox
fonte
8
Vorrei fare +1 su questo, ma trovo il "sì e no" fuorviante - dovresti cambiarlo per sottolineare che il nome del server verrà risolto utilizzando DNS senza crittografia.
— Lawrence Dol,
7
A mio avviso, l'OP utilizza la parola URL nel senso giusto. Penso che questa risposta sia più fuorviante, in quanto non fa chiaramente la differenza tra il nome host nell'URL e il nome host nella risoluzione DNS.
— Guillaume,
4
L'URL è crittografato. Ogni aspetto della transazione HTTP è crittografato. Non solo "tutto il resto". Periodo. -1.
— Marchese di Lorne,
4
@EJP ma la ricerca DNS fa uso ciò che è in una parte punto dell'URL, per così la persona non tecnica, l'intero URL non sono crittografati. La persona non tecnica che sta semplicemente utilizzando Google.com per cercare cose non tecniche non sa dove risiedano i dati o in che modo vengono gestiti. Il dominio, che fa parte dell'URL che l'utente sta visitando, non è crittografato al 100% perché io come attaccante posso annusare quale sito sta visitando. Solo il percorso / di un URL è intrinsecamente crittografato per i non addetti ai lavori (non importa come).
— trusktr,
6
@EJP, @ trusktr, @ Lawrence, @ Guillaume. Tutti voi vi state sbagliando. Questo non ha nulla a che fare con il DNS. SNI " invia il nome del dominio virtuale come parte della negoziazione TLS ", quindi anche se non usi DNS o se il tuo DNS è crittografato, uno sniffer può comunque vedere il nome host delle tue richieste.
— Pacerier,
9

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 durante la visita del sito. Ad esempio, se su un sito fossero presenti solo 2 pagine, una molto più grande dell'altra, il confronto tra le dimensioni del trasferimento di dati indica la pagina visitata. 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 documento di SciRate, https://scirate.com/arxiv/1403.0297 .

In generale, altre risposte sono corrette, praticamente sebbene questo documento mostri che le pagine visitate (ovvero l'URL) possono essere determinate in modo abbastanza efficace.

— pbhj
fonte
Ciò sarebbe realmente fattibile solo su siti molto piccoli e, in quei casi, il tema / tono / natura del sito sarebbe probabilmente lo stesso su ogni pagina.
— Cameron,
5
Dalla citazione che ho dato: "Presentiamo un attacco di analisi del traffico contro oltre 6000 pagine web che coprono le distribuzioni HTTPS di 10 siti Web leader del settore ampiamente utilizzati in settori come sanità, finanza, servizi legali e video in streaming. Il nostro attacco identifica le singole pagine in lo stesso sito Web con una precisione dell'89% [...] ". Sembra che la tua conclusione sulla fattibilità sia sbagliata.
— pbhj,
2
Per chiunque sia interessato a leggere di più su questo tipo di vulnerabilità, questi tipi di attacchi vengono generalmente definiti attacchi del canale laterale .
— Dan Bechard,
7

Non puoi sempre contare sulla privacy dell'URL completo. Ad esempio, come talvolta accade nelle reti aziendali, i dispositivi forniti come il PC aziendale sono configurati con un certificato radice "attendibile" aggiuntivo in modo che il browser possa tranquillamente fidarsi di un'ispezione 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 registro.

Inoltre, anche le tue password sono esposte e probabilmente registrate e questo è un altro motivo per usare una volta le password o per cambiarle frequentemente.

Infine, anche il contenuto della richiesta e della risposta viene esposto se non altrimenti crittografato.

Un esempio di impostazione dell'ispezione è descritto da Checkpoint qui . In questo modo è anche possibile creare un "internet café" vecchio stile utilizzando i PC in dotazione.

— Don Gillis
fonte
6

Collegamento alla mia risposta su una domanda duplicata . Non solo l'URL è disponibile nella cronologia dei browser, ma registra anche il lato server, ma viene anche inviato come intestazione del referente HTTP che, se si utilizzano contenuti di terze parti, espone l'URL a fonti indipendenti dal proprio controllo.

— JoshBerke
fonte
Fornire le chiamate di terze parti è HTTPS pure se questo non è un problema giusto?
— Liam,
3
Sarebbe crittografato con il certificato di terze parti in modo che potessero vedere l'URL
— JoshBerke
5

Ora è il 2019 ed è stato rilasciato TLS v1.3. Secondo Cloudflare, SNI può essere crittografato grazie a TLS v1.3. Quindi, mi sono detto alla grande! vediamo come appare nei pacchetti TCP di cloudflare.com Quindi, ho preso un pacchetto di handshake "client hello" da una risposta del server cloudflare usando Google Chrome come browser e wirehark come sniffer di pacchetti. Riesco ancora a leggere il nome del server in testo semplice all'interno del pacchetto Hello client.

inserisci qui la descrizione dell'immagine

Quindi, fai attenzione a ciò che puoi leggere perché questa non è ancora una connessione anonima. Un middleware tra il client e il server potrebbe registrare tutti i domini richiesti da un client.

Quindi sembra che la crittografia dell'SNI richieda implementazioni aggiuntive per funzionare con TLSv1.3

Il seguente articolo descrive la crittografia dell'SNI fornita da Cloudflare come parte di TLSv1.3. Tuttavia, tutti gli URL HTTP di cloudflare.com sono in chiaro all'interno del pacchetto TCP in TLS v1.3

[ https://blog.cloudflare.com/encrypted-sni/[[3]

— Nicolas Guérinet
fonte
"SNI può essere crittografato": questo è il punto chiave. Controllando cloudflare.com/ssl/encrypted-sni con l'attuale Google Chrome si dice "Il tuo browser non ha crittografato la SNI durante la visita di questa pagina". Ci vogliono due per il tango ...
— Piskvor lasciò l'edificio il
Apparentemente l'attuale Firefox può fare ESNI, ma è disabilitato per impostazione predefinita: è necessario abilitare network.security.esni.enabled, impostare network.trr.modesu 2 (che attualmente imposta il risolutore DoH su CloudFlare) e riavviare il browser (sic!); quindi utilizzerà ESNI, ove supportato dall'infrastruttura del dominio. Vedi blog.mozilla.org/security/2018/10/18/… per i dettagli.
— Piskvor lasciò l'edificio il
2

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 sulla sicurezza delle app mobili.

Per le app mobili , se controlli entrambe le estremità dell'applicazione (server e app), purché utilizzi HTTPS , sei sicuro . iOS o Android verificheranno il certificato e mitigheranno i possibili attacchi MiM (sarebbe l'unico punto debole in tutto questo). È possibile 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" qui sarebbe se il client o il server sono infettati da software dannoso in grado di vedere i dati prima che vengano racchiusi in https. Ma se qualcuno è infetto da questo tipo di software, avrà accesso ai dati, indipendentemente da ciò che usi per trasportarlo.

— Ricardo BRGWeb
fonte
1

Inoltre, se stai creando un'API ReSTful, i problemi di perdita del browser e di riferimento HTTP sono per lo più mitigati poiché il client potrebbe non essere un browser e potresti non avere collegamenti a clic delle persone.

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

— Chris Rutledge
fonte
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.