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 :

tls-auth

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 

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.csr

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 avez juste besoin d’un certificat pour votre site pour un nombre très limité d’utilisateurs : utilisez Cacert ou générez votre propre certificat avec OpenSSL (vous serez alors votre propre CA) . Inconvénient : une erreur s’affiche dans le navigateur et c’est à l’utilisateur de whitelister le site.

– vous n’avez qu’un seul sous-domaine à sécuriser, vous pouvez utiliser le certificat SSL gratuit offert par StartSSL. L’avantage, c’est que leur certificat est inclus et reconnu dans tous les navigateurs.

– vous avez besoin de sécuriser plusieurs sous-domaines. C’est mon cas et j’ai choisi de payer mon certificat. Je sais, c’est mal mais c’est apparemment le seul moyen d’avoir un certificat wildcard, qui sécurise tous les sous-domaines (*.example.com).

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 (StartSSL, Comodo, 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.pem

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"

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 DENY

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/

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

Synopsis » Monter un serveur dédié de A à Z

  1. Serveur dédié : installation d’Apache, PHP, MySQL et Webmin
  2. Serveur dédié : créer la base de données MySQL et importer WordPress
  3. Serveur dédié : créer et activer un Virtual Host sous Apache
  4. Serveur dédié : changer les DNS du nom de domaine et le faire pointer vers le serveur
  5. Serveur dédié : sécurisation des services avec iptables et fail2ban
  6. Serveur dédié : sécurisation de la couche TCP/IP
  7. Serveur dédié : création d’un serveur mail Postfix (sécurisé avec Saslauthd et certificat SSL) et Courier (accès POP et IMAP) utilisant une base MySQL d’utilisateurs/domaines virtuels
  8. Serveur dédié : sécuriser Apache 2 avec ModSecurity
  9. Serveur dédié : CHMOD récursif sur des fichiers ou répertoires en ligne de commande
  10. Serveur dédié : installer APC comme système de cache et configurer Varnish comme reverse-proxy pour Apache pour améliorer les performances
  11. Serveur dédié : afficher la véritable IP derrière un reverse-proxy comme Varnish
  12. Serveur dédié : intégrer SSH à WordPress pour mettre à jour le core, les plugins et les thèmes
  13. Serveur dédié : installer la dernière version d’APC par SVN
  14. Serveur dédié : analyse des performances du serveur
  15. Serveur dédié : mettre à jour le noyau Debian de la Kimsufi
  16. Serveur dédié : sauvegarde automatique des fichiers avec Backup Manager sur le serveur de sauvegarde OVH
  17. Serveur dédié : configurer la limite mémoire pour PHP et Suhosin
  18. Bash : supprimer tous les fichiers et sous-répertoires d’un répertoire
  19. Serveur dédié : impossible de se connecter à un port distant
  20. Rsync: rapatrier les fichiers du serveur à la maison
  21. Bash : réparer les tables MySQL en cas de crash
  22. Serveur dédié : création d’une seedbox avec Transmission
  23. Serveur dédié : des paquets LAMP à jour sous Debian
  24. Serveur dédié : mise à jour vers Debian 7 Wheezy
  25. Serveur dédié : activer X11 forwarding pour SSH
  26. Serveur dédié : optimiser toutes les images JPG et PNG avec OptiPNG et JpegOptim
  27. Postfix : résoudre l’erreur “fatal: www-data(33): message file too big”
  28. Serveur dédié : mise en place de l’IPv6
  29. WordPress : accorder les bonnes permissions aux fichiers et dossiers avec chown et chmod
  30. WordPress : héberger les images sur un sous-domaine
  31. Serveur dédié : ajouter l’authentification SPF, Sender-ID et DKIM à Postfix et Bind9 avec opendkim
  32. Apache : lorsque le domaine seul (sans WWW) renvoie une erreur 403
  33. Serveur dédié : sécuriser Apache avec HTTPS (HTTP avec la couche TLS/SSL) en Perfect Forward Secrecy
  34. Serveur dédié : passer WordPress en HTTPS (TLS/SSL)
  35. Serveur dédié : configurer Webmin en TLS avec un certificat SSL
  36. Serveur dédié : configurer Transmission pour accéder au WebUI via TLS-SSL
  37. Serveur dédié : installer et configurer Varnish 4
  38. Serveur dédié : passage au mod FastCGI et PHP-FPM avec Apache MPM Worker
  39. Récupérer un serveur Kimsufi après un plantage de kernel avec le mode rescue OVH
  40. Serveur dédié : configurer Postfix et Courier pour utiliser TLS-SSL en Perfect Forward Secrecy
  41. Serveur dédié : retirer Varnish, devenu inutile avec HTTPS
  42. Serveur dédié : installer la dernière version d’OpenSSL sous Debian
  43. Serveur dédié : activer l’IP canonique du serveur sous Apache
  44. Serveur dédié : mise à jour vers PHP 5.6
  45. MySQL : convertir les tables MyISAM au format InnoDB
  46. Serveur dédié : optimiser toutes les images GIF avec GIFsicle
  47. Serveur dédié : migration de MySQL vers MariaDB
  48. BASH : lister, bloquer et débloquer des adresses IP avec iptables
  49. Serveur dédié : produire une meilleure réserve d’entropie avec haveged
  50. Serveur dédié : mettre en place DNSSEC pour sécuriser les DNS du domaine
  51. Serveur dédié : mise en place du protocole DANE
  52. 8 règles d’or pour bien déployer DNSSEC et DANE
  53. Serveur dédié : installer PHP7 FPM avec FastCGI sous Debian
  54. Serveur dédié : optimiser la couche TCP
  55. Fail2Ban: protéger Postfix contre les attaques DoS de types AUTH, UNKNOWN et EHLO
  56. Serveur dédié : mettre à jour Apache pour HTTP/2
  57. Serveur dédié : ajouter le domaine à la liste HSTS preload
  58. Serveur dédié : ajouter l’authentification DMARC à Postfix et BIND
  59. Serveur dédié : à la recherche de l’inode perdue ou comment résoudre le problème “no space left on device”
  60. Serveur dédié : installer NginX avec support HTTP2 et certificat SSL, PHP, MariaDB sous Debian

Vous voulez un site WordPress ou WooCommerce qui soit à la fois rapide et performant? Vous êtes au bon endroit.

Découvrez comment je peux booster votre site »

Articles conseillés :

4 pensées sur “Serveur dédié : sécuriser Apache avec HTTPS (HTTP avec la couche TLS/SSL) en Perfect Forward Secrecy”

    • Salut,

      Je n’utilise pas phpMyAdmin mais Adminer, que je trouve bien plus simple à utiliser pour les mêmes fonctionnalités.

      En plus, il tient sur un seul fichier (bien moins lourd que PMA!) donc pas besoin de trifouiller dans Apache.

      Reply
  1. Mise à jour : modification de la valeur de l’entête X-Frame-Options (passage de DENY à SAMEORIGIN) pour plus de souplesse avec les iframes tierces.

    Reply

Opinions