È difficile da credere, ma la Server Name Indication (SNI) di TLS esiste da tredici anni. Nei tempi moderni è un dinosauro, ma stranamente poco utilizzato; anche se la situazione sta finalmente cambiando ed è in questo blog che esploriamo come i bilanciatori di carico avanzati edgeNEXUS possono supportare questa funzione. L’SNI risolve uno dei maggiori problemi che molti hanno con SSL/TLS/HTTPS: la necessità di dedicare un prezioso indirizzo IP a ogni dominio o sottodominio che deve essere protetto. Questo è necessario perché SSL/TLS protegge la connessione prima di poter ispezionare la richiesta HTTP iniziale del cliente, che contiene i preziosi dettagli del nome di dominio.
L “unico modo per essere sicuri di fornire il certificato corretto è servirne solo uno per indirizzo IP e utilizzare il DNS per garantire che le richieste a un nome di dominio specifico vengano indirizzate all” indirizzo IP di un host che serve il certificato corretto per quel dominio. In un “azienda privata potremmo forse utilizzare lo stesso indirizzo IP ma una porta diversa, ma saremmo obbligati ad assicurarci che tutti sappiano di dover utilizzare la porta non standard. Questa non è un” opzione praticabile quando si tratta di servizi pubblici accessibili via Internet.
Potremmo utilizzare certificati wildcard che proteggono tutti i sottodomini possibili (*.jetnexus.co.uk per esempio) ma non piacciono a nessuno, men che meno a chi si occupa di sicurezza. Qualunque cosa tu possa pensare degli uomini e delle donne NO! del mondo della sicurezza informatica, probabilmente non hanno tutti i torti. È difficile fidarsi di qualcosa che, per sua natura, rappresenta letteralmente tutto o quasi all’interno di un dominio. Quanti dispositivi memorizzano e quanti dipendenti hanno accesso al certificato e alla chiave in uso?
I certificati SAN (Server Alternative Name) sono sempre stati disponibili, ma richiedono la conoscenza di ogni specifico dominio da proteggere, nel momento in cui vengono generati. Per rimuovere o aggiungere un nome di dominio è necessario rigenerare il certificato e aggiornare tutti gli host interessati.
Questa è la scelta sempre più difficile che tutti noi abbiamo affrontato più volte (anche i nostri utenti e clienti): bruciare un indirizzo IP o accettare un compromesso (in tutti i sensi). Sempre più difficile perché gli indirizzi IP sono una risorsa limitata che diminuisce di disponibilità e acquista valore ogni giorno. Per nostra fortuna, questo annoso problema ha una soluzione da molti anni. Ci offre il meglio di tutti i mondi, ma fino a poco tempo fa aveva un impatto limitato.
SNI Fornisce un metodo al client per indicare al server (nel nostro caso un jetNEXUS) il nome di dominio con cui sta stabilendo una connessione. Ciò avviene popolando un campo di estensione nel primo pacchetto TLS del client (un hello) con il nome del dominio. Questo viene inviato “in chiaro” in modo che possa essere letto prima che il server invii il suo certificato SSL/TLS. In questo modo il server ha la possibilità di inviare il certificato previsto (ammesso che ne sia in possesso) tra tutti quelli che gli sono stati forniti.
In questo modo, un singolo Servizio Virtuale (e indirizzo IP) può essere configurato con tanti certificati SSL per quanti nomi di dominio desideri servire. Ognuno di essi può avere un certificato SSL dedicato e valido, fornito correttamente e senza errori, in base ai dati forniti dal cliente. Puoi servire www.jetnexus.com e www.loadbalance.co.uk allo stesso indirizzo IP e fornire certificati validi per entrambi: nessun compromesso, nessun problema e nessuno spreco di indirizzi IP.
Inoltre, puoi modificare l “elenco dei domini supportati dal Servizio Virtuale ogni volta che vuoi, con pochi clic nella GUI. Aggiungi o rimuovi certificati per aggiungere o rimuovere i domini supportati dal Servizio Virtuale. Non dimenticare di aggiornare anche i DNS. Se vuoi utilizzare server reali diversi per uno o due domini di alto valore, non c” è problema: basta una rapida regola flightPATH. Lo stesso vale per la compressione HTTP, la riscrittura degli URL o qualsiasi altra cosa ti serva. Un unico servizio virtuale e un unico indirizzo IP per più domini sono molto desiderabili, ma non devono limitare la gestione unica che potresti voler applicare al traffico dei diversi domini.
Ti ho sentito dire: “Qual è l ‘inghippo?’. Beh, un tempo ce n” era uno ed è il motivo per cui l “SNI esiste da così tanto tempo, ma solo ora sta facendo la sua comparsa nel bilanciamento del carico e in altri prodotti. Il motivo? Il supporto dei client. La longevità della combinazione incredibilmente popolare di Windows XP e IE6, che non supporta l” SNI, ha impedito a molti di utilizzarlo. Nessuno vuole potenzialmente tagliare fuori il 10-20% del proprio pubblico.
Oggi, tuttavia, la situazione è molto più felice: Windows XP ha superato la fine del supporto, IE6 è utilizzato per meno dell’1% sul web e l’aggiornamento gratuito a Windows 10 è stato promosso e adottato rapidamente. Possiamo finalmente essere sicuri che l’implementazione dell’SNI non avrà un impatto sui nostri clienti e sulla nostra attività. IE 7 in poi (su Vista o versioni successive) e quasi tutte le versioni di Chrome, Firefox e Safari, ad eccezione di quelle più datate, supportano l’SNI. Se vuoi controllare ed essere sicuro della tua specifica base di utenti, esiste una regola flightPATH anche per questo.
Per quanto riguarda la sicurezza, siamo chiari: il cliente fornisce informazioni in chiaro. Si tratta di informazioni che possono essere catturate via cavo. Il client esegue una query DNS in chiaro prima di connettersi. Non possiamo controllarlo, quindi non è considerato un rischio rivelare queste informazioni una seconda volta in un secondo momento. Forse vorresti controllare che il nome del dominio SNI corrisponda a quello trovato nell’intestazione HTTP Host, con una regola flightPATH o forse non ti interessa, ognuno è diverso. Questo suggerisce un problema di sicurezza? In ogni caso, il client è connesso e la connessione è sicura. A meno che tu non stia applicando dei criteri di sicurezza basati sul nome del dominio (e non dovresti farlo), allora tutto va bene.
Se vuoi davvero maggiori dettagli, dai un “occhiata all” RFC3546originale (sezione 3.1), al successivo RFC6066(sezione 3) e, se pensi che ci si possa fidare: Indicazione del nome del server su Wikipedi. Se hai bisogno di sicurezza a livello di applicazione, il WAF di edgeNEXUS si basa su una tecnologia di firewall applicativo leader nel settore. Disponibile tramite l “App Store di edgeNEXUS e utilizzando una tecnologia container di ultima generazione, il firewall applicativo edgeNEXUS offre una protezione completa per soddisfare i requisiti di conformità PCI-DSS e OWASP. Come discusso nei precedenti post del blog, flightPATH è un motore di regole dinamico e basato sugli eventi sviluppato da edgeNEXUS per manipolare e instradare in modo intelligente il traffico IP, HTTP e HTTPS bilanciato dal carico. Per saperne di più sulla gestione del traffico flightPATH clicca qui e per scoprire come sfruttare al meglio le regole disponibili consulta la Guida dell” utente di edgeNEXUS.
Un singolo Servizio Virtuale (e indirizzo IP) può essere configurato con tanti certificati SSL per quanti nomi di dominio desideri servire. Ognuno di essi può avere un certificato SSL dedicato e valido, fornito correttamente e senza errori, in base ai dati forniti dal cliente.
