CUSTOMIZE Utilisez-vous TLS plus ancien que 1.2 ? C’est bon, les retards de mise à jour de maintenance arrivent à tout le monde. Nous comprenons. Cependant, il est temps de passer à autre chose.
Business in a box.
Découvrez nos solutions.
Parlez à notre équipe de vente
Utilisez-vous TLS plus ancien que 1.2 ? Ce n’est pas grave, les retards de mise à jour de maintenance arrivent à tout le monde. Nous 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 tout lire à ce sujet dans ce post. Eh bien, nous y sommes, 2 ans plus tard et la prochaine version est sur le point d'être mise de côté, donc nous voulons que vous soyez préparé et évitiez toute interruption de service. Ce post est tout à fait destiné à vous préparer à fonctionner sans l'utilisation de TLS1.1 afin que nous puissions restreindre l'accès uniquement à TLS1.2. Nous vous guiderons pour vérifier votre version actuelle et comment effectuer la mise à niveau vers la dernière version. Pour le plaisir, nous aimerions vraiment entendre vos retours et vous ajouter à un "mur de l’excellence" mettant en vedette toutes ces entreprises soucieuses de la sécurité qui effectuent le changement en avance.
Cela me concerne-t-il ?
En 2018, nous avons demandé à nos clients de mettre à niveau, et TLS 1.2 a été la recommandation depuis un certain temps, il est donc très probable que vous ne soyez PAS affecté. Cependant, si vous utilisez une méthode pour injecter des messages (SMTP ou REST API) ou collecter 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 de lancer les tests suivants sur les serveurs qui se connectent réellement à SparkPost.
Pourquoi c'est important
Pourquoi maintenant?
En fait, la question devrait être «pourquoi le soutenez-vous encore?» TLS 1.2 est la norme sécurisée recommandée depuis plus d'une décennie et nous sommes à la limite de quiconque offrant encore un support pour quoi que ce soit de moins que TLS 1.2. Il est temps pour le support HTTPS faible de disparaître une fois pour toutes. Si vous utilisez encore TLS 1.1 après mars 2020, vous allez avoir du mal à vous connecter à la plupart des services. SparkPost a accordé suffisamment de temps pour mettre cela à jour et maintenant nous envoyons les notifications finales pour effectuer cette mise à niveau avant septembre, lorsque nous l'arrêterons définitivement.
Mais comment, je vous prie, pouvez-vous le réparer ?
Il est très possible que votre IT SysAdmin ou WebAdmin l'ait déjà fait pour vous dans le cadre de leur maintenance habituelle. Si c'est le cas, vous devriez leur offrir une bière et dire merci. Sinon, vous pouvez suivre certaines des étapes ci-dessous pour l'effectuer sous Linux, Windows et Mac.
Notez qu'au cours de ce document, nous testerons avec le point de terminaison US SparkPost.
Si vous utilisez normalement le déploiement européen, vous devriez utiliser le point de terminaison EU à la place.
Comment pouvez-vous vérifier ? (version Linux)
Tout d'abord, vérifions si votre aimable SysAdmin du quartier s'est déjà occupé 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 est d'utiliser nmap, mais vous pouvez également utiliser openssl. Vous pouvez utiliser nmap avec Linux, Windows et Mac, mais nous explorerons également d'autres méthodes pour Windows et Mac si vous ne souhaitez pas installer de nouveaux logiciels.
Pour faire cela avec nmap, testez les chiffrements contre un hôte HTTPS connu. Puisque le but est de s'assurer que nous nous connectons à SparkPost de manière sécurisée, testons cet endpoint. Assurez-vous d'exécuter les tests suivants sur les serveurs qui se connectent effectivement à 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 que les ALB d'AWS, et donc les connexions SparkPost, ne prennent pas encore en charge TLS 1.3, mais cela figure sur la feuille de route AWS.
Démarrage de Nmap 6.40 ( http://nmap.org ) le 2020-05-06 22:41 UTC Rapport d'analyse Nmap pour api.sparkpost.com (52.13.246.255) Hôte est en ligne (latence 0.00059s). Autres adresses pour api.sparkpost.com (non analysé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 open 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: | AUCUN | 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: | AUCUN |_ force la plus faible: fort Nmap done: 1 adresse IP (1 hôte en ligne) analysée en 0.11 secondes
À ce stade, vous pouvez effectivement vous arrêter si vous le souhaitez, car le point est de vous assurer que vous êtes capable de 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 va bien ici. Allez acheter une bière à ce SysAdmin et dites-lui merci.
Envoyez-nous un email et faites-nous savoir que vous avez réussi.
Vérification du support sur votre Mac
La raison la plus courante pour laquelle vous pourriez avoir besoin de vérifier le support sur votre Mac est que vous l'utilisez pour le développement local, supposons donc cela et vérifions votre support.
La méthode la moins invasive est d'utiliser curl qui devrait être intégré dans chaque Mac. Lancez l'application Terminal et utilisez l'indicateur de protocole pour tester spécifiquement TLS1.2.
curl https://api.sparkpost.com/ --tlsv1.2 --verbose * Tentative de connexion à 54.213.185.174... * TCP_NODELAY activé * Connecté à api.sparkpost.com (54.213.185.174) port 443 (#0) * ALPN, offre h2 * ALPN, offre http/1.1 * Sélection de chiffre : ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH * emplacement de vérification de certificat défini avec succès : * CAfile : /etc/ssl/cert.pem CApath : aucun * TLSv1.2 (SORTANT), poignée de main TLS, Client hello (1) : * TLSv1.2 (ENTRANT), poignée de main TLS, Serveur hello (2) : * TLSv1.2 (ENTRANT), poignée de main TLS, Certificat (11) : * TLSv1.2 (ENTRANT), poignée de main TLS, Échange de clé serveur (12) : * TLSv1.2 (ENTRANT), poignée de main TLS, Serveur terminé (14) : * TLSv1.2 (SORTANT), poignée de main TLS, Échange de clé client (16) : * TLSv1.2 (SORTANT), changement de chiffre TLS, Client hello (1) : * TLSv1.2 (SORTANT), poignée de main TLS, Terminé (20) : * TLSv1.2 (ENTRANT), changement de chiffre TLS, Client hello (1) : * TLSv1.2 (ENTRANT), 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 janvier 2020 00:00:00 GMT * date d'expiration : 28 février 2021 12:00:00 GMT * nomSubjectAlt : l'hôte "api.sparkpost.com" correspond au certificat "*.sparkpost.com" * émetteur : C=US; O=Amazon; OU=Server CA 1B; CN=Amazon * Vérification du certificat SSL réussie. * Utilisation de HTTP2, le serveur prend en charge l'utilisation multiple * Changement d'état de la connexion (HTTP/2 confirmé) * Copie des données HTTP/2 dans le tampon de flux pour la connexion après mise à niveau : long=0 * Utilisation de l'ID de flux : 1 (manipulation facile 0x7fbd69805200) > GET / HTTP/2 > Hôte: api.sparkpost.com > Agent utilisateur: curl/7.54.0 > Accept: */* > * Changement d'état de la connexion (MAX_CONCURRENT_STREAMS mis à jour)! < HTTP/2 200 < date: Thu, 07 May 2020 15:14:30 GMT < type de contenu: text/plain < longu🚀uiste du contenu: 95 < serveur : msys-http < * Connexion #0 à l'hôte api.sparkpost.com laissée intacte Oh salut! Vous devriez venir travailler avec nous et créer des trucs géniaux !
Si vous souhaitez 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
Renvoie une grande quantité de données comprenant :
SSL-Session: Protocole : TLSv1.2 Chiffre : ECDHE-RSA-AES256-GCM-SHA384
Vérification du support dans Windows
Similaire au cas d'utilisation sur Mac, la raison la plus courante pour laquelle vous pourriez avoir besoin de vérifier le support dans votre Windows est que vous l'utilisez pour le développement local, donc supposons cela et vérifions votre support.
Windows 7 et Windows 10 utilisent essentiellement le même processus. Si vous utilisez quelque chose de plus ancien, veuillez mettre à niveau 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 (habituellement).
Tapez "Options Internet" et sélectionnez la correspondance dans la liste résultante.
Cliquez sur l'onglet Avancé et à partir de 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 et ensuite Appliquer.
Attendez, quoi ? Pas de 1.2 ?
C’est dommage mec. Votre travail n'est pas encore terminé.
Si vous n'avez que TLS1.1, alors vous devriez mettre à jour vos paramètres de chiffrement.
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
(Note de côté : Étant donné qu'ils ne sont plus vraiment pris en charge nulle part, il est logique de retirer aussi les paramètres 1.0 et 1.1 pendant que vous y êtes.)
Cette configuration est généralement située dans /etc/httpd/conf.d/ssl.conf
Redémarrez Apache et vous êtes prêt à partir.
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 se trouve généralement dans /etc/nginx/conf.d/
Redémarrez Nginx et vous êtes prêt à partir.
service nginx restart
Si vous rencontrez des messages d'erreur lors du redémarrage, vous avez peut-être une bibliothèque SSL obsolète. Assurez-vous d'utiliser au moins openssl v1.0.1g.
Si vous utilisez Windows, les instructions pour configurer TLS1.2 se trouvent dans la section “Vérification de la prise en charge sous Windows” ci-dessus.
Tout est terminé maintenant ? Envoyez-nous un email et faites-nous savoir que vous avez réussi.
Aller un pas plus loin
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 ou les deux à venir. Pourquoi ne pas simplement passer à TLSv1.3 pendant que vous y êtes?
Malheureusement, les ALB d'AWS ne supportent pas encore TLS1.3, donc si vous mettez à jour votre configuration, votre connexion à SparkPost et à tout autre service AWS utilisant la couche ALB sera encore limitée à TLS1.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 changements 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é dehors
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 pas couper qui que ce soit et la date limite est septembre 2020. Si nous savons que vous êtes tous en zone de sécurité, nous nous sentirons beaucoup mieux d'arrêter l'ancien support.
