Attivazione di HTTPS sui tuoi server

Chris Palmer
Chris Palmer
Matt Gaunt

Passaggi descritti in questo articolo

  1. Crea una coppia di chiavi pubblica/privata RSA a 2048 bit.
  2. Genera una richiesta di firma del certificato (CSR) che incorpora la tua chiave pubblica.
  3. Condividi la richiesta di firma del certificato con l'autorità di certificazione (CA) per ricevere un certificato finale o una catena di certificati.
  4. Installa il certificato finale in una posizione non accessibile sul web come /etc/ssl (Linux e Unix) o ovunque sia richiesto da IIS (Windows).

Generazione di chiavi e richieste di firma dei 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/private e un CSR.

Genera una coppia di chiavi pubblica/privata

Iniziamo generando una coppia di chiavi RSA a 2048 bit. Una chiave più piccola, ad esempio 1024 bit, non è sufficientemente resistente agli attacchi di ipotesi di forza bruta. Una chiave più grande, ad esempio 4096 bit, è overkill. Nel tempo, le dimensioni delle chiavi aumentano a mano a mano che l'elaborazione dei computer diminuisce. 2048 è attualmente l'ideale.

Il comando per generare la 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 chiede in modo interattivo 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

E 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

Diverse autorità di certificazione (CA) richiedono metodi diversi per l'invio delle richieste di assistenza clienti. I metodi possono includere l'utilizzo di un modulo sul sito web, l'invio del CSR via email o altro. Alcune CA (o i relativi rivenditori) possono anche automatizzare parte o tutto il processo (inclusa, in alcuni casi, la coppia di chiavi e la generazione di CSR).

Invia la richiesta di firma del certificato (CSR) 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.

Ad esempio, un'autorità canadese al momento offre i seguenti prezzi:

  • Standard: 16 $/anno, valido per example.com e www.example.com.
  • Carattere jolly: $150/anno, valido per example.com e *.example.com.

A questi prezzi, i certificati con caratteri jolly sono economici se hai più di nove sottodomini, altrimenti puoi semplicemente acquistare uno o più certificati con nome singolo. Se, ad esempio, hai più di cinque sottodomini, potresti trovare più pratico un certificato con caratteri jolly quando decidi di abilitare HTTPS sui tuoi server.

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 facilmente supportare sia HTTP che HTTPS per tutti i client.

Tuttavia, la maggior parte degli operatori di siti utilizza l'hosting virtuale basato sul nome per conservare gli indirizzi IP e perché è più comodo in generale. Il problema riscontrato con IE su Windows XP e Android precedenti alla versione 2.3 è che non comprendono la funzionalità Server Name Indication (SNI), fondamentale per l'hosting virtuale basato sui nomi HTTPS.

Un giorno, si spera a breve, i client che non supportano SNI verranno sostituiti con software moderni. Monitora la stringa dello user agent nei log delle richieste per sapere quando è stata eseguita la migrazione di una quantità sufficiente della tua popolazione di utenti a un software moderno. Puoi decidere quale sia la soglia, magari inferiore al 5% o inferiore all'1%.

Se non disponi del servizio HTTPS sui tuoi server, abilitalo subito (senza reindirizzamento HTTP a HTTPS; vedi sotto). Configura il tuo server web per utilizzare i certificati che hai acquistato e installato. Potresti trovare utile il pratico generatore di configurazione di Mozilla.

Se hai molti nomi host o sottodomini, ognuno deve utilizzare il certificato corretto.

Ora, e per tutta la durata del tuo sito, controlla la tua configurazione HTTPS con il pratico server SSL di Qualys. Il tuo sito dovrebbe ottenere un punteggio positivo o negativo; considera tutto ciò che causa un punteggio inferiore come un bug. (la A di oggi è la B di domani, perché gli attacchi contro algoritmi e protocolli sono sempre migliori).

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 siano indipendenti dal protocollo, ovvero di utilizzare percorsi relativi o di escludere il protocollo come //example.com/something.js.

Si verifica un problema quando pubblichi una pagina tramite HTTPS che include risorse HTTP, noti come contenuti misti. I browser avvisano gli utenti che la piena potenza del protocollo HTTPS è stata persa. Infatti, nel caso di contenuti misti attivi (script, plug-in, CSS, iframe), spesso i browser non caricano né eseguono i contenuti, causando un errore di pagina. Ricorda che è perfettamente corretto includere risorse HTTPS in una pagina HTTP.

Inoltre, quando inserisci link ad altre pagine del tuo sito, gli utenti potrebbero eseguire il downgrade da HTTPS a HTTP.

Questi problemi si verificano quando le pagine includono URL intrasito completi che utilizzano lo schema http://.

Cosa non fare
<h1>Welcome To Example.com</h1>
<script src="http://example.com/jquery.js"></script>
<link rel="stylesheet" href="http://assets.example.com/style.css"/>
<img src="http://img.example.com/logo.png"/>;
<p>A <a href="http://example.com/2014/12/24/">new post on cats!</a></p>
Evita di utilizzare URL intrasito completi.

In altre parole, rendi il più possibile relativi gli URL intrasito: relativi a protocollo (senza protocollo, a partire da //example.com) o relativi all'host (a partire dal solo percorso, ad esempio /jquery.js).

Cosa fare
<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.
Cosa fare
<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.
Cosa fare
<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>
Utilizza URL HTTPS per gli URL intersito (ove possibile).

Devi usare un copione, non farlo manualmente. Se i contenuti del tuo sito si trovano in un database, testa lo script su una copia di sviluppo del tuo database. Se i contenuti del sito sono costituiti da file semplici, verifica lo script su una copia di sviluppo dei file. Esegui il push delle modifiche in produzione solo dopo che hanno superato il QA, come di consueto. Puoi utilizzare lo script di Bram van Damme o qualcosa di simile per rilevare contenuti misti nel tuo sito.

Quando esegui il collegamento ad altri siti (anziché includere risorse che ne derivano), non modificare il protocollo poiché 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 ancora il deployment di HTTPS, obbligare il tuo sito a utilizzare HTTPS per tutte le risorse secondarie potrebbe compromettere il rendimento. È probabile che esista un periodo in cui HTTPS è nuovo e strano per te e il sito HTTP deve continuare a funzionare allo stesso modo. Nel tempo, completerai la migrazione e il blocco 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. Inoltre, non devi fidarti di una terza parte, il che è sempre positivo.

Reindirizzamento da HTTP a HTTPS

Devi inserire un link canonico nell'intestazione della pagina per indicare ai motori di ricerca che HTTPS è il modo migliore per raggiungere il tuo sito.

Imposta i tag <link rel="canonical" href="https://…"/> nelle pagine. Questo aiuta i motori di ricerca a determinare il modo migliore per raggiungere il tuo sito.

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 tramite HTTPS, anche quando seguono un riferimento http://. Questo metodo consente di sconfiggere attacchi come SSL Stripping e di evitare il costo di andata e ritorno dell'301 redirect che abbiamo abilitato in Reindirizzamento da HTTP a HTTPS.

Attiva HTTP Strict Transport Security (HSTS) impostando l'intestazione Strict-Transport-Security. La pagina HSTS di OWASP contiene link alle istruzioni per vari software per 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 dovesse essere esposto in testo normale, la garanzia di sicurezza dell'intera sessione verrebbe eliminata, anche se hai eseguito tutto il resto in modo corretto.

Pertanto, modifica la tua applicazione web in modo che imposti sempre il flag di sicurezza per i cookie che imposta. Questa pagina OWASP spiega come impostare il flag sicuro in diversi framework di applicazioni. Ogni framework dell'applicazione ha un modo per 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 tuo sito mantenendone al contempo il ranking nella ricerca. Bing pubblica inoltre linee guida per i webmaster.

Esibizione

Quando i livelli dei contenuti e dell'applicazione sono ottimizzati (per consigli sui libri di Steve Souders), le restanti preoccupazioni relative alle prestazioni TLS sono generalmente ridotte rispetto al costo complessivo dell'applicazione. Inoltre, puoi ridurre e ammortizzare questi costi. Per ottimi consigli sull'ottimizzazione TLS e in generale, consulta High Performance Browser Networking di Ilya Grigorik. Vedi anche 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. Chris Palmer ha tenuto un discorso sulle prestazioni relative a 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 sono in grado di completare la sezione Attivare HTTPS sui tuoi server di questa guida, puoi modificare i link del tuo sito e passare al loro sito da http:// a https:// oppure utilizzare link relativi a protocollo.
  • Per risolvere una serie di problemi con le intestazioni referrer, utilizza il nuovo standard dei criteri referrer.

Poiché i motori di ricerca stanno eseguendo la migrazione al protocollo HTTPS, in futuro è probabile che vengano visualizzate altre intestazioni Referer quando esegui la migrazione ad HTTPS.

Entrate pubblicitarie

Gli operatori del sito che monetizzano il loro sito tramite la visualizzazione di annunci vogliono assicurarsi che la migrazione a HTTPS non riduca le impressioni degli annunci. Tuttavia, a causa di problemi di sicurezza dei contenuti misti, un <iframe> HTTP non funziona in una pagina HTTPS. Esiste un complesso problema di azione collettiva: 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 del sito non eseguono la migrazione ad HTTPS, gli inserzionisti non sono motivati a pubblicare HTTPS.

Gli inserzionisti devono offrire almeno un servizio pubblicitario tramite HTTPS (ad esempio, compilando la sezione "Attiva HTTPS sui tuoi server" in questa pagina). Molti già lo fanno. Dovresti chiedere almeno agli inserzionisti che non pubblicano HTTPS. Potrebbe essere opportuno rinviare il completamento della procedura Rendi relativi gli URL IntraSite finché un numero sufficiente di inserzionisti non interopererà correttamente.