it-swarm.dev

La crittografia in HTTPS viene eseguita dal browser o dal sistema?

Questa potrebbe essere una domanda di buon senso, ma non sono in grado di trovare documentazione su questo dopo aver cercato su Google per molto tempo

Quando il browser effettua una richiesta HTTP, crittografa i dati quindi e lì e qualsiasi proxy (anche sullo stesso sistema) riceverà i dati in forma crittografata? Tali dati possono essere manomessi correttamente tramite proxy (sullo stesso sistema, non sulla rete)?

Se il browser esegue la crittografia/decrittografia, per favore fatemi sapere se c'è qualche documentazione che lo dice. O se la crittografia/decrittografia è gestita dal protocollo SSL sottostante solo a livello di trasporto (quando la richiesta è in rete).

30
gurvinder372

La "S" in HTTPS sta per "sicuro" (Hypertext Transfer Protocol Secure) È un protocollo di comunicazione per comunicazioni sicure che utilizza Transport Layer Security ( TLS) e il suo predecessore, Secure Sockets Layer (SSL).

TLS/SSL viene inizializzato al livello 5 ( livello sessione ) quindi funziona al livello 6 ( livello presentazione ). La maggior parte delle applicazioni, come i browser Web, i client di posta elettronica o la messaggistica istantanea incorporano funzionalità dei livelli OSI 5, 6 e 7.

Quando si fa riferimento a HTTPS sarà un'implementazione di SSL/TLS nel contesto del protocollo HTTP. SSL/TLS verrà quindi implementato in browser (e server Web) per fornire riservatezza e integrità per il traffico HTTPS (crittografia effettiva dei dati).

Chromium e Firefox utilizzano un'API denominata NSS per implementare SSL/TLS nel rispettivo browser.

Microsoft Windows, ad esempio, ha un pacchetto di sicurezza chiamato SChannel (Secure Channel) che implementa SSL/TLS per fornire l'autenticazione tra client e server. Schannel viene ad esempio utilizzato dai client/server Microsoft Windows in un ambiente Active Directory.

Per quanto riguarda il proxy e la manomissione dei dati dipende dal protocollo con cui stai lavorando. Un buon esempio per familiarizzare in un contesto HTTP (S) è dare un'occhiata a Burp Proxy .

26
Moustache

Ci sono molte buone risposte qui su come HTTPS è gestito dal browser, ma non sono sicuro che la tua domanda reale sia stata risolta.

Tali dati possono essere manomessi correttamente tramite proxy (sullo stesso sistema, non sulla rete)?

Qui la risposta è . Questo potrebbe accadere in due modi:

  • Il browser stesso è compromesso da un plugin, un'estensione o un aggiornamento dannoso.
  • Il sistema è compromesso con malware che ha modificato i certificati di radice attendibili utilizzati dal browser (che possono essere o meno gli stessi utilizzati dal sistema operativo).
14
Iszi

La risposta è ... possibilmente.

Se si specifica https://, quindi il browser si assume la responsabilità della crittografia. Alcuni browser utilizzano API fornite dal sistema operativo (guardando IE qui) mentre altri (ad esempio Firefox) effettuano il tote lungo la propria crittografia e ignorano completamente la crittografia fornita dal sistema operativo.

La resistenza alla manomissione è garantita dalla PKI. Quindi, se l'archivio certificati attendibile del tuo sistema viene danneggiato, allora tutte le scommesse sono disattivate. Ad esempio, alcune società installeranno il proprio certificato CA per la firma interna che consente loro di eseguire il proxy "man-in-the-middle" di qualsiasi sessione del browser protetta senza generare allarmi da parte del browser. Anche in questo caso, su Windows i certificati CA sono gestiti dal sistema operativo se si utilizza IE o Chrome, mentre Firefox ha un proprio elenco CA attendibile unico e separato.

Ma se il tuo sistema è compromesso, allora sei un brindisi. Nessuna sicurezza può essere garantita, nemmeno SSL. Questo perché agenti dannosi possono integrarsi ovunque in una catena; forse a livello di rete, ma forse anche nel browser, o nel driver dello schermo, o ascoltando i tasti premuti ... niente è sicuro. Esiste un classe popolare di malware oggi che si inserisce nel browser per leggere e modificare i dati crittografati prima viene crittografato e dopo viene decifrato. Un obiettivo, ad esempio, è quello di modificare leggermente la tua esperienza in un sito bancario online per drenare i conti bancari e trasferire tutto il tuo denaro all'attaccante.

11
tylerl

Il browser crittografa i dati, a condizione che si fidi del certificato SSL/chiave pubblica a cui è stato fornito dal server a cui accede, che viene quindi passato al server e decrittografato al fine di avviare una "sessione" crittografata, tra le due entità.

Spiegazione eccellente e di facile comprensione qui .

  1. Il browser si connette a un server Web (sito Web) protetto con SSL (https). Il browser richiede che il server si identifichi.
  2. Il server invia una copia del suo certificato SSL, inclusa la chiave pubblica del server.
  3. Il browser controlla la radice del certificato rispetto a un elenco di autorità di certificazione attendibili e che il certificato non è scaduto, non revocato e che il suo nome comune è valido per il sito Web a cui si sta connettendo. Se il browser considera attendibile il certificato, crea, crittografa e restituisce una chiave di sessione simmetrica utilizzando la chiave pubblica del server.
  4. Il server decodifica la chiave di sessione simmetrica utilizzando la sua chiave privata e restituisce un riconoscimento crittografato con la chiave di sessione per avviare la sessione crittografata.
  5. Server e Browser ora crittografano tutti i dati trasmessi con la chiave di sessione.

Alcune informazioni utili sulle autorità di certificazione (autorità di certificazione): https://en.wikipedia.org/wiki/Certificate_authority

7
Justice Cassel

La crittografia SSL viene impostata dal browser (o da qualsiasi applicazione che utilizza SSL), anche quando un proxy locale risiede sul sistema. Un esempio, ad esempio, è che quando si esegue un pentest è necessario impostare un proxy locale per disporre del proprio certificato per poter decrittografare il traffico tra il browser e l'endpoint.

4
Lucas Kauffman

Il browser gestisce normalmente la decodifica. Ci sono alcune eccezioni a questo però. I proxy possono rimuovere SSL (nel qual caso l'icona del lucchetto non viene visualizzata normalmente) oppure possono essere leggermente più intelligenti e rassegnare le autorizzazioni SSL con un certificato considerato attendibile dal client in modo tale che il lucchetto venga comunque visualizzato, ma le informazioni sul certificato è cambiato. Le configurazioni davvero avanzate possono effettivamente monitorare la connessione SSL se hanno accesso alla chiave privata del server senza modificare nulla sebbene siano usati lato server, non lato client (a causa del modo in cui la chiave viene derivata per una sessione SSL).

4
AJ Henderson

Le specifiche SSL/TLS dettano il protocollo over-the-wire, ma non dicono nulla sull'implementazione di un client. In genere, il kernel del sistema operativo fornisce una base non crittografata TCP. Per implementare il livello SSL, il browser chiama le funzioni in una libreria crittografica (come OpenSSL , SSLeay, GNUtls o NSS ). Pertanto, il Il supporto SSL si verifica in genere nello spazio utenti , nello stesso processo del resto del browser.

Quanto al fatto che si consideri il supporto SSL fornito dal "sistema" - dipende. Il browser può collegarsi alla libreria crittografica staticamente o dinamicamente. Una libreria dinamica (o DLL) potrebbe essere distribuita con il sistema operativo oppure il fornitore del browser potrebbe spedire la propria copia della libreria.

Sul lato server, la situazione è spesso simile, in cui un modulo server Web fornisce supporto SSL (nello spazio utente, nello stesso processo del resto del server Web). Tuttavia, sono comuni anche configurazioni alternative. Il supporto crittografico può essere con accelerazione hardware . Un proxy inverso , come un bilanciamento del carico, può trovarsi di fronte al server Web reale e tradursi tra HTTP e HTTPS, nel qual caso i dati potrebbero viaggiare senza crittografia all'interno della rete del fornitore di contenuti.

Per rispondere alla preoccupazione dell'intercettazione e manomissione dei dati: Chiunque abbia accesso alla chiave privata del server può facilmente decrittografare la trasmissione . Come corollario, qualsiasi server che presenta un certificato firmato da un'autorità di certificazione attendibile dal proprio browser può falsificare il sito Web, purché il nome host su il certificato corrisponde al nome host nell'URL. (Ad esempio, Opera gestisce un proxy per il suo Opera Mini prodotto. Il Opera Mini browser incanala tutto il traffico attraverso il proxy di Opera e si fida completamente del certificato presentato dal proxy. Pertanto, sebbene il traffico tra il browser e il proxy possa essere crittografato e il traffico tra il proxy e il server Web dei contenuti possa essere crittografato, Opera ha le caratteristiche tecniche capacità di leggere tutti i dati che passano attraverso il suo proxy.) Infine, chiunque abbia la capacità di manomettere il browser (tramite qualche meccanismo di estensione o plug-in) o il linker dinamico (usando qualcosa come LD_PRELOAD) o l'elenco di certificati attendibili del browser potrebbe anche intercettare i dati, anche se a quel punto l'integrità del cliente è stata talmente compromessa che non c'è speranza per una sicurezza significativa.

4
200_success

Un proxy installato sul computer client può infatti intercettare un traffico HTTPS decrittografato.

Tuttavia, per fare ciò, deve inserire il proprio certificato nell'archivio certificati radice attendibile. Nel fare ciò, all'utente verranno richiesti diversi problemi di sicurezza, che non possono essere facilmente aggirati. Quindi è improbabile che questa tecnica venga utilizzata dal malware a meno che l'utente non sia abbastanza sciocco da permetterlo.

Un ottimo esempio di software che utilizza questa tecnica per scopi non nefasti è Fiddler - uno strumento di debug HTTP/HTTPS per sviluppatori web.

  • Puoi leggere come abilitare la decrittazione HTTPS in Fiddler qui .
  • Puoi vedere schermate delle finestre di dialogo che l'utente deve accettare qui .
2

Cosa intendi con "sistema?" La crittografia dovrebbe avvenire in alcune librerie. Ciò può essere considerato come parte del sistema in qualche modo, e in altri modi come parte del browser. (Anche il browser stesso fa parte del sistema, nel senso che è installato per tutti gli utenti che condividono l'eseguibile.)

La granularità della sicurezza è che l'intero browser e i suoi componenti si trovano nello stesso contesto di sicurezza (ad es. Processo del sistema operativo con il proprio spazio di indirizzi). La criptovaluta si svolge in quel processo.

Per intercettare i dati in chiaro, il software dovrebbe trovare un modo per violare il contesto di sicurezza del browser. Questo di solito è possibile nei sistemi operativi che hanno solo criteri di sicurezza a grana grossa, per il codice che ha in qualche modo acquisito i privilegi di superutente.

Per esempio. nei sistemi operativi simili a Unix possiamo usare la chiamata di sistema ptrace per collegarci a un processo e fare varie cose come sospendere e riprendere la sua esecuzione, monitorare le chiamate di sistema o esaminare/modificare la sua memoria.

I dati che entrano nel browser, come i tasti digitati nei moduli, hanno origine in qualche altro contesto di sicurezza, ovvero quello che contiene il driver della tastiera nel kernel del sistema operativo. Ciò può anche essere attaccato da un programma privilegiato in grado di accedere ai dati che passano attraverso i driver.

Tuttavia, un proxy HTTP/HTTPS (al contrario di un programma superutente dannoso che fa capolino nei processi) in esecuzione sullo stesso computer non avrebbe accesso al traffico in chiaro. Ciò che passa attraverso un proxy è il protocollo HTTPS crittografato.

0
Kaz