it-swarm.dev

SSL deve essere terminato in un bilanciamento del carico?

Quando si ospita un cluster di server di applicazioni Web è comune avere un proxy inverso (HAProxy, Nginx, F5, ecc.) Tra il cluster e Internet pubblico per bilanciare il traffico tra i server delle app. Per eseguire l'ispezione approfondita dei pacchetti, SSL deve essere terminato sul bilanciamento del carico (o precedente), ma il traffico tra il bilanciamento del carico e i server delle app non sarebbe crittografato. La risoluzione anticipata di SSL non renderebbe i server delle app vulnerabili allo sniffing dei pacchetti o all'avvelenamento da ARP?

SSL deve essere scaricato? In tal caso, come può essere fatto senza compromettere l'integrità dei dati forniti? La mia principale preoccupazione è per un'applicazione web in cui la crittografia a livello di messaggio non è un'opzione.

99
Matt Goforth

Mi sembra che la domanda sia "ti fidi del tuo data center". In altre parole, sembra che tu stia cercando di tracciare con precisione la linea in cui si trovano le reti non attendibili e inizia trust.

A mio avviso, la fiducia SSL/TLS dovrebbe terminare sul dispositivo di offload SSL poiché il dipartimento che gestisce quel dispositivo spesso gestisce anche la rete e l'infrastruttura. C'è una certa quantità di fiducia contrattuale lì. Non ha senso crittografare i dati su un server downstream poiché anche le stesse persone che supportano la rete hanno accesso a questo. (con la possibile eccezione in ambienti multi-tenant o requisiti aziendali unici che richiedono una segmentazione più profonda).

Un secondo motivo per cui SSL deve terminare al bilanciamento del carico è perché offre una posizione centralizzata per correggere gli attacchi SSL come CRIME o [~ # ~ ] bestia [~ ~ #] . Se SSL viene terminato su una varietà di server Web, in esecuzione su diversi sistemi operativi è più probabile che si verifichino problemi a causa di aggiuntivocomplessità . Mantienilo semplice e avrai meno problemi a lungo termine.

Detto ciò

  1. Sì, termina al bilanciamento del carico e offload SSL lì. Keep it simple.
  2. Il bilanciamento del carico Citrix Netscaler (ad esempio) può negare l'accesso non sicuro a un URL. Questa logica politica, combinata con le funzionalità di TLS, dovrebbe garantire che i tuoi dati rimangano confidenziali e senza manomissioni (dato che comprendo correttamente il tuo requisito di integrità)

Edit:

È possibile (e comune)

  • Esternalizzare il bilanciamento del carico (Amazon, Microsoft, ecc.)
  • Utilizzare un CDN di terze parti (Akamai, Amazon, Microsoft, ecc.)
  • O utilizzare un proxy di terze parti per prevenire attacchi DoS

... dove il traffico proveniente da quella terza parte verrebbe inviato ai tuoi server tramite collegamenti di rete che non gestisci. Pertanto, potrebbe non fidarsi di quei collegamenti non crittografati. In tal caso, è necessario crittografare nuovamente i dati o almeno farli viaggiare attraverso una VPN punto-punto.

Microsoft offre un tale prodotto VPN e consente l'outsourcing sicuro del perimetro.

78

Sì, direi che TLS dovrebbe essere scaricato. Ho fatto tutto ciò che menziono di seguito in particolare con Citrix Netscaler, ma credo che F5 dovrebbe essere in grado di fare le stesse cose.

Innanzitutto, devi sempre assicurarti di ripetere la crittografia sull'altro lato del bilanciamento del carico, ma il dispositivo che decodifica TLS dovrebbe essere in grado di ispezionare ciò che sta accadendo dal punto di vista della sicurezza. L'integrità dei dati non dovrebbe essere compromessa da questo approccio.

Molte persone mi hanno detto che la ri-crittografia sul back-end lo rende altrettanto costoso dal punto di vista computazionale, ma non è vero. La spesa con TLS è la costruzione e la chiusura della connessione, gestita dall'offloader TLS. Sul backend hai una connessione più persistente ai server, e quindi le risorse richieste sono molto più basse.

Inoltre, se non si dispone di offload TLS, anche un piccolo attacco DDoS tramite TLS annichilerebbe completamente i server. Conosco molto bene questa situazione e l'offload di TLS è un aiuto incredibile dal punto di vista computazionale e consente anche di bloccare gli attacchi più in alto nella catena. Per attacchi DDoS estremamente grandi, potresti persino dividere la tua strategia di mitigazione tra il tuo offloader TLS e i tuoi server.

18
JZeolla

Per controllare i dati che si trovano all'interno di una connessione SSL, uno di questi deve essere vero:

  • Il tunnel termina sulla macchina che esegue l'ispezione, ad es. il tuo "bilanciamento del carico".
  • Il sistema di ispezione conosce una copia della chiave privata del server e la connessione SSL non utilizza Diffie-Hellman effimero (ovvero il server non consente le suite di crittografia che contengono "DHE" nel loro nome).

Se segui la prima opzione, i dati viaggeranno senza crittografia tra il sistema di ispezione (il bilanciamento del carico) e i cluster, a meno che non li ricodifichi con qualche altro tunnel SSL: la connessione SSL principale è tra il browser client e il bilanciamento del carico e il carico bilanciamento mantiene un collegamento SSL (o qualche altra tecnologia di crittografia, ad esempio una VPN con IPsec ) tra se stesso e ciascuno dei nodi del cluster.

La seconda opzione è in qualche modo più leggera, poiché la finestra di ispezione dei pacchetti decodifica i dati ma non deve codificarli nuovamente. Tuttavia, ciò implica che tutti i nodi del cluster sono in grado di eseguire il SSL completo con il client, ovvero conoscere una copia della chiave privata del server. Inoltre, non supportare DHE significa che non otterrai la caratteristica elegante di Perfect Forward Secrecy (questo non è fatale, ma PFS sembra davvero buono nei controlli di sicurezza, quindi è una buona cosa avere).

In entrambi i casi, il nodo che esegue l'ispezione approfondita dei pacchetti deve avere un accesso privilegiato al tunnel SSL, il che lo rende piuttosto critico per la sicurezza.

7
Tom Leek

Suggerirei di terminare SSL presso il bilanciamento del carico (sia quello sulla rete, o presso un provider CDN o altro). Significa che l'LB può ispezionare il traffico e può svolgere un lavoro migliore nel bilanciamento del carico. Significa anche che il bilanciamento del carico è responsabile della gestione di client lenti, implementazioni SSL non funzionanti e errori generali di Internet. È probabile che il bilanciamento del carico abbia risorse migliori per farlo rispetto ai server back-end. Significa anche che i certificati SSL che il mondo vede sono tutti sul bilanciamento del carico (che si spera li renda più facili da gestire).

L'alternativa qui è semplicemente bilanciare il carico delle connessioni TCP dai client ai server back-end. Poiché l'LB non è in grado di ispezionare ciò che sta accadendo in questo modo, non può distribuire uniformemente il carico su i server back-end e i server back-end devono gestire tutte le imperfezioni di Internet. Utilizzerei questo metodo solo se non ti fidi del bilanciamento del carico, del provider CDN o altro.

La ricodifica o meno dal bilanciamento del carico ai server back-end è una questione di scelta e circostanza personale. Se hai a che fare con carte di credito o transazioni finanziarie, probabilmente sei regolato dal governo (i) e quindi dovrai ricodificarlo. Probabilmente dovresti anche ri-crittografare se il traffico tra bilanciamento del carico e server back-end viaggia su reti non attendibili. Se stai semplicemente ospitando il sito Web della tua azienda, potresti essere in grado di evitare l'ulteriore sovraccarico della crittografia, se non ti interessa davvero gli aspetti di sicurezza di esso.

La nuova crittografia non aggiunge tutto il carico che si potrebbe pensare. Di solito, il bilanciamento del carico sarà in grado di mantenere connessioni persistenti ai server, quindi il costo SSL sarà piuttosto basso per quel "hop" sulla rete.

L'ultima cosa a cui pensare è l'applicazione sui server back-end. Se tutto il traffico che arriva lì è HTTP, non può prendere decisioni in base al protocollo utilizzato dal client. Non può quindi dire "stai tentando di accedere alla pagina di accesso su HTTP, quindi ti reindirizzerò alla versione HTTPS della pagina", ad esempio. È possibile fare in modo che il bilanciamento del carico aggiunga un'intestazione HTTP per dire "questo proviene da HTTPS", ma quell'intestazione avrebbe bisogno di una gestione speciale nell'applicazione. A seconda della situazione, potrebbe essere più semplice crittografare nuovamente e consentire all'applicazione di funzionare nel modo "predefinito" anziché richiedere una modifica specifica del sito.

In breve, direi: termina con il bilanciamento del carico e ricrittografa i tuoi server back-end. Se lo fai e noti qualche problema, puoi apportare modifiche se necessario.

6
Ralph Bolton

Puoi scegliere di crittografare il traffico interno con un certificato di chiave inferiore. Inoltre, si consiglia di posizionare il bilanciamento del carico il più vicino possibile ai server per evitare sniffing o attacchi man-in-middle. La terminazione SSL può essere eseguita su Load Balancer per scaricare i lavori ad alta intensità di CPU lontano dai server Web. Se il marchio LB che hai scelto è in grado di svolgere determinate funzioni come l'ispezione delle connessioni di protocollo non valide, rilevare il comportamento DDoS, ecc.

1
Davis