Attivare HTTPS sui tuoi server

Chris Palmer
Chris Palmer
Matt Gaunt

Questa pagina fornisce indicazioni per configurare HTTPS sui tuoi server, inclusi i seguenti passaggi:

  • Creazione di una coppia di chiavi pubblica/privata RSA a 2048 bit.
  • Genera una richiesta di firma del certificato (CSR) che incorpora la tua chiave pubblica.
  • Condividere la CSR con l'autorità di certificazione (CA) per ricevere un certificato finale o una catena di certificati.
  • Installare il certificato finale in un luogo non accessibile tramite web, ad esempio /etc/ssl (Linux e Unix) o dove richiesto da IIS (Windows).

Questa sezione utilizza il programma a riga di comando openssl, fornito con la maggior parte dei sistemi Linux, BSD e Mac OS X, per generare chiavi private e pubbliche e una CSR.

Generare una coppia di chiavi pubblica/privata

Per iniziare, genera una coppia di chiavi RSA a 2048 bit. Una chiave più breve può essere violata da attacchi di brute force, 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 è il seguente:

Generating RSA private key, 2048 bit long modulus
.+++
.......................................................................................+++
e is 65537 (0x10001)

Genera una richiesta di firma del certificato

In questo passaggio, incorpori la chiave pubblica e le informazioni sulla tua organizzazione e sul tuo sito web in una richiesta di firma del certificato o CSR. Il comando openssl ti chiede i metadati richiesti.

Esegui il seguente 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 verificare la validità della CSR, 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 CSR a un'autorità di certificazione

Autorità di certificazione (CA) diverse richiedono di inviare le CSR in modi diversi. Ad esempio, possono utilizzare un modulo sul proprio sito web o inviare la RP tramite email. Alcune CA o i loro rivenditori potrebbero persino automatizzare parte o tutto il processo, inclusa, in alcuni casi, la generazione di coppie di chiavi e CSR.

Invia la CSR alla tua CA e segui le sue istruzioni per ricevere il certificato finale o la catena di certificati.

CA diverse addebitano importi diversi per il servizio di attestazione della tua chiave pubblica.

Esistono anche opzioni per mappare la chiave a più di un nome DNS, inclusi diversi nomi distinti (ad es. tutti example.com, www.example.com, example.net e www.example.net) o nomi "jolly" come *.example.com.

Copia i certificati su tutti i server di frontend in un luogo non accessibile via web come /etc/ssl (Linux e Unix) o dove richiesto da IIS (Windows).

Attivare HTTPS sui 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 configurare il server per il supporto di HTTPS.
  • Testa regolarmente il tuo sito con il test del server SSL di Qualys e assicurati di ottenere almeno una valutazione A o A+.

A questo punto, devi prendere una decisione operativa cruciale. Scegli una delle seguenti opzioni:

  • Dedica un indirizzo IP distinto a ogni nome host da cui il server web pubblica i contenuti.
  • Utilizza l'hosting virtuale basato su nome.

Se utilizzi indirizzi IP distinti per ogni nome host, puoi supportare sia HTTP sia HTTPS per tutti i client. Tuttavia, la maggior parte degli operatori di siti utilizza l'hosting virtuale basato su nome per risparmiare indirizzi IP e perché è più pratico in generale.

Se il servizio HTTPS non è ancora disponibile sui tuoi server, attivalo ora (senza reindirizzare HTTP a HTTPS. Per ulteriori informazioni, consulta Reindirizzare HTTP a HTTPS. Configura il server web in modo che utilizzi i certificati che hai acquistato e installato. Potresti trovare utile il generatore di configurazione di Mozilla.

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

Ora, e regolarmente per tutta la durata del sito, controlla la configurazione HTTPS con il test del server SSL di Qualys. Il tuo sito dovrebbe ottenere un punteggio A o A+. Tratta come bug tutto ciò che causa un voto inferiore e mantieni la tua attenzione, perché vengono sempre sviluppati nuovi attacchi contro algoritmi e protocolli.

Rendi relativi gli URL intrasito

Ora che il tuo sito è pubblicato sia su HTTP che su HTTPS, tutto dovrebbe funzionare nel modo più semplice possibile, indipendentemente dal protocollo. Un fattore importante è l'utilizzo di URL relativi per i link all'interno del sito.

Assicurati che gli URL intrasito e esterni non dipendano da un protocollo specifico. Utilizza percorsi relativi o ometti il protocollo come in //example.com/something.js.

La pubblicazione di 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 alcuni browser rifiutano di caricare o eseguire le risorse HTTP, il che ne impedisce il funzionamento. Tuttavia, puoi includere tranquillamente risorse HTTPS in una pagina HTTP. Per ulteriori indicazioni sulla risoluzione di questi problemi, consulta Correggere i contenuti misti.

Anche il passaggio a link basati su HTTP che rimandano ad altre pagine del tuo sito può comportare il downgrade dell'esperienza utente da HTTPS a HTTP. Per risolvere il problema, rendi gli URL intrasito il più relativi possibile, rendendoli relativi al protocollo (senza protocollo, che iniziano con //example.com) o all'host (che iniziano solo con il percorso, come /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 URL intrasito 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 gli URL intrasito relativi al 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>
Se possibile, utilizza URL HTTPS per i link ad altri siti.

Aggiorna i link con uno script, non manualmente, per evitare 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 tuo sito sono costituiti solo da file semplici, testa lo script su una copia di sviluppo dei file. Invia le modifiche in produzione solo dopo che sono state approvate dal QA, come di consueto. Puoi utilizzare lo script di Bram van Damme o un altro simile per rilevare i contenuti misti nel tuo sito.

Quando inserisci link ad altri siti (anziché includerne le risorse), non modificare il protocollo. Non hai alcun controllo sul funzionamento di questi siti.

Per semplificare la migrazione per i siti di grandi dimensioni, consigliamo gli URL relativi al protocollo. Se non sai ancora con certezza se puoi implementare completamente HTTPS, forzare il tuo sito a utilizzare HTTPS per tutte le risorse secondarie può avere un effetto contrario. È probabile che ci sia un periodo di tempo in cui HTTPS sia nuovo e strano per te, ma il sito HTTP deve comunque funzionare come sempre. Nel tempo, completerai la migrazione e bloccherai HTTPS (consulta le due sezioni successive).

Se il tuo sito dipende da script, immagini o altre risorse pubblicate da terze parti, come una CDN o jquery.com, hai due opzioni:

  • Utilizza URL relativi al protocollo per queste risorse. Se la terza parte non supporta HTTPS, chiedile di farlo. La maggior parte lo fa già, incluso jquery.com.
  • Pubblica le risorse da un server che controlli, che offre sia HTTP che HTTPS. Spesso è comunque una buona idea, perché hai un miglior controllo sull'aspetto, sulle prestazioni e sulla sicurezza del tuo sito e non devi fare affidamento su terze parti per mantenerlo al sicuro.

Reindirizza HTTP a HTTPS

Per indicare ai motori di ricerca di utilizzare HTTPS per accedere al tuo sito, inserisci un link canonico all'inizio di ogni pagina utilizzando i tag <link rel="canonical" href="https://…"/>.

Attivare la crittografia di trasporto rigorosa e i cookie sicuri

A questo punto, puoi "bloccare " l'utilizzo di HTTPS:

  • Utilizza HTTP Strict Transport Security (HSTS) per evitare il costo del reindirizzamento 301.
  • Imposta sempre l'indicatore Sicuro sui cookie.

Innanzitutto, utilizza Strict Transport Security per indicare ai client che devono sempre connettersi al tuo server utilizzando HTTPS, anche quando seguono un riferimento http://. In questo modo, vengono sconfitti attacchi come la rimozione di SSL e viene evitato il costo di andata e ritorno dell'elemento 301 redirect che abbiamo attivato in Reindirizza HTTP a HTTPS.

Per attivare HSTS, imposta l'intestazione Strict-Transport-Security. La pagina HSTS di OWASP contiene link alle istruzioni per vari tipi di software di server.

La maggior parte dei server web offre una funzionalità 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 venisse esposto in testo normale, la garanzia di sicurezza per l'intera sessione viene distrutta, anche se hai eseguito tutti gli altri passaggi correttamente.

Per evitare ciò, modifica l'app web in modo da impostare sempre l'indicatore Sicuro sui cookie che imposta. Questa pagina di OWASP spiega come impostare il flag Secure in diversi framework per app. Ogni framework per app ha un modo per impostare il flag.

La maggior parte dei server web offre una semplice funzionalità 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 positivo della qualità della ricerca. Google pubblica anche una guida su come trasferire, spostare o eseguire la migrazione del tuo sito mantenendone il ranking nei risultati di ricerca. Bing pubblica anche linee guida per i webmaster.

Prestazioni

Quando i livelli di contenuti e applicazioni sono ben ottimizzati (consulta i libri di Steve Souders per ricevere consigli), i problemi di prestazioni TLS rimanenti sono generalmente ridotti rispetto al costo complessivo dell'applicazione. Puoi anche ridurre e ammortizzare questi costi. Per consigli sull'ottimizzazione di TLS, consulta High Performance Browser Networking di Ilya Grigorik, nonché OpenSSL Cookbook e Bulletproof SSL And TLS di Ivan Ristic.

In alcuni casi, TLS può migliorare le prestazioni, soprattutto perché consente di utilizzare HTTP/2. Per ulteriori informazioni, consulta il discorso di Chris Palmer sulle prestazioni di HTTPS e HTTP/2 al Chrome Dev Summit 2014.

Intestazioni referrer

Quando gli utenti seguono i link dal tuo sito HTTPS ad altri siti HTTP, gli agenti utente non inviano l'intestazione Referer. Se si tratta di un problema, esistono diversi modi per risolverlo:

  • Gli altri siti devono eseguire la migrazione a HTTPS. Se i siti di riferimento completano la sezione Attivare HTTPS sui server di questa guida, puoi modificare i link nel tuo sito in modo che rimandino ai loro da http:// a https:// o utilizzare link relativi al protocollo.
  • Per risolvere una serie di problemi con le intestazioni referrer, utilizza il nuovo standard per i criteri relativi al referrer.

Entrate pubblicitarie

Gli operatori di siti che monetizzano il proprio sito mostrando annunci vogliono assicurarsi che la migrazione a HTTPS non riduca le impressioni degli annunci. Tuttavia, a causa di problemi di sicurezza relativi ai contenuti misti, un <iframe> HTTP non funziona in una pagina HTTPS. Finché gli inserzionisti non pubblicano 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 a HTTPS, gli inserzionisti hanno poca motivazione a pubblicare tramite HTTPS.

Puoi iniziare a uscire da questa situazione di stallo utilizzando gli inserzionisti che offrono servizi pubblicitari tramite HTTPS e chiedendo agli inserzionisti che non utilizzano affatto HTTPS di almeno renderlo un'opzione. Potresti dover posticipare il completamento della funzionalità Rendi relativi gli URL intrasite finché un numero sufficiente di inserzionisti non interagisce correttamente.