Tutorial: Configurazione SSL/TLS su AMI Amazon Linux

Connettersi all'istanza e confermare che Apache è in esecuzione.

[ec2-user ~]$ sudo service httpd status

Se necessario, avviare Apache.

[ec2-user ~]$ sudo service httpd start

Per verificare che tutti i pacchetti software siano aggiornati, eseguire un aggiornamento rapido del software sull'istanza. Questo processo può richiedere alcuni minuti, ma è importante assicurarsi di disporre della versione più recente degli aggiornamenti della sicurezza e delle correzioni dei bug.

[ec2-user ~]$ sudo yum update -y

Dopo aver aggiornato l'istanza, aggiungere il supporto per TLS installando il modulo Apache mod_ssl:

[ec2-user ~]$ sudo yum install -y mod_ssl

L'istanza dispone ora dei file seguenti, che serviranno per configurare il server sicuro e creare un certificato per il test:

I file .key e .crt sono entrambi in formato PEM, che è composto da caratteri ASCII con codifica Base64 racchiusi tra le righe "BEGIN" e d "END", come nell'esempio di certificato riportato di seguito:

-----BEGIN CERTIFICATE-----
MIIEazCCA1OgAwIBAgICWxQwDQYJKoZIhvcNAQELBQAwgbExCzAJBgNVBAYTAi0t
MRIwEAYDVQQIDAlTb21lU3RhdGUxETAPBgNVBAcMCFNvbWVDaXR5MRkwFwYDVQQK
DBBTb21lT3JnYW5pemF0aW9uMR8wHQYDVQQLDBZTb21lT3JnYW5pemF0aW9uYWxV
bml0MRkwFwYDVQQDDBBpcC0xNzItMzEtMjAtMjM2MSQwIgYJKoZIhvcNAQkBFhVy
...
z5rRUE/XzxRLBZOoWZpNWTXJkQ3uFYH6s/sBwtHpKKZMzOvDedREjNKAvk4ws6F0
WanXWehT6FiSZvB4sTEXXJN2jdw8g+sHGnZ8zCOsclknYhHrCVD2vnBlZJKSZvak
3ZazhBxtQSukFMOnWPP2a0DMMFGYUHOd0BQE8sBJxg==
-----END CERTIFICATE-----

I nomi e le estensioni dei file sono una convenzione e non hanno effetto sulla funzione; puoi chiamare un certificato cert.crt, cert.pem o utilizzare qualunque altro nome del file, fintanto che la relativa direttiva nel file ssl.conf utilizza lo stesso nome.

Riavviare Apache.

[ec2-user ~]$ sudo service httpd restart

Il server Web Apache ora dovrebbe supportare HTTPS (HTTP protetto) sulla porta 443. Provalo digitando l'indirizzo IP o il nome di dominio completo della tua EC2 istanza nella barra degli URL del browser con il prefisso. https:// Poiché ti stai connettendo a un sito con un certificato host autofirmato non attendibile, il browser potrebbe visualizzare una serie di avvisi di sicurezza.

Ignorare gli avvisi e passare al sito. Se la pagina predefinita di test di Apache viene visualizzata, significa che TLS è stato correttamente configurato sul server. Tutti i dati in transito tra il browser e il server ora sono crittografati in modo sicuro.

Per evitare che i visitatori del sito vedano schermate di avviso, devi ottenere un certificato che non solo esegua la crittografia, ma anche che ti autentichi pubblicamente come proprietario del sito.

Connect alla propria istanza e accedi a/etc/pki/tls/private/. Si tratta della directory in cui è memorizzata la chiave privata del server per TLS. Se preferisci utilizzare una chiave host esistente per generare la CSR, passa alla Fase 3.

(Opzionale) Generare una nuova chiave privata. Di seguito sono riportate alcune configurazioni di chiave di esempio. Qualsiasi chiave risultante funziona con il server Web, ma può variare nella modalità (e nel livello) di sicurezza implementata.

Assicurati che la nuova chiave privata abbia proprietà e autorizzazioni estremamente restrittive (owner=root, group=root, solo per il proprietario). read/write I comandi sono simili ai seguenti:

[ec2-user ~]$ sudo chown root.root custom.key
[ec2-user ~]$ sudo chmod 600 custom.key
[ec2-user ~]$ ls -al custom.key

I precedenti comandi dovrebbero restituire il seguente risultato:

-rw------- root root custom.key

Dopo aver creato e configurato una chiave affidabile, puoi creare una CSR.

Creare una CSR utilizzando la chiave preferita; l'esempio seguente utilizza custom.key:

[ec2-user ~]$ sudo openssl req -new -key custom.key -out csr.pem

OpenSSL visualizza una finestra di dialogo e richiede l'immissione delle informazioni riportate nella seguente tabella. Tutti i campi, tranne Common Name (Nome comune), sono facoltativi per un certificato host di base convalidato a livello di dominio.

Infine, OpenSSL richiede l'immissione di una password di verifica opzionale. Questa password è valida solo per la CSR e per le transazioni tra te e la CA. Pertanto, attieniti alle raccomandazioni della CA in merito alla definizione di questo tipo di password e all'altro campo facoltativo, ovvero il nome azienda facoltativo. La password di verifica associata alla CSR non ha alcuna ripercussione sulla funzionalità del server.

Il file csr.pem risultante contiene la chiave pubblica, la firma digitale della chiave pubblica e i metadati immessi.

Inviare la CSR a una CA. In genere, questa operazione prevede l'apertura del file CSR in un editor di testo e la copia del contenuto in un modulo Web. In questo momento, è possibile che ti venga chiesto di fornire uno o più nomi alternativi del soggetto (SANs) da inserire nel certificato. Se www.example.com è il nome comune, example.com potrebbe essere un nome alternativo di oggetto (SAN) valido e viceversa. Un visitatore del sito che immesse uno di questi due nomi avrebbe accesso a una connessione priva di errori. Se il modulo web CA lo consente, includi il nome comune nell'elenco di SANs. Alcuni lo CAs includono automaticamente.

Dopo l'approvazione della richiesta, riceverai un nuovo certificato host firmato dalla CA. Ti potrebbe inoltre venire richiesto di scaricare un file di certificato intermedio contenente i certificati aggiuntivi necessari per completare la catena di attendibilità della CA.

- - - - -BEGIN CERTIFICATE - - - - - 

- - - -END CERTIFICATE - - - - -

[ec2-user certs]$ openssl x509 -in certificate.crt -text

Posizionare il nuovo certificato firmato dalla CA ed eventuali certificati intermedi nella directory /etc/pki/tls/certs.

Dall'interno della /etc/pki/tls/certs directory, usa i seguenti comandi per verificare che le impostazioni di proprietà, gruppo e autorizzazione dei file corrispondano ai valori predefiniti altamente restrittivi di Amazon Linux (owner=root, group=root, solo per proprietario). read/write

[ec2-user certs]$ sudo chown root.root custom.crt
[ec2-user certs]$ sudo chmod 600 custom.crt
[ec2-user certs]$ ls -al custom.crt

I precedenti comandi dovrebbero restituire il seguente risultato:

-rw------- root root custom.crt

Le autorizzazioni del file del certificato intermedio sono meno rigide (owner=root, group=root, il proprietario può scrivere, il gruppo può leggere, tutti gli utenti possono leggere). I comandi sono simili ai seguenti:

[ec2-user certs]$ sudo chown root.root intermediate.crt
[ec2-user certs]$ sudo chmod 644 intermediate.crt
[ec2-user certs]$ ls -al intermediate.crt

I precedenti comandi dovrebbero restituire il seguente risultato:

-rw-r--r-- root root intermediate.crt

Se è stata utilizzata una chiave personalizzata per creare la CSR e il certificato host risultante, rimuovere o rinominare la vecchia chiave dalla directory /etc/pki/tls/private/ e quindi installare la nuova chiave nella stessa posizione.

Dall'interno della /etc/pki/tls/private directory, verifica che le impostazioni di proprietà, gruppo e autorizzazione dei file corrispondano ai valori predefiniti altamente restrittivi di Amazon Linux (owner=root, group=root, solo per il proprietario). read/write I comandi sono simili ai seguenti:

[ec2-user private]$ sudo chown root.root custom.key
[ec2-user private]$ sudo chmod 600 custom.key
[ec2-user private]$ ls -al custom.key

I precedenti comandi dovrebbero restituire il seguente risultato:

-rw------- root root custom.key

Modificare /etc/httpd/conf.d/ssl.conf per riflettere i nuovi file del certificato e della chiave.

1. Indicare il percorso e il nome del file del certificato host firmato dalla CA nella direttiva SSLCertificateFile di Apache:

   SSLCertificateFile /etc/pki/tls/certs/custom.crt

2. In caso di ricezione di un file del certificato intermedio (intermediate.crt in questo esempio), specificare il relativo percorso e nome di file utilizzando la direttiva SSLCACertificateFile di Apache:

   SSLCACertificateFile /etc/pki/tls/certs/intermediate.crt

   Nota

   Alcuni CAs combinano il certificato host e i certificati intermedi in un unico file, rendendo questa direttiva non necessaria. Consultare le istruzioni fornite dalla CA.

3. Indicare il percorso e il nome del file della chiave privata nella direttiva SSLCertificateKeyFile di Apache:

   SSLCertificateKeyFile /etc/pki/tls/private/custom.key

Salvare /etc/httpd/conf.d/ssl.conf e riavviare Apache.

[ec2-user ~]$ sudo service httpd restart

Testare il server digitando il nome del dominio nella barra dell'URL di un browser con il prefisso https://. Il browser deve caricare la pagina di test su HTTPS senza errori.

Aprire il file di configurazione /etc/httpd/conf.d/ssl.conf in un editor di testo e commentare le seguenti righe inserendo il carattere "#" all'inizio:

#SSLProtocol all -SSLv3
#SSLProxyProtocol all -SSLv3

Aggiungere le seguenti direttive:

SSLProtocol -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 +TLSv1.2
SSLProxyProtocol -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 +TLSv1.2

Queste direttive disabilitano in modo esplicito SSL versioni 2 e 3, nonché TLS versioni 1.0 e 1.1. Il server ora non accetta più connessioni crittografate con client che utilizzano crittografie diverse da TLS 1.2. Le descrizioni dettagliate della direttiva indicano più chiaramente al lettore la tipologia di configurazione impostata per il server.

Aprire il file di configurazione /etc/httpd/conf.d/ssl.conf e cercare la sezione con esempi commentati per la configurazione di SSLCipherSuite e SSLProxyCipherSuite.

#SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5
#SSLProxyCipherSuite HIGH:MEDIUM:!aNULL:!MD5

Non apportare alcuna modifica e aggiungere le seguenti direttive alla fine del file:

SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:
ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:
ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:AES:!aNULL:!eNULL:!EXPORT:!DES:
!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA

SSLProxyCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:
ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:
ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:AES:!aNULL:!eNULL:!EXPORT:!DES:
!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA

Questi tipi di crittografia sono un sottoinsieme di un elenco più esteso di tipi di cifratura supportati in OpenSSL. Sono stati selezionati e ordinati in base ai seguenti criteri:

Le crittografie di maggiore importanza includono ECDHE (acronimo di Elliptic Curve Diffie-Hellman Ephemeral, Diffie-Hellman a curva ellittica) nel proprio nome; ephemeral indica la proprietà Forward Secrecy. Inoltre, ora RC4 è tra i cifrari proibiti verso la fine.

È consigliabile utilizzare un elenco esplicito di crittografie anziché utilizzare le impostazioni di default o direttive concise il cui contenuto non è visibile. L'elenco di crittografie visualizzato nell'esempio è solo uno dei possibili elenchi. Ad esempio, potresti voler ottimizzare l'elenco dal punto di vista della velocità e non della proprietà Forward Secrecy.

Se si prevede la necessità di supportare i client più vecchi, è possibile consentire la suite di crittografia DES- CBC3 -SHA.

Ogni aggiornamento a OpenSSL introduce nuove crittografie e rende obsolete quelle vecchie. Mantieni aggiornata la tua istanza EC2 Amazon Linux, tieni d'occhio gli annunci sulla sicurezza di OpenSSL e fai attenzione alle segnalazioni di nuovi exploit di sicurezza pubblicate dalla stampa tecnica.

Rimuovi i commenti mediante la rimozione del carattere "#" dalla riga seguente:

#SSLHonorCipherOrder on

Questo comando obbliga il server a preferire crittografie di maggiore importanza, comprese (in questo caso) quelle che supportano la proprietà Forward Secrecy. Con questa direttiva abilitata, il server cerca di stabilire una connessione stabile e affidabile prima di ripiegare sulle crittografie consentite con un livello inferiore di sicurezza.

Riavviare Apache. Se testate nuovamente il dominio su Qualys SSL Labs, dovreste vedere che la vulnerabilità è scomparsa. RC4