Questa pagina è stata tradotta dall'API Cloud Translation.

Attivare HTTPS sui tuoi server

Chris Palmer

Matt Gaunt

Questa pagina fornisce indicazioni per configurare il protocollo HTTPS sui tuoi server, tra cui il seguenti passaggi:

Creazione di una coppia di chiavi pubbliche/private RSA a 2048 bit in corso...
È in corso la generazione di una richiesta di firma del certificato (CSR) che incorpora la chiave pubblica.
Condivisione della richiesta di firma del certificato con l'autorità di certificazione (CA) per ricevere un o una catena di certificati.
Installare il certificato finale in una posizione non accessibile dal web, ad esempio /etc/ssl (Linux e Unix) o ovunque sia richiesto da IIS (Windows).

Genera chiavi e richieste di firma dei certificati

Questa sezione utilizza il programma a riga di comando Opensl, che include Sistemi Linux, BSD e Mac OS X per generare chiavi private e pubbliche 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 mediante attacchi di forza bruta e chiavi più lunghe usano risorse non necessarie.

Utilizza il seguente comando per generare una coppia di chiavi RSA:

openssl genrsa -out www.example.com.key 2048

Viene restituito il seguente output:

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 il tuo sito web in una richiesta di firma del certificato o in una richiesta di firma del certificato. 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:
         ...

Inviare la richiesta di firma del certificato a un'autorità di certificazione

Le diverse autorità di certificazione (CA) richiedono di inviare loro le tue CSR in vari modi. Ad esempio, puoi utilizzare un modulo sul sito web o inviare il CSR via email. Alcune CA, o i relativi rivenditori, potrebbero automatizzare del tutto o in parte del processo, inclusa, in alcuni casi, la coppia di chiavi e la generazione di CSR.

Invia il CSR alla tua CA e segui le relative istruzioni per ricevere il documento finale di certificati o catena di certificati.

CA diverse addebitano somme di denaro diverse per il servizio di coupon per la chiave pubblica.

Esistono anche opzioni per mappare la chiave a più di un nome DNS, tra cui: diversi nomi distinti (ad esempio, tutti example.com, www.example.com, example.net, e www.example.net) o "caratteri jolly" quali *.example.com.

Copia i certificati su tutti i server front-end in una posizione non accessibile dal web come /etc/ssl (Linux e Unix) o ovunque IIS (Windows) richieda che li rappresentano.

Attivare l'HTTPS sui tuoi server

L'attivazione di HTTPS sui tuoi server è un passaggio fondamentale per garantire la sicurezza nelle tue pagine web.

Utilizza lo strumento di configurazione del server di Mozilla per impostare il server per HTTPS assistenza in tempo reale.
Testa regolarmente il tuo sito con il Qualys Verifica del server SSL e verifica ottieni almeno un A o A+.

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

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

Se utilizzi indirizzi IP diversi per ogni nome host, puoi supportare sia HTTP che HTTPS per tutti i client. Tuttavia, la maggior parte degli operatori di siti utilizza l'hosting virtuale per conservare gli indirizzi IP e perché è più conveniente in generale.

Se sui tuoi server non è ancora disponibile il servizio HTTPS, abilitalo ora (senza reindirizzamento da HTTP a HTTPS. Vedi Reindirizzare da HTTP a HTTPS per ulteriori informazioni). Configura il tuo server web per utilizzare i certificati che acquistato e installato. Potresti trovare il file di configurazione di Mozilla generatore utile.

Se hai molti nomi host o sottodomini, ciascuno deve utilizzare il nome certificato.

Ora, e regolarmente per tutta la durata del tuo sito, controlla il tuo protocollo HTTPS configurazione con Qualys' Test del server SSL. Il tuo sito dovrebbe assegnare un punteggio A o A+. Tratta tutto ciò che causa un voto inferiore come un bug e rimanere diligenti, perché i nuovi attacchi contro algoritmi e protocolli sono sempre in fase di sviluppo.

Rendi relativi gli URL intrasito

Ora che la pubblicazione del tuo sito viene pubblicata sia su HTTP che su HTTPS, è necessario che le cose funzionino nel modo più semplice possibile indipendentemente dal protocollo. Un fattore importante è l'utilizzo 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.

Pubblicazione di una pagina contenente risorse HTTP utilizzando HTTPS possono causare problemi. Quando un browser rileva altrimenti una pagina sicura con risorse non sicure, avvisa gli utenti che la pagina non è completamente sicuro e alcuni browser si rifiutano di caricare o eseguire l'HTTP che spezza la pagina. Tuttavia, puoi includere tranquillamente il protocollo HTTPS in una pagina HTTP. Per ulteriori indicazioni su come risolvere questi problemi, consulta Correzione dei contenuti misti.

Seguendo link basati su HTTP ad altre pagine del sito puoi anche eseguire il downgrade della un'esperienza utente da HTTPS a HTTP. Per risolvere il problema, imposta gli URL intrasiti come relativi il più possibile, rendendoli relativi al protocollo (senza un che inizia con //example.com) o relativo all'host (che inizia con nel 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 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 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>

Se possibile, utilizza URL HTTPS per i link ad altri siti.

Aggiorna i link con uno script, non manualmente, per evitare di commettere errori. Se le tue del sito si trovino in un database, testa lo script su una copia di sviluppo del per configurare un database. Se i contenuti del tuo sito sono costituiti solo da file semplici, testa lo script su una copia di sviluppo dei file. Esegui il push delle modifiche in produzione solo dopo le modifiche superano il QA, come di consueto. Puoi usare lo script di Bram van Damme o qualcosa di simile per rilevare contenuti misti nel tuo sito.

Quando si creano link ad altri siti (invece di includere risorse provenienti da questi siti), non cambino il protocollo. Non hai il controllo sul funzionamento di questi siti.

Per semplificare la migrazione per siti di grandi dimensioni, consigliamo di utilizzare URL relativi al protocollo. Se non sai con certezza se puoi ancora eseguire il deployment di HTTPS, forzando il tuo sito a utilizza HTTPS per tutte le risorse secondarie. È probabile che ci sia un periodo di in cui HTTPS è nuovo e strano per te, e il sito HTTP deve ancora funzionare come mai prima d'ora. Nel tempo, completerai la migrazione e bloccherai HTTPS (vedi le due sezioni successive).

Se il tuo sito dipende da script, immagini o altre risorse pubblicati da una terza parte ad esempio CDN o jquery.com, hai due opzioni:

Utilizza URL relativi a protocollo per queste risorse. Se la terza parte non per pubblicare HTTPS, chiedigli di farlo. Nella maggior parte dei casi lo fanno già, incluso jquery.com.
Pubblica le risorse da un server controllato da te, che offre supporto e HTTPS. Questa è comunque una buona idea, perché in tal caso avrete a disposizione controllo sull'aspetto, sulle prestazioni e sulla sicurezza del tuo sito e non hanno affidare a terze parti la sicurezza del tuo sito.

di Gemini Advanced.

Reindirizzamento da HTTP a HTTPS

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

Attiva il livello massimo di Transport Security e i cookie protetti

A questo punto, sei pronto per "connetterti" l'utilizzo di HTTPS:

Utilizza HTTP Strict Transport Security (HSTS) per evitare il costo dell'errore 301 reindirizzamento.
Imposta sempre il flag Sicurezza sui cookie.

Innanzitutto, utilizza Strict Transport Security di indicare ai clienti di connettersi sempre al server tramite HTTPS, anche quando segui un riferimento http://. In questo modo sconfiggi attacchi come Sblocco SSL, ed evita il costo di andata e ritorno di 301 redirect che abbiamo attivato in Reindirizza da HTTP a HTTPS.

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

La maggior parte dei server web offre una funzionalità simile per l'aggiunta di intestazioni personalizzate.

Inoltre, è importante assicurarsi che i clienti non inviino mai cookie (ad esempio, autenticazione o preferenze del sito) su HTTP. Ad esempio, se l'utente i cookie di autenticazione debbano essere esposti in testo normale, la tua garanzia di sicurezza per l'intera sessione, anche se hai fatto tutto il resto giusto!

Per evitare che questo accada, modifica l'app web in modo che imposti sempre il flag Sicuro sui cookie e set di dati. Questa pagina OWASP spiega come impostare il flag Secure in diversi framework dell'app. Ogni framework appl offre un modo per impostare il flag.

La maggior parte dei server web offre una semplice funzione di reindirizzamento. Usa 301 (Moved Permanently) per indicare ai motori di ricerca e ai browser che la versione HTTPS è canonica, e reindirizzare gli utenti alla versione HTTPS del tuo sito da HTTP.

Posizionamento nella ricerca

Google utilizza HTTPS come qualità di ricerca positiva Google Cloud. Google pubblica anche una guida su come trasferire, spostare o migrare sito mantenendo al contempo il suo ranking nella ricerca. Bing pubblica anche linee guida per webmaster.

Prestazioni

Quando i livelli di contenuto e di applicazione sono ottimizzati (fai riferimento Steve Souders per ricevere consigli), il resto del protocollo TLS i problemi di prestazioni sono generalmente ridotti rispetto al costo complessivo un'applicazione. Puoi anche ridurre e ammortizzare questi costi. Per consigli su TLS dell'ottimizzazione, consulta High Performance Browser Networking (Networking del browser ad alte prestazioni) Ilya Grigorik e il film di Ivan Ristic OpenSSL Cookbook e SSL e TLS blindati.

In alcuni casi, TLS può migliorare le prestazioni, principalmente grazie alla HTTP/2 possibile. Per ulteriori informazioni, leggi l'articolo Chris Palmer's per parlare delle prestazioni di HTTPS e HTTP/2 Chrome Dev Summit 2014.

Intestazioni del referrer

Quando gli utenti seguono link dal tuo sito HTTPS ad altri siti HTTP, gli user agent non è necessario inviare l'intestazione del referrer. Se questo è un problema, esistono diversi modi per Per risolverlo:

Gli altri siti devono eseguire la migrazione a HTTPS. Se i siti invitati completano nella sezione Attiva HTTPS sui tuoi server di questa guida, puoi modificare i link nel tuo sito ai suoi da http:// a https:// o utilizza i link relativi a protocollo.
Per aggirare i numerosi problemi legati alle intestazioni del referrer, utilizza il nuovo Standard dei referrer delle norme.

di Gemini Advanced.

Entrate pubblicitarie

Gli operatori dei siti che monetizzano il proprio sito tramite la pubblicazione di annunci vogliono assicurarsi la migrazione a HTTPS non riduce le impressioni degli annunci. Tuttavia, a causa di combinazioni problemi di sicurezza del contenuto, un <iframe> HTTP non funziona su 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. ma finché gli operatori dei siti non migrano su HTTPS gli inserzionisti hanno poca motivazione per pubblicare HTTPS.

Puoi avviare il processo per eliminare questa situazione di stallo utilizzando inserzionisti che offrire servizi pubblicitari tramite HTTPS e chiedere agli inserzionisti che non pubblicano annunci HTTPS almeno il tutto per renderlo un'opzione. Potresti dover rimandare il completamento Rendi relativi gli URL intrasito finché un numero sufficiente di inserzionisti interagiscono correttamente.