In realtà ho ricevuto alcuni progetti dai miei ex colleghi. Si tratta di applicazioni basate su socket TCP App-Server. Ho notato che alcune delle interazioni auth / login utilizzano RSA / AES codificare / decodificare
come so, se abbiamo adottato il socket TLS nel livello di trasporto, i dati tra di noi sono crittografati.
quindi ... se usiamo TLS, abbiamo ancora bisogno di crittografare / decodificare i dati nel codice del livello di applicazione? o è solo uno sforzo ridondante.
Sì e No.
La crittografia non è una sorta di proposizione "have it" o "do not have it". Il concetto di crittografia ha senso solo nel contesto.
Un esempio che dovrebbe dimostrare più chiaramente il fallimento: immagina di avere un documento che deve essere tenuto al sicuro. Lo carichi sul tuo account Dropbox. Ora è crittografato?
Sì , è stato crittografato durante il transito. Dropbox utilizza HTTPS, quindi è stato crittografato tramite TLS durante il caricamento (e qualsiasi download). Viene quindi decifrato dall'altra parte dopo che è stato trasferito.
Sì , è crittografato nella memoria (per quanto ne sappiamo). Dropbox dice che crittografa tutti i dati sui loro server usando le chiavi specifiche per il tuo account. È poi decifrato in modo trasparente per te su richiesta.
Ma No , il documento non è crittografato in un modo che conta per tu . Dropbox sincronizza i file su tutti i tuoi computer e salva una copia di testo normale sul tuo computer. Quindi se qualcuno guarda il tuo computer, può leggere il documento senza dover eludere alcuna crittografia.
Durante la crittografia dei dati, devi capire cosa stai cercando di proteggere e chi stai cercando di proteggerlo da . Devi capire cosa stai cercando di prevenire con la tua crittografia. Una volta compreso ciò che stai cercando di realizzare, dovrebbe essere immediatamente evidente se la crittografia che hai ti sta facendo bene o meno.
Da una prospettiva di difesa in profondità potrebbe essere utile implementare la crittografia a livello di applicazione, in base alla classificazione dei dati.
Immagina il seguente esempio: sei una banca e utilizzi un'API REST per recuperare le informazioni sul saldo per un conto bancario specifico. L'URL dell'API è:
Il numero di conto bancario in questo esempio è 12345678. Sebbene il tuo canale di comunicazione sia crittografato, il numero di conto bancario può ancora essere memorizzato nella cache localmente e verrà visualizzato nei file di registro del server web.
Questa potrebbe essere una buona ragione per avere la crittografia del livello dell'applicazione per evitare la registrazione di informazioni sensibili.
Prima di tutto, SSL non è né un protocollo di livello di rete né un protocollo a livello di applicazione. È uno che "si siede" tra entrambi gli strati.
In secondo luogo, a causa della sua posizione, SSL offre alle macchine client la possibilità di applicare selettivamente la protezione di sicurezza su singole applicazioni piuttosto che impostare la crittografia su un intero gruppo di applicazioni.
La procedura può essere eseguita senza riguardo al livello di rete. Per questi motivi, quando SSL viene utilizzato per crittografare il traffico di rete, solo i dati del livello dell'applicazione sono effettivamente crittografati.
Quindi, tutto ciò che serve è HTTPS / SSL con autenticazione client. L'aggiunta di un secondo livello di crittografia non aggiunge alcuna sicurezza.
Leggi altre domande sui tag authentication cryptography tls