Se ho un sito Web o un'app mobile, questo parla al server tramite una connessione SSL / TLS protetta (ad es. HTTPS) e crittografa anche i messaggi inviati e ricevuti tra l'utente e il server in cima alla connessione già sicura , farò delle mosse non necessarie? O la doppia crittografia è un metodo comune? Se sì, perché?
Non è raro, ma potrebbe non essere richiesto. Molti sviluppatori sembrano dimenticare che il traffico HTTPS è già crittografato - basta guardare il numero di domande sull'implementazione della crittografia lato client su questo sito Web - o ritenere che non ci si possa fidare a causa di problemi ben pubblicizzati come pasticcio MitM SSL Lenovo .
Tuttavia, la maggior parte delle persone non ne è stata influenzata, e al momento non ci sono attacchi particolarmente validi contro TLSv1.2, quindi non aggiunge molto.
D'altra parte, ci sono motivi legittimi per crittografare i dati prima della trasmissione in alcuni casi. Ad esempio, se stai sviluppando un'applicazione di archiviazione, potresti voler crittografare utilizzando un'app sul lato client con una chiave nota solo all'utente: ciò significherebbe che il server non sarebbe in grado di decodificare i dati affatto, ma potrebbe ancora memorizzarlo. L'invio tramite HTTPS significherebbe che anche un utente malintenzionato non dovrebbe essere in grado di acquisire i dati crittografati dal client, ma anche se lo facessero, non avrebbe importanza. Questo pattern è spesso utilizzato dai gestori di password basati su cloud.
In sostanza, dipende da cosa ti stai difendendo - se non ti fidi di SSL / TLS, però, probabilmente non puoi fidarti del codice di crittografia che stai inviando (nel caso dell'applicazione web)!
HTTPS fornisce solo la crittografia mentre il messaggio è in transito sulla rete / Internet.
Se il messaggio viene memorizzato o elaborato da un intermediario (ad esempio una coda di messaggi) a un certo punto tra il client e il server che infine lo elabora, non rimarrà crittografato mentre è nell'intermediario.
Inoltre, se TLS / SSL viene terminato nei perimetri del servizio (ad esempio su un servizio di bilanciamento del carico), potrebbe non essere crittografato sulla rete interna. Questo può essere un problema in cui è richiesta un'elevata sicurezza, ad esempio in alcuni ambienti regolamentati.
In entrambi i casi, la crittografia a livello di messaggio garantisce che i dati vengano crittografati in tutti i punti tra il client e il destinatario finale.
Come ha detto @honze, questo è chiamato difesa in profondità ed è inteso a garantire che anche se un sistema è parzialmente compromesso (ad esempio, riescono a fare un attacco man-in-the-middle per compromettere SSL / TLS, oppure sfruttare una vulnerabilità nella coda dei messaggi per ottenere i dati a riposo) l'autore dell'attacco non può accedere ai dati protetti.
Mi piacerebbe condividere la mia esperienza sulla domanda del titolo. Non è realmente correlato alla domanda completa in sé, ma questo risponde alla domanda "perché qualcuno dovrebbe duplicare la doppia?"
In passato ho lavorato per un'organizzazione che gestisce la comunicazione tra i fornitori di assistenza (medici, ospedali, ecc.) e le organizzazioni assicurative (mutualità). Abbiamo agito come un router.
Lo schema era approssimativamente il seguente:
care provider 1 \ / insuring organization 1
care provider 2 ---- router (us) ---- insuring organization 2
care provider 3 / \ insuring organization 3
Abbiamo avuto la seguente protezione:
Spero che questo chiarisca perché è possibile richiedere diversi livelli di crittografia.
Hai ragione. Questo è un concetto di sicurezza multistrato noto come difesa in profondità.
È probabile che i messaggi crittografati indirizzino la crittografia end-to-end e SSL / TLS indirizzi la crittografia dei metadati. Questo è uno schema utile.
HTTPS è crittografato in transito e decrittografato alle estremità. Quindi la situazione ovvia in cui potresti voler duplicare la doppia è dove non vuoi uno (o forse entrambi!) Delle estremità per vedere il testo in chiaro.
Alcune situazioni che posso pensare in cima alla mia testa:
email crittografata tramite provider di posta web. Se invio un messaggio crittografato GPG tramite Gmail che accedo tramite una connessione HTTPS, viene crittografato due volte. Perché non voglio che gmail legga il contenuto.
servizi di backup crittografati. Voglio utilizzare HTTPS per impedire il furto delle credenziali di accesso, ma non voglio che il servizio di backup visualizzi "dentro" i backup.
gateway di pagamento. Potresti immaginarne uno in cui viene inviato un messaggio crittografato tra un token hardware di pagamento sicuro e una banca, tramite un dispositivo non sicuro di un utente e il sito di un commerciante. Il collegamento nel mezzo dovrebbe essere HTTPS, ma ciò non è sufficiente: deve essere crittografato sul PC insicuro e sul sito Web del venditore meno sicuro.
Si noti che S / MIME prevede "triple wrap" (sign / encrypt / sign): link , quindi se consideri la firma e la crittografia anche più possibilità potrebbero avere senso.
Volevo dare un motivo in più: la standardizzazione.
Ho un'applicazione che per ragioni di sicurezza, tutti i dati che entrano e escono da esso devono essere crittografati. Poiché è già crittografato una volta, i dati sono autorizzati a scorrere su entrambe le connessioni http (legacy) e https (corrente). Ha molto più senso crittografare due volte rispetto a creare una versione dell'applicazione che viene eseguita non crittografata su https e crittografata su http.
Sono le migliori pratiche quando si tratta di informazioni altamente sensibili come dati finanziari, medici, militari o psicologici. L'idea di base delle crittografie multiple è impedire a qualsiasi utente non autorizzato di recuperare i dati. Supponiamo che le iniziali combinazioni possibili per il metodo di crittografia siano 1 miliardo. Applicando un altro metodo di crittografia su di esso, potremmo moltiplicare le possibilità per 1b ^ 3. Richiederebbe a un utente non autorizzato di impiegare più tempo per decrittografare i dati. Mentre la crittografia non è ancora perfetta, è meglio.
In una delle organizzazioni in cui ho lavorato, abbiamo utilizzato più crittografie. Questa è una semplificazione del flusso precedente:
Se non si ha a che fare con un ambiente con una rete pesante con dati sensibili, questo è eccessivo.
La strategia alla base di questo metodo garantisce che i dispositivi, i componenti (MAC) e l'IP siano stati autenticati. La crittografia dei dati è una procedura standard e pertanto invia l'HTTPS. Alcune organizzazioni vanno oltre la sicurezza di base e richiedono anche reti di tipo darknet che utilizzano Freenet, I2P, IPsec / VPN o Tor per connettersi. Indipendentemente dalla crittografia, la compressione dei dati ridurrà le risorse di storage e di rete richieste; tuttavia, compenserà le tue prestazioni con la RAM o l'elaborazione. Infine, il motivo per cui abbiamo riavviato la connessione dopo una disconnessione è che abbiamo scoperto un modo per dirottare il flusso di dati tramite man-in-the-middle.
In definitiva, non esiste un modo perfetto per crittografare i dati per sempre, ma concentrare i tuoi sforzi sulla crittografia fino a quando i dati o le informazioni diventano irrilevanti o produci un modo superiore per crittografare i dati.
Esistono diversi motivi per l'invio di dati crittografati tramite una connessione crittografata:
Anche se tutte le comunicazioni sono crittografate tramite HTTPS, il client può ancora avere la possibilità di vedere il proprio traffico prima della crittografia con vari strumenti di debug. Soprattutto se utilizzi un ambiente browser o un'app con https fornito da un sistema sottostante.
In questo caso è possibile crittografare i dati con una chiave statica, in modo che il client non possa leggere e manipolare facilmente il traffico. Ovviamente questa è solo offuscamento, dal momento che la chiave deve essere memorizzata da qualche parte sulla macchina client (almeno nella RAM), ma con il codice sorgente del software è sempre solo un'offuscamento. L'utente dovrebbe spendere un notevole sforzo per recuperare la chiave e decrittografare il traffico per leggere e manipolare le sue richieste.
Gli esempi potrebbero essere un gioco basato sul Web che sottomette i punteggi più alti dei giocatori.
Il motivo principale della crittografia a più livelli è la separazione delle preoccupazioni.
Spesso un insieme di dati può essere elaborato da più server, eventualmente controllati da più organizzazioni, non tutti i quali sono completamente fidati di tutti i dati. Nella maggior parte dei casi, la maggior parte di questi server intermedi ha solo bisogno di agire su parti dei dati, e quindi se non hanno bisogno di vedere alcune parti di dati, quella parte può essere crittografata. Fornirai l'accesso intermedio ai dati di cui hanno bisogno per vedere crittografati in una chiave che hanno e blob crittografati che possono trasmettere ad altri server per un'ulteriore elaborazione.
L'esempio più semplice è l'e-mail con crittografia GPG e TLS. Il compito principale di un agente di trasferimento della posta (relay di posta elettronica) è trasferire la posta da un hop a quello successivo. Devono vedere le informazioni di routing della posta per fare il loro lavoro, ma non dovrebbero aver bisogno di vedere i messaggi stessi. Così raddoppierete la crittografia della connessione e-mail con una chiave che l'agente di trasferimento della posta può comprendere e il messaggio con un'altra chiave che solo il destinatario comprende.
Un altro esempio è il servizio di pianificazione di calendario / notifica. Inserisci eventi nel tuo calendario, per essere avvisati dall'applicazione di calendario che qualcosa sta accadendo in un determinato momento. Il calendario non ha avuto bisogno di sapere che cos'è l'evento, chi è coinvolto negli eventi, né dove si trova l'evento.
Un motivo secondario per la crittografia multipla è come un'assicurazione nel caso in cui uno dei livelli di crittografia venga interrotto. IMO, questo è un motivo molto più debole perché è necessario considerare che ogni livello aggiuntivo non necessario aumenta la complessità dell'implementazione e la complessità è il nemico della sicurezza.
Non vedo questo menzionato qui, ma penso che sia leggermente più importante di un commento. Potrebbero farlo per perfetta segretezza in avanti . Un utente malintenzionato potrebbe non conoscere la chiave della connessione HTTPS, ma potrebbe registrare ogni singolo byte e memorizzarlo per anni. In questo modo possono comprometterti, scoprire una vulnerabilità o costringerti a rivelare la chiave privata del tuo server in un secondo momento, quindi tornare indietro nella cronologia e decifrare i tuoi messaggi. Avendo una chiave temporanea temporanea che crittografa i messaggi sotto la connessione HTTPS, l'utente malintenzionato sarebbe comunque in grado di leggere i messaggi, o almeno in ritardo significativo.
Se ho capito bene, la rete Tor funziona in questo modo:
Alice scrive una lettera a Dave e la crittografa tre volte: prima con la chiave di Dave, poi aggiunge l'indirizzo di Dave, crittografa il pacchetto con la chiave di Craig, aggiunge l'indirizzo di Craig e crittografa il pacchetto con la chiave di Bob.
Invia quindi la lettera a Bob, che la decifra, e trova l'indirizzo di Craig e lo inoltra a lui.
Craig lo decifra, trova l'indirizzo di Dave e lo inoltra a lui. Dave lo decifra e trova che la lettera è per lui
In un mondo perfetto, nessuno, ad eccezione di Alice e Dave, ora può dire che Dave è effettivamente il destinatario di quella lettera, perché potrebbe essere che abbia trovato l'indirizzo di Emily nella busta e lo abbia inoltrato.
Una seconda applicazione sarebbe quella di criptare un messaggio sia con la propria chiave privata che con la chiave pubblica del destinatario. Il destinatario decrittografa il messaggio con la tua chiave pubblica e la sua chiave privata, e può così ottenere l'informazione che il messaggio proviene da te e per lui. Di solito, un HMAC viene utilizzato per assicurarsi che il messaggio provenga effettivamente da un certo mittente e non sia stato manomesso.
Probabilmente esistono difetti in entrambi gli algoritmi e implementazioni, che devono ancora essere scoperti. Idealmente questi difetti non esisterebbero ma lo fanno.
Se decidi di crittografare con due algoritmi diversi e solo uno di essi è difettoso, sei ancora a posto e i tuoi dati sono al sicuro. Se il primo livello è rotto, un utente malintenzionato può ottenere solo testo cifrato. Se il secondo livello è rotto, un utente malintenzionato non è in grado di superare il primo livello.
La doppia crittografia (o tripla o quadrupla o ...) può essere un buon modo per evitare di mettere tutte le uova nello stesso paniere.
Per evitare problemi con la conformità PCI, in cui lo sviluppatore desidera utilizzare il gateway di pagamento e imposta la conformità a terze parti.
I campi nel post del modulo possono essere crittografati dal lato client, quindi lo sviluppatore non ha alcun dettaglio della carta non criptata che passi attraverso i loro sistemi (quindi un passo in più rispetto al non memorizzarli).
In particolare, questo è in cima a HTTPS . Pertanto, il sito Web non vede nemmeno i dati non crittografati, solo l'utente e il gateway di pagamento.
Esempio con il gateway di pagamento Brain Tree: link
Non esattamente un problema HTTPS, ma un altro caso valido di doppia crittografia è comunemente usato in Tor nel caso in cui "non credo che il fattorino e voglia rimanere anonimo usando più passaggi".
Ogni "ragazzo delle consegne" decifra solo la busta per scoprire l'altro ragazzo delle consegne. La comunicazione in questo caso è incapsulata e crittografata nel proxy SOCKS.
Leggi altre domande sui tag encryption tls