Terminare un volume elevato di connessioni SSL in modo efficace

Question

Ho recentemente creato un server socket Web basato su Node.js che è stato testato per gestire circa 2.000 nuove richieste di connessione al secondo su una piccola istanza EC2 (m1.small). Considerando il costo di un'istanza m1.small e la possibilità di mettere più istanze dietro un server proxy capace di WebSocket come HAProxy, siamo molto contenti dei risultati.

Tuttavia, ci siamo resi conto che non avevamo ancora eseguito test con SSL, quindi abbiamo esaminato una serie di opzioni SSL. È apparso evidente che terminare le connessioni SSL sul server proxy è ideale perché il server proxy può ispezionare il traffico e inserire intestazioni come X-Forward-For in modo che il server sappia da quale IP proviene la richiesta.

Così ho esaminato una serie di soluzioni come Pound, stunnel e stallone, che consentivano la terminazione delle connessioni in entrata su 443 e quindi passate su HAProxy sulla porta 80, che a sua volta trasmette la connessione al web server. Purtroppo, tuttavia, ho scoperto che l'invio di traffico al server proxy di terminazione SSL su un'istanza c1.medium (CPU alta) ha consumato molto rapidamente tutte le risorse della CPU e solo a una velocità di circa 50 richieste al secondo. Ho provato a utilizzare tutte e tre le soluzioni elencate sopra, e tutte hanno funzionato all'incirca nello stesso modo in cui suppongo che sotto il cofano si affidino comunque a OpenSSL. Ho provato a utilizzare un'istanza di CPU alta molto grande a 64 bit (c1.xlarge) e ho riscontrato che le prestazioni si limitano a scalare in modo lineare con il costo. Quindi, basandomi sui prezzi EC2, dovrei pagare circa $ 600p/m per 200 richieste SSL al secondo, invece di $ 60p/m per 2.000 richieste non SSL al secondo. Il prezzo precedente diventa economicamente non redditizio molto rapidamente quando iniziamo a pianificare di accettare 1.000 o 10.000 di richieste al secondo.

Ho anche provato a terminare l'SSL utilizzando il server https di Node.js, e le prestazioni erano molto simili a Pound, stunnel e perno, quindi nessun chiaro vantaggio a quell'approccio.

Quindi quello che spero che qualcuno possa aiutare è di consigliare come posso aggirare questo ridicolo costo che dobbiamo assorbire per fornire connessioni SSL. Ho sentito che gli acceleratori hardware SSL offrono prestazioni molto migliori in quanto l'hardware è progettato per la crittografia e la decrittografia SSL, ma poiché attualmente stiamo utilizzando Amazon EC2 per tutti i nostri server, l'uso di acceleratori hardware SSL non è un'opzione a meno che non dispongano di dati separati centro con server fisici. Sto solo cercando di capire come Amazon, Google, Facebook possano fornire tutto il loro traffico su SSL quando il costo è così elevato. Ci deve essere una soluzione migliore là fuori.

Qualsiasi consiglio o idea sarebbe molto apprezzato.

Grazie Matt

Answer 1

Le prestazioni del Node.js' server HTTPS è molto simile a Pound, stunnel e stud, e non v'è alcun vantaggio chiaro a questo approccio.

Answer 2

Mi sto anche chiedendo come farlo in modo efficace. La terminazione ssl di AWS è terribilmente lenta, ma forse c'è un modo per migliorarne le prestazioni. Stud sembrava promettente, ma come hai detto tu, ha anche un costo di cpu.

Answer 3

Non so molto sulla potenza della CPU disponibile in diverse istanze EC2, ma presumo che il problema non risieda nella scelta del software proxy con terminazione TLS, ma con la loro configurazione. Senza alcuna configurazione, presumo che tutti offriranno tutti i pacchetti di crittografia supportati, compresi quelli (molto) lenti. E probabilmente lasceranno che il cliente scelga quello che gli piace di più.

Non tutte le suite di crittografia TLS sono uguali, alcune hanno costi di CPU più elevati di altre, sia dallo scambio di chiavi che dallo stesso codice. A seconda del software utilizzato, ci dovrebbe essere un modo per specificare una serie di cifrature accettate dal server (e anche un modo per far insistere il server su questo). Per OpenSSL questi funzionano in questo modo: http://www.openssl.org/docs/apps/ciphers.html#CIPHER_STRINGS

Se stai andando per la velocità, assicurati almeno che non stai usando le cifre che impiegano scambi chiave-chiave Diffie-Hellmann (il tipo non ellittico-curva). Per disabilitare le suite di crittografia utilizzando lo scambio di chiavi DH, accertarsi che la stringa includa !DH in un determinato momento. È possibile verificare quale stringa determina la disponibilità di codici con, ad esempio, openssl ciphers -v 'HIGH:!aNULL:!DH:!ECDH'.

Questa stringa disabilita sia gli scambi di chiavi Diffie-Hellman sia quelli ellittici Curve Diffie-Hellmann normali. Questo probabilmente lascia solo lo scambio di chiavi RSA, a seconda della versione di OpenSSL.

Per quanto riguarda i cifrari, è necessario verificare l'hardware EC2 desiderato. Senza l'accelerazione hardware, probabilmente dovresti preferire RC4 su AES128 su AES256 su qualsiasi altra cosa, at least according to this benchmark.

Suggerisco anche di leggere this wonderful post, in particolare il primo diagramma illuminante che mostra l'impatto della DH sulle prestazioni dell'handshake TLS.

Infine, assicurarsi di utilizzare la cache di sessione TLS. Ciò risparmia anche parte della CPU.

Answer 4

Ho appena realizzato che Amazon Elastic Load Balancer è molto lento per la terminazione SSL ... Ho fatto un semplice test su www.blitz.io (nessuna relazione, solo un cliente) con 1 a 250 connessioni simultanee su 1 minuto. Ha fallito in modo orribile ... Ma se eseguo il TCP 443 sul front-end di ELB e TCP 443 su backend senza certificato, cancella la CPU di una piccola istanza quando esegue IIS e un certificato SSL su quell'istanza. Ho bisogno solo di strette di mano, è un semplice servizio web che serve clienti da ogni parte. Nuova configurazione di connessione e smontaggio ogni volta.

Come è possibile progettare un servizio Web SSL ad alto traffico, preferibilmente con SSL fino al back-end per una stretta conformità alla sicurezza?