Con HTTPS, l’URL e le intestazioni delle richieste sono protetti come il corpo della richiesta?

Voglio solo verificare, quando fai una connessione SSL (http post) per dire:

https://www.example.com/some/path?customer_key=123123123 

Se non vuoi che qualcuno sappia su customer_key, questo approccio non funzionerà anche se sto facendo una connessione https corretta?

Tutti i dati che voglio essere protetti devono essere nel corpo della richiesta giusto?

Citando la RFC HTTPS :

Quando l’handshake TLS è terminato. Il client può quindi avviare la prima richiesta HTTP. Tutti i dati HTTP DEVONO essere inviati come “dati dell’applicazione” TLS.

In sostanza, il canale SSL / TLS sicuro viene stabilito per primo. Solo allora viene utilizzato il protocollo HTTP. Questo proteggerà tutto il traffico HTTP con SSL, comprese le intestazioni HTTP (che contengono l’URL e i cookie).

Ciò che potrebbe essere visibile nell’handshake è il nome host stesso, poiché è contenuto nel certificato del server che sarà visibile in chiaro nell’handshake (ed è spesso facile indovinare il nome host guardando comunque all’indirizzo IP di destinazione).

Quando si utilizza l’indicazione del nome del server, il nome host richiesto dovrebbe essere visibile anche nell’estensione server_name nel messaggio ClientHello . Altrimenti, potrebbe esserci un po ‘di ambiguità (per gli intercettatori) per indovinare il nome host dal certificato se il certificato è valido per più nomi host (ad es. Più oggetti Alt. Nomi o caratteri jolly). In questo caso, l’intercettazione della richiesta DNS da parte del client potrebbe dare un indizio all’attaccante.

Leggendo le risposte e i commenti di altre persone, alcuni citano problemi relativi a Referer (perso una r nelle specifiche) e log.

  • I referrer non devono essere inviati quando si passa da HTTPS a HTTP (ma vengono spesso inviati quando si passa da un sito HTTPS a un altro sito HTTPS) .
  • A proposito della cronologia: devi solo fidarti di chi potenzialmente può ottenere legittimamente quella chiave (cioè i tuoi utenti) per non diffonderlo. Se necessario, avere una strategia per cambiarlo una volta ogni tanto.
  • Informazioni sui log: stavo dando per scontato che tu fossi protetto dalla rete . L’URL (inclusa la query) si troverà effettivamente nei log, ma se qualcuno è in grado di attaccare la tua macchina in modo da ottenere i registri, devi preoccuparti maggiormente delle chiavi dell’app.

Uno dei rimanenti punti deboli potenziali è come si fornisce quel collegamento all’utente. Se è incorporato in una pagina Web pubblicata su un semplice HTTP, chiunque sia in grado di leggere quella pagina sarà in grado di vederlo. Dovresti pubblicare anche questa pagina su HTTPS. Se invece invii quel collegamento via e-mail, direi che tutte le scommesse sono distriggerste, poiché i server di posta raramente crittografano le connessioni tra loro e gli utenti spesso accedono spesso al loro account e-mail senza alcuna crittografia.

MODIFICARE:

Inoltre, se si sta utilizzando l’autenticazione del certificato client, il certificato client sarà visibile se è negoziato durante l’handshake iniziale. Ciò potrebbe far trapelare il nome dell’utente che accede al sito Web (spesso i DN object contengono il nome utente). Il certificato client non sarà visibile se viene inviato durante un handshake rinegoziato.

Solo www.example.com sarà visibile ai ficcanaso. La sezione del percorso della richiesta è protetta da SSL / TLS.

Ovviamente, è necessario aver inviato anche il collegamento ipertestuale originale tramite HTTPS.

I dati della richiesta verranno inviati dopo aver stabilito la connessione protetta, quindi non preoccuparti dell’URL precedente, ma ricorda che i tuoi dati non sono crittografati, solo il canale tra server e client è crittografato, se uno può decifrare questo canale, quindi può vedere chiaramente i tuoi dati.

SSL è un canale crittografato wrapper in cima ai tuoi dati. Se i dati sono chiari, chiunque possa violare l’SSL può vedere chiaramente i tuoi dati.

Rivedere la mia risposta a NO! Apparentemente solo il nome host viene inviato in chiaro prima che venga stabilita la connessione SSL.

http://answers.google.com/answers/threadview/id/758002.html

Dipende..

Se si utilizza uno sniffer di pacchetti, non è ansible visualizzare i dati inviati sul filo. Il problema principale di questo approccio è che l’url della richiesta viene spesso salvato nel log del server in testo normale, la cronologia del browser mantiene l’URL, gli URL sono passati nelle intestazioni Referrer e forse persistono dai servizi di terze parti (google analytics).