protocollo di sicurezza contro gli attacchi su SSL / TLS

Question

protocollo di sicurezza contro gli attacchi su SSL / TLS

#1 da (2 voti)
#2 da (2 voti)
#3 da (0 voti)

3

Un client sta comunicando con un server tramite https utilizzando l'autenticazione a due vie. Vorrei aggiungere un ulteriore livello di sicurezza.

Il protocollo sarà simile a:

Una chiave simmetrica a 128 bit è memorizzata in un file sul server.
Il client si connette all'indirizzo IP del server utilizzando https: // e ottiene l'accesso tramite il suo certificato client che è considerato affidabile dal server.
Il client mostra una pagina html vuota con una casella di input in cui deve digitare la chiave simmetrica, che viene quindi memorizzata localmente come variabile js nel browser.
Una fase di verifica viene eseguita inviando al server un messaggio crittografato con AES utilizzando la chiave simmetrica del client, che viene quindi decrittografata con la sua versione della chiave simmetrica. Se questo ha successo, al client viene dato l'accesso al resto dell'html.
Tutti i dati successivi scambiati dal client e dal server vengono crittografati / decodificati utilizzando la chiave simmetrica per AES-CBC.

Due esempi dei motivi per cui questo livello aggiuntivo può fornire ulteriore sicurezza:

Se l'utente malintenzionato riceve un certificato che è considerato affidabile dal client e funge da server. Non sarebbe in grado di leggere i messaggi inviati da un cliente.
Se l'utente malintenzionato si impadronisce di un certificato ritenuto attendibile dal server, dovrà comunque digitare la chiave simmetrica.

Ho ragione riguardo ai due esempi, e in secondo luogo, vedi qualche difetto / attacco di cui non sono a conoscenza?

P.S. Per chiarire: la stessa chiave simmetrica verrebbe utilizzata per ogni sessione, poiché è quella che viene riparata e archiviata sul server. Un IV casuale viene utilizzato per ciascuna crittografia AES-CBC e viene inviato insieme al messaggio crittografato.

tls aes

posta peter 02.05.2017 - 17:29

fonte

3 risposte

2

Dov'è la sicurezza aggiuntiva nel tuo schema? Il Cliente fornisce la chiave al server (o all'attentatore) in modo che possa essere recuperata da un utente malintenzionato.

Fai un passo indietro e spiega quale attacco stai cercando di difendere. E puoi spiegare come la tua attuale configurazione per TLS non ti protegge già per questo?

Se (e sto indovinando il tuo scopo qui) ho ragione nel presumere che tu voglia aggiungere la validazione tra client e server. Questo risultato è ottenuto tramite qualcosa chiamato certificati lato client.

risposta data 02.05.2017 - 17:55

fonte

0

Sembra che il client non si fidi della comunicazione crittografata. Dato il corpus di conoscenze intorno a SSL / TLS è completo forse il modo in cui il client sta tentando potrebbe essere gestito meglio usando FIDO U2F.

Detto questo, un'istanza in cui la crittografia aggiuntiva ha senso è per il contenuto come ProtonMail che fornisce cassette postali o Mega proposizione da offrire sui file caricati.

risposta data 04.05.2017 - 00:58

fonte

Leggi altre domande sui tag tls aes

utente sconosciuto sul mio router Mantiene l'identità del messaggio originale quando si inviano più messaggi e-mail

score 2 · Accepted Answer

1) se qualcuno può rubare la chiave privata TLS, non può rubare la chiave simmetrica?

2) se qualcuno può MitM la tua connessione TLS può cambiare il javascript che il server invia al client, in modo che lo script invierà la chiave inserita dal client per l'hacker.

3) Se l'hacker può decodificare la connessione TLS e bypassare l'autenticazione del client TLS, memorizzerà il messaggio inviato dal client al punto 4, quindi si riconnetterà al server e invierà nuovamente lo stesso messaggio. Il server lo decrittografa correttamente e garantisce l'accesso. Per evitare che ciò accada, il server può inviare una stringa casuale (challenge) e il client deve inviare la richiesta di conferma crittografata e MACed (con HMAC). Se il messaggio non è MAC, l'hacker può modificare il primo blocco del messaggio crittografato in modalità CBC modificando IV e potrebbe essere di nuovo l'autenticazione di bypass.

Sembra che la tua soluzione possa rendere un po 'più difficile l'hacker a ottenere le tue informazioni, ma sicuramente renderà più difficile legittimare l'utente a lavorare con il server. IMHO non migliora le cose.

In generale, la creazione di un robusto protocollo crittografico è un'attività molto difficile e non è consigliabile crearla finché non si è veramente a conoscenza di ciò che si sta facendo. Anche i protocolli creati da gruppi di professionisti in un primo momento presentano una vulnerabilità negativa.