Tag: chiffrement | Page 2

Postfix : résoudre l’erreur “Untrusted TLS connection established to Gmail”

8 April 202206 mai 2015 by Matt Biscay · Lecture: 2 minutes

En vérifiant les logs de mon serveur mail, je me suis aperçu que, malgré mon certificat, la connexion du serveur à un serveur sortant n’était pas entièrement chiffrée.

Voici comment remédier à ce problème.

Postfix : “untrusted connection SMTP”

Concrètement, voici la transcription du log d’une connexion SMTP dite “untrusted connection SMTP” :

postfix/cleanup: message-id=<9@mail.example.com>
opendkim: DKIM-Signature field added (s=mail, d=example.com)
postfix/qmgr: from=<user@example.com>, size=483, nrcpt=1 (queue active)
postfix/smtp: Untrusted TLS connection established to gmail-smtp-in.l.google.com[2a00:1450:4013:c01::1a]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
postfix/smtp: to=<user@gmail.com>, relay=gmail-smtp-in.l.google.com[2a00:1450:4013:c01::1a]:25, delay=1.5, delays=0.12/0.06/0.55/0.73, dsn=2.0.0, status=sent (250 2.0.0 OK 1430771763 z16si1523612wjr.190 - gsmtp)
postfix/qmgr: removed</user@gmail.com></user@example.com>Code language: HTTP (http)

Comme on peut le constater, notre connexion TLS n’est pas chiffrée de bout en bout :

Untrusted TLS connection established to gmail-smtp-in.l.google.com[2a00:1450:4013:c01::1a]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)Code language: JavaScript (javascript)

Solution : ajouter la directive smtp_tls_CAfile

J’ai pour habitude de mettre les mêmes valeurs pour les directives smtp_* et smtpd_* mais dans ce cas précis, il faut modifier la valeur de la directive smtp_tls_CAfile.

On édite le fichier de configuration de Postfix :

nano /etc/postfix/main.cf

On modifie smtp_tls_CAfile pour pointer vers le fichier /etc/ssl/certs/ca-certificates.crt:

###
# Trusted TLS connection to gmail-smtp
# by Matt 
# https://www.skyminds.net
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
###Code language: PHP (php)

et on redémarre Postfix :

service postfix restart

Trusted TLS connection established

Après un envoi de test, voici ce que nous donnent les logs:

postfix/cleanup: message-id=<a@mail.example.com>
opendkim: DKIM-Signature field added (s=mail, d=example.com)
postfix/qmgr: from=<user@example.com>, size=483, nrcpt=1 (queue active)
postfix/smtp: Trusted TLS connection established to gmail-smtp-in.l.google.com[74.125.136.27]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
postfix/smtp: to=<user@gmail.com>, relay=gmail-smtp-in.l.google.com[74.125.136.27]:25, delay=1.1, delays=0.12/0.07/0.31/0.58, dsn=2.0.0, status=sent (250 2.0.0 OK 1430772064 jt5si24487408wjc.48 - gsmtp)
postfix/qmgr: removed</user@gmail.com></user@example.com></a@mail.example.com>Code language: HTML, XML (xml)

Et voilà, connexion vers les serveurs SMTP chiffrée et validée comme trusted!

Résoudre les lightbox vides dans l’administration WordPress

6 November 202426 avril 2015 by Matt Biscay · Lecture: 3 minutes

Le problème : des iframes entièrement vides dans l’interface d’administration WordPress

Depuis mon passage à HTTPS, j’ai constaté que lorsqu’un plugin possédait une mise à jour et que l’on cliquait sur le lien “voir les détails de la version x.x”, j’avais droit à une jolie lightbox (ThickBox sous WordPress) toute vide.

C’était également le cas lors de la mise à jour des plugins, des thèmes ou de WordPress même : je n’obtenais jamais la ligne qui confirmait que le plugin avait bel et bien été réactivé.

Cette situation a duré des mois : j’ai d’abord soupçonné une mise à jour de WordPress qui aurait abimé un fichier donc j’ai ré-uploadé tous les fichiers, procédé à de multiples mises à jour mineures puis majeures.

J’ai ensuite jeté un œil aux plugins, en désactivant quelques uns pour essayer de trouver celui qui perturbait le système. Rien. Et visiblement, personne n’a jamais été confronté à ce problème sur la toile.

Et puis cette semaine, eurêka !

La solution : la configuration Apache du serveur

J’ai trouvé la solution un jour que je travaillais sur autre chose, en analysant les messages de l’inspecteur de code. Ce dernier me renvoyait de multiples avertissements lorsqu’un message a attiré mon attention :

Load denied by X-Frame-Options.... X-Frame-Options does not permit framing.

Et là, banco, j’ai immédiatement compris ce qui clochait. Lors de la bascule vers la version chiffrée du site, j’avais effectivement ajouté un nouvel entête X-Frame-Options comme ceci :

Header always set X-Frame-Options DENYCode language: JavaScript (javascript)

Cela est bien trop restrictif puisque la valeur DENY empêche l’affichage du site dans un cadre (frame).

Or le back-office de WordPress charge effectivement les messages relatifs aux mises à jour dans un cadre, sous la forme d’une lightbox: il faut donc utiliser la valeur SAMEORIGIN.

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é : retirer Varnish, devenu inutile avec HTTPS

29 March 202220 février 2015 by Matt Biscay · Lecture: 3 minutes

J’ai vraiment aimé jouer avec Varnish.

Le problème, c’est qu’en passant l’intégralité du site en HTTPS, il m’est devenu inutile.

Varnish est incompatible avec HTTPS et ne le sera probablement jamais puisque les connexions chiffrées ne doivent, par définition, jamais être mises en cache.

Par conséquent, j’ai décidé de le retirer temporairement du serveur : cela me fera un service de moins à gérer.

Notez que je ne le désinstalle pas, je m’assure juste qu’on ne fait pas appel à lui. Cela me permettra de le remettre en route si jamais j’héberge un jour un site en HTTP simple.

Ce tutoriel part du principe que vous avez suivi les tutoriels précédents et que votre serveur tourne avec Apache et Varnish comme reverse-proxy.

Configuration d’Apache

On doit éditer plusieurs fichiers :

1. le fichier /etc/apache2/ports.conf :

 nano /etc/apache2/ports.conf

On remet les valeurs par défaut et on écoute sur le port 80 :

# If you just change the port or add more ports here, you will likely also
# have to change the VirtualHost statement in
# /etc/apache2/sites-enabled/000-default
# This is also true if you have upgraded from before 2.2.9-3 (i.e. from
# Debian etch). See /usr/share/doc/apache2.2-common/NEWS.Debian.gz and
# README.Debian.gz

# SkyMinds.Net
# Quand Varnish est actif
# NameVirtualHost *:8080
# Listen 8080

# Apache only
NameVirtualHost *:80
Listen 80


    # If you add NameVirtualHost *:443 here, you will also have to change
    # the VirtualHost statement in /etc/apache2/sites-available/default-ssl
    # to 
    # Server Name Indication for SSL named virtual hosts is currently not
    # supported by MSIE on Windows XP.

   NameVirtualHost *:443
   Listen 443



    Listen 443
Code language: PHP (php)

2. les fichiers de chacun de nos VirtualHosts :

nano /etc/apache2/sites-available/www.skyminds.net
nano /etc/apache2/sites-available/static.skyminds.netCode language: JavaScript (javascript)

On écoutait sur le port 8080, on se remet sur le port 80 :

#<virtualhost *:8080="">
<virtualhost *:80="">
Code language: HTML, XML (xml)

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é : configurer Transmission pour accéder au WebUI via TLS-SSL

30 March 202213 octobre 2014 by Matt Biscay · Lecture: 3 minutes

TLS est activé sur notre serveur Apache, WordPress sert désormais ses pages avec une connexion chiffrée et Webmin se sert de notre certificat SSL.

Aujourd’hui, je cherche à lancer le client bittorent Transmission et… je tombe sur un message d’erreur qui m’empêche d’accéder son interface web : “Error code: ssl_error_rx_record_too_long”.

Voici donc comment corriger le problème et afficher l’interface Web de Transmission en HTTPS. Ce tutoriel prend moins de 10 minutes à réaliser.

Erreur : “SSL received a record that exceeded the maximum permissible length”

Le premier message d’erreur sur lequel je tombe est le suivant :

Secure Connection Failed
An error occurred during a connection to www.example.com:9091. SSL received a record that exceeded the maximum permissible length. (Error code: ssl_error_rx_record_too_long)

Je commence par vérifier le fichier de configuration de Transmission et m’aperçoit assez rapidement qu’il ne sera d’aucun secours.

Une recherche sur le net m’informe qu’il faut probablement voir du côté de la configuration Apache – qui ne contenait jusqu’alors aucune référence à Transmission.

Plusieurs essais de configuration plus tard, l’erreur se transforme en erreur 409.

Erreur “409: Conflict”

Le second message auquel je me heurte est le suivant :

409: Conflict
Your request had an invalid session-id header.
To fix this, follow these steps:
When reading a response, get its X-Transmission-Session-Id header and remember it
Add the updated header to your outgoing requests
When you get this 409 error message, resend your request with the updated header
This requirement has been added to help prevent CSRF attacks.

C’est la première fois que je tombe sur une erreur 409, je suis plutôt content. Je continue donc de tester diverses directives Apache jusqu’à trouver la bonne recette pour faire fonctionner le client web UI de Transmission over SSL.

Serveur dédié : configurer Webmin en TLS avec un certificat SSL

20 August 202110 octobre 2014 by Matt Biscay · Lecture: 2 minutes

Après avoir ajouté la couche TLS/SSL au serveur Apache puis configuré WordPress pour fonctionner uniquement en HTTPS, je me suis intéressé à Webmin.

Je n’utilise pas Webmin pour configurer le serveur parce que c’est une sacrée usine à gaz mais pour certaines choses, c’est utile.

Erreur Webmin : Secure Connection Failed

Après le passage aux connexions sécurisées, j’ai obtenu l’erreur suivante :

Secure Connection Failed
An error occurred during a connection to example.com:10000. The server presented a certificate with a key size that is too small to establish a secure connection. (Error code: mozilla_pkix_error_inadequate_key_size)

En substance, ce message d’erreur indique que la clé du certificat créé par Webmin lors de son installation est trop faible par rapport aux nouvelles exigences de notre certificat. Pas de problème, il suffit de créer un certificat spécialement pour Webmin.

Serveur dédié : passer WordPress en HTTPS (TLS/SSL)

30 September 202407 octobre 2014 by Matt Biscay · Lecture: 9 minutes

Vous avez sauté le pas et avez validé votre nom de domaine avec un certificat TLS/SSL. Très bien ! Voyons comment passer WordPress sur la version sécurisée de votre site.

Il existe des plugins WordPress entièrement dédiés à SSL pour rediriger vers les pages sécurisées mais on peut très bien faire sans, avec un peu d’huile de coude.

Le tutoriel est pour Debian et WordPress tourne sous Apache chez moi. Cela prend moins d’une heure pour configurer l’essentiel mais il est probable que vous ayez des petites corrections (thèmes, plugins) pour que tout soit servi en https.

Le but est de tout (oui, absolument tout!) servir via la connexion sécurisée.

Étape 1 : configurer Apache

On édite notre fichier de configuration :

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

et voici ce que garde pour VirtualHost *:80 :

ServerName www.skyminds.net
ServerAlias skyminds.net
DocumentRoot /home/skyminds/public_html/
Redirect 301 / https://www.skyminds.net/Code language: JavaScript (javascript)

La directive ServerName est nécessaire. Ensuite, une simple redirection renvoie toutes les requêtes du port 80 vers le port 443, sécurisé. Même pas besoin de mod_rewrite!

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.

← Précédent