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

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

TLS / SSL è inizializzato al livello 5 ( il livello di sessione ) quindi funziona al livello 6 (il livello di presentazione ). La maggior parte delle applicazioni, come browser Web, client di posta elettronica o 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 nei browser (e nel web server) per fornire riservatezza e integrità per il traffico HTTPS ( crittografia effettiva dei dati).

Chromium e Firefox utilizzano un'API chiamata NSS per implementare SSL / TLS nei rispettivi browser.

Microsoft Windows, per esempio, ha un pacchetto di sicurezza chiamato SChannel (Secure Channel) che implementa SSL / TLS per fornire l'autenticazione tra client e server. Schannel è ad esempio utilizzato dai client / server Microsoft Windows all'interno di 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 al Burp Proxy .

Qui ci sono molte buone risposte su come HTTPS viene gestito dal browser, ma non sono sicuro che la tua domanda reale sia stata indirizzata.

Can that data be tampered successfully via proxy (on the same system, not on network)?

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

• Il browser stesso è compromesso da un plug-in, estensione o aggiornamento dannoso.
• Il sistema è compromesso con malware che ha alterato i certificati di radice affidabili utilizzati dal browser (che può essere o non essere lo stesso utilizzato dal sistema operativo).

La risposta è ... possibilmente .

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

La resistenza alla manomissione è garantita dall'infrastruttura PKI. Pertanto, se l'archivio dei certificati attendibili del tuo sistema viene danneggiato, tutte le scommesse sono disattivate. Ad esempio, alcune aziende installeranno il proprio certificato CA per la firma interna che consentirà loro di gestire il proxy man-in-the-middle in qualsiasi sessione protetta del browser senza generare allarmi dal browser. Anche in questo caso, su Windows i certificati CA sono gestiti dal sistema operativo se si utilizza IE o Chrome, mentre Firefox dispone di un elenco CA attendibile univoco e separato.

Ma se il tuo sistema è compromesso, allora sei brindisi. Nessuna sicurezza può essere garantita, nemmeno SSL. Questo perché gli agenti maligni possono incorporarsi ovunque in una catena; forse a livello di rete, ma forse anche nel browser, o nel driver del display, o ascoltando le sequenze di tasti ... nulla è sicuro. Oggi esiste una classe popolare di malware che si inserisce nel browser per leggere e modificare i dati crittografati prima viene crittografato e dopo viene decodificato. Un obiettivo, ad esempio, è modificare leggermente la tua esperienza in un sito di banking online per drenare i conti bancari e trasferire tutti i tuoi soldi all'attaccante.

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

Spiegazione eccellente e di facile comprensione qui .

1. Browser connects to a web server (website) secured with SSL (https). Browser requests that the server identify itself.
2. Server sends a copy of its SSL Certificate, including the server’s public key.
3. Browser checks the certificate root against a list of trusted CAs and that the certificate is unexpired, unrevoked, and that its common name is valid for the website that it is connecting to. If the browser trusts the certificate, it creates, encrypts, and sends back a symmetric session key using the server’s public key.
4. Server decrypts the symmetric session key using its private key and sends back an acknowledgement encrypted with the session key to start the encrypted session.
5. Server and Browser now encrypt all transmitted data with the session key.

Alcune informazioni preziose sulle CA (autorità di certificazione): link

Il browser gestisce normalmente la decrittografia. 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 l'SSL con un certificato che è considerato affidabile dal client in modo tale che il blocco venga ancora visualizzato, ma le informazioni sul certificato è cambiato. Configurazioni realmente avanzate possono effettivamente monitorare la connessione SSL se hanno accesso alla chiave privata del server senza modificare nulla anche se vengono utilizzate lato server, non lato client (a causa del modo in cui la chiave viene derivata per una sessione SSL).

La crittografia SSL è configurata dal browser (o da qualsiasi applicazione che utilizza SSL), anche quando un proxy locale risiede nel sistema. Un esempio, ad esempio, è che quando si esegue un pentest è necessario configurare un proxy locale affinché il proprio certificato sia in grado di decrittografare il traffico tra il browser e l'endpoint.

Le specifiche SSL / TLS dettano il protocollo over-the-wire, ma non dicono nulla su come viene implementato un client. In genere, il kernel del sistema operativo fornisce un socket TCP non crittografato di base. Per implementare il livello SSL, il browser chiama le funzioni in una libreria crittografica (come OpenSSL , SSLeay, < a href="http://www.gnutls.org/"> GNUtls o NSS ) . Pertanto, il supporto SSL normalmente si verifica in spazio utente , nello stesso processo del resto del browser.

Per quanto riguarda l'eventuale supporto SSL fornito dal "sistema", dipende. Il browser può collegarsi alla libreria crittografica in modo statico o dinamico. Una libreria dinamica (o DLL) potrebbe essere distribuita con il sistema operativo, oppure il venditore del browser può 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 potrebbe essere accelerato dall'hardware . Un reverse proxy , come un bilanciamento del carico, può sedersi di fronte al server Web reale e tradurre tra HTTP e HTTPS, nel qual caso i dati potrebbero viaggiare non crittografati all'interno della rete del provider di contenuti.

Per affrontare il problema dell'intercettazione e della manomissione dei dati: Chiunque abbia accesso alla chiave privata del server può facilmente decodificare la trasmissione . Come corollario, qualsiasi server che presenta un certificato firmato da un'autorità di certificazione attendibile dal tuo browser può spoof il sito Web, a condizione che il nome host sul certificato corrisponda al nome host nell'URL. (Ad esempio, Opera gestisce un proxy per il suo prodotto Opera Mini . Il browser Opera Mini incanala tutto il traffico tramite 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 di contenuto possa essere crittografato, Opera ha la capacità tecnica di leggere tutti i dati in corso attraverso il suo proxy.) Infine, chiunque abbia la capacità di manomettere il browser (con qualche meccanismo di estensione o plugin) o il linker dinamico (usando qualcosa come LD_PRELOAD) o l'elenco dei certificati attendibili del browser potrebbe anche intercettare i dati, anche se a quel Indicare che l'integrità del cliente è stata così compromessa che non c'è speranza per una sicurezza significativa.

Un proxy installato sul computer client può effettivamente intercettare un traffico HTTPS di decrittografia.

Tuttavia, per fare ciò, deve posizionare il proprio certificato nell'archivio certificati radice attendibili. In tal modo, all'utente verranno richieste diverse sfide di sicurezza, che non possono essere facilmente aggirate. Quindi è improbabile che questa tecnica venga utilizzata dal malware a meno che l'utente non sia abbastanza sciocco da consentirgli di accadere.

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

• Puoi leggere come abilitare la decrittografia HTTPS in Fiddler qui .
• Puoi vedere gli screenshot delle finestre di dialogo che l'utente deve accettare qui .

Che cosa intendi per "sistema?" La crittografia dovrebbe verificarsi in alcune librerie. Questo può essere considerato come parte del sistema in qualche modo e in altri modi come parte del browser. (Anche il browser stesso è 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 esempio, il processo del sistema operativo con il proprio spazio indirizzo). La crittografia ha luogo in quel processo.

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

es. in sistemi operativi Unix-like possiamo usare la chiamata di sistema ptrace per allegare a un processo, e fare varie cose come sospendere e riprendere l'esecuzione, monitorare le chiamate di sistema o esaminare / modificare la sua memoria.

I dati che arrivano nel browser, come le sequenze di tasti che inserisci nei form, hanno origine in un altro contesto di sicurezza, in particolare quello che contiene il driver della tastiera nel kernel del sistema operativo. Questo può anche essere attaccato da un programma privilegiato che è in grado di accedere ai dati che passano attraverso i driver.

Tuttavia, un proxy HTTP / HTTPS (al contrario di un programma superuser maligno che fa capolino nei processi) in esecuzione sulla stessa macchina non avrebbe accesso al traffico in chiaro. Ciò che passa attraverso un proxy è il protocollo HTTPS crittografato.