POST su HTTPS "abbastanza sicuro" per i dati sensibili?

9

Mi chiedo se impedire la possibilità di un certificato SSL compromesso che potrebbe potenzialmente divulgare informazioni sensibili se fosse prudente crittografare ulteriormente i dati trasmessi su SSL.

Scenario immaginario: due applicazioni web. Una è un'applicazione Web, l'altra è un'applicazione che fornisce un'API di autenticazione.

L'app Web invia un HTTPS POST all'API di autenticazione contenente nome utente e password. È crittografato tramite SSL.

Tuttavia, non è stato possibile sniffare i dati se un utente malintenzionato doveva compromettere il certificato SSL?

Il mio pensiero è di aggiungere un altro livello di crittografia, ad es. abbiamo una coppia di chiavi pubblica / privata aggiuntiva e crittografiamo anche tutte le informazioni nel POST.

Ciò significherebbe che un utente malintenzionato che ha compromesso il certificato SSL avrebbe dovuto trovare una chiave privata aggiuntiva per interrompere la comunicazione.

Pensieri?

    
posta user8405 06.02.2014 - 22:01
fonte

4 risposte

5

Invece di crittografia aggiuntiva, se deve essere sicuro, utilizzare l'autenticazione a due fattori. Fai in modo che gli utenti utenti inseriscano un nome utente, una password e un numero casuale a 6 cifre inviato tramite e-mail o SMS. Un certificato compromesso significa che l'attaccante può eventualmente controllare l'intero carico utile SSL in entrambe le direzioni; includendo qualsiasi codice inviato al client per eseguire la crittografia richiesta per l'autenticazione con il server.

Considerare anche la separazione tra il server applicazioni e il server di autenticazione. Ciò rende molto più difficile per un utente malintenzionato fare qualcosa di utile con un elenco acquisito di nomi utente e password se non vengono effettivamente accettati dal server delle applicazioni; questo è il concetto dietro OAuth2. È molto più facile recuperare un server piuttosto che attaccare due server (almeno, in teoria).

    
risposta data 06.02.2014 - 23:08
fonte
2

Suppongo che quando si dice che la "web app" invia un POST, ciò che si intende veramente è che la pagina html nel browser degli utenti effettua una richiesta POST a un server di terze parti.

L'evento di un compromesso SSL / TLS da parte di un attaccante esterno (CA / governo canaglia) è probabilmente piuttosto basso. Ciò lascia due possibilità.

# 1. Il tuo server è stato compromesso da un attacco non correlato e la chiave privata è stata rubata

Se qualcuno è nel tuo sistema e può accedere alla chiave privata, è probabile che possa accedere alla tua applicazione / fonte e modificarla per sifonare i dati (MITM). A quel punto nessun crypto extra ti salverà.

# 2. Le impostazioni utilizzate per creare / distribuire SSL / TLS sono sbagliate. Se utilizzi algoritmi / hash non sicuri o una vecchia versione SSL potresti essere vulnerabile agli attacchi specifici SSL ( link ) . Ricordarsi di utilizzare SSL 3 / TLS. Preferibilmente TLS 1.2.

    
risposta data 07.02.2014 - 03:51
fonte
0

Sì! TLS è non sicuro - la sostituzione del certificato è estremamente comune (la maggior parte delle aziende utilizza dispositivi edge-inspection edge, la maggior parte delle scuole e unis, tutti i firewall buoni e anche diversi paesi obbligano tutti gli utenti a installare la propria CA in modo che possano MitM e ispezionare il traffico "crittografato"). Circa ogni 2 mesi, si scopre che anche una nuova CA è stata compromessa. Ci sono anche molti malware che installano la propria CA sui computer delle vittime.

L'uso di 2FA non è una soluzione per questo problema. 2FA è una tecnologia di autenticazione di 35 anni che non ha assolutamente nulla a che fare con la protezione contro l'intercettazione del traffico.

    
risposta data 14.03.2017 - 16:31
fonte
0

Se si suppone che la chiave privata sia stata compromessa (il certificato è rilasciato con ogni transazione, ma è inutile senza la chiave privata), sarebbe dovuto essere stato in banca. Se questo è il caso, qualsiasi altro meccanismo di sicurezza fornito dalla banca è ugualmente nullo e non valido.

Se si presume che il browser o l'applicazione dispongano di un'autorità CA aggiuntiva (come spesso accade per i datori di lavoro), in sostanza il client viene compromesso. Se non ti fidi dell'elenco delle CA, perché ti fiderei che il browser non abbia alcun hook - o per quello che riguarda un keylogger?

Se questo viene fatto da un'applicazione che stai scrivendo, dovresti essere in grado di ottenere il certificato TLS per la tua connessione. Questo dovrebbe essere possibile per Java in un browser, (anche se apparentemente non da Javascript). Stai ancora, naturalmente, partendo dal presupposto che il programma application / java non sia stato manomesso - non c'è modo di eseguire codice fidato su una piattaforma non sicura.

Se si dispone di una connessione TLS utilizzando Diffie-Hellman, non è possibile decrittografare i dati acquisiti, anche con la chiave privata (citazione: link ).

Un attacco man-in-the-middle funzionerà ancora anche per un Diffie-Hellman (se l'attaccante ha la chiave privata e il certificato, sono indistinguibili dal legittimo proprietario).

La mia opinione personale è che, se qualcuno sta manomettendo / tentando di manomettere i miei dati, allora non voglio un altro livello di crittografia, voglio essere informato (e ho rifiutato il servizio).

Nota anche: ho visto certificati CA aggiuntivi installati da software antimalware, quindi è possibile eseguire la scansione di malware fornito da https.

    
risposta data 04.08.2018 - 12:36
fonte

Leggi altre domande sui tag