SSL /TLS Best practice per il 2023

Nel 2023, proteggere il tuo sito web con un SSL /TLS il certificato non è più facoltativo, anche per le aziende che non trattano direttamente le informazioni sensibili dei clienti sul Web. I motori di ricerca come Google utilizzano la sicurezza del sito come segnale di posizionamento SEO e browser Web popolari come Chrome avvisano gli utenti di siti Web che non utilizzano HTTPS:

Tuttavia, la prospettiva di configurare i server Web e le applicazioni per utilizzare SSL /TLS protocollo correttamente può sembrare scoraggiante, poiché ci sono molte configurazioni arcane e scelte di progettazione da fare. Questa guida fornisce una rapida panoramica dei punti principali da tenere a mente quando si configura SSL /TLS per il tuo sito web, concentrandoti su sicurezza e prestazioni. C'è ancora molto da coprire solo con le basi, quindi lo abbiamo suddiviso in una serie di passaggi.

Scegli un'autorità di certificazione affidabile (CA)

I tuoi certificati sono affidabili quanto la CA che li emette. Tutte le CA pubblicamente attendibili sono soggette a rigorosi controlli di terze parti per mantenere la loro posizione nei principali programmi di certificati root del sistema operativo e del browser, ma alcuni sono più bravi a mantenere quello stato rispetto ad altri. Cerca una CA che (come SSL.com):

• Svolge la maggior parte dei suoi affari nel campo dei servizi di fiducia PKI. Queste aziende hanno più da perdere se vengono alla luce cattive pratiche di sicurezza e tutto da guadagnare mantenendo il passo con l'evoluzione degli standard del settore.
• Risponde in modo efficiente ed efficace alle scoperte di vulnerabilità che interessano la sicurezza e la privacy degli utenti, come nel settore entropia del numero di serie numero di inizio 2019. Ricerca nei forum del settore come politica.di.sicurezza.mozilla.dev può darti una buona idea di come una particolare CA reagisce alle avversità.
• Offre prodotti e servizi utili, come certificati EV (Extended Validation), emissione di certificati in blocco / automatizzata tramite un intuitivo API oppure Protocollo ACME, semplici servizi di monitoraggio e gestione del ciclo di vita dei certificati e supporto per l'integrazione con un ampio elenco di soluzioni di terze parti.
• Ha una reputazione per l'ottimo servizio clienti e supporto tecnico. Mantenere il sito web della tua azienda sicuro il 100% delle volte è importante e devi essere in grado di avere un vero esperto al telefono quando le cose vanno male.

Autorizzazione dell'autorità di certificazione (CAA)

Autorizzazione dell'autorità di certificazione (CAA) è uno standard per proteggere i siti Web designando CA specifiche autorizzate a emettere certificati per un nome di dominio. Dopo aver scelto una CA, dovresti prendere in considerazione configurazione dei record CAA per autorizzarlo.

Genera e proteggi le tue chiavi private

I SSL /TLS protocollo utilizza un coppia di chiavi per autenticare le identità e crittografare le informazioni inviate su Internet. Uno di questi (il Chiave pubblica) è inteso per un'ampia distribuzione e l'altro (il chiave privata) dovrebbe essere mantenuto nel modo più sicuro possibile. Queste chiavi vengono create insieme quando si genera un richiesta di firma del certificato (CSR). Ecco alcuni suggerimenti da tenere a mente riguardo alle tue chiavi private:

• Usa chiavi private forti: I tasti più grandi sono più difficili da decifrare, ma richiedono un sovraccarico di elaborazione. Attualmente, si consiglia almeno una chiave RSA a 2048 bit o una chiave ECDSA a 256 bit e la maggior parte dei siti Web può raggiungere una buona sicurezza ottimizzando le prestazioni e l'esperienza utente con questi valori.
  
  Nota: per una panoramica di questi due algoritmi, consultare l'articolo di SSL.com, Confronto tra ECDSA e RSA.
• Proteggi le tue chiavi private:
  • Genera le tue chiavi private in un ambiente sicuro e affidabile (preferibilmente sul server in cui verranno distribuite o su un dispositivo conforme a FIPS o Common Criteria). Mai consentire a una CA (oa chiunque altro) di generare chiavi private per tuo conto. Una CA pubblica affidabile, come SSL.com, non si offrirà mai di generare o gestire le tue chiavi private a meno che non siano generate in un token hardware sicuro o HSM e non siano esportabili.
  • Dare accesso alle chiavi private solo se necessario. Genera nuove chiavi e revocare tutti i certificati per le vecchie chiavi quando i dipendenti con accesso alla chiave privata lasciano l'azienda.
  • Rinnova i certificati il ​​più spesso possibile (almeno una volta all'anno sarebbe utile), preferibilmente utilizzando ogni volta una chiave privata appena generata. Strumenti di automazione come Protocollo ACME sono utili per programmare rinnovi frequenti dei certificati.
  • Se una chiave privata è stata (o potrebbe essere stata) compromessa, revocare tutti i certificati per questa chiave, generano una nuova coppia di chiavi ed emettono un nuovo certificato per la nuova coppia di chiavi.

Configura il tuo server

In superficie, installazione di un SSL /TLS a livello internazionale può sembrare un'operazione semplice; tuttavia, ci sono ancora molte molte decisioni di configurazione che devono essere prese per garantire che il tuo server web sia veloce e sicuro e che gli utenti finali abbiano un'esperienza fluida, priva di errori e avvisi del browser. Di seguito sono riportati alcuni suggerimenti di configurazione per aiutarti a tenere il passo durante la configurazione di SSL /TLS sui tuoi server:

• Assicurati che tutti i nomi host siano coperti: Il tuo certificato copre il nome di dominio del tuo sito sia con che senza l'estensione www prefisso? C'è un Nome alternativo soggetto (SAN) per ogni nome di dominio che il certificato intende proteggere?
• Installa catene di certificati complete: SSL entità finale /TLS i certificati sono generalmente firmati da certificati intermedi piuttosto che dalla chiave radice di una CA. Assicurati che tutti i certificati intermedi siano installati sul tuo server web per fornire ai browser un file percorso di certificazione ed evitare avvisi ed errori relativi all'affidabilità per gli utenti finali. La tua CA sarà in grado di fornirti qualsiasi intermediario necessario; I clienti di SSL.com possono utilizzare il nostro Download certificato intermedio pagina per recuperare bundle intermedi per molte piattaforme server.
• Usa SSL corrente /TLS Protocolli (TLS 1.2 o 1.3): Alla fine del 2018, tutti i principali fornitori di browser hanno annunciato piani di deprezzamento TLS 1.0 e 1.1 entro la prima metà del 2020. Google deprecato TLS v1.0 e v1.1 in Chrome 72 (rilasciato il 30 gennaio 2919). Le versioni 84 di Chrome (rilasciate il 14 luglio 2020) e successive presentano un avviso intermedio per questi protocolli e il supporto doveva essere completamente rimosso nel maggio 2021. Supporto browser diffuso per SSL /TLS versioni, come SSL v3, è ormai lontana. Mentre TLS 1.2 è attualmente la versione più utilizzata di SSL /TLS protocollo, TLS 1.3 (l'ultima versione) è già supportato nelle versioni attuali della maggior parte dei browser Web.
• Utilizzare un breve elenco di Secure Cipher Suites: Scegli solo le suite di crittografia che offrono una crittografia di almeno 128 bit o più potenti quando possibile. Anche il National Institute of Standards and Technology (NIST) raccomanda questo TLS le implementazioni si spostano dalle suite di cifratura contenenti il ​​codice DES (o le sue varianti) a quelle che utilizzano AES. Infine, l'utilizzo solo di un piccolo sottoinsieme di suite di cifratura potenzialmente accettabili riduce al minimo la superficie di attacco per le vulnerabilità non ancora scoperte. L'appendice di SSL.com Guida alla TLS Conformità alle norme fornisce configurazioni di esempio per le piattaforme web server più popolari, utilizzando TLS 1.2
  
  Nota: L'uso di cifre non sicure e deprecate (come RC4) può causare errori di sicurezza del browser, come ERR_SSL_VERSION_OR_CIPHER_MISMATCH su GoogleChrome.
• Usa il segreto d'ufficio (FS): Conosciuto anche come perfetto segreto in avanti (PFS), FS assicura che una chiave privata compromessa non comprometterà anche le chiavi di sessione passate. Per abilitare FS:
  • Configurazione TLS 1.2 per utilizzare l'algoritmo di scambio di chiavi Elliptic Curve Diffie-Hellman (EDCHE) (con DHE come fallback) ed evitare completamente lo scambio di chiavi RSA, se possibile.
  • Usa il TLS 1.3. TLS 1.3 fornisce segretezza anticipata per tutti TLS sessioni tramite il Effimero Diffie-Hellman (EDH o DHE) protocollo di scambio chiavi.
• permettere TLS Ripresa della sessione: Analogamente all'utilizzo di keepalives per mantenere connessioni TCP persistenti, TLS la ripresa della sessione consente al tuo server web di tenere traccia degli SSL /TLS sessioni e riprenderle, ignorando l'overhead computazionale della negoziazione delle chiavi di sessione.
• Considera la cucitura OCSP: Pinzatura OCSP consente ai server Web di fornire le informazioni di revoca memorizzate nella cache direttamente al client, il che significa che un browser non dovrà contattare un server OCSP per verificare se il certificato di un sito Web è stato revocato. Eliminando questa richiesta, la pinzatura OCSP offre un reale incremento delle prestazioni. Per ulteriori informazioni, leggi il nostro articolo, Ottimizzazione del caricamento della pagina: pinzatura OCSP.

Utilizzare le migliori pratiche per la progettazione di applicazioni Web

Progettare le tue applicazioni web tenendo conto della sicurezza è importante tanto quanto configurare correttamente il tuo server. Questi sono i punti più importanti per assicurarti che i tuoi utenti non siano esposti uomo al centro attacchi e che la tua applicazione ottenga i vantaggi SEO che derivano da buone pratiche di sicurezza:

• Elimina contenuto misto: I file JavaScript, le immagini e i file CSS dovrebbero contro tutti i accessibile con SSL /TLS. Come descritto nell'articolo di SSL.com, HTTPS Everywhere, servendo contenuto misto non è più un modo accettabile per migliorare le prestazioni del sito Web e può comportare avvisi di sicurezza del browser e problemi SEO.
• Usa cookie sicuri: Impostazione del Secure flag nei cookie imporrà la trasmissione su canali sicuri (ad es. HTTPS). Puoi anche impedire a JavaScript lato client di accedere ai cookie tramite HttpOnly contrassegnare e limitare l'uso di cookie tra siti con il SameSite bandiera.
• Valuta il codice di terze parti: Assicurati di comprendere i potenziali rischi dell'utilizzo di librerie di terze parti nel tuo sito web, come la possibilità di introdurre inavvertitamente vulnerabilità o codice dannoso. Controlla sempre l'affidabilità di terze parti al meglio delle tue capacità e collega a tutto il codice di terze parti con HTTPS. Infine, assicurati che il tuo vantaggio da qualsiasi elemento di terze parti sul tuo sito web valga il rischio.

Controlla il tuo lavoro con gli strumenti diagnostici

Dopo aver configurato SSL /TLS sul tuo server e sito web o apportando modifiche alla configurazione, è importante assicurarsi che tutto sia impostato correttamente e che il tuo sistema sia sicuro. Sono disponibili numerosi strumenti diagnostici per controllare l'SSL /TLS. Ad esempio, SSL Shopper's Controllo SSL ti farà sapere se il tuo certificato è installato correttamente, quando scadrà e mostrerà il certificato catena di fiducia.

Sono disponibili altri strumenti e applicazioni online che eseguiranno la scansione del tuo sito verificando problemi di sicurezza come contenuto misto. Puoi anche verificare la presenza di contenuti misti con un browser Web utilizzando i suoi strumenti di sviluppo integrati:

Qualunque strumento tu scelga, è anche importante impostare una pianificazione per il controllo del tuo SSL /TLS installazione e configurazione. La tua CA potrebbe anche essere in grado di aiutarti in questo; ad esempio, per comodità dei nostri clienti, SSL.com fornisce avvisi automatici di imminente scadenza del certificato.

Implementare HTTP Strict Transport Security (HSTS)

HTTP Strict Transport Security (HSTS) è un meccanismo di politica di sicurezza che aiuta a proteggere i siti Web da attacchi di downgrade del protocollo e dirottamento dei cookie. Consente ai server Web di dichiarare che i browser Web (o altri agenti utente conformi) dovrebbero interagire con esso solo utilizzando connessioni HTTPS sicure e mai tramite il protocollo HTTP non sicuro. Questa politica viene comunicata dal server all'agente utente tramite un campo di intestazione della risposta HTTP denominato "Strict-Transport-Security".

Implementare Sicurezza del trasporto rigoroso HTTP (HSTS), devi aggiungere un'intestazione di risposta speciale alla configurazione del tuo server web.

Ecco una guida passo passo:

1. Assicurati che il tuo sito supporti HTTPS: prima di abilitare HSTS, il tuo sito deve avere un file valido Certificato SSL ed essere in grado di servire contenuti su HTTPS. Se il tuo sito non è ancora configurato per HTTPS, dovrai farlo ottenere un certificato SSL e configura il tuo server per usarlo.

L'intestazione è sempre impostata su Strict-Transport-Security "max-age=31536000; includeSubDomains"

_{Questa riga indica al browser di utilizzare sempre HTTPS per il tuo sito per il prossimo anno (31,536,000 secondi), inclusi tutti i sottodomini.}

2. Metti alla prova la tua configurazione: dopo aver aggiunto l'intestazione HSTS, dovresti testare il tuo sito per assicurarti che funzioni correttamente. Puoi farlo visitando il tuo sito e utilizzando gli strumenti per sviluppatori del tuo browser per controllare le intestazioni delle risposte. Dovresti vedere l'intestazione Strict-Transport-Security con il valore che hai impostato.
3. Prendi in considerazione l'idea di aggiungere il tuo sito all'elenco di precaricamento HSTS: l'elenco di precaricamento HSTS è un elenco di siti codificati nei browser come abilitati per HSTS. Ciò fornisce un ulteriore livello di protezione, in quanto garantisce che la prima connessione al tuo sito sia sicura, anche prima che venga ricevuta l'intestazione HSTS. Puoi inviare il tuo sito all'elenco di precaricamento HSTS su hstspreload.org.

Usa caso: un sito web di notizie vuole assicurarsi che i suoi utenti si colleghino sempre ad esso in modo sicuro, anche se digitano accidentalmente "http" invece di "https" nell'URL. Il sito Web utilizza HSTS aggiungendo l'intestazione Strict-Transport-Security alla sua configurazione del server, impostando un'età massima lunga e includendo tutti i sottodomini. Questo dice agli agenti utente di connettersi sempre ad esso utilizzando HTTPS, proteggendo gli utenti da attacchi che tentano di eseguire il downgrade della connessione a HTTP e rubare i loro cookie. Il sito Web si sottopone anche all'elenco di precaricamento HSTS per una protezione aggiuntiva.

Implementare il pinning della chiave pubblica HTTP (HPKP)

HTTP Public Key Pinning (HPKP) era una funzione di sicurezza che consentiva a un server Web di associare a se stesso una specifica chiave pubblica crittografica per impedire attacchi man-in-the-middle (MITM) con certificati falsi.

Ecco una breve panoramica di come è stato utilizzato:

1. Genera informazioni di blocco: Il primo passaggio nell'implementazione di HPKP è stato generare le informazioni di blocco. Ciò ha comportato la creazione di un hash crittografico della chiave pubblica del certificato o della chiave pubblica del certificato intermedio o root.
2. Configurare il server web: Il passaggio successivo è stato configurare il server web per includere il file Public-Key-Pin HTTP intestazione nelle risposte. Questa intestazione includeva gli hash delle chiavi pubbliche (i "pin"), un tempo di vita (per quanto tempo il browser dovrebbe ricordare le informazioni) e facoltativamente un URI di report (dove il browser invierebbe report di errori di convalida dei pin).
3. Gestire gli errori di convalida dei pin: se un browser che supporta HPKP riceve una catena di certificati che non include almeno una delle chiavi pubbliche bloccate, considera la connessione non attendibile. Se è stato specificato un URI di report, il browser invierà anche un report dell'errore a tale URI.

Tuttavia, a causa del rischio di uso improprio e della possibilità di causare denial of service, HPKP è stato deprecato dalla maggior parte dei browser e non è più una pratica consigliata. L'errata configurazione di HPKP potrebbe portare a una situazione in cui un sito Web diventa inaccessibile.

Usa caso: In passato, un'azienda tecnologica utilizzava HPKP per bloccare le proprie chiavi pubbliche sui propri server. Ciò ha garantito che se un'autorità di certificazione (CA) fosse stata compromessa e un certificato fosse stato emesso per errore per il proprio dominio, i browser non si sarebbero fidati di esso a meno che non avesse anche una chiave pubblica che corrispondeva a una delle chiavi bloccate. Tuttavia, hanno dovuto fare molta attenzione per evitare di perdere l'accesso alle chiavi bloccate, il che avrebbe reso inaccessibile il loro sito web. Dovevano anche assicurarsi di disporre di un processo per ruotare i pin prima che scadessero, per evitare di rendere il loro sito inaccessibile agli utenti con informazioni di pinning memorizzate nella cache.

Usa il TLS Fallback SCSV per prevenire gli attacchi di downgrade del protocollo

TLS SCSV di riserva (Valore della suite di cifratura di segnalazione) è un meccanismo introdotto per prevenire attacchi di downgrade del protocollo. Questi attacchi si verificano quando un utente malintenzionato interferisce con il processo di configurazione della connessione e induce il client e il server a utilizzare una versione del protocollo meno sicura di quella che entrambi supportano effettivamente.

Ecco come puoi implementare TLS SCSV di riserva:

1. Aggiorna l'SSL del tuo server/TLS Biblioteca: il primo passaggio consiste nell'assicurarsi che l'SSL/TLS supporti per biblioteche TLS SCSV di riserva. Questa funzione è stata introdotta in OpenSSL 1.0.1j, 1.0.0o e 0.9.8zc. Se utilizzi un SSL diverso/TLS library, controlla la sua documentazione o contatta i suoi sviluppatori.
2. Configura il tuo server: Una volta che il tuo server SSL/TLS supporti per biblioteche TLS Fallback SCSV, potrebbe essere necessario configurare il server per utilizzarlo. I passaggi esatti dipenderanno dal software del tuo server. Ad esempio, in Apache, potrebbe essere necessario aggiungere o modificare una riga nel file di configurazione in questo modo:

Protocollo SSL Tutti -SSLv2 -SSLv3

Questa riga indica al server di utilizzare tutte le versioni del protocollo tranne SSLv2 e SSLv3. Se il client e il server supportano entrambi TLS 1.2, ma il client tenta di utilizzare TLS 1.1 (probabilmente a causa dell'interferenza di un utente malintenzionato), il server lo riconoscerà come un tentativo di fallback e rifiuterà la connessione.

3. Metti alla prova il tuo server: dopo aver configurato il tuo server, dovresti testarlo per assicurarti che sia implementato correttamente TLS SCSV di riserva. Esistono vari strumenti online che possono aiutarti in questo, come SSL Labs Server Test.

Usa caso: una società globale utilizza TLS Fallback SCSV per proteggere le sue comunicazioni interne. Ciò garantisce che se un utente malintenzionato tenta di forzare un downgrade del protocollo, il server lo riconoscerà e rifiuterà la connessione, proteggendo i dati sensibili dell'azienda. Il team IT dell'azienda aggiorna regolarmente SSL/TLS librerie e configurazioni per garantire che stiano utilizzando le funzionalità di sicurezza più recenti e utilizzano strumenti online per testare i propri server e confermare che stanno implementando correttamente TLS SCSV di riserva.

Evita problemi di contenuto misto

Il contenuto misto è un rischio per la sicurezza che si verifica quando una pagina web caricata tramite una connessione HTTPS sicura include risorse, come immagini, video, fogli di stile o script, che vengono caricate tramite una connessione HTTP non sicura. I browser possono bloccare questo contenuto misto o visualizzare un avviso per l'utente, che può danneggiare la percezione dell'utente della sicurezza del sito.

Ecco come evitare problemi con i contenuti misti:

1. Usa HTTPS per tutte le risorse: il modo più semplice per evitare contenuti misti è assicurarsi che tutte le risorse del tuo sito siano caricate tramite HTTPS. Ciò include immagini, script, fogli di stile, iframe, richieste AJAX e qualsiasi altra risorsa utilizzata dal tuo sito.
2. Aggiorna il codice del tuo sito: se il codice del tuo sito include URL HTTP hardcoded per le risorse, dovrai aggiornarli per utilizzare invece HTTPS. Se la risorsa è ospitata su un server che non supporta HTTPS, potrebbe essere necessario ospitare la risorsa sul proprio server o trovare una risorsa alternativa che possa essere caricata tramite HTTPS.
3. Configura il tuo server per inviare un'intestazione Content-Security-Policy: l'intestazione HTTP Content-Security-Policy (CSP) ti consente di controllare quali risorse il tuo sito può caricare. Impostando un'intestazione CSP che consenta solo risorse HTTPS, puoi assicurarti che il tuo sito non includa accidentalmente contenuti misti.

Usa caso: una rivista online garantisce che tutti i contenuti, incluse immagini e script, vengano caricati tramite HTTPS. Ciò impedisce agli aggressori di manomettere queste risorse e potenzialmente iniettare contenuti dannosi. Gli sviluppatori web della rivista esaminano regolarmente il codice del sito per assicurarsi che tutte le risorse siano caricate su HTTPS e configurano il loro server per inviare una rigorosa intestazione Content-Security-Policy. Usano anche strumenti online per scansionare il loro sito alla ricerca di problemi di contenuto misto e correggere quelli che trovano.

Utilizza l'indicazione del nome del server (SNI) per l'hosting di più siti

Indicazione nome server (SNI) è un'estensione di TLS protocollo che consente a un server di presentare più certificati sullo stesso indirizzo IP e numero di porta. Ciò è particolarmente utile per i provider di web hosting che devono ospitare più siti Web sicuri, ciascuno con il proprio certificato SSL, sullo stesso server.

Ecco come puoi utilizzare SNI:

1. Assicurati che il software del tuo server supporti SNI: Il primo passaggio consiste nell'assicurarsi che il software del server supporti SNI. La maggior parte dei server Web moderni, inclusi Apache, Nginx e IIS, supportano SNI.
2. Configura il tuo server: Il passaggio successivo consiste nel configurare il server per l'utilizzo di SNI. Ciò comporta in genere l'aggiunta di un blocco di configurazione separato per ogni sito che si desidera ospitare sul server e la specifica del file Certificato SSL da utilizzare per ogni sito. I passaggi esatti dipenderanno dal software del tuo server.
3. Testa la tua configurazione: Dopo aver configurato il tuo server, dovresti testarlo per assicurarti che stia utilizzando correttamente SNI. Puoi farlo visitando ogni sito che stai ospitando sul server e controllando che venga utilizzato il certificato SSL corretto.

Usa caso: un provider di hosting utilizza SNI per servire più siti Web dallo stesso indirizzo IP. Ciò consente loro di utilizzare in modo efficiente il proprio spazio di indirizzi IP e semplificare la configurazione di rete. Configurano il loro server per utilizzare un certificato SSL diverso per ogni sito e testano regolarmente la loro configurazione per garantire che venga utilizzato il certificato corretto per ogni sito. Ciò garantisce che ogni sito disponga di una connessione sicura e affidabile, anche se sono tutti serviti dallo stesso indirizzo IP.

Ottimizza le prestazioni con la ripresa della sessione

La ripresa della sessione è una caratteristica del TLS protocollo che consente a un client e a un server di utilizzare le stesse chiavi di crittografia in più sessioni, riducendo il sovraccarico di stabilire ogni volta una nuova connessione sicura. Ciò può migliorare significativamente le prestazioni, in particolare per le applicazioni in cui il client si disconnette e si riconnette frequentemente.

 Ecco come puoi utilizzare la ripresa della sessione:

1. Assicurati che il software del tuo server supporti la ripresa della sessione: Il primo passaggio consiste nell'assicurarsi che il software del server supporti la ripresa della sessione. La maggior parte dei server Web moderni, inclusi Apache, Nginx e IIS, supportano questa funzionalità.
2. Configura il tuo server: Il passaggio successivo consiste nel configurare il server in modo che utilizzi la ripresa della sessione. Ciò comporta in genere l'abilitazione della cache della sessione e l'impostazione di un valore di timeout per la cache. I passaggi esatti dipenderanno dal software del tuo server.
3. Testa la tua configurazione: Dopo aver configurato il tuo server, dovresti testarlo per assicurarti che stia utilizzando correttamente la ripresa della sessione. Puoi farlo stabilendo a TLS connessione al server, disconnessione e riconnessione. Se la ripresa della sessione funziona correttamente, la seconda connessione dovrebbe essere più rapida da stabilire rispetto alla prima.

Usa caso: un'app per dispositivi mobili utilizza la ripresa della sessione per mantenere connessioni veloci e sicure. Ciò è particolarmente utile quando l'app viene utilizzata in aree con copertura di rete irregolare, in quanto consente all'app di ristabilire rapidamente una connessione sicura dopo un'interruzione. Gli sviluppatori dell'app configurano il proprio server per utilizzare la ripresa della sessione e testano regolarmente la funzionalità per assicurarsi che funzioni correttamente. Ciò garantisce che l'app possa fornire un'esperienza rapida e senza interruzioni per gli utenti, anche in condizioni di rete difficili.

Garantisci la validità del certificato con la graffatura OCSP

La pinzatura OCSP (Online Certificate Status Protocol) è un metodo per migliorare le prestazioni di SSL/TLS pur mantenendo la sicurezza della connessione. Consente al server di recuperare lo stato corrente dei propri certificati dall'autorità di certificazione (CA) e quindi di fornire tale stato ai client durante il TLS stretta di mano.

Ecco come implementare la pinzatura OCSP:

1. Assicurati che il software del tuo server supporti la pinzatura OCSP: il primo passaggio consiste nell'assicurarsi che il software del server supporti la pinzatura OCSP. La maggior parte dei server Web moderni, inclusi Apache, Nginx e IIS, supportano questa funzionalità.
2. Configura il tuo server: il passaggio successivo consiste nel configurare il server in modo che utilizzi la pinzatura OCSP. Questo in genere implica l'abilitazione della funzione nel SSL/del tuo serverTLS configurazione e specificando una posizione in cui il server deve archiviare le risposte OCSP. I passaggi esatti dipenderanno dal software del tuo server.
3. Testa la tua configurazione: Dopo aver configurato il tuo server, dovresti testarlo per assicurarti che utilizzi correttamente la pinzatura OCSP. Puoi farlo stabilendo a TLS connessione al tuo server e controllando che il server includa una risposta OCSP nel file TLS stretta di mano.

Usa caso: un rivenditore online utilizza la pinzatura OCSP per verificare rapidamente lo stato del suo certificato SSL. Ciò garantisce che i clienti abbiano sempre una connessione sicura e possano fidarsi che i loro dati siano al sicuro. Il team IT del rivenditore configura il proprio server per utilizzare la pinzatura OCSP e testa regolarmente la funzionalità per assicurarsi che funzioni correttamente. Questo aiuta a mantenere la fiducia dei loro clienti e a proteggere i loro dati sensibili.

Disabilita TLS Compressione per mitigare l'attacco CRIME

TLS la compressione è una caratteristica che può migliorare le prestazioni di SSL/TLS riducendo la quantità di dati che devono essere inviati sulla rete. Tuttavia, può anche rendere la connessione vulnerabile all'attacco CRIME (Compression Ratio Info-leak Made Easy), che può consentire a un utente malintenzionato di dedurre il contenuto del traffico crittografato.

Ecco come puoi disabilitare TLS compressione: 

1. Assicurati che il software del tuo server supporti la disabilitazione TLS Compressione: Il primo passaggio consiste nell'assicurarsi che il software del server supporti la disabilitazione TLS compressione. La maggior parte dei server Web moderni, inclusi Apache, Nginx e IIS, supportano questa funzionalità.
2. Configura il tuo server: Il passaggio successivo consiste nel configurare il server in modo che sia disabilitato TLS compressione. I passaggi esatti dipenderanno dal software del tuo server. Ad esempio, in Apache, potresti aggiungere una riga come questa al tuo file di configurazione:

SSLCompressione disattivata

Questa riga dice al server di non usare la compressione per SSL/TLS connessioni.

3. Testa la tua configurazione: Dopo aver configurato il tuo server, dovresti testarlo per assicurarti che si stia disabilitando correttamente TLS compressione. Puoi farlo stabilendo a TLS connessione al tuo server e verificando che la connessione non stia utilizzando la compressione.

Usa caso: un istituto finanziario disabilita TLS compressione sui suoi server per proteggersi dall'attacco CRIME. Questo aiuta a garantire la riservatezza dei dati finanziari sensibili, come i numeri di conto e i dettagli delle transazioni. Il team IT dell'istituto configura i propri server per la disattivazione TLS compressione e testano regolarmente i server per assicurarsi che stiano implementando correttamente questa misura di sicurezza. Questo aiuta a proteggere i clienti dell'istituto ea mantenere la loro fiducia.

Realizzare TLS Session Ticket correttamente

TLS i biglietti di sessione sono una caratteristica del TLS protocollo che può migliorare le prestazioni consentendo a un client e a un server di riprendere una sessione precedente senza dover eseguire un handshake completo. Tuttavia, devono essere implementati correttamente per evitare potenziali problemi di sicurezza.

Ecco come puoi implementare correttamente TLS biglietti di sessione:

1. Assicurati che il software del tuo server supporti TLS Biglietti di sessione: Il primo passaggio consiste nell'assicurarsi che il software del server supporti TLS biglietti di sessione. La maggior parte dei server Web moderni, inclusi Apache, Nginx e IIS, supportano questa funzionalità.
2. Configura il tuo server: Il passaggio successivo consiste nel configurare il server da utilizzare TLS biglietti di sessione. Questo in genere implica l'abilitazione della funzione nel SSL/del tuo serverTLS configurazione. I passaggi esatti dipenderanno dal software del tuo server.
3. Usa chiavi di ticket di sessione univoche: Per evitare potenziali problemi di sicurezza, ogni server deve utilizzare una chiave di ticket di sessione univoca. Se utilizzi un servizio di bilanciamento del carico, dovresti configurarlo per distribuire i client in base al loro ticket di sessione, piuttosto che consentire ai client di utilizzare un ticket di sessione emesso da un server per stabilire una sessione con un altro server.
4. Ruota regolarmente le chiavi del ticket di sessione: Per migliorare ulteriormente la sicurezza, è necessario ruotare regolarmente le chiavi del ticket di sessione. Questo spesso può essere automatizzato utilizzando il software del server o un sistema di gestione delle chiavi separato.

Usa caso: una grande azienda tecnologica con più server garantisce che ogni server utilizzi una chiave di ticket di sessione univoca. Ciò impedisce a un utente malintenzionato di utilizzare un ticket di sessione da un server per impersonare un utente su un altro server. Il team IT dell'azienda configura i propri server da utilizzare TLS ticket di sessione e hanno istituito un sistema per ruotare regolarmente le chiavi del ticket di sessione. Configurano inoltre il loro sistema di bilanciamento del carico per distribuire i client in base al loro ticket di sessione, migliorando ulteriormente la sicurezza del loro sistema.

Abilita rinegoziazione sicura

La rinegoziazione sicura è una caratteristica di SSL/TLS protocolli che consentono al client o al server di richiedere un nuovo TLS stretta di mano nel mezzo di una sessione. Questo può essere utile per una serie di motivi, come l'aggiornamento delle chiavi di crittografia o la modifica del livello di crittografia. Tuttavia, se non gestito in modo sicuro, può essere sfruttato da un utente malintenzionato per inserire testo in chiaro nella comunicazione crittografata.

Ecco come abilitare la rinegoziazione sicura:

2. Assicurati che il software del tuo server supporti la rinegoziazione sicura: Il primo passaggio consiste nell'assicurarsi che il software del server supporti la rinegoziazione sicura. La maggior parte dei server Web moderni, inclusi Apache, Nginx e IIS, supportano questa funzionalità.
3. Configura il tuo server: il passaggio successivo consiste nel configurare il server in modo che utilizzi la rinegoziazione sicura. Questo in genere implica l'abilitazione della funzione nel SSL/del tuo serverTLS configurazione. I passaggi esatti dipenderanno dal software del tuo server.
4. Testa la tua configurazione: dopo aver configurato il tuo server, dovresti testarlo per assicurarti che stia usando correttamente la rinegoziazione sicura. Puoi farlo stabilendo a TLS connessione al tuo server e quindi tentando di rinegoziare la connessione.

Usa caso: una piattaforma di social media consente la rinegoziazione sicura per proteggere i dati degli utenti. Ciò impedisce a un utente malintenzionato di inserire contenuti dannosi nella comunicazione crittografata tra l'utente e il server. Il team IT della piattaforma configura i propri server per utilizzare la rinegoziazione sicura e testa regolarmente i server per assicurarsi che stiano implementando correttamente questa misura di sicurezza. Questo aiuta a proteggere gli utenti della piattaforma e a mantenere la loro fiducia.

Disabilita la rinegoziazione avviata dal client per prevenire gli attacchi DoS

La rinegoziazione avviata dal client è una funzionalità di SSL/TLS protocolli che consente al client di richiedere un nuovo TLS stretta di mano nel mezzo di una sessione. Tuttavia, se un utente malintenzionato può forzare un server a rinegoziare continuamente le sessioni, può consumare risorse eccessive e potenzialmente portare a un attacco Denial of Service (DoS).

Ecco come disabilitare la rinegoziazione avviata dal client:

1. Assicurati che il tuo software server supporti la disabilitazione della rinegoziazione avviata dal client: il primo passaggio consiste nell'assicurarsi che il software del server supporti la disattivazione della rinegoziazione avviata dal client. La maggior parte dei server Web moderni, inclusi Apache, Nginx e IIS, supportano questa funzionalità.
2. Configura il tuo server: il passaggio successivo consiste nel configurare il server per disabilitare la rinegoziazione avviata dal client. Ciò comporta in genere l'aggiunta di una direttiva all'SSL/TLS configurazione. I passaggi esatti dipenderanno dal software del tuo server.
3. Testa la tua configurazione: Dopo aver configurato il tuo server, dovresti testarlo per assicurarti che stia disabilitando correttamente la rinegoziazione avviata dal client. Puoi farlo stabilendo a TLS connessione al tuo server e quindi tentando di rinegoziare la connessione. Se il server rifiuta correttamente la richiesta di rinegoziazione, allora è configurato correttamente.

Usa caso: una piattaforma di gioco online disabilita la rinegoziazione avviata dal client per proteggersi da potenziali attacchi DoS. Questo aiuta a garantire che la piattaforma rimanga disponibile per il divertimento degli utenti, anche di fronte a potenziali attacchi. Il team IT della piattaforma configura i propri server per disabilitare la rinegoziazione avviata dal client e testa regolarmente i server per assicurarsi che stiano implementando correttamente questa misura di sicurezza. Questo aiuta a proteggere gli utenti della piattaforma e a mantenere la loro fiducia.

Stai attento alle nuove vulnerabilità

La sicurezza Web è un obiettivo in costante movimento e dovresti sempre essere alla ricerca del prossimo attacco e applicare prontamente le patch di sicurezza sul tuo server. Ciò significa leggere e rimanere in contatto con ciò che c'è all'orizzonte quando si tratta di sicurezza delle informazioni, oltre a tenersi aggiornati sugli aggiornamenti software, soprattutto quelli critici. Sito Web di SSL.com (dove stai leggendo questo in questo momento) è un'ottima fonte per rimanere aggiornato su SSL /TLS e sicurezza delle informazioni.

Ma per quanto riguarda…?

Se desideri saperne di più su uno qualsiasi degli argomenti trattati in questa guida e conoscere nuovi problemi e tecnologie man mano che si presentano, puoi iniziare navigando e cercando su SSL.com Knowledgebase, che teniamo aggiornato settimanalmente con i nuovi sviluppi nel campo di SSL /TLS ed PKI. Puoi anche sentirti libero di contattare il nostro staff di supporto in qualsiasi momento via e-mail all'indirizzo Support@SSL.com, al telefono al 1-877-SSL-Secureo facendo clic sul collegamento della chat in basso a destra in questa pagina.

Ottieni la consulenza di un esperto sui certificati SSL.
Compila il modulo per una consulenza.