Serveur dédié : sécuriser Apache avec HTTPS (HTTP avec la couche TLS/SSL) en Perfect Forward Secrecy

Cela fait quelques mois que j’en parle mais aujourd’hui je le fais, je passe le site en HTTPS – ou techniquement en HTTP avec la couche TLS.

Après les révélations d’Edward Snowden et les multiples affaires concernant les écoutes et les fuites des données des citoyens, je pense qu’il est temps de reprendre un peu les choses en main et de nous intéresser au chiffrement de nos connexions.

La réalisation de ce tutoriel prend moins de 30 minutes, il y a peu de fichiers à éditer et de lignes à copier mais il faut être assez attentif aux diverses manipulations (notamment lors de la génération du certificat).

SSL ou TLS ?

Secure Sockets Layer (SSL) est un protocole cryptographique qui permet une communication sécurisée sur Internet. SSL a été développée par Netscape. SSL 2.0 date de 1995, SSL 3.0 de 1996. Les navigateurs actuels ne supportent plus SSL 2.0.

Transport Layer Security (TLS) est le successeur de SSL. TLS 1.0 date de 1999, TLS 1.1 de 2006 et TLS 1.2 de 2008.

Depuis septembre 2014, la dernière version de tous les navigateurs majeurs supporte SSL 3.0, TLS 1.0, 1.1, et 1.2 activés par défaut et les mitigations contre les attaques connues ont été implémentées.

Les navigateurs qui posent encore problème :

– support de TLS 1.1 and 1.2 mais désactivés par défaut : Internet Explorer (8–10 for Windows 7 / Server 2008 R2, 10 for Windows 8 / Server 2012, Mobile 10 for Windows Phone 8), Opera 12

– non-support de TLS 1.1 et 1.2: Internet Explorer (6-8 for Windows Server 2003, 7–9 for Windows Vista / Server 2008, Mobile 7 and 9 for Windows Phone 7.x), Safari 6 for Mac OS X 10.7 and 10.8

– mitigations contre les attaques connues non implémentées: Safari 6 for Mac OS X 10.7

HTTPS et TLS

Le protocole HTTPS (“Hypertext Transport Protocol Secure” ou protocole de transfert hypertexte sécurisé) protège l’intégrité et la confidentialité des informations des visiteurs d’un site.

Par exemple, lorsqu’un internaute saisit des informations dans un formulaire en ligne afin de recevoir des notifications ou d’acheter un produit, un site sécurisé protège les informations personnelles de cet internaute et garantit que ce dernier communique bien avec le propriétaire autorisé du site.

Avec le HTTPS, les informations sont sécurisées via le protocole Transport Layer Security (TLS), qui offre trois niveaux clés de protection.

1. le chiffrement : consiste à coder les données échangées pour les protéger des interceptions illicites. Cela signifie que lorsqu’un internaute navigue sur un site Web, personne ne peut “écouter” ses conversations, suivre ses activités sur diverses pages ni voler ses informations.

2. l’intégrité des données : les informations ne peuvent être ni modifiées, ni corrompues durant leur transfert, que ce soit délibérément ou autrement, sans être détectées.

3. l’authentication : prouve que les internautes communiquent avec le bon site Web. Cet élément protège contre les attaques de l’homme du milieu (“Man In The Middle” aka MITM) et instaure un climat de confiance pour l’internaute.

Aperçu du fonctionnement de l’authentification client TLS :

Dans la majorité des cas, l’utilisateur authentifie le serveur TLS sur lequel il se connecte. Cette authentification est réalisée par l’utilisation d’un certificat numérique X.509 délivré par une autorité de certification (AC). De plus en plus d’applications web utilisent maintenant l’authentification du poste client en exploitant TLS.

Il est alors possible d’offrir une authentification mutuelle entre le client et le serveur. Le certificat client peut être stocké au format logiciel sur le poste client ou au format matériel (carte à puce, token USB) pour augmenter la sécurité du lien TLS. Cette solution permet d’offrir des mécanismes d’authentification forte.

L’activation du HTTPS pour votre site implique l’obtention d’un certificat de sécurité. Ce dernier est délivré par l’autorité de certification (CA), qui prend des mesures pour vérifier que votre adresse Web appartient bien à votre entreprise, et protège ainsi vos clients d’attaques de l’homme du milieu.

Lors de la configuration de votre certificat, la clé doit être au minimum de 2048 bits, encodée en sha256.

Etape 1 : création de la clé et du Certificate Signing Request (CSR)

Nous allons placer notre certificat dans /etc/ssl :

cd /etc/ssl

On crée une clé de 4096 bits, encodée en SHA256 :

openssl genrsa -out /etc/ssl/skyminds.net.key 4096 -sha256

et on restreint les droits sur le fichier :

chmod 400 skyminds.net.key Code language: CSS (css)

Nous créeons ensuite notre Certificate Signing Request (CSR), à partir de notre nouvelle clé :

openssl req -new -key /etc/ssl/skyminds.net.key -out /etc/ssl/skyminds.net.csrCode language: JavaScript (javascript)

Le fichier CSR va nous permettre de générer un certificat signé par une Certificate Authority (CA).

Etape 2 : signature du certificat par la Certificate Authority (CA)

Plusieurs choix s’offrent à vous :

Vous pouvez sécuriser vos domaines et sous-domaines très simplement avec un certificat SSL gratuit offert par Let’s Encrypt.

La signature du certificat est on ne peut plus simple. Affichez le contenu du CSR :

cat /etc/ssl/skyminds.net.csr

et copiez-collez-le dans l’interface de la CA (votre fournisseur de certificat). Vous obtiendrez un fichier au format .crt et un fichier .ca-bundle qu’il faudra placer dans /etc/ssl avec les autres.

Si vous utilisez StartSSL, téléchargez ces deux fichiers dans /etc/ssl :

wget https://www.startssl.com/certs/sub.class1.server.ca.pem
wget https://www.startssl.com/certs/ca.pemCode language: JavaScript (javascript)

Si vous utilisez une autre CA, téléchargez les fichiers signatures qu’elle vous a envoyé dans /etc/ssl.

Etape 3 : configuration d’Apache et mod_ssl

On active mod_ssl :

a2enmod ssl

On édite la configuration Apache du site :

nano /etc/apache2/sites-available/www.skyminds.net

et voici les lignes concernant mod_ssl qui vont mettre en place TLS. Je les ajoute en haut du fichier :

ServerAdmin webmaster@localhost
ServerName www.skyminds.net
ServerAlias skyminds.net
DocumentRoot /home/skyminds/public_html/

	#   SSL Engine Switch:
	#   Enable/Disable SSL for this virtual host.
	SSLEngine on

	#   Certificate files
	#   If both key and certificate are stored in the same file, only the
	#   SSLCertificateFile directive is needed.
	# SSLCertificateFile    /etc/ssl/certs/ssl-cert-snakeoil.pem
	# SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
	
	SSLCertificateFile /etc/ssl/skyminds.net.crt
	SSLCertificateKeyFile /etc/ssl/skyminds.net.key

	#   Server Certificate Chain:
	#   Point SSLCertificateChainFile at a file containing the
	#   concatenation of PEM encoded CA certificates which form the
	#   certificate chain for the server certificate. Alternatively
	#   the referenced file can be the same as SSLCertificateFile
	#   when the CA certificates are directly appended to the server
	#   certificate for convinience.
	#SSLCertificateChainFile /etc/apache2/ssl.crt/server-ca.crt
	
	# pour StartSSL
	# SSLCertificateChainFile /etc/ssl/sub.class1.server.ca.pem

	#   Certificate Authority (CA):
	#   Set the CA certificate verification path where to find CA
	#   certificates for client authentication or alternatively one
	#   huge file containing all of them (file must be PEM encoded)
	#   Note: Inside SSLCACertificatePath you need hash symlinks
	#         to point to the certificate files. Use the provided
	#         Makefile to update the hash symlinks after changes.
	#SSLCACertificatePath /etc/ssl/certs/
	#SSLCACertificateFile /etc/apache2/ssl.crt/ca-bundle.crt
	
	# pour StartSSL
	# SSLCACertificateFile /etc/ssl/ca.pem
	# pour Comodo / autres CA
	 SSLCACertificateFile /etc/ssl/skyminds.net.ca-bundle

	#   SSL Engine Options:
	#   Set various options for the SSL engine.
	#   o FakeBasicAuth:
	#     Translate the client X.509 into a Basic Authorisation.  This means that
	#     the standard Auth/DBMAuth methods can be used for access control.  The
	#     user name is the `one line' version of the client's X.509 certificate.
	#     Note that no password is obtained from the user. Every entry in the user
	#     file needs this password: `xxj31ZMTZzkVA'.
	#   o ExportCertData:
	#     This exports two additional environment variables: SSL_CLIENT_CERT and
	#     SSL_SERVER_CERT. These contain the PEM-encoded certificates of the
	#     server (always existing) and the client (only existing when client
	#     authentication is used). This can be used to import the certificates
	#     into CGI scripts.
	#   o StdEnvVars:
	#     This exports the standard SSL/TLS related `SSL_*' environment variables.
	#     Per default this exportation is switched off for performance reasons,
	#     because the extraction step is an expensive operation and is usually
	#     useless for serving static content. So one usually enables the
	#     exportation for CGI and SSI requests only.
	#   o StrictRequire:
	#     This denies access when "SSLRequireSSL" or "SSLRequire" applied even
	#     under a "Satisfy any" situation, i.e. when it applies access is denied
	#     and no other module can change it.
	#   o OptRenegotiate:
	#     This enables optimized SSL connection renegotiation handling when SSL
	#     directives are used in per-directory context.
	#SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire
	<filesmatch "\.(cgi|shtml|phtml|php)$"="">
		SSLOptions +StdEnvVars
	
	
		SSLOptions +StdEnvVars
	

	#   SSL Protocol Adjustments:
	BrowserMatch "MSIE [2-6]" \
		nokeepalive ssl-unclean-shutdown \
		downgrade-1.0 force-response-1.0
	# MSIE 7 and newer should be able to use keepalive
	BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown
	
# from Cipherli.st
# https://cipherlist.eu/
SSLCipherSuite AES256+EECDH:AES256+EDH
SSLProtocol All -SSLv2 -SSLv3
SSLCompression off # Requires Apache >= 2.4
SSLHonorCipherOrder On
SSLUseStapling on # Requires Apache >= 2.4
SSLStaplingCache "shmcb:logs/stapling-cache(150000)" # Requires >= Apache 2.4
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
Header always set X-Frame-Options SAMEORIGIN
Header always set X-Permitted-Cross-Domain-Policies "master-only"Code language: PHP (php)

Les dernière lignes proviennent de Cipherli.st et permettent de mettre en place une bonne sécurité pour SSL/TLS : une suite de ciphers mettant en place Perfect Forward Secrecy qui désactivent SSLv2 et SSLv3, et qui ajoute HTTP Strict Transport Security (HSTS), les entêtes X-Frame-Deny et active l’OCSP Stapling :

# from Cipherli.st
# https://cipherlist.eu/
SSLCipherSuite AES256+EECDH:AES256+EDH
SSLProtocol All -SSLv2 -SSLv3
SSLCompression off # Requires Apache >= 2.4
SSLHonorCipherOrder On
SSLUseStapling on # Requires Apache >= 2.4
SSLStaplingCache "shmcb:logs/stapling-cache(150000)" # Requires >= Apache 2.4
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"
Header always set X-Frame-Options DENYCode language: PHP (php)

Je vous conseille de garder un oeil sur Cipherli.st, en cas de changements relatifs aux ciphers.

On redirige ensuite tout le site vers la version sécurisée dans le VirtualHost:

ServerName www.skyminds.net
Redirect permanent / https://www.skyminds.net/Code language: JavaScript (javascript)

Ensuite, on redémarre le serveur Apache :

service apache2 restart

Et on lance l’outil SSL Server Test de Qualys, qui nous donne un très joli A+ !

Relancez votre site et attendez quelques minutes que la propagation se fasse : la connexion apparaît comme sécurisée assez vite sous Chrome/Chromium mais a mis un peu de temps à être considérée comme sécurisée sous FireFox.

Perfect-Forward Secrecy ?

La propriété de forward secrecy permet à une information chiffrée aujourd’hui de rester confidentielle en cas de compromission future de la clef privée d’un correspondant. Cela devrait vous rappeler le fiasco HeartBleed.

Je vous conseille l’excellent article de Vincent Bernat sur SSL/TLS & Perfect Forward Secrecy.

Conclusion

Voilà, votre domaine sous Apache devrait maintenant être sécurisé via TLS. Il ne vous reste plus qu’à sécuriser les autres services qui tournent sur votre serveur. Je reviendrai sur certains de ses services bientôt !

A vous le HTTPS !

Quelques articles intéressants sur HTTPS :

1. How to deploy HTTPS correctly
2. Hardening your web servers’ SSL ciphers
3. SSL Pulse : statistiques sur le déploiement SSL

Articles conseillés :

• Serveur dédié : configurer Postfix et Courier pour utiliser TLS-SSL en Perfect Forward Secrecy
• Serveur dédié : passer WordPress en HTTPS (TLS/SSL)
• Serveur dédié : mettre à jour Apache pour HTTP/2
• Serveur dédié : configurer Transmission pour accéder au WebUI via TLS-SSL
• Serveur dédié : configurer Webmin en TLS avec un certificat SSL
• Serveur dédié : produire une meilleure réserve d’entropie avec haveged