SSL è abbastanza sicuro per un'API REST: qualcuno ha utilizzato PGP o AES per crittografare i dati effettivi all'interno di SSL?

Question

SSL è abbastanza sicuro per un'API REST: qualcuno ha utilizzato PGP o AES per crittografare i dati effettivi all'interno di SSL?

#1 da (16 voti)
#2 da (7 voti)
#3 da (4 voti)

16

Forse sono troppo paranoico, ma dopo aver letto le ultime notizie sulla sicurezza della rete, sto iniziando a credere che SSL non è più abbastanza per le trasmissioni di dati sensibili.

Rif:

link
link

Sono uno sviluppatore web che sta studiando la costruzione di alcune nuove API, principalmente per uso privato (le macchine aziendali parlano tra loro). Alcuni sistemi potrebbero essere al di fuori della rete aziendale. La mia domanda riguarda la sicurezza aggiuntiva relativa alle API stesse.

Qualcuno ha mai pensato o ha implementato qualcosa come PGP o AES per crittografare tutti i dati effettivamente andando avanti e indietro all'interno delle comunicazioni API?

Sto parlando di che ancora usa SSL come wrapper per la coperta all'esterno, ma poi fa un passo avanti crittografando l'intero payload. Ovviamente questo crea un po 'di overhead in crittografia / decrittografia su entrambe le estremità. Il fatto è che sto bene concettualmente. L'hardware è economico.

Ciò a cui non sono particolarmente affezionato è semplicemente l'invio dei miei dati in testo chiaro e l'inserimento di tutte le mie uova nel cestino SSL.

Pensieri?

rest tls appsec

posta Steve 05.12.2013 - 18:39

fonte

3 risposte

Leggi altre domande sui tag rest tls appsec

La protezione da USB errato non funziona per me Utilizzo di TPM con DMcrypt?

score 16 · Answer 1

Sì, ci sono situazioni in cui i livelli di crittografia hanno senso. Ecco un esempio specifico:

SSL può essere decifrato legittimamente in punti intermedi; non è sempre end-to-end:

Akamai potrebbe decodificare e crittografare nuovamente il traffico per il quale fornisce la consegna dei contenuti.
Prolexic desidera le chiavi SSL dei propri client in modo che, quando sono chiamati a proteggersi da un DDoS, possano aprire pacchetti e prendere decisioni intelligenti su cosa consentire e cosa lasciare.
Un IDS / IPS può essere configurato con chiavi private al fine di decrittografare il traffico per l'analisi e si desidera proteggere i dati riservati dal loro accesso.
Anche interno a un'azienda, SSL può essere decifrato su un gateway edge SSL per motivi di prestazioni e passato non criptato su reti interne.

Qualcuno salterà qui e dirà "Non dovresti usare SSL in questo modo!" Concordato. Capita solo che accada nel mondo reale una quantità non trascurabile del tempo per ragioni ragionevoli.

La mia azienda ha un'API che fa ciò che descrivi. Le transazioni XML-over-HTTPS hanno campi sensibili specifici crittografati con la crittografia a chiave pubblica. L'SSL può essere decifrato dagli host interinali per ragioni come quelle che ho elencato sopra senza esporre le informazioni sensibili. È una soluzione intelligente per un vero problema.

score 7 · Answer 2

Un collega e io abbiamo fatto una presentazione all'AppSec USA alcuni anni fa proprio su questo argomento. (Ammetto che all'inizio è un po 'asciutto, ma diventa più interessante a metà):

link

La risposta dipende da cosa è il tuo modello di minaccia.

Se il tuo modello di minaccia include un utente malintenzionato, allora no, SSL non è sufficiente. Un utente finale può facilmente MITM la propria macchina e visualizzare o modificare il traffico API. Nel nostro intervento dimostriamo uno scenario ipotetico

Se il tuo modello di minaccia include stati nazione che eseguono un attacco man-in-the-middle, allora anche SSL con una CA di terze parti non è molto sicuro. (Questo è ciò a cui Rook fa riferimento in precedenza.) Il blocco dei certificati è una soluzione possibile - ne discutiamo nel nostro discorso - ma ha alcuni inconvenienti, come una maggiore difficoltà durante il rollover dei certificati quando scadono.

Il nostro intervento riguarda alcune possibili attenuazioni, ma il problema di fondo di fidarsi di un dispositivo che non è sotto il tuo controllo non è generalmente risolto.

score 4 · Answer 3

La crittografia dei dati e la trasmissione di questo testo cifrato con lo streaming SSL / TLS offrono zero vantaggi per la sicurezza ed è solo uno spreco di risorse. SSL / TLS fornisce molto più della riservatezza e l'uso di SSL / TLS per trasmettere il testo cifrato è ridondante. Ciò che è stato dimostrato per prevenire attacchi MITM (BGP o DNS) e altre forme di coercizione governativa è Pinning certificato . Leggi: La tua applicazione non dovrebbe subire i problemi di SSL . Non vedo l'ora di utilizzare HTTP-Strict-Transport Security (HSTS) per il blocco dei certificati in quanto ciò fornirà strumenti utili per migliorare HTTPS.

SSL / TLS è molto efficiente e ha un solido design, il nostro PKI d'altra parte è perennemente rotto e non dovrebbe essere considerato affidabile da tutti. Se una PKI interrotta influisce sul modello della minaccia, utilizzare la funzione di blocco della cert. Se non si desidera utilizzare un algoritmo specifico, definire il proprio elenco di suite di crittografia consentite.