Tag: OpenSSL

PHP: résoudre l’erreur “file_get_contents(): SSL operation failed with code 1”

14 March 202231 mai 2020 by Matt Biscay · Lecture: 2 minutes

J’ai récemment joué avec l’API de YouTube pour pouvoir récupérer diverses informations sur les vidéos afin d’ajouter au site les données structurées idoines.

Il se trouve qu’en local, lorsque l’on utilise file_get_contents(), on peut obtenir une erreur de ce type lorsque le serveur n’est pas configuré avec le bundle de certificats OpenSSL:

Warning: file_get_contents(): SSL operation failed with code 1. OpenSSL Error messages: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed in ...php on line 2

Warning: file_get_contents(): Failed to enable crypto in ...php on line 2

Warning: file_get_contents(https://........f=json): failed to open stream: operation failed in ...php on line 2
Code language: JavaScript (javascript)

Si cela vous arrive, plusieurs solutions s’offrent à vous.

Méthode 1: configuration de PHP côté machine/serveur

1. Vérifiez qu’OpenSSL est bien installé sur votre machine (il devrait l’être sur le serveur!).

2. Ajoutez cette ligne à la configuration de PHP, dans votre php.ini:

openssl.cafile=/usr/local/etc/openssl/cert.pemCode language: JavaScript (javascript)

3. Redémarrez le service PHP.

Méthode 2 : une fonction qui utilise curl au lieu de file_get_contents()

Au lieu de m’embêter à configurer OpenSSL ou à toucher à PHP dans un conteneur docker (Local), il se trouve que l’on peut réécrire la fonction file_get_contents() avec une fonction maison qui utilise curl.

Voici la fonction en question:

/*
Custom CURL function that mimicks file_get_contents()
@returns false if no content is fetched
Matt Biscay (https://mattbiscay.com)
*/
function sky_curl_get_file_contents( $URL ){
	$c = curl_init();
	curl_setopt( $c, CURLOPT_RETURNTRANSFER, 1 );
	curl_setopt( $c, CURLOPT_URL, $URL );
	$contents = curl_exec( $c );
	curl_close( $c );
	if( $contents ) :
		return $contents;
	else:
		return false;
	endif;
}Code language: PHP (php)

La fonction retourne false si la requête échoue, ce qui est très utile pour éviter de faire des appels à des valeurs d’un tableau qui n’existe pas.

On peut alors réfléchir à un autre moyen de peupler les champs de données structurées (mais c’est un sujet à aborder une autre fois).

Serveur dédié : mettre à jour OpenSSL sous Debian pour bénéficier de TLS 1.3

24 March 202201 novembre 2018 by Matt Biscay · Lecture: 5 minutes

Cet article fait suite à un précédent tutoriel – installer la dernière version d’OpenSSL sous Debian.

Cela fait un petit moment que je voulais mettre à jour ma configuration TLS et je me suis dit que la Toussaint serait parfaite pour cela.

Aujourd’hui, le serveur passe donc à TLS 1.3, ce qui nécessite une mise à jour d’OpenSSL et la mise à jour des ciphers sous NginX.

Mise à jour d’OpenSSL

Je n’avais pas mis OpenSSL à jour depuis le dernier tuto donc il est aisé de connaitre sa version:

openssl version

Résultat :

OpenSSL v1.1.0fCode language: CSS (css)

Un autre moyen de connaître les versions disponibles dans les repos:

dpkg -l '*openssl*' | awk '/^i/{print $2}' | xargs apt-show-versions -aCode language: JavaScript (javascript)

Résultat:

openssl:amd64 1.1.0f-5 install ok installed
openssl:amd64 1.1.0f-3+deb9u2 stable debian.mirrors.ovh.net
openssl:amd64 1.1.0f-3+deb9u2 stable security.debian.org
openssl:amd64 1.1.0f-5 newer than version in archive
perl-openssl-defaults:amd64 3 install ok installed
perl-openssl-defaults:amd64 3 stable debian.mirrors.ovh.net
perl-openssl-defaults:amd64/stable 3 uptodate
python3-openssl:all 16.2.0-1 install ok installed
python3-openssl:all 16.2.0-1 stable debian.mirrors.ovh.net
python3-openssl:all/stable 16.2.0-1 uptodate

Pour obtenir la version 1.1.1 d’OpenSSL, qui est le sésame pour TLS 1.3, nous allons temporairement ajouter le repo sid, mettre à jour OpenSSL et ses dérivés puis remettre apt dans sa position stable.

On met à jour nos sources apt:

nano /etc/apt/sources.listCode language: PHP (php)

et on y ajoute sid:

deb http://ftp.debian.org/debian sid main
deb-src http://ftp.debian.org/debian sid mainCode language: JavaScript (javascript)

On met à jour apt:

apt update

Et on met à jour openssl:

apt install openssl libssl1.1Code language: CSS (css)

Résultat:

Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  libc-bin libc-dev-bin libc-l10n libc6 libc6-dev libc6-i386 libnih-dbus1 libnih1 libssl-dev locales
  python-httplib2
apt-listchanges: News
---------------------

glibc (2.26-5) unstable; urgency=medium

  Starting with version 2.26-1, the glibc requires a 3.2 or later Linux
  kernel.  If you use an older kernel, please upgrade it *before*
  installing this glibc version. Failing to do so will end-up with the
  following failure:

    Preparing to unpack .../libc6_2.26-5_amd64.deb ...
    ERROR: This version of the GNU libc requires kernel version
    3.2 or later.  Please upgrade your kernel before installing
    glibc.

  The decision to not support older kernels is a GNU libc upstream
  decision.

  Note: This obviously does not apply to non-Linux kernels.

 -- Aurelien Jarno <aurel32@debian.org>  Tue, 23 Jan 2018 22:03:12 +0100

openssl (1.1.1-2) unstable; urgency=medium

  Following various security recommendations, the default minimum TLS version
  has been changed from TLSv1 to TLSv1.2. Mozilla, Microsoft, Google and Apple
  plan to do same around March 2020.

  The default security level for TLS connections has also be increased from
Suggested packages:
  glibc-doc
The following packages will be upgraded:
Setting up libc6-i386 (2.27-8) ...
Setting up python-httplib2 (0.11.3-1) ...
Processing triggers for libc-bin (2.27-8) ...
Setting up libssl1.1:amd64 (1.1.1-2) ...
locale: Cannot set LC_ALL to default locale: No such file or directory
Setting up libc-l10n (2.27-8) ...
Setting up openssl (1.1.1-2) ...
Installing new version of config file /etc/ssl/openssl.cnf ...
Processing triggers for man-db (2.7.6.1-2) ...
Setting up libc-dev-bin (2.27-8) ...
Setting up libc6-dev:amd64 (2.27-8) ...
Setting up locales (2.27-8) ...
Installing new version of config file /etc/locale.alias ...
Generating locales (this might take a while)...
  en_GB.ISO-8859-1... done
  en_GB.UTF-8... done
  en_GB.ISO-8859-15... done
Generation complete.
Setting up libnih1 (1.0.3-10+b1) ...
Setting up libnih-dbus1 (1.0.3-10+b1) ...
Setting up libssl-dev:amd64 (1.1.1-2) ...
Processing triggers for libc-bin (2.27-8) ...
Scanning processes...
Scanning candidates...
Scanning linux images...
Failed to retrieve available kernel versions.
Restarting services...
 invoke-rc.d bind9 restart
 invoke-rc.d cgmanager restart
 invoke-rc.d cgproxy restart
 invoke-rc.d fail2ban restart
ERROR  No section: 'Definition'
ERROR  No section: 'Definition'
ERROR  No section: 'Definition'
ERROR  No section: 'Definition'
ERROR  No section: 'Definition'
ERROR  No section: 'Definition'
ERROR  No section: 'Definition'
ERROR  No section: 'Definition'
 invoke-rc.d haveged restart
 invoke-rc.d irqbalance restart
 invoke-rc.d lvm2-lvmetad restart
 invoke-rc.d lvm2-lvmpolld restart
 invoke-rc.d lwresd restart
 invoke-rc.d mdadm restart
 invoke-rc.d mdadm-waitidle restart
 invoke-rc.d minissdpd restart
 invoke-rc.d nginx restart
 invoke-rc.d opendkim restart
 invoke-rc.d opendmarc restart
 invoke-rc.d php7.2-fpm restart
 invoke-rc.d postfix restart
 invoke-rc.d redis-server restart
 invoke-rc.d rsyslog restart
 invoke-rc.d saslauthd restart
 invoke-rc.d ssh restart
Services being skipped:
 invoke-rc.d dbus restart
No containers need to be restarted.</aurel32@debian.org>Code language: PHP (php)

On teste notre nouvelle verison d’openssl:

openssl version

Résultat:

OpenSSL 1.1.1  11 Sep 2018Code language: CSS (css)

Et en un peu plus précis:

dpkg -l '*openssl*' | awk '/^i/{print $2}' | xargs apt-show-versions -aCode language: JavaScript (javascript)

Résultat:

openssl:amd64 1.1.1-2 install ok installed
openssl:amd64 1.1.0f-3+deb9u2 stable debian.mirrors.ovh.net
openssl:amd64 1.1.0f-3+deb9u2 stable security.debian.org
openssl:amd64 1.1.1-2         sid    ftp.debian.org
openssl:amd64/sid 1.1.1-2 uptodate
perl-openssl-defaults:amd64 3 install ok installed
perl-openssl-defaults:amd64 3 stable debian.mirrors.ovh.net
perl-openssl-defaults:amd64 3 sid    ftp.debian.org
perl-openssl-defaults:amd64/stable 3 uptodate
python3-openssl:all 16.2.0-1 install ok installed
python3-openssl:all 16.2.0-1 stable debian.mirrors.ovh.net
python3-openssl:all 18.0.0-1 sid    ftp.debian.org
python3-openssl:all/stable 16.2.0-1 upgradeable to 18.0.0-1

Mettre à jour les ciphers pour NginX

Il ne nous reste plus qu’à ajouter les nouveaux ciphers pour TLS 1.3 pour les services sécurisés.

Nous mettons donc la configuration des server blocks NginX à jour:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers "TLS13+AESGCM+AES128:EECDH+AESGCM:EECDH+CHACHA20";Code language: CSS (css)

On vérifie la configuration:

nginx -t

et on redémarre le serveur:

service nginx restart

Il ne vous reste plus qu’à vérifier votre configuration TLS sur SSL Labs.

Hébergement OVH : passer à TLS 1.2+ pour WooCommerce et PayPal

22 October 202116 avril 2017 by Matt Biscay · Lecture: 3 minutes

Si vous possédez une boutique en ligne et que vous acceptez PayPal comme moyen de paiement, vous n’êtes pas sans savoir qu’à partir du 30 juin, PayPal exigera une connexion TLS version 1.2 pour gérer la transaction entre votre boutique et PayPal.

Concrètement, votre serveur ou votre hébergement doit être configuré pour servir les pages en HTTPS (certificat SSL obligatoire) et avec une version d’OpenSSL qui donne la priorité au protocole TLS version 1.2+.

Chez OVH, la version d’OpenSSL dépend de la version de PHP configurée pour votre hébergement et surtout du mode utilisé. Pour avoir la dernière version d’OpenSSL, il faut absolument être en mode Stable.

Cela ne prend que quelques minutes à configurer.

TLS sur un serveur dédié

Dans le cas de votre serveur dédié, il suffit de mettre à jour OpenSSL et d’éditer la configuration du serveur (Apache / nginx) pour désactiver les protocoles SSL, TLSv1, TLS v1.1 pour ne garder que TLS v1.2 et TLS v1.3.

TLS sur un hébergement mutualisé OVH

Dans le cadre d’un hébergement mutualisé OVH voici la marche à suivre. Commencez par vous rendre dans le Manager OVH puis :

activer le certificat SSL Let’s Encrypt.
choisir une version de PHP récente en mode Stable.
passer l’intégralité de votre WordPress / Woocommerce en https (si ce n’est déjà fait mais si vous avez une boutique en ligne, ce devrait être le cas depuis longtemps).

En image, voici ce que cela donne :

Hébergement OVH : passer à TLS 1.2 pour WooCommerce et PayPal photo

C’est l’étape 2 qui est primordiale pour activer TLS 1.2 : cela permet de passer d’OpenSSL 0.9.8 à OpenSSL 1.0.1t à l’heure où j’écris ces lignes.

Vérification TLS v1.2

Pour connaître la version d’OpenSSL en vigueur sur votre serveur :

openssl version

Enfin, pour savoir si la connexion entre votre serveur et les serveurs de PayPal se fait bien à l’aide du chiffrement TLS 1.2, lancez cette commande sur votre serveur/hébergement dans un terminal :

php -r '$ch = curl_init(); curl_setopt($ch, CURLOPT_URL, "https://tlstest.paypal.com/"); var_dump(curl_exec($ch)); var_dump(curl_error($ch));'Code language: JavaScript (javascript)

Si la connexion est bien servie en TLS 1.2, le résultat devrait être :

PayPal_Connection_OKbool(true)
string(0) ""Code language: JavaScript (javascript)

Voilà, en espérant que cela puisse vous servir. C’est simple à mettre en place et ne prend que quelques minutes pour retrouver un chiffrement plus sécurisé.

Si vous avez besoin d’un développeur WooCommerce professionel pour mettre tout cela en place, contactez-moi.

Bonne mise à jour.

Serveur dédié : mettre à jour Apache et configurer le mod_h2 pour HTTP/2 photo

Serveur dédié : mettre à jour Apache pour HTTP/2

7 March 202420 décembre 2015 by Matt Biscay · Lecture: 6 minutes

C’est sur toutes les lèvres : 2015 aura vu l’arrivée de PHP7 et de la révision du protocole HTTP qui passe à la version 2, en remplacement du mod_spdy de Google.

Tout cela promet pas mal de gains de performance donc il est très tentant de le vérifier par nous-mêmes.

HTTP/2 : une évolution du protocole HTTP

Avec HTTP/1.1, la vie des développeurs n’était pas simple. L’optimisation d’un site revenait à plusieurs techniques qui tournaient toutes autour de l’idée de minimiser le nombre de requêtes HTTP vers un serveur d’origine.

Un navigateur ne peut ouvrir qu’un nombre limité de connexions TCP simultanées vers une origine et le chargement des ces ressources via chacune de ces connexions est un processus en série : la réponse de chaque ressource doit être retournée avant que la réponse de la ressource suivante ne soit envoyée. C’est ce qu’on appelle le head-of-line blocking.

HTTP/2 promet donc des gains de performance d’environ 30%, sans avoir à gérer ni minification ni concaténation dans le processus de création et déploiement des pages.

Plus besoin (normalement!) d’optimiser les connexions TCP ou les requêtes HTTP avec la création de sprites, le chargement des ressources directement dans le corps des pages, la concaténation ou la création de sous-domaines pour charger les ressources en parallèle (domain sharding) pour contourner les limitations d’HTTP 1.1.

Serveur dédié : mise en place du protocole DANE

12 September 202102 décembre 2015 by Matt Biscay · Lecture: 6 minutes

Aujourd’hui, je vous montre comment mettre en place le protocole DANE sur votre serveur.

En pré-requis, votre domaine doit:

Cela prend environ 20 minutes à configurer, auxquelles s’ajouteront quelques heures afin que la résolution DNS avec les changements soit complète.

DANE : l’authentification TLS sans autorité de certification

DANE (DNS-based Authentication of Named Entities) est un protocole qui permet aux certificats X.509 – généralement utilisés pour TLS – d’être liés au DNS en s’appuyant sur DNSSEC.

L’IETF a défini DANE dans la RFC 6698 comme un moyen d’authentifier des clients TLS et des serveurs sans passer par une autorité de certification (AC).

Cette démarche s’enregistre dans une logique de sécurisation des accès clients-serveurs pour d’une part sécuriser les requêtes DNS effectuées depuis les postes clients au travers des protocoles/mécanismes DNSSEC et TLS, et d’autre part mieux sécuriser les accès chiffrés des clients vers le serveurs.

Le chiffrement TLS est actuellement basé sur des certificats qui sont délivrés par des Autorités de Certification (AC ou Certificate Authority, CA en anglais).

Or, ces dernières années ont vu un certain nombre d’AC qui ont souffert de sérieux problèmes d’intrusions et de failles de sécurité, ce qui a permis la délivrance de certificats pour des sites très connus à des personnes qui ne détenaient pas ces domaines.

Faire confiance à un large nombre d’Autorités de Certification peut être un problème, étant donné que n’importe laquelle d’entre elles, si elle est compromise, pourrait délivrer un certificat pour n’importe quel nom de domaine.

Le protocole DANE permet à l’administrateur d’un nom de domaine de certifier les clés utilisées dans les clients ou serveurs TLS de ce domaine en les insérant au niveau du DNS.

DANE a donc besoin que les enregistrements DNS soient signés avec DNSSEC pour que son modèle de sécurité fonctionne.

De surcroit, DANE permet à l’adminstrateur du domaine de spécifier quelle autorité de certification est autorisée à délivrer des certificats pour une ressource particulière, ce qui résoud le problème des autorités de certification qui sont capables de délivrer des certificats pour n’importe quel nom de domaine.

Serveur dédié : mise en place du protocole DANE photo 3

Les enregistrements TLSA

DANE utilise des enregistrements TLSA, qui incluent l’empreinte du certificats X.509 qui protège un nom de domaine.

Nous devons tout d’abord générer cet enregistrement TLSA en nous basant sur le certificat installé sur notre serveur. Ensuite, cet enregistrement TLSA sera ajouté à notre zone DNS.

Serveur dédié : installer la dernière version d'OpenSSL sous Debian photo

Bash : lister et redémarrer tous les services qui utilisent libssl après une mise à jour d’OpenSSL

8 April 202209 septembre 2015 by Matt Biscay · Lecture: 2 minutes

Lorsque l’on met à jour OpenSSL, tous les services qui utilisent les librairies SSL et qui sont chargés en mémoire ne rechargent pas les librairies (dont libssl) qui viennent d’être mises à jour.

Idéalement, il faudrait rebooter le système mais lorsqu’il s’agit d’un serveur, ce n’est pas toujours possible. Si les services ne sont pas redémarrés (restart) ou rechargés (reload) après une mise à jour, ils seront toujours vulnérables aux problèmes de sécurité que corrige la nouvelle version.

Voici donc comment détecter les services qui utilisent les librairies d’OpenSSL afin de les redémarrer et éviter de rebooter la machine.

Lister les services qui utilisent libssl

Vérifiez que votre système possède la commande lsof. Elle devrait normalement être prise en charge par votre gestionnaire de paquets.

Pour lister les services qui utilisent OpenSSL, il suffit de vérifier lesquels utilisent le paquet libssl en les classant par ordre alphabétique et en supprimant les doublons:

lsof | grep libssl | awk '{print $1}' | sort | uniqCode language: JavaScript (javascript)

Résultat:

apache2
fail2ban-
opendkim
php5-fpm
tlsmgr

Il ne vous reste plus qu’à redémarrer les services présents dans cette liste qui font appel à OpenSSL.

Lister les services qui utilisent une ancienne version de libssl

Si vous avez mis à jour OpenSSL mais que vous n’avez pas redémarré votre serveur, il est possible que certains services utilisent toujours une ancienne librairie non-patchée d’OpenSSL.

Serveur dédié : installer la dernière version d’OpenSSL sous Debian

29 March 202223 février 2015 by Matt Biscay · Lecture: 6 minutes

Aujourd’hui, on s’intéresse à la mise à jour d’OpenSSL sur un serveur Debian, en utilisant les dépôts sid.

Cela va nous permettre d’installer la dernière mise à jour d’OpenSSL, responsable du chiffrement des connexions de plusieurs services (serveur de fichier, serveur mail, serveur DNS…), pour plus de sécurité sur le serveur.

Ce tutoriel ne prend que quelques minutes et quatre étapes mais il faut bien le suivre jusqu’au bout.

Vérification de la version d’OpenSSL

On commence par vérifier la version d’OpenSSL installée sur notre Debian, pourtant à jour :

openssl version

résultat :

OpenSSL 1.0.1e 11 Feb 2013Code language: CSS (css)

Ouch! Ah oui, ça date un peu! Vérifions les versions disponibles :

apt-cache policy openssl

résultat :

openssl:
  Installed: 1.0.1e-2+deb7u14
  Candidate: 1.0.1e-2+deb7u14
  Version table:
 *** 1.0.1e-2+deb7u14 0
        500 http://security.debian.org/ wheezy/updates/main amd64 Packages
        100 /var/lib/dpkg/status
     1.0.1e-2+deb7u13 0
        500 http://mirror.ovh.net/debian/ wheezy/main amd64 PackagesCode language: JavaScript (javascript)

Nous avons la dernière version stable qui correspond aux dernières mises à jour de notre distribution mais c’est loin d’être la dernière version disponible.

Mise à jour de nos dépôts avec la version sid (unstable)

Nous allons tous simplement installer la dernière version d’OpenSSL qui se trouve dans les dépôts sid, réputés instables car non-testés de manière exhaustive.

On édite la liste de nos dépôts :

nano  /etc/apt/sources.listCode language: PHP (php)

et on y ajoute les dépôts sid :

deb http://ftp.debian.org/debian sid main
deb-src http://ftp.debian.org/debian sid mainCode language: JavaScript (javascript)

On met à jour nos dépôts:

apt-get updateCode language: JavaScript (javascript)

On vérifie les versions d’OpenSSL disponibles :

apt-cache policy openssl

Résultat :

openssl:
  Installed: 1.0.1e-2+deb7u14
  Candidate: 1.0.1k-1
  Version table:
     1.0.1k-1 0
        500 http://ftp.debian.org/debian/ sid/main amd64 Packages
 *** 1.0.1e-2+deb7u14 0
        500 http://security.debian.org/ wheezy/updates/main amd64 Packages
        100 /var/lib/dpkg/status
     1.0.1e-2+deb7u13 0
        500 http://mirror.ovh.net/debian/ wheezy/main amd64 PackagesCode language: JavaScript (javascript)

Pas mal : nous pouvons passer de la version 1.0.1e à la version 1.0.1k et donc bénéficier de tous les mises à jour récentes d’OpenSSL.

Serveur dédié : configurer Postfix et Courier pour utiliser TLS-SSL en Perfect Forward Secrecy

13 April 202221 novembre 2014 by Matt Biscay · Lecture: 6 minutes

Aujourd’hui, on va s’atteler à sécuriser le serveur de mail, géré par Postfix et Courier, pour utiliser notre certificat SSL et en ajoutant le Perfect Forward Secrecy.

Ce tutoriel part du principe que votre serveur tourne sous Debian et que vous avez suivi le tutoriel précédent sur Postfix avec gestion d’utilisateurs virtuels, c’est-à-dire que le serveur de mail doit déjà être opérationnel.

Vérification du fonctionnement du serveur de mail

On commence par vérifier que le serveur est capable d’envoyer des mails avec :

echo "test" | mail -s testsubject user@example.comCode language: PHP (php)

Si le mail est reçu, passez à l’étape suivante.

Configuration du certificat SSL

Nous allons concaténer la clé et le certificat pour Courier :

cd /etc/ssl
cat skyminds.net.key  skyminds_net.crt >> courier-key-crt-dh.pem

et on va y inclure un échange de clés Diffie-Hellman :

openssl dhparam 2048 >> courier-key-crt-dh.pemCode language: CSS (css)

On ajoute une autre clé DH en 2048 bits:

openssl gendh -out /etc/postfix/dh_2048.pem -2 2048

L’échange de clés Diffie-Hellman – du nom de ses auteurs Whitfield Diffie et Martin Hellman – est une méthode par laquelle deux personnes nommées conventionnellement Alice et Bob peuvent se mettre d’accord sur un nombre (qu’ils peuvent utiliser comme clé pour chiffrer la conversation suivante) sans qu’une troisième personne appelée Ève puisse découvrir le nombre, même en ayant écouté tous leurs échanges. Cela sécurise un peu plus l’échange.

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

26 September 202429 septembre 2014 by Matt Biscay · Lecture: 10 minutes

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.

La faille Heartbleed dans OpenSSL : mettez à jour vos serveurs

30 March 202210 avril 2014 by Matt Biscay · Lecture: 4 minutes

Heartbleed

Dans la nuit du lundi 7 au mardi 8 avril 2014, une équipe de chercheurs du Codenomicon et le chercheur Neel Mehta de Google Security ont découvert une faille dans la librairie open-source OpenSSL.

OpenSSL est une librairie utilisée pour gérer la couche SSL/TLS de nombreux logiciels (serveurs webs, webmails, VPN, messagerie instantanée…).

La faille, baptisée Heartbleed, est une vulnérabilité sérieuse dans le protocole d’encryption OpenSSL, utilisé pour chiffrer et sécuriser les connexions.

Potentiellement, cette faille permet de dérober des données normalement chiffrées et des clés privées.

Concrètement, cela signifie que toutes les données que nous avons considérées comme sécurisées ne l’étaient pas.

Heartbleed affecte approximativement 66 % des serveurs du monde entier et existe depuis décembre 2011.

En exploitant cette faille, un hacker peut lire 64 KB de la mémoire du système protégé par OpenSSL et ainsi voler les mots de passe, les clés de chiffrement, toutes les données qui transitent entre votre ordinateur et le serveur, et ensuite pouvoir se faire passer de manière transparente pour un service web ou un internaute…

Cela ne laisse aucune trace : un PoC est disponible.

Déterminer la version d’OpenSSL

Toutes les versions d’OpenSSL 1.0.1 à 1.0.1f inclus sont vulnérables. Pour savoir quelle version d’OpenSSL est actuellement installées sur votre système, tapez :

dpkg -s openssl | grep Version

La faille a été introduit dans OpenSSL en décembre 2011 et s’est retrouvé dans la nature avec la sortie d’OpenSSL 1.0.1 le 14 mars 2012.

OpenSSL 1.0.1g, sortie le 7 avril 2014, corrige Heartbleed.