Quanto guadagna una richiesta GET su HTTPS a un intercettatore

Question

Quanto guadagna una richiesta GET su HTTPS a un intercettatore

#1 da (7 voti)
#2 da (3 voti)
#3 da (1 voti)

6

Correggimi se ho torto, secondo HTTP v1.1 una semplice richiesta CONNECT avvia un tunnel SSL tra il server e un client. è solo dopo la creazione del tunnel che viene inviata la richiesta GET o POST completa. Ciò che viene inizialmente inviato è una versione ridotta di una richiesta GET / POST per avviare SSL.

Quando viene avviato SSL, per quanto ne so, un evescritto può vedere solo l'IP di destinazione, l'IP di origine e la PORTA nel pacchetto TCP / IP. Tutto il resto è crittografato. per favore, correggimi di nuovo, se ho un'idea sbagliata sullo stesso. Questo è semplicemente un insieme di informazioni raccolte a cui richiedo conferma.

Se quello che ho detto finora è corretto,

chiamando l'URL: www.websiteurl.com?username=name&password=PASSWORD

Dovrebbe essere perfettamente sicuro fin tanto che solo un intercettatore osserva i pacchetti che viaggiano tra server e client. So che dal momento che gli URL vengono registrati ovunque nel computer locale, può essere pericoloso. Non sto pianificando di implementare un sistema con questa conoscenza, ma ho bisogno di confermare se so quello che so correttamente.

Quindi sarebbe sicuro inviare informazioni sensibili su GET quando si utilizza HTTPS dopo l'avvio della sessione SSL con il server?

Questa domanda potrebbe non avere alcuna implementazione pratica poiché l'invio di informazioni sensibili tramite URL non è necessario.

http tls man-in-the-middle

posta Dina 30.10.2014 - 09:52

fonte

3 risposte

3

according to HTTP v1.1 a simple CONNECT request initiates a SSL tunnel between the server and a client.

Non proprio corretto. CONNECT è usato solo insieme ai proxy. E anche allora stabilisce solo un tunnel direttamente sull'altro lato, ma non ancora il tunnel SSL. Il tunnel SSL è con e senza proxy stabilito solo con l'handshake SSL tra entrambe le parti.

When the SSL is initiated, as for my knowledge, an evesdropper can only see the destination IP, source IP and the PORT in the TCP/IP packet.

Può anche vedere il nome host richiesto nella maggior parte dei casi, perché tutti i browser moderni utilizzano SNI (indicazione del nome del server) per fornire supporto per più certificati dietro lo stesso IP. E anche senza questo può vedere il certificato dal server, che di solito include il nome host richiesto (ma potrebbero esserci anche altri nomi all'interno). L'intercettatore può anche vedere che è SSL, che vengono utilizzati i cifrari, quale versione del protocollo viene detta ecc.

Ma non può visualizzare l'URL completo o altre informazioni dalla richiesta come i cookie ecc.

So would it be safe to send sensitive information over GET when using HTTPS after the SSL session is initiated with the server?

Se le informazioni sensibili non sono nel nome host, ma nel percorso o nella stringa di query o nel payload di una richiesta POST, TLS è sufficiente.

risposta data 30.10.2014 - 10:26

fonte

1

Potrebbe già avere una risposta, ma, in un ambiente normale (ad esempio a casa) vedresti solo l'handshake TCP e l'handshake SSL tra host e OCS (Original content server) o webserver. Solo se sei in una configurazione proxy esplicita, vedresti la richiesta HTTP CONNECT, ma sarebbe dall'host al proxy. Il proxy quindi intercettava il traffico. Verrà quindi visualizzato l'handshake SSL tra host e proxy e nulla più.

risposta data 26.09.2015 - 15:42

fonte

Leggi altre domande sui tag http tls man-in-the-middle

Quali personaggi pericolosi devono essere filtrati dall'input dell'utente prima di essere utilizzati in una query DB2 SQL? Gli attacchi CSRF sono davvero ciechi

score 7 · Accepted Answer

Correct me if I am wrong, according to HTTP v1.1 a simple CONNECT request initiates a SSL tunnel between the server and a client. its only after the tunnel is created that the complete GET or POST request is sent.

No, questo non è un CONNECT HTTP, è una richiesta di connessione TCP. Il metodo HTTP CONNECT viene utilizzato solo se ci si connette tramite un proxy HTTP e il certificato del server proxy non è considerato attendibile dal browser client. Ciò renderà le future richieste trasferite sul proxy come dati SSL puri (crittografati), anziché come richieste HTTP (decifrate sul proxy e quindi reencrittate per il percorso di destinazione).

When the SSL is initiated, as for my knowledge, an evesdropper can only see the destination IP, source IP and the PORT in the TCP/IP packet. Everything else is encrypted. please do correct me again

Quasi. Possono vedere le porte e gli IP di origine e di destinazione e, se SNI è abilitato possono vedere il nome del dominio di destinazione.

So would it be safe to send sensitive information over GET when using HTTPS after the SSL session is initiated with the server?

Sì, per questi scopi. Un MITM non vedrebbe i parametri del percorso o della stringa di query sull'URL, anche se lo menzioni è facile per questi perdersi in luoghi come la cronologia del browser, i registri di qualsiasi server proxy fidato (ad esempio un proxy in un ambiente aziendale che è considerato affidabile dal computer client) o possibilmente nell'intestazione referer .