Utilisez-vous TLS version antérieure à 1.2 ? Ce n'est pas grave, les délais de mise à jour de maintenance arrivent à tout le monde. Nous le comprenons. Cependant, il est temps de passer à autre chose.
Rappelez-vous, en juin 2018, lorsque nous avons déprécié l'utilisation de TLS 1.0 ? Si vous ne vous en souvenez pas, ce n'est pas grave, vous pouvez lire tout à ce sujet dans cet article. Eh bien, nous y sommes, 2 ans plus tard et la prochaine version est sur le point d'être mise sur la touche, donc nous voulons que vous soyez préparé et d'éviter toute interruption de service. Cet article est entièrement consacré à vous préparer à fonctionner sans utiliser TLS 1.1 afin que nous puissions restreindre l'accès uniquement à TLS 1.2. Nous allons vous guider sur la façon de vérifier votre version actuelle et comment passer à la dernière version. Juste pour le plaisir, nous aimerions vraiment entendre vos retours et vous ajouter à un "mur de l'incroyable" présentant toutes ces entreprises soucieuses de la sécurité qui font le changement tôt.
Est-ce que cela m'affecte ?
En 2018, nous avons demandé à nos clients de faire une mise à jour, et TLS 1.2 est recommandé depuis un certain temps, donc il est très probable que vous ne soyez PAS affecté. Cependant, si vous utilisez n'importe quelle méthode pour injecter des messages (SMTP ou REST API) ou recueillir des données (métriques ou webhooks, etc.), alors vous devriez vraiment vérifier maintenant pour vous assurer que votre système peut prendre en charge TLS 1.2. Assurez-vous d'exécuter les tests suivants sur les serveurs qui se connectent réellement à SparkPost.
Pourquoi est-ce important
SparkPost n'acceptera pas les connexions sur TLS 1.1 après septembre 2020
Les versions antérieures ne sont pas sécurisées
TLS 1.2 est le protocole recommandé depuis plus d'une décennie
Tous les bons élèves le font
Pourquoi maintenant ?
En fait, la question devrait être “pourquoi continuez-vous à le supporter ?” TLS 1.2 est la norme sécurisée recommandée depuis plus d'une décennie et nous sommes à bout touchant pour que quiconque offre encore un support pour quoi que ce soit de moins que TLS 1.2. Il est temps que le support HTTPS faible cesse une fois pour toutes. Si vous utilisez toujours TLS 1.1 après mars 2020, vous aurez du mal à vous connecter à la plupart des services. SparkPost a accordé amplement de grâce pour effectuer cette mise à jour et maintenant nous envoyons des avis finaux pour obtenir cette mise à jour avant septembre, lorsque nous le détruirons définitivement.
Mais comment, je vous prie, pouvez-vous le corriger ?
Il est très possible que votre SysAdmin IT ou WebAdmin l'ait déjà fait pour vous dans le cadre de leur maintenance normale. Si c'est le cas, vous devriez leur acheter une bière et dire merci. Sinon, vous pouvez suivre certaines des étapes ci-dessous pour le faire sous Linux, Windows et Mac.
Notez qu'à travers ce document, nous testerons avec le point d'accès US de SparkPost.
Si vous utilisez normalement le déploiement européen, vous devriez utiliser le point d'accès UE à la place.
Comment pouvez-vous vérifier ? (version Linux)
Tout d'abord, vérifions pour voir si votre sympathique SysAdmin de quartier a déjà pris soin de cela pour vous. Cela fait en fait partie de la configuration SSL, donc cela peut être géré dans la configuration de votre système. En supposant que vous utilisez Linux, la méthode la plus descriptive consiste à utiliser nmap, mais vous pouvez également utiliser openssl. Vous pouvez utiliser nmap avec Linux, Windows et Mac, mais nous explorerons d'autres méthodes pour Windows et Mac également si vous ne voulez pas installer de nouvelle application.
Pour faire cela avec nmap, testez les chiffrements contre un hôte HTTPS connu. Puisque le but est d'assurer que nous nous connectons à SparkPost de manière sécurisée, testons contre ce point d'accès. Assurez-vous d'exécuter les tests suivants sur les serveurs qui se connectent réellement à SparkPost.
nmap --script ssl-enum-ciphers -p 443 api.sparkpost.com
Cela a été fait sur mon propre serveur de développement et vous pouvez facilement voir que ma configuration prend en charge TLS 1.1 et 1.2 mais pas 1.3. Il est important de noter à ce stade qu'AWS ALBs, et donc les connexions SparkPost, ne prennent pas encore en charge TLS 1.3, mais c'est sur la feuille de route d'AWS.
Démarrage de Nmap 6.40 ( http://nmap.org ) le 2020-05-06 22:41 UTC Rapport de scan Nmap pour api.sparkpost.com (52.13.246.255) L'hôte est accessible (0.00059s de latence). D'autres adresses pour api.sparkpost.com (non scannées) : 34.211.102.211 52.43.22.201 54.213.185.174 100.20.154.199 52.43.110.79 52.40.215.39 52.40.175.169 enregistrement rDNS pour 52.13.246.255 : ec2-52-13-246-255.us-west-2.compute.amazonaws.com PORT ÉTAT SERVICE 443/tcp ouvert https | ssl-enum-ciphers: | TLSv1.1: | chiffrements: | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - fort | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - fort | TLS_RSA_WITH_AES_128_CBC_SHA - fort | TLS_RSA_WITH_AES_256_CBC_SHA - fort | compresseurs: | NULL | TLSv1.2: | chiffrements: | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - fort | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 - fort | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - fort | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - fort | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 - fort | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - fort | TLS_RSA_WITH_AES_128_CBC_SHA - fort | TLS_RSA_WITH_AES_128_CBC_SHA256 - fort | TLS_RSA_WITH_AES_128_GCM_SHA256 - fort | TLS_RSA_WITH_AES_256_CBC_SHA - fort | TLS_RSA_WITH_AES_256_CBC_SHA256 - fort | TLS_RSA_WITH_AES_256_GCM_SHA384 - fort | compresseurs: | NULL |_ force la plus faible : forte Nmap terminé : 1 adresse IP (1 hôte accessible) scannée en 0.11 secondes
À ce stade, vous pouvez réellement arrêter si vous le souhaitez, car le but est de vous assurer que vous pouvez vous connecter à SparkPost en utilisant TLS 1.2. Si votre connexion prend en charge TLS 1.2, c'est ce dont nous avons besoin à ce stade, donc tout est bon ici. Allez acheter une bière à ce SysAdmin et dites merci.
Envoyez-nous un email et faites-nous savoir si vous avez réussi.
Vérification de la prise en charge sur votre Mac
La raison la plus courante pour laquelle vous pourriez avoir besoin de vérifier la prise en charge sur votre Mac est que vous l'utilisez pour le développement local, donc supposons cela et vérifions votre prise en charge.
La méthode la moins invasive consiste à utiliser curl qui devrait être intégré à chaque Mac. Lancez l'application Terminal et utilisez le drapeau de protocole pour tester spécifiquement pour TLS 1.2.
curl https://api.sparkpost.com/ --tlsv1.2 --verbose * Tentant 54.213.185.174... * TCP_NODELAY défini * Connecté à api.sparkpost.com (54.213.185.174) port 443 (#0) * ALPN, offrant h2 * ALPN, offrant http/1.1 * Sélection de chiffrements : ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH * vérification réussie des emplacements de certificats : * CAfile : /etc/ssl/cert.pem CApath : aucun * TLSv1.2 (SORTIE), poignée de main TLS, Client hello (1) : * TLSv1.2 (ENTRÉE), poignée de main TLS, Serveur hello (2) : * TLSv1.2 (ENTRÉE), poignée de main TLS, Certificat (11) : * TLSv1.2 (ENTRÉE), poignée de main TLS, Échange de clé du serveur (12) : * TLSv1.2 (ENTRÉE), poignée de main TLS, Serveur terminé (14) : * TLSv1.2 (SORTIE), poignée de main TLS, Échange de clé du client (16) : * TLSv1.2 (SORTIE), changement de chiffre, Client hello (1) : * TLSv1.2 (SORTIE), poignée de main TLS, Terminé (20) : * TLSv1.2 (ENTRÉE), changement de chiffre, Client hello (1) : * TLSv1.2 (ENTRÉE), poignée de main TLS, Terminé (20) : * Connexion SSL utilisant TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256 * ALPN, le serveur a accepté d'utiliser h2 * Certificat du serveur : * sujet : CN=*.sparkpost.com * date de début : 30 janv 00:00:00 2020 GMT * date d'expiration : 28 févr 12:00:00 2021 GMT * sujetAltName : hôte "api.sparkpost.com" correspondant au cert's "*.sparkpost.com" * émetteur : C=US; O=Amazon; OU=Server CA 1B; CN=Amazon * vérification de certificat SSL ok. * Utilisation de HTTP2, le serveur prend en charge plusieurs utilisations * État de connexion modifié (HTTP/2 confirmé) * Copie des données HTTP/2 dans le tampon de flux pour le tampon de connexion après la mise à niveau : len=0 * Utilisation de l'ID de flux : 1 (manipulation facile 0x7fbd69805200) > GET / HTTP/2 > Hôte : api.sparkpost.com > User-Agent : curl/7.54.0 > Accept : */* > * État de connexion modifié (MAX_CONCURRENT_STREAMS mis à jour) ! < HTTP/2 200 < date : jeu. 07 mai 2020 15:14:30 GMT < type de contenu : text/plain < longueur de contenu : 95 < serveur : msys-http < * Connexion #0 à l'hôte api.sparkpost.com laissée intacte Oh hey ! Vous devriez venir travailler avec nous et construire des choses incroyables !
Si vous voulez tester en utilisant la connexion SMTP, vous pouvez également le faire avec cette commande :
openssl s_client -crlf -starttls smtp -tls1_2 -connect smtp.sparkpostmail.com:587
Retourne un grand nombre de données, y compris :
SSL-Session : Protocole : TLSv1.2 Chiffre : ECDHE-RSA-AES256-GCM-SHA384
Vérification de la prise en charge sous Windows
De manière similaire au cas d'utilisation Mac, la raison la plus courante pour laquelle vous pourriez avoir besoin de vérifier la prise en charge dans votre Windows est que vous l'utilisez pour le développement local, donc supposons cela et vérifions votre prise en charge.
Windows 7 et Windows 10 utilisent à peu près le même processus. Si vous utilisez quelque chose d'antérieur, veuillez mettre à jour car les versions antérieures ne prennent pas en charge TLS 1.2.
Commencez par cliquer sur DÉMARRER dans le coin inférieur gauche (généralement).
Tapez “Options Internet” et sélectionnez la correspondance dans la liste résultante.
Cliquez sur l'onglet Avancé et depuis là, faites défiler jusqu'en bas. Si TLS 1.2 est coché, vous êtes déjà prêt. Si ce n'est pas le cas, veuillez cocher la case à côté de Utiliser TLS 1.2 puis Appliquer.
Attendez, quoi ? Pas de 1.2 ?
Dommage mon pote. Votre travail n'est pas encore terminé.
Si vous n'avez que TLS 1.1, vous devriez mettre à jour vos paramètres de chiffre.
En supposant que vous utilisez Linux et Apache pour la gestion des connexions TLS, vous pouvez mettre à jour la configuration SSL en modifiant cette ligne pour ajouter “+TLSv1.2 ” :
SSLProtocol -all +TLSv1 +TLSv1.1 +TLSv1.2
(Remarque : Étant donné qu'ils ne sont vraiment plus supportés nulle part, il est logique de supprimer également les paramètres 1.0 et 1.1 pendant que vous êtes ici.)
Cette configuration est généralement située dans /etc/httpd/conf.d/ssl.conf
Redémarrez Apache et vous êtes bon à aller.
service httpd restart
Si vous utilisez Nginx, vous voudrez modifier cette ligne de manière similaire :
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
Cette configuration est généralement située dans /etc/nginx/conf.d/
Redémarrez Nginx et vous êtes bon à aller.
service nginx restart
Si vous rencontrez des messages d'erreur lors du redémarrage, vous pourriez avoir une bibliothèque SSL obsolète. Assurez-vous d'utiliser au moins openssl v1.0.1g.
Si vous utilisez Windows, les instructions pour régler TLS 1.2 se trouvent dans la section “Vérification de la prise en charge dans Windows” ci-dessus.
Tout est bon maintenant ? Envoyez-nous un email et faites-nous savoir si vous avez réussi.
Faire un pas de plus
Pourquoi s'arrêter à TLS 1.2 quand vous savez - vous savez juste - que nous allons tous devoir passer à TLS 1.3 dans l'année qui vient. Pourquoi ne pas simplement passer à TLSv1.3 pendant que nous y sommes ?
Malheureusement, les ALB d'AWS ne prennent pas encore en charge TLS 1.3, donc si vous mettez à jour votre configuration, votre connexion à SparkPost et tout autre service AWS qui utilise la couche ALB restera limitée à TLS 1.2. Personnellement, je pense toujours que c'est une bonne idée de prendre de l'avance et de passer à 1.3 pendant que vous effectuez des modifications de toute façon.
Si vous souhaitez ajouter la prise en charge de TLS 1.3, vous devrez probablement d'abord mettre à jour votre bibliothèque OpenSSL à la version V1.1.1 ou ultérieure, puis ajouter +TLSv1.3 à la ligne de protocole mentionnée ci-dessus. Des instructions similaires peuvent être trouvées ici pour Nginx et Cloudflare également.
Restez en sécurité là-bas
Enfin, ce serait formidable si vous pouviez nous envoyer un email rapide pour nous faire savoir que vous avez vérifié que vous êtes capable de TLS 1.2. Nous ne voulons vraiment couper qui que ce soit et la date limite est septembre 2020. Si nous savons que vous êtes tous dans la zone de sécurité, nous nous sentirons beaucoup mieux à propos de l'arrêt du support ancien.