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 ritengono che non ci si possa fidare a causa di problemi ben pubblicizzati come Lenovo SSL MitM pasticcio.

Tuttavia, la maggior parte delle persone non ne è stata colpita e al momento non ci sono attacchi particolarmente praticabili contro TLSv1.2, quindi non lo fa " t davvero aggiungere 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 decrittografare i dati, 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 modello viene 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 della crittografia il codice che stai inviando (nel caso dell'applicazione web) neanche!

HTTPS fornisce la crittografia solo 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 alla fine lo elabora, quindi non rimarrà crittografato mentre si trova nell'intermediario.

Inoltre, se TLS / SSL viene terminato nei perimetri del servizio (ad esempio su un bilanciamento del carico), potrebbe non 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 garantirà che i dati siano crittografati in tutti i punti tra il client e il ricevitore finale.

Come ha detto @honze, questa si chiama difesa in profondità ed ha lo scopo di garantire che anche se un sistema è parzialmente compromesso (ad esempio riescono a fare un attacco man-in-the-middle per compromettere SSL / TLS o sfruttare una vulnerabilità nella coda dei messaggi per ottenere i dati inattivi) l'aggressore non può accedere ai dati protetti.

Vorrei condividere la mia esperienza sulla domanda del titolo. Non è realmente correlato alla domanda completa in sé, ma risponde alla domanda "perché qualcuno dovrebbe crittografare due volte?"

In passato ho lavorato per un'organizzazione che gestisce la comunicazione tra operatori sanitari (medici, ospedali , ecc.) e le organizzazioni assicurative (mutue). Ci siamo comportati come un router.

Lo schema era più o meno il seguente:

  fornitore di assistenza 1 \ / organizzazione assicurativa 1 fornitore di assistenza 2 ---- router (noi) ---- organizzazione assicurativa 2 fornitore di assistenza 3 / \ organizzazione assicurativa 3  

Avevamo la seguente protezione:

1. Crittografia end-to-end : Il fornitore di cure 1 deve inviare le informazioni del paziente all'organizzazione assicurativa 1. Queste informazioni sono sensibili alla privacy e pertanto devono essere crittografate. Al nostro livello non abbiamo il diritto di sapere quali dati vengono inviati all'organizzazione assicurativa.
2. Fornitore di assistenza - crittografia del router: il fornitore di assistenza invia le informazioni come metadati per noi a essere in grado di gestirlo. Queste informazioni devono essere crittografate. Il contratto stabiliva che i messaggi dovevano ancora essere crittografati anche all'interno della nostra rete in modo che solo uno dei nostri server conoscesse i metadati delle informazioni inviate. Poiché disponiamo di diverse pipe (bilanciatori del carico, firewall, ecc.), Anche la crittografia è richiesta a questo livello.
3. HTTPS per evitare attacchi MITM: non solo i nostri dati avevano bisogno essere protetti, ma anche i metadati HTTP dovevano essere protetti, quindi HTTPS.

Spero che questo faccia luce sul motivo per cui possono essere richiesti diversi livelli di crittografia.

Hai ragione. Questo è un concetto di sicurezza multilivello noto come difesa in profondità.

È probabile che i messaggi crittografati indirizzino la crittografia end-to-end e SSL / TLS si rivolga alla crittografia dei metadati. Questo è un modello utile.

HTTPS è crittografato in transito e decrittografato alle estremità. Quindi la situazione ovvia in cui potresti voler eseguire la doppia crittografia è dove non vuoi che una (o forse entrambe!) Delle estremità veda il testo in chiaro.

Alcune situazioni Riesco a pensare fuori dalla mia testa:

• e-mail crittografata tramite provider di webmail. Se invio un messaggio crittografato GPG tramite Gmail a cui accedo tramite una connessione HTTPS, viene crittografato due volte. Perché non voglio che Gmail legga i contenuti.

• servizi di backup crittografati. Desidero utilizzare HTTPS per impedire il furto delle mie credenziali di accesso, ma non voglio che il servizio di backup veda "all'interno" dei backup.

• gateway di pagamento. Potresti immaginarne uno in cui un messaggio crittografato viene inviato tra un token hardware di pagamento sicuro e una banca, tramite il dispositivo non sicuro di un utente e il sito di un commerciante. Il collegamento al centro dovrebbe essere HTTPS, ma non è sufficiente: deve essere crittografato sul PC non sicuro e sul sito web del commerciante meno sicuro.

Tieni presente che S / MIME prevede il "triplo avvolgimento" (firma / crittografia / firma): https://tools.ietf.org/html/rfc2634, quindi se consideri la firma e la crittografia anche più possibilità potrebbero avere senso .

Volevo fornire un motivo in più: la standardizzazione.

Ho un'applicazione che per motivi di sicurezza, tutti i dati che entrano ed escono da essa devono essere crittografati. Poiché è già crittografato una volta, i dati possono fluire su entrambe le connessioni http (legacy) e https (corrente). Ha molto più senso crittografare due volte piuttosto che creare una versione dell'applicazione che viene eseguita non crittografata su https e crittografata su http.

Si tratta di best practice quando si tratta di informazioni altamente sensibili come dati finanziari, medici, militari o psicologici. L'idea di base di più crittografie è impedire a qualsiasi utente non autorizzato di recuperare i dati. Supponiamo che le possibili combinazioni iniziali per il metodo di crittografia fossero 1 miliardo. Applicando un altro metodo di crittografia su di esso, potremmo moltiplicare le possibilità a 1b ^ 3. Richiederebbe a un utente non autorizzato di impiegare più tempo per decrittare i dati. Anche se la crittografia non è ancora perfetta, è meglio.

In una delle organizzazioni in cui ho lavorato abbiamo utilizzato più crittografie. Questa è una semplificazione del flusso precedente:

• Controlla i dispositivi e i componenti client e server per l'autorizzazione sul software
• Crittografa i dati sulla memoria
• Comprimi i dati
• Crittografa i dati con software proprietario
• Inizia la connessione con il server
• Controlla i dispositivi e i componenti client e server per l'autorizzazione alla connessione
• Comprimi trasmissione
• Invia dati tramite connessione crittografata; Se la connessione viene interrotta, riavvia l'intero processo.
• Dopo aver completato con successo il file, controlla la coerenza dei dati

Se non hai a che fare con un ambiente che è pesante in rete 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, così come l'invio tramite HTTPS. Alcune organizzazioni vanno oltre la sicurezza di base e richiedono anche reti tipo darknet che utilizzano Freenet, I2P, IPsec / VPN o Tor per connettersi. Indipendentemente dalla crittografia, la compressione dei dati ridurrà l'archiviazione richiesta e le risorse di rete; tuttavia, compenserà le prestazioni in RAM o 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 concentra i tuoi sforzi sulla crittografia fino a quando i dati o le informazioni non diventano irrilevanti o non produci un modo migliore per crittografare i dati.

Esistono diversi motivi per inviare dati crittografati su una connessione crittografata:

• anche se la crittografia della connessione è interrotta (ad es. MitM, possibile ma difficile con HTTPS e che porta a intercettazione di tutti i dati trasmessi), i dati sono ancora crittografati
• il server HTTPS potrebbe non essere considerato attendibile ed è responsabile della trasmissione dei dati a un altro server
• allo stesso modo, il server HTTPS potrebbe inoltrare i dati a un altro server tramite una connessione non crittografata e fare in modo che il client crittografi i dati prima della trasmissione riduce il carico sul server HTTPS che altrimenti dovrebbe crittografare i dati da tutti i client invece di essere in grado di passarli direttamente

Offuscamento API

Anche se tutte le comunicazioni sono crittografate tramite HTTPS, il client può comunque avere la possibilità di vedere il suo 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 potresti crittografare i tuoi dati con una chiave statica, in modo che il client non possa leggere e manipolare facilmente il traffico. Ovviamente questo è solo un offuscamento, poiché la chiave deve essere memorizzata da qualche parte sulla macchina client (almeno nella RAM), ma con il codice sorgente del software è sempre solo offuscamento. L'utente dovrebbe dedicare uno sforzo considerevole per recuperare la tua chiave e decrittografare il tuo traffico per leggere e manipolare le sue richieste.

Un esempio potrebbe essere un gioco basato sul web, che invia ai giocatori il punteggio più alto.

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.

Quindi invia la lettera a Bob, che la decrittografa, trova l'indirizzo di Craig e glielo inoltra.

Craig lo decrittografa, trova l'indirizzo di Dave e glielo inoltra. Dave lo decifra e scopre che la lettera è per lui

In un mondo perfetto, nessuno tranne Alice e Dave potrebbe ora dire che Dave è davvero il destinatario di quella lettera, perché POTREBBE ESSERE che aveva trovato L'indirizzo di Emily all'interno della busta e inoltrato.

Una seconda applicazione potrebbe essere quella di crittografare un messaggio sia con la tua 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 le informazioni che il messaggio è da te e per lui. Ma di solito, un HMAC viene utilizzato per assicurarsi che il messaggio provenga effettivamente da un certo mittente e non sia stato manomesso.

Il motivo principale per la crittografia a più livelli è la separazione delle preoccupazioni.

Spesso un insieme di dati può essere elaborato da più server, possibilmente controllati da più organizzazioni, non tutte sono completamente attendibili dall'intero dati. Nella maggior parte dei casi, la maggior parte di questi server intermedi deve agire solo su parti dei dati, quindi se non hanno bisogno di vedere alcune parti di dati, quella parte può essere crittografata. Daresti l'accesso intermedio ai dati di cui hanno bisogno per vedere crittografati in una chiave che hanno e i blob crittografati che possono trasmettere ad altri server per un'ulteriore elaborazione.

L'esempio più semplice è l'email con crittografia GPG e TLS. Il compito principale di un agente di trasferimento della posta (relè di posta) è trasferire la posta elettronica da un hop all'altro. Hanno bisogno di vedere le informazioni di instradamento della posta per svolgere il loro lavoro, ma non dovrebbero aver bisogno di vedere i messaggi stessi. Pertanto, crittograferai due volte la 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 del calendario / notifica. Inserisci eventi nel tuo calendario, per essere avvisato dall'applicazione di calendario che qualcosa sta accadendo in un determinato momento. Il calendario non aveva bisogno di sapere qual è l'evento, chi è coinvolto negli eventi, né dove si trova.

Un motivo secondario per la crittografia multipla è come un'assicurazione nel caso in cui uno dei livelli di crittografia sia rotto. 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 lo vedo 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 tua connessione HTTPS, ma potrebbe registrare ogni singolo byte e conservarlo per anni. Quindi potrebbero hackerarti lungo la linea, scoprire una vulnerabilità o costringerti a rivelare la chiave privata del tuo server in un secondo momento, quindi tornare indietro nella cronologia e decrittografare i tuoi messaggi. Avendo una chiave temporanea temporanea che crittografa i messaggi sotto la connessione HTTPS, l'aggressore non sarebbe comunque in grado di leggere i messaggi o, per lo meno, ritarderebbe notevolmente.

Per evitare problemi con la conformità PCI, in cui lo sviluppatore desidera utilizzare il gateway di pagamento e impone la conformità alla terza parte.

I campi nel modulo post possono essere crittografati lato client, quindi lo sviluppatore non ha i dettagli della carta non crittografati che passano attraverso i loro sistemi (quindi un passo avanti 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: https://www.braintreepayments.com/blog/ crittografia lato client /

È probabile che al momento esistano difetti sia negli algoritmi che nelle implementazioni, che devono ancora essere scoperti. Idealmente questi difetti non esisterebbero ma lo sono.

Se crittografi con due algoritmi diversi e solo uno di essi è difettoso, stai comunque bene ei tuoi dati sono al sicuro. Se il primo livello è rotto, un utente malintenzionato può solo ottenere testo cifrato. Se il secondo livello è rotto, un utente malintenzionato non è in grado di attraversare il primo livello.

La doppia crittografia (o tripla o quadrupla o ..) può essere un buon modo per evitare di mettere tutte le tue uova in un paniere.

Non esattamente il problema HTTPS, ma un altro caso d'uso valido della doppia crittografia è comunemente usato in Tor nel caso in cui "non credo al ragazzo delle consegne e voglio rimanere anonimo utilizzando più passaggi".

Ogni "fattorino" decrittografa solo la busta per scoprire l'altro fattorino. La comunicazione in questo caso è incapsulata e crittografata nel proxy SOCKS.