Questa pagina fornisce indicazioni per la configurazione di HTTPS sui tuoi server, inclusi i seguenti passaggi:
- Creazione di una coppia di chiavi pubblica/privata RSA a 2048 bit.
- Generazione di una richiesta di firma del certificato (CSR) che incorpora la tua chiave pubblica.
- Condividi la tua richiesta di firma del certificato con l'autorità di certificazione (CA) per ricevere un certificato finale o una catena di certificati.
- Installa il certificato finale in una posizione non accessibile sul web come
/etc/ssl(Linux e Unix) o ovunque sia richiesto da IIS (Windows).
Genera chiavi e richieste di firma di certificati
In questa sezione viene utilizzato il programma a riga di comando opensl fornito dalla maggior parte dei sistemi Linux, BSD e Mac OS X, per generare chiavi pubbliche e private e una CSR.
Genera una coppia di chiavi pubblica/privata
Per iniziare, genera una coppia di chiavi RSA a 2048 bit. Una chiave più breve può essere spezzata da attacchi di ipotesi di forza bruta, mentre le chiavi più lunghe utilizzano risorse non necessarie.
Utilizza il seguente comando per generare una coppia di chiavi RSA:
openssl genrsa -out www.example.com.key 2048
L'output sarà il seguente:
Generating RSA private key, 2048 bit long modulus
.+++
.......................................................................................+++
e is 65537 (0x10001)
Genera una richiesta di firma del certificato
In questo passaggio, incorpora la chiave pubblica e le informazioni sulla tua organizzazione e sul tuo sito web in una richiesta di firma del certificato o in una CSR. Il comando openssl
ti chiede i metadati richiesti.
Esegui questo comando:
openssl req -new -sha256 -key www.example.com.key -out www.example.com.csr
Restituisce quanto segue:
You are about to be asked to enter information that will be incorporated
into your certificate request
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:CA
State or Province Name (full name) [Some-State]:California
Locality Name (for example, city) []:Mountain View
Organization Name (for example, company) [Internet Widgits Pty Ltd]:Example, Inc.
Organizational Unit Name (for example, section) []:Webmaster Help Center Example
Team
Common Name (e.g. server FQDN or YOUR name) []:www.example.com
Email Address []:webmaster@example.com
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Per garantire la validità della richiesta di firma del certificato, esegui questo comando:
openssl req -text -in www.example.com.csr -noout
La risposta dovrebbe essere simile alla seguente:
Certificate Request:
Data:
Version: 0 (0x0)
Subject: C=CA, ST=California, L=Mountain View, O=Google, Inc.,
OU=Webmaster Help Center Example Team,
CN=www.example.com/emailAddress=webmaster@example.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:ad:fc:58:e0:da:f2:0b:73:51:93:29:a5:d3:9e:
f8:f1:14:13:64:cc:e0:bc:be:26:5d:04:e1:58:dc:
...
Exponent: 65537 (0x10001)
Attributes:
a0:00
Signature Algorithm: sha256WithRSAEncryption
5f:05:f3:71:d5:f7:b7:b6:dc:17:cc:88:03:b8:87:29:f6:87:
2f:7f:00:49:08:0a:20:41:0b:70:03:04:7d:94:af:69:3d:f4:
...
Invia la richiesta di firma del cliente a un'autorità di certificazione
Le diverse autorità di certificazione (CA) esigono di inviare loro i CSR in modi diversi. tra cui l'utilizzo di un modulo sul sito web o l'invio del CSR via email. Alcune CA, o i relativi rivenditori, potrebbero persino automatizzare parte o tutto il processo, inclusa, in alcuni casi, la coppia di chiavi e la generazione di CSR.
Invia la richiesta di assistenza clienti alla tua CA e segui le relative istruzioni per ricevere il certificato finale o la catena di certificati.
CA diverse addebitano importi diversi per il servizio di garanzia per la chiave pubblica.
Esistono anche opzioni per mappare la chiave a più nomi DNS, inclusi diversi nomi distinti (ad es. tutti example.com, www.example.com, example.net e www.example.net) o nomi di "caratteri jolly" come *.example.com.
Copia i certificati su tutti i tuoi server front-end, in una posizione non accessibile dal web come /etc/ssl (Linux e Unix) o in qualsiasi altro luogo in cui IIS (Windows) lo richieda.
Attivare HTTPS sui tuoi server
L'attivazione di HTTPS sui tuoi server è un passaggio fondamentale per garantire la sicurezza delle tue pagine web.
- Utilizza lo strumento di configurazione del server di Mozilla per impostare il server per il supporto HTTPS.
- Testa regolarmente il tuo sito con il test del server SSL di Qualys e assicurati di ottenere almeno un A o A+.
A questo punto, devi prendere una decisione operativa cruciale. Scegli una delle seguenti opzioni:
- Dedica un indirizzo IP distinto a ciascun nome host da cui il server web gestisce i contenuti.
- Utilizzare l'hosting virtuale basato sul nome.
Se utilizzi indirizzi IP distinti per ogni nome host, puoi supportare sia HTTP che HTTPS per tutti i client. Tuttavia, la maggior parte degli operatori dei siti utilizza l'hosting virtuale basato sul nome per conservare gli indirizzi IP e perché è più comodo in generale.
Se non disponi ancora del servizio HTTPS sui tuoi server, abilitalo subito (senza reindirizzare HTTP a HTTPS. Per ulteriori informazioni, consulta la sezione Reindirizzamento da HTTP a HTTPS. Configura il tuo server web per l'utilizzo dei certificati acquistati e installati. Potresti trovare utile il generatore di configurazione di Mozilla.
Se hai molti nomi host o sottodomini, ognuno deve utilizzare il certificato corretto.
Ora, e con regolarità, per tutta la durata del tuo sito, controlla la configurazione HTTPS con il Qualys' SSL Server Test. Il tuo sito dovrebbe ottenere un punteggio A o A+. Tratta come bug tutto ciò che causi un punteggio inferiore e sii diligente, perché vengono sviluppati costantemente nuovi attacchi contro algoritmi e protocolli.
Rendi relativi gli URL intrasito
Ora che gestisci il tuo sito sia su HTTP che su HTTPS, le cose devono funzionare nel modo più agevole possibile, indipendentemente dal protocollo. Un fattore importante è l'uso di URL relativi per i link intrasito.
Assicurati che gli URL intrasito e gli URL esterni non dipendano da un protocollo specifico.
Utilizza percorsi relativi o escludi il protocollo come in //example.com/something.js.
Pubblicare una pagina contenente risorse HTTP utilizzando HTTPS può causare problemi. Quando un browser rileva una pagina altrimenti sicura che utilizza risorse non sicure, avvisa gli utenti che la pagina non è completamente sicura e che alcuni browser si rifiutano di caricare o eseguire le risorse HTTP, causando un errore nella pagina. Tuttavia, puoi includere in sicurezza le risorse HTTPS in una pagina HTTP. Per ulteriori indicazioni sulla risoluzione di questi problemi, consulta la sezione Correggere i contenuti misti.
Seguendo i link basati su HTTP che rimandano ad altre pagine del tuo sito, puoi anche eseguire il downgrade dell'esperienza utente da HTTPS a HTTP. Per risolvere il problema, rendi gli URL tra siti il più relativi possibile, rendendoli relativi a protocollo (senza un protocollo, a partire da //example.com) o relativi all'host (a partire dal solo percorso, ad esempio /jquery.js).
<h1>Welcome To Example.com</h1> <script src="/jquery.js"></script> <link rel="stylesheet" href="/assets/style.css"/> <img src="/images/logo.png"/>; <p>A <a href="/2014/12/24">new post on cats!</a></p>Utilizza gli URL all'interno del sito relativi.
<h1>Welcome To Example.com</h1> <script src="//example.com/jquery.js"></script> <link rel="stylesheet" href="//assets.example.com/style.css"/> <img src="//img.example.com/logo.png"/>; <p>A <a href="//example.com/2014/12/24/">new post on cats!</a></p>In alternativa, utilizza URL intrasito relativi a protocollo.
<h1>Welcome To Example.com</h1> <script src="/jquery.js"></script> <link rel="stylesheet" href="/assets/style.css"/> <img src="/images/logo.png"/>; <p>A <a href="/2014/12/24">new post on cats!</a></p> <p>Check out this <a href="https://foo.com/"><b>other cool site.</b></a></p>Se possibile, utilizza URL HTTPS per i link ad altri siti.
Aggiorna i link con uno script e non manualmente, per evitare di commettere errori. Se i contenuti del tuo sito si trovano in un database, testa lo script su una copia di sviluppo del database. Se i contenuti del sito sono costituiti solo da file semplici, verifica lo script su una copia di sviluppo dei file. Invia le modifiche in produzione solo dopo che hanno superato il QA, come di consueto. Per rilevare contenuti misti nel sito, puoi utilizzare lo script di Bram van Damme o un testo simile.
Non modificare il protocollo quando crei link ad altri siti (anziché includere risorse che ne derivano). Non hai il controllo sul funzionamento di questi siti.
Per semplificare la migrazione per i siti di grandi dimensioni, ti consigliamo di utilizzare URL relativi a protocollo. Se non hai la certezza di poter eseguire il deployment di HTTPS completamente, forzare il sito a utilizzare HTTPS per tutte le risorse secondarie può compromettere il sistema. È probabile che ci sia un periodo in cui HTTPS è nuovo e strano per te e il sito HTTP deve continuare a funzionare allo stesso modo. Nel tempo, potrai completare la migrazione e bloccare in HTTPS (vedi le due sezioni successive).
Se il tuo sito dipende da script, immagini o altre risorse fornite da una terza parte, ad esempio una CDN o jquery.com, hai due opzioni:
- Utilizza URL relativi a protocollo per queste risorse. Se la terza parte non pubblica HTTPS, chiedile di farlo. Nella maggior parte dei casi, è già possibile, incluso jquery.com.
- Gestisci le risorse da un server controllato da te, che offre sia HTTP che HTTPS. Spesso questa è una buona idea, perché in questo modo puoi avere un maggiore controllo sull'aspetto, sulle prestazioni e sulla sicurezza del tuo sito e non devi fidarti di una terza parte per mantenerlo sicuro.
Reindirizzamento da HTTP a HTTPS
Per indicare ai motori di ricerca di utilizzare HTTPS per accedere al tuo sito, inserisci un link canonico nella parte superiore di ogni pagina utilizzando i tag <link rel="canonical" href="https://…"/>.
Attiva Strict Transport Security e proteggi i cookie
A questo punto, è tutto pronto per "bloccare " l'utilizzo di HTTPS:
- Utilizza HTTP Strict Transport Security (HSTS) per evitare il costo del reindirizzamento 301.
- Imposta sempre il flag di sicurezza sui cookie.
In primo luogo, utilizza Strict Transport Security per comunicare ai client che devono sempre connettersi al tuo server utilizzando HTTPS, anche quando seguono un riferimento http://. In questo modo sconfigge attacchi come
SSL Stripping
ed evita il costo di andata e ritorno dell'301 redirect che abbiamo abilitato in
Reindirizzamento HTTP a HTTPS.
Per attivare HSTS, imposta l'intestazione Strict-Transport-Security. La pagina HSTS di OWASP contiene link a istruzioni per vari tipi di software server.
La maggior parte dei server web offre una capacità simile per aggiungere intestazioni personalizzate.
È inoltre importante assicurarsi che i client non inviino mai cookie (ad esempio per l'autenticazione o le preferenze del sito) tramite HTTP. Ad esempio, se il cookie di autenticazione di un utente viene mostrato sotto forma di testo normale, la tua garanzia di sicurezza per l'intera sessione viene eliminata, anche se hai eseguito tutto il resto in modo corretto.
Per evitare che questo accada, modifica l'app web in modo che imposti sempre il flag di sicurezza sui cookie che imposta. Questa pagina OWASP spiega come impostare il flag di sicurezza in diversi framework di app. Ogni framework appl consente di impostare il flag.
La maggior parte dei server web offre una semplice funzione di reindirizzamento. Utilizza 301 (Moved Permanently) per indicare ai motori di ricerca e ai browser che la versione HTTPS è canonica e reindirizza gli utenti alla versione HTTPS del tuo sito da HTTP.
Posizionamento nella ricerca
Google utilizza HTTPS come indicatore di qualità della ricerca positiva. Google pubblica inoltre una guida su come trasferire, spostare o migrare il sito mantenendo al contempo il ranking nei risultati di ricerca. Bing pubblica inoltre linee guida per i webmaster.
Esibizione
Quando i livelli dei contenuti e dell'applicazione sono ottimizzati (per consigli, consulta i libri di Steve Souders), le restanti preoccupazioni relative alle prestazioni TLS sono generalmente ridotte rispetto al costo complessivo dell'applicazione. Puoi anche ridurre e ammortizzare questi costi. Per consigli sull'ottimizzazione TLS, consulta le pagine High Performance Browser Networking di Ilya Grigorik, nonché il OpenSSL Cookbook di Ivan Ristic e Bulletproof SSL and TLS.
In alcuni casi, TLS può migliorare le prestazioni, principalmente grazie alla possibilità di utilizzare HTTP/2. Per ulteriori informazioni, leggi il discorso di Chris Palmer sulle prestazioni di HTTPS e HTTP/2 al Chrome Dev Summit 2014.
Intestazioni del referrer
Quando gli utenti seguono i link dal tuo sito HTTPS ad altri siti HTTP, gli user agent non inviano l'intestazione Referer. Se questo è un problema, ci sono diversi modi per risolverlo:
- Gli altri siti dovrebbero eseguire la migrazione al protocollo HTTPS. Se i siti referenti completano la sezione
Attiva HTTPS sui tuoi server di
questa guida, puoi modificare i link presenti nel tuo sito e rimandare al loro sito da
http://ahttps://o utilizzare link relativi a protocollo. - Per risolvere una serie di problemi con le intestazioni referrer, utilizza il nuovo standard dei criteri referrer.
Entrate pubblicitarie
Gli operatori del sito che monetizzano il loro sito mostrando annunci vogliono assicurarsi che la migrazione a HTTPS non riduca le impressioni degli annunci. Tuttavia, a causa di problemi di sicurezza con contenuti misti, un <iframe> HTTP non funziona su una pagina HTTPS.
Finché gli inserzionisti non pubblicano annunci tramite HTTPS, gli operatori dei siti non possono eseguire la migrazione a HTTPS
senza perdere le entrate pubblicitarie. Tuttavia, finché gli operatori dei siti non eseguono la migrazione ad HTTPS,
gli inserzionisti non saranno motivati a pubblicare HTTPS.
Puoi avviare il processo per risolvere questo stallo utilizzando gli inserzionisti che offrono servizi pubblicitari tramite HTTPS e chiedendo agli inserzionisti che non utilizzano il protocollo HTTPS di farlo almeno come un'opzione. Potrebbe essere necessario rinviare il completamento di Rendi relativi gli URL IntraSite fino a quando un numero sufficiente di inserzionisti interapera correttamente.