Le richieste SSL possono essere inoltrate tramite proxy emettendo un secondo certificato?

Questo è esattamente il motivo per cui sono diventato così incazzato alla Bank of America quando hanno inviato un link a myfraudprevention.com quando pensavano che il mio account fosse compromesso. SSL funziona solo per verificare che alcune terze parti attendibili abbiano convalidato che il sito Web visitato è il nome dell'URL visitato. Se hai inviato qualcuno al tuo sito web e quel sito Web aveva un certificato, potresti comunque rendere il sito simile a quello che volevi, incluso un sito di phishing che finge di essere un'altra organizzazione.

Tutto ciò che SSL dovrebbe interessare è che tu sei effettivamente il proprietario di charliesbank.com. Bank of America stava letteralmente addestrando i propri utenti a cadere vittima di phishing in una e-mail progettata per aiutare a fermare le frodi ...

L'allenamento degli utenti è l'unico modo per impedirlo al momento. Se si verificano effettivamente i dettagli del certificato presentato, è necessario fornire maggiori dettagli sull'organizzazione a cui è rilasciato il certificato. Se il certificato SSL ha Extended Validation ed è l'organizzazione con cui vuoi parlare, vuol dire che alcune autorità di certificazione hanno guardato a loro e determinato che sono l'organizzazione che affermano di essere, ma attualmente è nell'interfaccia utente capire come funziona questo processo e fai la verifica da soli. È anche sull'utente controllare l'URL a cui sono connessi.

Probabilmente non c'è molto da fare per migliorare questo o come non c'è modo per il computer di sapere che l'utente desiderava davvero bobsbank.com ma ha visitato charliesbank.com. L'icona potrebbe essere sostituita con qualcosa che mostri maggiori dettagli sul certificato, ma in generale ciò causa maggiore confusione per la maggior parte degli utenti che non capiscono come funziona SSL.

L'attacco viene evitato con l'uso di certificati , ovvero i nomi . Il browser di Alice rifiuterà il certificato di Charlie, perché il browser vuole parlare con www.thebank.com e quindi si aspetta di vedere quel nome esatto www.thebank.com nel certificato del server presunto. Il certificato di Charlie contiene www.evilcharlie.com , il nome del proprio sito Web.

Per attuare il suo attacco, Charlie avrebbe dovuto corrompere una CA (una delle persone di cui si fidava per impostazione predefinita nel browser di Alice) per rilasciargli un certificato contenente www.thebank.com . Naturalmente, una buona CA non accetterà che (quando lo fanno, rende le notizie ; tali disavventure si verificano una volta all'anno in tutto il mondo, il che non è così frequente).

Does this attack work

Sì, infatti ci sono soluzioni commerciali per fare esattamente questo. Apparentemente non per scopi dannosi.

and is there any way to prevent against it?

Sì, non utilizzare una connessione Internet che dispone di tale proxy. Più comunemente, queste installazioni si trovano su reti aziendali, reti di campus o altri luoghi in cui l'operatore di rete desidera esaminare tutto il traffico, compreso il traffico SSL.

In genere queste installazioni richiedono l'installazione di un certificato di autorità radice "falso" SSL nel browser utilizzato per firmare i certificati generati per eseguire l'attacco man-in-the-middle. Quindi ... non farlo. Anche se l'utente malintenzionato ha già un certificato CA installato sul tuo computer che non sarebbe necessario.

Does the attack work?

Sì l'attacco funzionerebbe. A differenza di alcune altre risposte, non è necessaria alcuna modifica speciale nell'archivio certificati CA locale del dispositivo che voglio attaccare.

Is there any way to prevent it?

L'unico modo in cui posso pensare di risolvere questo problema è utilizzare i certificati client / TLS reciproco , o una "app" che si collega solo al sito attendibile.

.. l'attacco

Un "Phishing Proxy & Certificate Substitution" funzionerebbe in questo modo:

Supponiamo che volessi attaccare una banca chiamata www.contoso.com e acquisto il nome DNS www.contos0.com . Quindi acquisto un certificato di controllo del dominio standard che verifica semplicemente che possiedo il controllo del dominio. Non è necessario alcun certificato EV, anche se suppongo che si possa essere acquisito.

Quindi l'utente malintenzionato ottiene il software TCP che essenzialmente esegue l'eco dei dati e li inoltra al server successivo. Il processo avviene anche al contrario e viene eseguita una sessione duplex.

L'attacco di phishing simile a questo:

Browser  <---->  contos0.com:443 (decrypt and rencrypt) <----> contoso.com

.. la mitigazione

Per siti web / desktop normali

Poiché il tuo server web può utilizzare qualsiasi CA per generare certificati client, puoi:

1. Iscrivi gli utenti al certificato utilizzando l'elemento HTML5 KeyGen
2. Oppure iscriviti gli utenti semplicemente offrendo l'intero certificato (chiave pubblica e privata in un PFX combinato) per il download.

Ho testato l'interfaccia utente per vari browser e vedo il Keygen più facile da gestire per l'utente finale, anche se ha bisogno di miglioramenti.

Per le app mobili

I browser mobili non mostrano quasi mai la barra del browser, quindi la maggior parte degli utenti non sapranno se si trovano su un sito di phishing, un sito HTTPS o un sito con un certificato EV.

• Quando un utente accede al tuo sito web puoi reindirizzarli alla tua app iOS, Android, Blackberry o Windows . Ciò rafforzerà il buon comportamento dell'utente finale e farà in modo che accedano solo tramite un'applicazione "attendibile".

• Certificati client in un browser Web o un'applicazione web

I certificati SSL di base e la consapevolezza umana di base dovrebbero essere sufficienti a proteggerlo nuovamente. Ma il business moderno ha degradato il processo di rilascio di un certificato SSL e la nuova tecnologia sta confondendo le persone.

In passato, ottenere un certificato SSL implicava la verifica dall'autorità di certificazione e una tariffa pesante. La commercializzazione del processo ha determinato la riduzione della qualità della verifica e l'introduzione di certificati SSL "solo per la convalida del dominio" per i quali viene eseguita una verifica minima. E così, i certificati SSL sono diventati così popolari che le persone hanno iniziato a considerarli come un dato di base, non qualcosa che dovrebbe essere controllato . I browser non sono stati d'aiuto né identificando chiaramente i certificati di alta qualità.

Quindi sono stati introdotti i certificati di convalida estesa (EV) per garantire che il proprietario del sito Web gestisca un'attività affidabile e abbia un'identità verificabile. Un costoso e noioso processo di controllo scoraggia i malfattori ad acquistare certificati EV. Questi certificati sono dotati di una maggiore sicurezza visiva, quella lunga barra verde con il nome dell'azienda.

Ma i certificati EV non risolvono il problema di confusione. Secondo uno studio della Stanford University e della ricerca Microsoft studio di usabilità del display EV in Internet Explorer 7:

Participants who received no training in browser security features did not notice the extended validation indicator and did not outperform the control group.

mentre

Participants who were asked to read the Internet Explorer help file were more likely to classify both real and fake sites as legitimate.