<\/p>\n
\u00c8 difficile da credere, ma la Server Name Indication (SNI) di TLS<\/a> esiste da tredici anni. Nei tempi moderni \u00e8 un dinosauro, ma stranamente poco utilizzato; anche se la situazione sta finalmente cambiando ed \u00e8 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\u00e0 di dedicare un prezioso indirizzo IP a ogni dominio o sottodominio che deve essere protetto. Questo \u00e8 necessario perch\u00e9 SSL\/TLS protegge la connessione prima di poter ispezionare la richiesta HTTP iniziale del cliente, che contiene i preziosi dettagli del nome di dominio. <\/p>\n L \u201cunico modo per essere sicuri di fornire il certificato corretto \u00e8 servirne solo uno per indirizzo IP e utilizzare il DNS per garantire che le richieste a un nome di dominio specifico vengano indirizzate all\u201d indirizzo IP di un host che serve il certificato corretto per quel dominio. In un \u201cazienda 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 \u00e8 un\u201d opzione praticabile quando si tratta di servizi pubblici accessibili via Internet. <\/p>\n 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. \u00c8 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? <\/p>\n 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 \u00e8 necessario rigenerare il certificato e aggiornare tutti gli host interessati. <\/p>\n Questa \u00e8 la scelta sempre pi\u00f9 difficile che tutti noi abbiamo affrontato pi\u00f9 volte (anche i nostri utenti e clienti): bruciare un indirizzo IP o accettare un compromesso (in tutti i sensi). Sempre pi\u00f9 difficile perch\u00e9 gli indirizzi IP sono una risorsa limitata che diminuisce di disponibilit\u00e0 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. <\/p>\n 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\u00f2 avviene popolando un campo di estensione nel primo pacchetto TLS del client (un hello) con il nome del dominio. Questo viene inviato \u201cin chiaro\u201d in modo che possa essere letto prima che il server invii il suo certificato SSL\/TLS. In questo modo il server ha la possibilit\u00e0 di inviare il certificato previsto (ammesso che ne sia in possesso) tra tutti quelli che gli sono stati forniti. <\/p>\n In questo modo, un singolo Servizio Virtuale (e indirizzo IP) pu\u00f2 essere configurato con tanti certificati SSL per quanti nomi di dominio desideri servire. Ognuno di essi pu\u00f2 avere un certificato SSL dedicato e valido, fornito correttamente e senza errori, in base ai dati forniti dal cliente. Puoi servire www.jetnexus.com<\/a> e www.loadbalance.co.uk<\/a> allo stesso indirizzo IP e fornire certificati validi per entrambi: nessun compromesso, nessun problema e nessuno spreco di indirizzi IP. <\/p>\n Inoltre, puoi modificare l \u201celenco 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\u201d \u00e8 problema: basta una rapida regola flightPATH. Lo stesso vale per la compressione HTTP, la riscrittura degli<\/a> URL o qualsiasi altra cosa ti serva. Un unico servizio virtuale e un unico indirizzo IP per pi\u00f9 domini sono molto desiderabili, ma non devono limitare la gestione unica che potresti voler applicare al traffico dei diversi domini. <\/p>\n Ti ho sentito dire: “Qual \u00e8 l \u2018inghippo?\u2019. Beh, un tempo ce n” era uno ed \u00e8 il motivo per cui l “SNI esiste da cos\u00ec 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\u00e0 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. <\/p>\n Oggi, tuttavia, la situazione \u00e8 molto pi\u00f9 felice: Windows XP ha superato la fine del supporto, IE6 \u00e8 utilizzato per meno dell’1% sul web e l’aggiornamento gratuito a Windows 10 \u00e8 stato promosso e adottato rapidamente. Possiamo finalmente essere sicuri che l’implementazione dell’SNI non avr\u00e0 un impatto sui nostri clienti e sulla nostra attivit\u00e0. IE 7 in poi (su Vista o versioni successive) e quasi tutte le versioni di Chrome, Firefox e Safari, ad eccezione di quelle pi\u00f9 datate, supportano l’SNI. Se vuoi controllare ed essere sicuro della tua specifica base di utenti, esiste una regola flightPATH anche per questo. <\/p>\n 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 \u00e8 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 \u00e8 diverso. Questo suggerisce un problema di sicurezza? In ogni caso, il client \u00e8 connesso e la connessione \u00e8 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. <\/p>\n Se vuoi davvero maggiori dettagli, dai un \u201cocchiata all\u201d RFC3546<\/a>originale (sezione 3.1), al successivo RFC6066<\/a>(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 \u201cApp 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\u00e0 PCI-DSS e OWASP. Come discusso nei precedenti post del blog, flightPATH \u00e8 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\u00f9 sulla gestione del traffico flightPATH clicca qui e per scoprire come sfruttare al meglio le regole disponibili consulta la Guida dell\u201d utente di edgeNEXUS. <\/p>\n <\/p>\n Un singolo Servizio Virtuale (e indirizzo IP) pu\u00f2 essere configurato con tanti certificati SSL per quanti nomi di dominio desideri servire. Ognuno di essi pu\u00f2 avere un certificato SSL dedicato e valido, fornito correttamente e senza errori, in base ai dati forniti dal cliente. <\/p><\/blockquote>\n","protected":false},"excerpt":{"rendered":" \u00c8 difficile da credere, ma la Server Name Indication (SNI) di TLS esiste da tredici anni. Nei tempi moderni \u00e8 un dinosauro, ma stranamente poco utilizzato; anche se la situazione sta finalmente cambiando ed \u00e8 in questo blog che esploriamo come i bilanciatori di carico avanzati edgeNEXUS possono supportare questa funzione. L’SNI risolve uno […]<\/p>\n","protected":false},"author":13,"featured_media":34796,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[371],"tags":[407,1464,1463,1465,1176,1462],"class_list":["post-53071","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog-it","tag-bilanciatore-di-carico","tag-certificati-ssl","tag-identificazione-del-nome-del-server","tag-sicurezza-ssl","tag-ssl-it","tag-tls-sni-it"],"yoast_head":"\n