Soluzioni Accelerazione SSL & Offload SSL

I prodotti LoadMaster di KEMP sono estremamente economici e comprendono bilanciamento del carico con Layer 4-7, commutazione del contenuto e persistenza del server, Secure Sockets Layer (SSL) – anche conosciuto come Transport Security Layer (TLS) - accelerazione/offload SSL, bilanciamento del carico WTS e persistenza con l'integrazione di Directory di sessione, oltre alla capacità di front-end applicativo (caching, compressione, sistema di prevenzione intrusioni), offrendo così il miglior rapporto prezzo/prestazioni del settore.

L'offload di processi SSL (scambio di chiave, installazione e disinstallazione di connessioni SSL e crittografia di massa), è un lavoro che richiede un notevole sforzo da parte del computer e può occupare un numero significativo di risorse hardware disponibili di un bilanciatore di carico, che invece potrebbero essere allocate per gestire le altre molteplici mansioni (come bilanciamento del carico, controllo integrità, commutazione del contenuto, persistenza, eccetera). Per ridurre l'impatto dei processi SSL sul bilanciatore di carico, la maggior parte dei vendor di SLB di alto profilo utilizzano ASIC (Circuiti Integrati Specifici per l'Applicazione) speciali, ottimizzati esclusivamente per l'accelerazione SSL

Qui di seguito riportiamo una descrizione dettagliata dell'accelerazione SSL

KEMP SSL Everything: L'accelerazione SSL che protegge tutto il sito, senza eccezioni

Quando si utilizza il protocollo SSL, molto spesso non lo si sfrutta appieno. La tecnologia SSL è potente ed è in grado di aiutare le organizzazioni a proteggere i propri dati e i propri utenti. Anche se la tecnologia dietro il protocollo SSL è solida, le buone pratiche più comuni per la sua implementazione non sfruttano completamente i benefici che ne derivano. Questo può rivelarsi inadatto a fornire la sicurezza necessaria per l'attuale ambiente di applicazione web.

Accelerazione SSL 101

Per spiegare questo punto, rivediamo prima rapidamente che cosa la tecnologia SSL può offrire a un'organizzazione in termini di vantaggi. I vantaggi sono costituiti da fiducia e privacy.

La fiducia è legata all'utilizzo di una CA (Autorità di certificazione) come VeriSign o Thawte. Se il vostro certificato SSL è firmato da una CA, nessuno potrà utilizzare il vostro nome di dominio con SSL senza che si verifichino determinati tipi di errore.

La privacy è fornita dalla crittografia, la quale si occupa di codificare il traffico in modo da renderlo incomprensibile a occhi indiscreti. Con un HTTP tradizionale le informazioni quali nomi utente, password, informazioni riguardanti carte di credito vengono tutte inviate in Internet in formato solo testo. Qualcuno potrebbe potenzialmente "fiutare" questo traffico, il che equivale, in chiave elettronica, a origliare una conversazione. Inoltre il processo potrebbe venire automatizzato, in modo da essere svolto senza sorveglianza. Un programma fiuta in automatico la rete e ne estrae parti programmate per essere interessanti, come password e numeri di carte di credito. Perciò la crittografia è uno degli strumenti più potenti utilizzati nell'ambito dell'e-commerce.

L'accelerazione SSL in pratica

La capacità di dare fiducia e privacy consente a un'organizzazione di proteggere informazioni sensibili. Oggi il protocollo SSL viene utilizzato soprattutto per proteggere solo alcune tipologie di informazioni sensibili. Esse comprendono:

  • Password (al momento del login)
  • Transazioni con carte di credito, che rappresenta un requisito di compliance PCI (settore delle carte di pagamento)

La maggior parte di ciò per il quale può essere utilizzato il protocollo SSL può essere classificato in uno di questi due modi. Ma è l'unico tipo di dati sensibili in grado di trarre vantaggio da SSL? Consideriamo quanto segue:

  • Promemoria su strategia aziendale (posta elettronica web).
  • Informazioni di vendita riservate (CRM)
  • Segreti commerciali (portale web)
  • Identificatori di sessione (nel cookie HTTP)

Ad eccezione della tecnologia VPN, che può essere presente o assente, di solito la maggior parte delle aziende non protegge il grosso di queste informazioni. Tutto viene svolto con un comune HTTP non SSL.

Pensiamoci un attimo: quale tipo di dato inviato in Internet può essere considerato non sensibile? Quali sono cioè le informazioni che, se in mano alla concorrenza o al pubblico, non ci creerebbero problemi?

Potrebbe anche succedere che la maggior parte dei vostri dati non sia sensibile, ma alcuni di essi è inevitabile che lo siano. Come si fa a sapere che cosa è o non è sensibile? Perché allora non proteggere tutto?

Protezione di sessione

Esiste un altro tipo di dati che gli utenti vorrebbero proteggere, anche se la maggior parte di essi lo ignora. Questi dati si definiscono "cookie di sessione". Quando il protocollo web venne sviluppato, era inizialmente "senza stato", vale a dire che ogni richiesta era indipendente l'una dall'altra. Quando il web passò da pagine statiche ad applicazioni web interattive, venne a crearsi la necessità di instaurare una relazione tra utente e server, in cui l'applicazione web avrebbe adattato le risposte in modo specifico per quell'utente. Ciò venne fatto assegnando all'utente un'ID di sessione, generalmente sotto forma di un cookie HTTP.

Quando un utente accede ad un'applicazione web, gli viene assegnata un'ID di sessione, solitamente una lunga stringa casuale di lettere e numeri. L'utente invia poi questa ID di sessione al server ogni volta che ne viene fatta richiesta. Il server è allora in grado di creare contenuti in modo dinamico (come una pagina di portale personalizzata, account e-mail privato, eccetera) per tale utente.

Se un malintenzionato entrasse in possesso di questo valore ID di sessione, nascerebbe un problema. Potrebbe assumere il controllo di una sessione dell’utente, fingendosi costui senza nessuna richiesta di verifica di accesso da parte del server.

Se ad essere eseguiti con protocollo SSL sono unicamente l'accesso iniziale e magari le transazioni con carta di credito, ciò significa che questo valore di ID di sessione viene inviato ripetutamente in rete "in chiaro" (senza crittografia). Ciò rende relativamente facile spiare questi dati particolari, perché la privacy è assente.

Dove sta il trucco, allora?

Considerati i vantaggi di SSL e la natura della gran parte dei dati trasferiti, perché il protocollo SSL non viene usato per default? Per rispondere a questa domanda dobbiamo guardare alla storia di SSL e a come si è sviluppato il suo impiego.

Quando venne creato per la prima volta, il principale difetto di SSL era che richiedeva più potenza in termini di risorse del server. La crittografia e decrittografia richiedono molto lavoro per la CPU. Inoltre, le CPU per uso generico (come i processori x86) non sono ottimizzate per questa attività. Un discorso vale tutt’oggi, anche per le CPU moderne.

Quando si naviga su un sito che sfrutta la tecnologia SSL, non si nota il maggiore utilizzo di CPU necessario a decrittografare una pagina web proveniente da un server. Le poche connessioni aperte non creano un impatto significativo sui moderni sistemi per utente web, anche modesti.

Vediamola però dalla prospettiva del server: Esso sta elaborando dozzine, centinaia o forse migliaia di connessioni simultanee. Se il server sta cercando di crittografare tutto allo stesso modo, la CPU sarà presto sovraccarica.

I server devono lavorare molto più duramente per elaborare pagine protette da SSL. Immaginate di avere degli scaffali pieni fino all'orlo di server che elaborano applicazioni web. Però, invece di utilizzare le loro CPU per fornire le applicazioni, usano una porzione notevole delle risorse disponibili occupandosi di crittografia e decrittografia. È come chiamare un team di ottimi neurochirurghi e riempirli di scartoffie noiose così che possano eseguire solo metà delle operazioni. È solo uno spreco di preziose risorse.

Allo stesso modo, l’atteggiamento tradizionale nei confronti di SSL indica una scarsa apertura mentale. Dal momento che le risorse SSL sono considerate limitate, solo le parti più critiche di un'interazione utente vengono poi crittografate. Dopo aver utilizzato SSL per registrare un numero di carta di credito o autenticare una password, si viene reindirizzati alla parte del sito non coperta da SSL.

SSL e Application delivery - 101

Per risolvere questi limiti nell'ambito di SSL delivery, la progettazione di sistema ha sviluppato una nuova tecnologia, denominata ASIC SSL (Circuiti Integrati Specifici per l'Applicazione). Gli ASIC sono come i processori tradizionali ma, invece di essere progettati per svolgere un'ampia gamma di attività (giocare, avviare un processore per la scrittura, navigare in Internet), i processori ASIC presentano una funzionalità estremamente limitata. Nel caso degli ASIC SSL, essi si limitano a svolgere esclusivamente operazioni SSL, ma sono incredibilmente bravi a farlo. Se una CPU x86 può essere in grado di gestire 20 nuove connessioni SSL al secondo, una ASIC SSL può essere in grado di gestire 2.000 nuove connessioni SSL.

Paradossalmente, la stessa Intel è stata tra i primi a mettere in commercio un acceleratore SSL, perché anche Intel aveva capito che le CPU x86 erano inefficienti in presenza di tassi elevati di comunicazioni SSL.

Inizialmente questi processori specializzati SSL vennero utilizzati negli stessi server. Si installava una scheda PCI con un ASIC SSL e il software di gestione web utilizzava questi processori invece della CPU generale per svolgere il lavoro SSL. Il server poteva offrire i vantaggi dei servizi SSL senza lo svantaggio dell’efficienza. Tuttavia l’aspetto negativo di questo metodo risiede nel fatto che è necessaria una scheda SSL per server e i costi possono lievitare rapidamente. Se ciascuna scheda costa $700 e i server sono 20, il totale è di $14.000 solo per la tecnologia SSL.

Poi furono sviluppate e messe in commercio applicazioni speciali di rete, chiamate acceleratori SSL. Gli acceleratori SSL sono dispositivi che si collocano tra utente e server, accettano le connessioni SSL dall'utente e le trasmettono al server senza crittografia. I dati inviati tramite rete pubblica sono protetti e il server vede traffico non crittografato, così nessuna risorsa CPU viene utilizzata su SSL.

Questo modello si è rivelato estremamente utile. Talmente utile che i bilanciatori del carico sono stati combinati con acceleratori SSL, così che ora essi funzionano sullo stesso telaio; questo tipo di ibridizzazione viene comunemente definita ADC (Application Delivery Controller).

Dal momento che la sessione SSL viene terminata sull'ADC, l'ADC è in grado di svolgere le stesse funzioni Layer 7 che avvengono con HTTP non SSL, comprese commutazione del contenuto, persistenza dei cookie e prevenzione/rilevazione delle intrusioni (IPS).

È proprio qui che la serie LoadMaster di ADC di KEMP entra in gioco. Un LoadMaster KEMP è posizionato davanti a un gruppo di server e fornisce accelerazione SSL così come bilanciamento intelligente del carico e commutazione dei contenuti.

La mentalità dell'abbondanza

Con questa nuova tecnologia, SSL è ora applicabile a tutta la vostra infrastruttura web. I processori SSL gestiscono SSL e i server trascorrono il tempo facendo ciò che viene loro meglio. In questo modo si liberano risorse per far sì che i server possano gestire altre attività.

Perché non è una pratica comune? Parte dei motivi risiedono nel fatto che SSL è stato a lungo paragonato con l'elevato utilizzo di CPU e quella linea di pensiero non è cambiata. Ma è ora che cambi.

La potenza dell'hardware

LoadMaster 2500 e LoadMaster 3500 comprendono processori SSL integrati. Loadmaster 2500 può gestire 1.000 TPS (transazioni al secondo) e LoadMaster 3500 può gestire 3.000 TPS.

Ma questo basta? Questa potenza SSL basta a spostare il protocollo SSL relativo a password e carte di credito su LoadMaster oppure anche l'intero sito? In che modo le TPS SSL si traducono in altre metriche web più familiari? Per rispondere a tali domande, diamo uno sguardo ai parametri piuttosto noti di dimensione pagina e larghezza di banda.

Innanzitutto parliamo del significato di TPS. La "T" di TPS si riferisce alla connessione SSL iniziale. Si tratta certamente della parte più pesante, a livello di CPU, dell'intero processo. Il collegamento iniziale si trova là dove viene svolta la maggior parte del lavoro, nonché dove un acceleratore SSL si rivela di assoluta utilità.

Prendendo una determinata dimensione di pagina web e facendo due calcoli, si riesce a capire il livello di larghezza di banda che un determinato livello di TPS potrebbe spingere. A titolo di esempio, utilizzeremo una pagina web di dimensioni pari a 100 kilobyte (HTML e immagini comprese, ovvero una pagina dimensioni medie). Con una pagina di dimensioni pari a 100 kilobyte, quanta banda potranno creare 1000 TPS? Facciamo l'ipotesi di HTTP 1.1, in modo tale che tutti i 100 kilobyte degli oggetti vengano richiesti nell'ambito di una sola connessione (e quindi una sola transazione SSL). 100 kilobyte equivalgono a 800 kilobit o 800.000 bit. Moltiplicandolo per 1.000 otterremo 800.000.000 bit nell'arco di un solo secondo. Questo si traduce in 800 megabit. Si tratta di un traffico davvero enorme. Più di quanto sarebbe necessario per LM-2500. In ogni caso i 3.000 TPS disponibili in LM-3500 si traducono in oltre 1 gigabit, che è più quanto sarebbe necessario. Ovviamente, dimensioni di pagina diverse e differenti comportamenti di navigazione dell'utente avranno altri effetti su questi numeri, ma rappresentano una buona indicazione del tipo di prestazione che ci si può attendere. Morale: Il livello di TPS disponibile in LM-2500 e LM-3500 è superiore rispetto a quanto effettivamente necessario, così che il TPS non è un fattore limitante. In pratica c'è abbastanza potenza SSL per ogni piccola o media impresa (PMI). Grazie alle licenze SSL incluse, il costo aggiuntivo per "proteggere con SSL" tutto il sito è pari a zero, rispetto all'aggiunta di schede SSL singole su ciascun server.

Una scelta semplice

Con i processori SSL su base hardware e la loro capacità di offload di lavoro SSL per intere infrastrutture web senza perdita in termini di performance e capacità e nessun costo supplementare (rispetto al non SSL), perché non estendere SSL a tutto? Solo vantaggi, nessuno svantaggio.

Con la potenza dei processori SSL integrati nel controller per application delivery senza costi supplementari, non c'è motivo per non estendere SSL a tutto il sito. Il costo è zero, i rischi potenziali vengono mitigati e gli utenti, se notano una differenza, la notano in positivo.

Chi è KEMP Technologies

KEMP Technologies è leader nei controller per application delivery a prezzo contenuto e applicazioni per bilanciatori del carico server su misura per soddisfare le necessità delle piccole e medie imprese (PMI) che si affidano a Internet per l’e-commerce e altre applicazioni importanti dal profilo commerciale. KEMP aiuta le PMI a far crescere rapidamente la propria attività commerciale grazie ad una elevata disponibilità 24 ore su 24, a una migliore efficienza dell'infrastruttura web, scalabilità e ad operazioni sicure, il tutto semplificando i costi IT.

Migliaia di prodotti KEMP LoadMaster vengono utilizzati oggi per incrementare la soddisfazione dei clienti accelerandone l'accesso ad applicazioni web fondamentali per le attività commerciali. Anche i fornitori di servizi gestiti si affidano ai prodotti KEMP per consentire tempi di introduzione sul mercato veloci e operazioni a prezzi contenuti per servizi gestiti nuovi o già esistenti.

I prodotti LoadMaster di KEMP sono estremamente economici e comprendono bilanciamento del carico con Layer 4-7, commutazione del contenuto e persistenza del server, accelerazione/offload SSL, bilanciamento del carico WTS e persistenza con l'integrazione di Directory di sessione, insieme con capacità di front-end applicativo (caching, compressione, sistema di prevenzione intrusioni) offrendo il miglior rapporto prezzo/prestazioni del settore.