L'SSL dovrebbe essere terminato con un bilanciamento del carico?

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

Secondo me, il trust SSL / TLS dovrebbe terminare con il dispositivo di offload SSL poiché il dipartimento che gestisce quel dispositivo spesso gestisce anche il networking e l'infrastruttura. C'è una certa quantità di fiducia contrattuale lì. Non è necessario crittografare i dati su un server downstream poiché le stesse persone che stanno supportando la rete di solito hanno anche 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 dovrebbe terminare con il bilanciamento del carico è perché offre una posizione centralizzata per correggere attacchi SSL come CRIMINE 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 del aggiuntivo complessità . Rendilo semplice e avrai meno problemi a lungo termine.

Detto questo

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

Modifica

È possibile (e comune) a

• Esternalizza il bilanciamento del carico (Amazon, Microsoft, ecc.)
• Utilizza un CDN di terze parti (Akamai, Amazon, Microsoft, ecc.)
• O usa un proxy di terze parti per prevenire gli attacchi DoS

... dove il traffico proveniente da quella terza parte verrebbe inviato ai tuoi server tramite collegamenti di rete che non gestisci. Quindi non ci si può fidare di quei collegamenti non criptati. In tal caso, è necessario ricrittografare i dati o, per lo meno, trasferire tutti i dati attraverso una VPN point point.

Microsoft offre un tale prodotto VPN e consente l'esternalizzazione sicura del perimetro.

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

In primo luogo, è sempre necessario assicurarsi di ricodificarlo dall'altra parte del servizio di bilanciamento del carico, ma il dispositivo che decrittografa 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 ricodifica 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, che gestisce lo scaricatore TLS. Sul backend si ha una connessione più persistente con i server e quindi le risorse richieste sono molto più basse.

Inoltre, se non si dispone di TLS offloading, anche un piccolo attacco DDoS tramite TLS annullerebbe completamente i server. Conosco bene questa situazione e l'offload TLS è un aiuto incredibile dal punto di vista computazionale e consente inoltre di bloccare gli attacchi lungo la catena. Per attacchi DDoS di dimensioni estremamente grandi, puoi addirittura dividere la tua strategia di mitigazione tra il tuo scaricatore TLS e i tuoi server.

Per ispezionare i dati che rientrano in una connessione SSL, uno di questi deve essere vero:

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

Se segui la prima opzione, i dati viaggeranno in chiaro tra il sistema di ispezione (il bilanciamento del carico) ei cluster, a meno che non lo decifri nuovamente con un altro tunnel SSL: la connessione SSL principale è tra il browser client e il bilanciamento del carico, e il bilanciamento del carico mantiene un collegamento SSL (o qualche altra tecnologia di crittografia, ad esempio una VPN con IPsec ) tra sé e ciascuno di i nodi del cluster.

La seconda opzione è leggermente più leggera, dal momento che l'ispettore di pacchetti decodifica semplicemente i dati ma non è necessario ricodificarli. Tuttavia, ciò implica che tutti i nodi del cluster sono in grado di eseguire l'intero SSL con il client, ovvero una copia della chiave privata del server. Inoltre, il fatto di non supportare DHE significa che non otterrai l'elegante funzionalità 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 deep packet deve avere un accesso privilegiato nel tunnel SSL, il che lo rende piuttosto critico per la sicurezza.

Vorrei sostenere la terminazione di SSL nel bilanciamento del carico (che sia sulla tua rete, o su un provider CDN o altro). Significa che LB può ispezionare il traffico e può fare un lavoro migliore di bilanciamento del carico. Significa anche che il tuo bilanciamento del carico è responsabile della gestione dei client lenti, delle implementazioni SSL interrotte e della sfocatura generale di Internet. È probabile che il bilanciamento del carico sia dotato di risorse migliori per farlo rispetto ai server back-end. Significa anche che il certificato SSL che il mondo vede sono tutti sul bilanciamento del carico (il che, si spera, li rende più facili da gestire).

L'alternativa qui è semplicemente bilanciare il carico delle connessioni TCP dai client ai server back-end. Poiché il LB non è in grado di ispezionare ciò che sta succedendo in questo modo, non può distribuire il carico in modo uniforme tra i server back-end e i server back-end devono gestire tutte le falle di Internet. Userei questo metodo solo se non ti fidi del tuo bilanciamento del carico, del provider CDN o di qualsiasi altra cosa.

Ricalcolare o meno dal bilanciamento del carico verso i server back-end è una questione di scelta personale e circostanza. Se hai a che fare con carte di credito o transazioni finanziarie, probabilmente sei regolato dai governi e quindi dovrai crittografare nuovamente. Probabilmente dovresti anche ricrittografare se il traffico tra il servizio di bilanciamento del carico e quello di back-end viaggia su reti non sicure. Se stai solo ospitando il sito web della tua azienda, potresti essere in grado di evitare l'overhead aggiuntivo della re-crittografia, se non ti interessa davvero gli aspetti di sicurezza di esso.

La ri-crittografia non aggiunge tanto carico quanto si potrebbe pensare. Di solito, il bilanciamento del carico sarà in grado di mantenere le 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 è HTTP, allora non può prendere decisioni basate sul protocollo che il client stava usando. Non può quindi dire "stai cercando di accedere alla pagina di accesso tramite 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 tale intestazione avrebbe bisogno di una gestione speciale nell'applicazione. A seconda della situazione, potrebbe essere più semplice re-crittografare e consentire all'applicazione di funzionare in modo "predefinito" anziché richiedere una modifica specifica del sito.

In sintesi, direi: termina con il bilanciamento del carico e ricalni nuovamente ai tuoi server back-end. Se lo fai e noti qualche problema, puoi apportare delle modifiche se necessario.

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