Mettre un certificat SSL sur un service ne veut pas dire qu’il est s\u00e9curis\u00e9 \u00ab\u00a0out of the box\u00a0\u00bb. SSL regroupe plusieurs protocoles et versions diff\u00e9rentes.<\/p>\n\n\n\n\n\n\n\n
Ces versions sont souvent l\u00e0 pour garder une r\u00e9tro-compatibilit\u00e9 avec des clients anciens. Autant cela pourrait \u00eatre tol\u00e9r\u00e9 dans un r\u00e9seau interne avec des progiciels qui ne sont plus maintenue et o\u00f9 le co\u00fbt de mise \u00e0 jour est souvent report\u00e9 sur un projet de migration. Autant quand il s’agit de services ouverts sur internet on se doit de faire le n\u00e9cessaire pour ne pas exposer des protocoles anciens ou \u00eatre sensible \u00e0 certaines faiblesses ou failles de la n\u00e9gociation SSL.<\/p>\n\n\n\n
Sur Internet une seule r\u00e8gle, utiliser les derni\u00e8res versions des protocoles SSL et TLS et d\u00e9sactiver le support des anciennes versions et des types de hachages faibles. Mais cela peut couper l’acc\u00e8s \u00e0 des clients l\u00e9g\u00e8rement ancien sans \u00eatre obsol\u00e8tes.<\/p>\n\n\n\n
Or les algorithmes propos\u00e9s peuvent \u00e0 eux seuls mettre \u00e0 mal la \u00ab\u00a0s\u00e9curit\u00e9\u00a0\u00bb de la communication.<\/p>\n\n\n\n
Avec des outils comme Prenons par exemple la m\u00e9thode On trouve un peu partout des tutoriels expliquant comment g\u00e9n\u00e9rer son CSR, demander son certificat officiel ou auto sign\u00e9 et l’installer sur son serveur Apache ou Nginx. Mais beaucoup de ces tutoriels omettent certains arguments indispensables dans la configuration de ces outils.<\/p>\n\n\n\n Voici ce que l’on peut trouver comme configuration de base et que nous ne recommandons pas<\/mark> pour la configuration d’Apache :<\/p>\n\n\n\n et pour Nginx :<\/p>\n\n\n\n Or avec ces configurations, quels algorithmes, quelle longueur de clef sont utilis\u00e9s? Pour cela il faut chercher les valeurs par d\u00e9faut pour la version du serveur web que l’on a. Avouez que l’on passe totalement \u00e0 c\u00f4t\u00e9 de notre configuration.<\/p>\n\n\n\n Puis sont arriv\u00e9s les premi\u00e8res failles sur SSL et TLS. SSL v2.0 tout d’abord mais qui n’est normalement plus utilis\u00e9 (sauf surprise pour notre fameuse banque). Beaucoup de m\u00e9dias ont vu en l’\u00e9t\u00e9 2011 la fin possible de la s\u00e9curit\u00e9 sur internet sachant que la faille nomm\u00e9e \u00ab\u00a0BEAST Attack\u00a0\u00bb qui a fait grand bruit n’exploite une faille connue depuis 2002<\/a> et qui a conduit \u00e0 sortir la version 1.1 de TLS en 2006 et en 2004 pour l’impl\u00e9mentation de TLS dans OpenSSL.<\/p>\n\n\n\n Si la faille est corrig\u00e9e, pourquoi certains paniquent sur ce sujet et pourquoi des services dit \u00ab\u00a0s\u00e9curis\u00e9s\u00a0\u00bb utilisent encore ces m\u00e9thode de chiffrement? Le probl\u00e8mes est l’inertie des clients (web, messagerie, vpn, communication instantan\u00e9e, … ou tout logiciel qui a besoin de s\u00e9curis\u00e9 une transaction avec un serveur). Ces clients utilisent tr\u00e8s majoritairement la librairie NSS<\/a> pour b\u00e9n\u00e9ficier des fonctionnalit\u00e9s de chiffrement des communication. Cette librairie tarde \u00e0 prendre en compte les diff\u00e9rentes risques de TLSv1.0 et ne supporte pas les versions TLSv1.1 et TLSv1.2 ce qui fait que la grande majorit\u00e9 des navigateurs web m\u00eames r\u00e9cents ne savent pas communiquer en TLSv1.1<\/strong> et sup\u00e9rieur.<\/p>\n\n\n\n Lorsque l’on met en ligne des services proposant SSL et\/ou TLS, la moindre des choses est de propos\u00e9es un environnement applicatif \u00e0 jour en proposant une parade \u00e0 chaque nouveau risque et en mettant \u00e0 jour sa plateforme quitte \u00e0 la faire compl\u00e8tement \u00e9voluer. De l\u00e0 certains pourront se dire si on d\u00e9sactive TLSv1.0 comme SSLv2.0, on enl\u00e8ve tout soucis, dans l’absolue oui mais il va falloir faire avec vos clients.<\/p>\n\n\n\n Si l’on reste sur le domaine des sites web, il n’y a (en septembre 2011) seulement Internet Explorer 9 et Op\u00e9ra 10 qui supportent les trois versions de TLS v1.0, v1.1, v1.2. On tape souvent sur le dos de ces deux navigateurs mais ils nous montrent ici qu’ils restent au plus proche de l’\u00e9volution de la s\u00e9curit\u00e9. Safari d’Apple, Firefox de Mozilla et Chrome de Google ne supportent (en janvier 2012) que TLS v1.0, des demandes ont pourtant \u00e9t\u00e9 faites dans les bugtrackers, certains ont propos\u00e9s des patchs notamment pour Chromium mais sans plus d’actions.<\/p>\n\n\n\n Pour en revenir \u00e0 la faille \u00ab\u00a0BEAST\u00a0\u00bb, cette derni\u00e8re serait compl\u00e8tement inop\u00e9rante \u00e0 partir de TLSv1.1 mais comme TLSv1.0 a encore de l’avenir sur nos serveurs, il faut filtrer les m\u00e9thodes de chiffrement utilis\u00e9es. Dans le cas de cette attaque c’est la m\u00e9thode RC4 qu’il faut \u00e9viter. Pour cela il faut donc forcer les services \u00e0 ne proposer que les bonnes m\u00e9thodes.<\/p>\n\n\n\n Nous allons reprendre nos exemples sur les serveurs web.<\/p>\n\n\n\n Tout d’abord sur Apache nous allons remplacer OpenSSL par GnuTLS pour apporter le support des versions r\u00e9centes de TLS et le support de SNI pour mettre plusieurs certificats diff\u00e9rents sur une m\u00eame adresse ip. Ensuite vous pouvez retirer toute r\u00e9f\u00e9rence au module ssl, c’est \u00e0 dire tous les blocs Dans la configuration du vhost :<\/p>\n\n\n\n La syntaxe est \u00e0 peu pr\u00e8s identique au module SSL, on active le module TLS, on sp\u00e9cifie le chemin vers le certificat, le chemin vers la clef du certificat. A noter qu’il n’y a pas d’\u00e9quivalent \u00e0 la d\u00e9claration La ligne Enfin on force Apache \u00e0 communiquer tous les \u00e9l\u00e9ments d’une page de mani\u00e8re s\u00e9curis\u00e9e en ajoutant la directive Depuis le 16 janvier 2012, Nginx supporte les versions TLSv1.1 et TLSv1.2 mais dans la version de d\u00e9veloppement uniquement, la version stable se base exclusivement sur OpenSSL et ne support donc pas plus que TLSv1.0 pour le moment.<\/p>\n\n\n\n Ici comme pour Apache nous retrouvons deux lignes de configurations pour le chemin du certificat (avec les certificats interm\u00e9diaire et racine \u00e0 la suite dans le m\u00eame fichier) et le chemin de la clef. On force l’utilisation de TLSv1 en attendant de pouvoir activer les versions ult\u00e9rieures. On pr\u00e9cise les m\u00e9thodes que l’on souhaite autoriser Comme vous avez pu le voir, proposer des services s\u00e9curis\u00e9s ne consiste pas \u00e0 juste faire une demande de certificat le plus \u00ab\u00a0trusted\u00a0\u00bb qui soit et l’installer de base sur votre serveur applicatif. Nous avons pu croiser chez quelques clients des aberrations de configuration souvent due au fait qu’on laisse les options par d\u00e9faut sans savoir r\u00e9ellement ce qu’elles proposent. Ces avertissements valent pour toutes les communications SSL\/TLS et nous vous recommandons fortement de v\u00e9rifier vos VPN-SSL et la configuration de ces derniers, il serait dommage de faciliter l’acc\u00e8s \u00e0 votre entreprise parce qu’un employer s’est connect\u00e9 sur votre VPN \u00e0 partir d’un r\u00e9seau wifi ouvert que l’on trouve dans les h\u00f4tels \/ restaurants.<\/p>\n\n\n\n Mettre un certificat SSL sur un service ne veut pas dire qu’il est s\u00e9curis\u00e9 \u00ab\u00a0out of the box\u00a0\u00bb. SSL regroupe plusieurs protocoles et versions diff\u00e9rentes.<\/p>\n","protected":false},"author":2,"featured_media":3035,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[9],"tags":[22,23,24,25],"class_list":["post-832","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-securite","tag-faille","tag-gnutls","tag-openssl","tag-ssltls"],"_links":{"self":[{"href":"https:\/\/www.digdeo.fr\/articles\/wp-json\/wp\/v2\/posts\/832","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.digdeo.fr\/articles\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.digdeo.fr\/articles\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.digdeo.fr\/articles\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.digdeo.fr\/articles\/wp-json\/wp\/v2\/comments?post=832"}],"version-history":[{"count":3,"href":"https:\/\/www.digdeo.fr\/articles\/wp-json\/wp\/v2\/posts\/832\/revisions"}],"predecessor-version":[{"id":3036,"href":"https:\/\/www.digdeo.fr\/articles\/wp-json\/wp\/v2\/posts\/832\/revisions\/3036"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.digdeo.fr\/articles\/wp-json\/wp\/v2\/media\/3035"}],"wp:attachment":[{"href":"https:\/\/www.digdeo.fr\/articles\/wp-json\/wp\/v2\/media?parent=832"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.digdeo.fr\/articles\/wp-json\/wp\/v2\/categories?post=832"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.digdeo.fr\/articles\/wp-json\/wp\/v2\/tags?post=832"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}sslscan<\/code> ou tout simplement gnutls-cli<\/code> on peut \u00e9tudier tous les composants du services SSL \/ TLS et mettre en \u00e9vidence les algorithmes de chiffrement qui sont disponibles.<\/p>\n\n\n\nTLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5<\/code> qui chiffre sur une clef de longueur de 40bits. A premi\u00e8re vue certains diront que 40bits ce n’est pas beaucoup, d’autres auront remarqu\u00e9 que l’on utilise RC2 au lieu d’RC5 et les plus avertis verront l’usage de CBC peu recommandable avec RC4. Cette de m\u00e9thode de chiffrement est vuln\u00e9rable<\/strong> et il serait compl\u00e8tement fou pour s’authentifier sur un site web dit \u00ab\u00a0s\u00e9curis\u00e9\u00a0\u00bb avec cette algorithme. Et pourtant cette m\u00e9thode est utilise en ce d\u00e9but 2012 par une grande banque mondiale pour l’authentification de ses clients.<\/p>\n\n\n\nProbl\u00e8mes des configurations de base<\/h2>\n\n\n\n
SSLEngine On\nSSLCertificateFile \/etc\/apache2\/ssl\/www.mydomain.com.crt\nSSLCertificateKeyFile \/etc\/apache2\/ssl\/www.mydomain.com.key<\/pre>\n\n\n\n
listen 443 ssl;\nssl_certificate \/etc\/nginx\/ssl\/www.mydomain.com.crt;\nssl_certificate_key \/etc\/nginx\/ssl\/www.mydomain.com.key;<\/pre>\n\n\n\n
Les premi\u00e8res failles SSL TLS<\/h2>\n\n\n\n
Configuration SSL\/TLS sur Apache et Nginx<\/h2>\n\n\n\n
Apache et GnuTLS avec mod_gnutls<\/h3>\n\n\n\n
L’exemple vaut ici pour un serveur Debian, tout d’abord on install la librairie gnutls pour Apache 2 ainsi que les utilitaires GnuTLS pour la manipulation des certificats. Il faut penser \u00e0 d\u00e9sactiver le module ssl car les deux vont alors vouloir \u00e9couter sur le port 443 https par d\u00e9faut et Apache ne va pas d\u00e9marrer alors qu’un apache2ctl -t<\/code> pensera que la configuration est bonne.<\/p>\n\n\n\napt-get install libapache2-mod-gnutls gnutls-bin\na2enmod gnutls\na2dismod ssl<\/pre>\n\n\n\n
<\/code> ou bien toutes les d\u00e9clarations SSL*<\/code>.<\/p>\n\n\n\nGnuTLSEnable on\nGnuTLSCertificateFile \/etc\/ssl\/certs\/www.mydomain.com.pem\nGnuTLSKeyFile \/etc\/ssl\/private\/www.mydomain.com.key\nGnuTLSPriorities NONE:+VERS-TLS1.2:+VERS-TLS1.1:+VERS-TLS1.0:+AES-256-CBC:+DHE-RSA:+RSA:+SHA1:+COMP-NULL:+COMP-DEFLATE\nHeader always set Strict-Transport-Security \"max-age=500; includeSubDomains\"<\/pre>\n\n\n\n
SSLCertificateChainFile<\/code> sur GnuTLS il faut comme chez Nginx mettre les certificats interm\u00e9diaires et la racine \u00e0 la suite du certificat du domaine dans le fichier www.mydomain.com.pem<\/code>.<\/p>\n\n\n\nGnuTLSPriorities<\/code> d\u00e9finie les m\u00e9thodes cipher, la m\u00e9thode pour l’\u00e9change de clef, cette pour l’authentification et les options qui vont \u00eatre utilis\u00e9s. On part de NONE et on ajoute ce dont on a besoin. On pr\u00e9cise donc que l’on souhaite g\u00e9rer TLSv1.2 TLSv1.1 et TLSv1.0, puis on donne les m\u00e9thodes TLS_RSA_WITH_AES_256_CBC_SHA<\/code> et TLS_DHE_RSA_WITH_AES_256_CBC_SHA<\/code> toutes deux avec des clefs de 256bits, enfin on utilisera RSA pour l’\u00e9change de clef et SHA1 pour l’authentification. Enfin on pr\u00e9cise avec COMP-NULL<\/code> et COMP-DEFLATE<\/code> que l’on supporte des flux non compress\u00e9s et la compression des flux en zlib.<\/p>\n\n\n\nStrict-Transport-Security<\/code> dans les headers de la r\u00e9ponse au client.<\/p>\n\n\n\nNginx SSL\/TLS<\/h3>\n\n\n\n
listen 443 ssl;\nssl_certificate \/etc\/ssl\/certs\/www.mydomain.com.crt;\nssl_certificate_key \/etc\/ssl\/private\/www.mydomain.com.key;\nssl_protocols TLSv1;\nssl_ciphers AES256-SHA:DHE-RSA-AES256-SHA;\nssl_prefer_server_ciphers on;\nssl_session_cache shared:SSL:10m;\nssl_session_timeout 10m;\nkeepalive_timeout 70;\nadd_header Strict-Transport-Security max-age=500;<\/pre>\n\n\n\n
TLS_RSA_WITH_AES_256_CBC_SHA<\/code> et TLS_DHE_RSA_WITH_AES_256_CBC_SHA<\/code>. Avec l’option ssl_prefer_server_ciphers<\/code> on force le client a utiliser une des m\u00e9thodes du serveur uniquement. Les param\u00e8tres ssl_session*<\/code> et keepalive_timeout<\/code> permettent de garder les sessions ouvertes plus longtemps que pour le http non crypt\u00e9 afin de ne pas ren\u00e9gocier les sessions \u00e0 chaque page visit\u00e9e, c’est un param\u00e9trage pour all\u00e9ger le traitement cpu. Enfin on ajoute le header strict transport security pour que le navigateur ne charge aucun \u00e9l\u00e9ment de page en dehors du canal https.<\/p>\n\n\n\nL’important de bien choisir ses Ciphers SSL TLS<\/h2>\n\n\n\n