È possibile eseguire una vera crittografia SSL end-to-end?

Questa pratica è talvolta descritta come "attacco istituzionale man-in-the-middle " . Può essere fatto modificando il codice client (in modo tale da consentire tale proxy), o aggiungendo una CA speciale nel trust store del client; in quest'ultimo caso, il proxy intercetta la connessione, genera un certificato falso per il server (emesso dalla CA speciale - è "speciale" in quanto la chiave privata è controllata dal proxy) e esegue un vero attacco "MitM" ".

Questo è fatto da grandi filtri di contenuto organizzativo (ad esempio ProxySG di Bluecoat ) e da "Acceleratori di Internet" come quello che osservare (accedendo al contenuto dei dati grezzi, il proxy MitM può applicare alcune strategie per "accelerare le cose", ovvero la memorizzazione nella cache e la compressione forzata dei dati).

Gli acceleratori spesso fanno affidamento sulla modifica del codice client, che consente più "accelerazioni" rispetto all'intercettazione di base con un certificato falso del server. Questo è probabilmente il tuo caso; sarà specifico per il browser. È un un problema di sicurezza poiché sconfigge uno dei punti chiave di SSL, ovvero per garantire riservatezza e integrità end-to-end. Conosco alcune banche che sono davvero scontente di questo, perché rende molto più difficile applicare un valore legale all'Internet banking basato su SSL. Come utente, puoi difendere questa pratica (che è davvero diffusa) utilizzando un browser alternativo (ad esempio Firefox sembra essere disponibile per alcuni telefoni Nokia) e verificare che il browser alternativo si fidi della CA radice "affidabile".

( Nota: mi viene da pensare che poiché questi "acceleratori di Internet" tendono a utilizzare la compressione indiscriminata dei dati sul collegamento tra il telefono e il proxy MitM, sono probabilmente vulnerabili a attacco CRIME . Potrebbe valere la pena di investigare e pubblicizzare .)

Modifica: mentre il MitM delle connessioni SSL sembra verificarsi con il browser di Nokia (ad esempio, vedi questo articolo ), la funzione corrispondente in Opera / OperaMini, chiamata turbo , afferma non di farlo per SSL, solo per HTTP semplice:

Even while using Opera Turbo, secured connections do not go through Opera's servers. This means that when you are using your bank or transmitting sensitive data, you are talking directly with the website.

si tratta di TRUST, che si riduce a:

1. ti fidi del tuo browser per dirti che è collegato in modo sicuro a un sito SSL / TLS?
2. Ti fidi dell'autorità di certificazione di aver correttamente convalidato il sito web e che i dettagli del certificato sono veri?
3. Ti fidi del certificato stesso?

Rispondere a questi è abbastanza difficile, ma darò il mio punto di vista.

1. Mi fido dei browser open source perché potrei sempre guardare il codice - se non lo faccio, un'anima intraprendente lo farà e suonerà tutto su Internet se dovesse risultare che c'era una backdoor di qualche tipo
2. Guardo sempre l'emittente del certificato (solitamente disponibile tramite "Visualizza certificato" o qualcosa del genere. È un emittente Wierdo che rimuovo dal mio elenco di emittenti approvati.
3. Questo non è un problema molto diffuso, ma quando DigiNotar è stato compromesso, rilasciava certificati falsi che erano automaticamente considerati affidabili dai broswers. Non va bene.

Se tutte queste tre cose sono OK, non vedo come un ISP (o un fornitore di rete a monte) possa MITM con successo senza alcun avvertimento, l'utente. Nella domanda dell'OP - menzionano che usano Opera. Opera è un fornitore di browser a sorgente chiuso, anche se Opera Browser in generale è di ottima qualità.

Spero che queste tre domande aiuteranno l'utente a fare una scelta informata.

So my question is very simple: how can I securely connect, from a desktop computer (not from a phone), to websites using HTTPS (like my online banking website or my GMail), knowing that I may be using an ISP interested in spying on me?

Does a browser like Google Chrome, for example, have any protection against this? (for example is it sufficient to look at the green "lock" icon followed by "HTTPS://mail.google.com/..." or can this be tricked too by the ISP?)

È molto semplice. Ottieni il browser e il sistema operativo da una fonte attendibile ed esamina l'origine del certificato. Se l'origine è la fonte prevista, ad esempio, Verisign. Quindi puoi avere fiducia che Verisign ha verificato l'identità del proprietario in base alla Dichiarazione di pratica di certificazione.

Per essere sicuro di non farti ingannare in un momento di pigrizia. Elimina le autorità di certificazione che non ti fidi dal tuo browser.

Se hai ottenuto il browser scaricandolo tramite il tuo ISP, potrebbero intercettare la richiesta e sostituirla con un browser con certificati attendibili dalla propria CA. Questo tipo di comportamento è più simile ai governi repressivi o, come sembra, alle telecomunicazioni.

A seconda dei tuoi criteri, ottenere la tua prima fonte attendibile può essere complicato, ma una volta ottenuto, puoi usare quella fonte attendibile per verificare altre fonti attendibili. Ad esempio, è possibile scaricare una nuova versione di Chrome tramite la connessione dell'ISP se si è connessi al sito di download tramite SSL, si fida del certificato, si fida del computer e si fida dell'autore del browser.

Quello che i client che usano i relay finiscono per fare è che un altro server agisce come end-point e il "browser" è più di un client di visualizzazione remota. Se le comunicazioni rimosse dal client di visualizzazione sono correttamente crittografate, potrebbe esserci un problema di privacy, ma meno di sicurezza, in quanto ci si fida della terza parte che esegue l'inoltro.

Per quanto riguarda come assicurarsi di essere protetti su un desktop, un ISP non potrebbe farlo. L'unico motivo per cui i browser possono farlo è perché controllano il browser e ciò che il browser dice è legittimo. Fondamentalmente inoltrano le informazioni che il loro server riceve come informazioni sul certificato e si fida in particolare perché non funziona attraverso l'API crpytographic locale.

Finché il browser utilizzato sta eseguendo la convalida crittografica del certificato, non vi è modo che un ISP o altra terza parte possa impersonare il mittente a meno che non disponga di un certificato valido (risolvente) per l'URI a cui ci si sta connettendo . Quindi, se puoi fidarti del tuo browser, puoi fidarti della tua connessione SSL, ma solo se ti fidi dell'integrità del tuo browser.