Questa domanda può essere riformulata come segue: C'è una situazione in cui l'attaccante può compromettere TLS, ma non una crittografia aggiuntiva? La risposta sta nell'implementazione di entrambi i sistemi.
The API will be using the HTTPS protocol, but management thinks that is not sufficient and that we need to encrypt the data itself before it is sent.
La direzione sembra sempre pensare che più è meglio, ma devi pensare a dove sono le chiavi per sviluppare un modello di minaccia. I server che hanno i dati sono gli stessi server che stanno stabilendo la connessione TLS? In tal caso, quindi crittografarlo prima di essere inviato non fornirebbe alcun vantaggio, dal momento che un compromesso di tali server fornirebbe contemporaneamente entrambe le chiavi di crittografia.
Is SSL/TLS sufficient for safe transit of the file?
Supponendo che sia configurato correttamente, è sicuro e sufficiente. Si desidera selezionare una suite di crittografia protetta. Sono disponibili guide online per la selezione di una buona suite TLS. Per un'API interna, non è necessario tutto ciò, poiché puoi agire come la tua CA in modo sicuro.
Does HTTPS/SSL protect binary data or just plain text?
Nel protocollo HTTP, l'unica cosa che suggerisce il tipo di dati è l'intestazione Content-Type . Questa intestazione indica all'applicazione finale come interpretare ciò che riceve. TLS opera su un livello superiore a quello, e come tale la codifica è irrilevante. Codifica ciecamente tutti i dati, comprese le intestazioni.
Does the length of time that it will take to transfer a file of that size pose additional security risks over plain text?
La quantità di tempo necessaria per trasferire i dati su TLS non influisce sulla sua sicurezza. Nessun codice moderno si indebolirà solo perché stai crittografando una grande quantità di dati. TLS è abbastanza veloce che, su tutto tranne l'hardware più vecchio, funzionerà altrettanto bene come una semplice connessione.
Is the concern with the additional layer of encryption justified?
Supponendo che la topografia della rete sia tale che TLS fornirà la crittografia end-to-end, allora no, non vi è alcuna giustificazione per la crittografia aggiuntiva. La complessità aggiunta potrebbe introdurre bug. Se controlli entrambi i server, puoi utilizzare un certificato autofirmato e verificare l'impronta digitale, quindi non devi fare affidamento su un'autorità di certificazione per l'autenticazione.
In altre parole, l'unica volta che non sarebbe sufficiente è se una delle seguenti condizioni è vera:
- C'è un punto debole nella progettazione o implementazione di TLS.
- Una funzione richiesta non è presente in TLS.
- C'è una situazione in cui un utente malintenzionato può ottenere la chiave TLS senza ottenere l'altra chiave.
Se nessuno di questi è vero, TLS fornirà tre garanzie principali:
-
Autenticazione : puoi essere sicuro che la connessione dall'altra parte è chi dicono di essere.
-
Integrità : i dati in transito non possono essere modificati senza che l'altro utente ne sia a conoscenza.
-
Riservatezza : tutto il traffico sarà leggibile solo per le parti interessate.
Ad esempio, la crittografia aggiuntiva con GnuPG non fornirà ulteriori garanzie.