Product
Obsolescence des versions 1.0 et 1.1 de TLS
Depuis les débuts de Mailgun, nous mettons un point d’honneur à ce que nos expéditeurs puissent envoyer leurs emails de la manière la plus sécurisée possible. Lorsque nous avons annoncé le support de TLS en 2014, nous l’avons fait en pensant au client, et nous continuons à le faire aujourd’hui alors que nous prévoyons l’obsolescence des versions 1.0 et 1.1 de TLS au profit de la version 1.2 de TLS, plus sécurisée.
Cela dit, il est important de noter que le 8 mars 2021, Mailgun n’autorisera plus les connexions TLS utilisant les versions obsolètes 1.0 et 1.1.
Pourquoi abandonner les versions 1.0 et 1.1 de TLS ?
Les anciennes versions de TLS sont criblées de failles de sécurité. C’est pourquoi ces protocoles sont mis à jour au fil du temps pour corriger ces vulnérabilités et assurer la sécurité des utilisateurs. La version 1.0 de TLS est sortie en 1999 et a connu de nombreux problèmes avec Heartbleed, POODLE, CRIME, etc. Cela dit, il était temps que les entreprises abandonnent leur support des versions 1.0 et 1.1.
En ce qui concerne l’obsolescence de TLS, de nombreuses autres entreprises technologiques ont également choisi d’abandonner ces anciens protocoles. En mars 2020, les quatre principaux fournisseurs de navigateurs Internet ont mis fin à leur support des versions 1.0 et 1.1 de TLS, ce qui a constitué une avancée majeure vers une meilleure sécurité. Bien que Mailgun ne soit ni la première ni la dernière entreprise à annoncer la fin du support des versions 1.0 et 1.1 de TLS, c’est le moment idéal pour vérifier et vous assurer que votre environnement prend en charge la version 1.2 afin de n’avoir aucune interruption de service.
Si vous utilisez déjà la version 1.2 de TLS, c’est parfait ! Effectuer ce type de mises à jour de maintenance est impératif, prendre de l’avance vous fera donc gagner du temps à l’avenir. Si vous ne savez pas avec certitude si votre environnement prend en charge la version 1.2 de TLS, c’est le moment idéal pour vérifier.
C’est un processus simple, mais nous avons pris les devants et listé ci-dessous comment vérifier votre version de TLS avec Mailgun.
Les étapes pour vérifier le support de TLS 1.2 par votre environnement sont assez simples. Nous avons listé ci-dessous les détails pour effectuer cette vérification sur les systèmes Linux et Windows. S’il prend en charge la version 1.2, vous n’avez aucune autre étape à suivre car nous utiliserons cette version par défaut. Si votre environnement ne prend pas en charge TLS 1.2, un peu de travail supplémentaire vous attend.
Linux
Si vous exécutez votre application d’envoi sur un serveur Linux, vous pouvez utiliser l’utilitaire nmap pour vérifier quelles versions de TLS votre stack prend en charge. Sur votre machine locale, exécutez la commande suivante, en remplaçant « api.mailgun.net » par votre propre domaine :
nmap --script ssl-enum-ciphers -p 443 api.mailgun.net
Voici un exemple de sortie pour api.mailgun.net :
Starting Nmap 7.70 ( https://nmap.org ) at 2020-09-11 13:39 CDT
Nmap scan report for api.mailgun.net (3.220.71.10)
Host is up (0.047s latency).
Other addresses for api.mailgun.net (not scanned): 34.198.11.146 3.93.126.5 52.87.122.201 52.7.64.51 3.226.21.161 52.7.38.97 34.199.221.7
rDNS record for 3.220.71.10: ec2-3-220-71-10.compute-1.amazonaws.com
PORT STATE SERVICE
443/tcp open https
| ssl-enum-ciphers:
| TLSv1.0:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| compressors:
| NULL
| cipher preference: server
| TLSv1.1:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| compressors:
| NULL
| cipher preference: server
| TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| compressors:
| NULL
| cipher preference: server
|_ least strength: A
Comme vous pouvez le voir dans la sortie ci-dessus, api.mailgun.net prend en charge TLSv1.2, donc tout est prêt. Tant que vous obtenez une sortie similaire affichant TLSv1.2, c’est aussi votre cas !
Si vous ne voyez pas la sortie ci-dessus, vous devrez commencer par mettre à jour Apache/Nginx et OpenSSL et/ou mettre à jour vos fichiers de configuration nginx.conf ou Apache pour activer TLSv1.2.
Windows
Pour les utilisateurs de .NET, vous devez tout d’abord vous assurer que votre serveur prend en charge TLS 1.2. Si vous utilisez Server 2008 ou 2012, le support de TLS 1.2 n’était pas disponible par défaut, vous devrez donc vous assurer de disposer des mises à jour appropriées installées afin de prendre en charge TLS 1.2. Si vous utilisez Server 2012 R2 ou 2016, TLS 1.2 devrait déjà être installé et défini par défaut.
Ensuite, nous vous recommandons fortement de mettre à jour toutes vos applications pour utiliser le framework .NET 4.6 ou supérieur, car ceux-ci prennent en charge TLS 1.2 par défaut. Sinon, vous pourrez peut-être utiliser les solutions de contournement suivantes pour les anciennes versions de .NET :
- .NET 4.5. TLS 1.2 est pris en charge, mais ce n’est pas un protocole par défaut. L’utilisation du code suivant définira TLS 1.2 par défaut. Vous devrez exécuter ce code avant d’établir une connexion à une ressource sécurisée :
System.Net.ServicePointManager.SecurityProtocol |= SecurityProtocolType.Tls12;
2. .NET 4.0. TLS 1.2 n’est pas pris en charge, mais si .NET 4.5 (ou supérieur) est installé sur le même système, vous pouvez toujours choisir d’utiliser TLS 1.2. Étant donné que le SecurityProtocolType de .NET 4.0 n’a pas d’entrée pour TLS1.2, vous devrez utiliser une représentation numérique de cette valeur d’énumération :
ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;
Ou utilisez la modification suivante du registre.
3. .NET 3.5 ou inférieur. Assurez-vous de disposer des mises à jour suivantes, ainsi que des clés de registre.
Point de terminaison de test de Mailgun
De plus, nous avons récemment ajouté un point de terminaison d’API de test qui n’acceptera que les requêtes utilisant la version 1.2 de TLS (https://api-test.mailgun.net/v3) pour permettre à nos clients de tester leur configuration. Si vous avez effectué des mises à jour et que vous souhaitez confirmer que vous vous connectez bien à l’aide du bon protocole, passer un appel d’API vers ce point de terminaison confirmera votre mise à jour. Sinon, les appels vers ce point de terminaison échoueront si un ancien protocole est toujours utilisé par votre application.
Attention : ce point de terminaison est configuré uniquement à des fins de test, ne supportera pas des charges d’envoi normales complètes et n’est pas spécifique à une région. Une fois vos tests terminés, vous devrez mettre à jour votre configuration vers le point de terminaison précédent que vous utilisiez.
Alors que nous prévoyons ces changements et migrations vers des versions plus récentes à l’avenir, n’oubliez pas que nous pensons toujours à vous. Avec les articles de blog et les rappels par email, notre objectif est de nous assurer qu’aucun client ne soit pris au dépourvu.
Comment vérifier si votre environnement prend en charge TLS 1.2