CUSTOMIZE Czy używasz TLS starszego niż 1.2? Nic nie szkodzi, opóźnienia w aktualizacjach konserwacyjnych zdarzają się każdemu. Rozumiemy to. Jednak nadszedł czas, aby iść dalej.
Czy używasz TLS starszego niż 1.2? To w porządku, opóźnienia w aktualizacjach konserwacyjnych zdarzają się każdemu. Rozumiemy to. Jednak nadszedł czas, aby przejść dalej.
Pamiętasz czerwiec 2018, kiedy przestaliśmy obsługiwać TLS 1.0? Jeśli nie pamiętasz, to nic, możesz o tym przeczytać w tym poście. No cóż, jesteśmy tutaj, 2 lata później, a kolejna wersja ma być wycofana, więc chcemy, abyś był przygotowany i uniknął każdego przestoju w usłudze. Ten post dotyczy tego, jak być przygotowanym do działania bez TLS1.1, abyśmy mogli ograniczyć dostęp jedynie do TLS1.2. Przeprowadzimy Cię przez proces sprawdzania obecnej wersji i jak zaktualizować ją do najnowszej. Dla zabawy, naprawdę chcielibyśmy usłyszeć Twoją opinię i dodać Cię na „ścianę świetności”, na której znajdą się wszystkie te firmy dbające o bezpieczeństwo, które dokonują zmiany wcześniej.
Czy to mnie dotyczy?
W 2018 roku poprosiliśmy naszych klientów o aktualizację, a TLS 1.2 było zaleceniem od dłuższego czasu, więc jest bardzo prawdopodobne, że NIE jesteś dotknięty. Jednak jeśli używasz jakiejkolwiek metody do wstrzykiwania wiadomości (SMTP lub REST API) lub zbierania danych (metryk lub webhooków, itp.), to naprawdę powinieneś teraz sprawdzić, czy Twój system może obsługiwać TLS 1.2. Upewnij się, że uruchamiasz następujące testy na serwerach, które faktycznie łączą się z SparkPost.
Dlaczego to jest ważne
Dlaczego teraz?
Właściwie pytanie powinno brzmieć „dlaczego wciąż go wspierasz?” TLS 1.2 jest zalecanym bezpiecznym standardem od ponad dekady i jesteśmy na etapie, gdy ktokolwiek rzeczywiście oferuje jakiekolwiek wsparcie dla czegokolwiek mniej niż TLS1.2. Nadszedł czas, aby słabe wsparcie HTTPS odeszło na zawsze. Jeśli nadal używasz TLS 1.1 po marcu 2020 roku, będziesz mieć trudności z łączeniem się z większością usług. SparkPost zapewnił wystarczająco dużo czasu na zaktualizowanie tego, a teraz wysyłamy ostateczne zawiadomienia, aby zaktualizować to przed wrześniem, kiedy to wyłączymy na dobre.
Ale jak, powiedz mi, można to naprawić?
Jest bardzo możliwe, że Twój IT SysAdmin lub WebAdmin zrobił to już dla Ciebie w ramach ich normalnej konserwacji. Jeśli tak, powinieneś kupić im piwo i podziękować. Jeśli nie, możesz wykonać poniższe kroki, aby zrobić to w Linuxie, Windowsie i Macu.
Zauważ, że w całym tym dokumencie przetestujemy z amerykańskim punktem końcowym SparkPost
Jeśli normalnie używasz europejskiej wersji, powinieneś używać punktu końcowego UE zamiast tego.
Jak można sprawdzić? (Linux version)
Najpierw sprawdźmy, czy Twój przyjazny lokalny SysAdmin już się tym zajął. To jest właściwie częścią konfiguracji SSL, więc można to zarządzać w konfiguracji systemowej. Zakładając, że używasz Linuxa, najbardziej opisową metodą jest użycie nmap, ale możesz również użyć openssl. Możesz użyć nmap z Linuxem, Windows i Mac, ale przyjrzymy się także innym metodom dla Windows i Mac, jeśli nie chcesz instalować nowego oprogramowania.
Aby to zrobić z nmap, przetestuj szyfry w stosunku do znanego hosta HTTPS. Ponieważ celem jest upewnienie się, że łączymy się bezpiecznie z SparkPost, przeprowadźmy test na tym punkcie końcowym. Upewnij się, że przeprowadzasz następujące testy na serwerach, które rzeczywiście łączą się z SparkPost.
nmap --script ssl-enum-ciphers -p 443 api.sparkpost.com
Zrobiłem to na własnym serwerze deweloperskim i łatwo możesz zobaczyć, że moja konfiguracja obsługuje TLS 1.1 i 1.2, ale nie 1.3. Ważne jest, aby zauważyć w tym momencie, że AWS ALBs, a zatem połączenia SparkPost, nie obsługują jeszcze TLS1.3, ale jest to na mapie drogowej AWS.
Rozpoczynanie Nmap 6.40 ( http://nmap.org ) w 2020-05-06 22:41 UTC Raport z skanowania Nmap dla api.sparkpost.com (52.13.246.255) Host jest w górze (opóźnienie 0,00059s). Inne adresy dla api.sparkpost.com (nie skanowane): 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 zapis rDNS dla 52.13.246.255: ec2-52-13-246-255.us-west-2.compute.amazonaws.com PORT STAN USŁUGA 443/tcp otwarty https | ssl-enum-ciphers: | TLSv1.1: | szyfry: | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - silny | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - silny | TLS_RSA_WITH_AES_128_CBC_SHA - silny | TLS_RSA_WITH_AES_256_CBC_SHA - silny | kompresory: | NULL | TLSv1.2: | szyfry: | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - silny | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 - silny | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - silny | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - silny | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 - silny | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - silny | TLS_RSA_WITH_AES_128_CBC_SHA - silny | TLS_RSA_WITH_AES_128_CBC_SHA256 - silny | TLS_RSA_WITH_AES_128_GCM_SHA256 - silny | TLS_RSA_WITH_AES_256_CBC_SHA - silny | TLS_RSA_WITH_AES_256_CBC_SHA256 - silny | TLS_RSA_WITH_AES_256_GCM_SHA384 - silny | kompresory: | NULL |_ najsłabsza siła: silny Skanowanie Nmap zakończone: przeskanowano 1 adres IP (1 host w górze) w 0,11 sekundy
W tym momencie możesz faktycznie przestać, jeśli chcesz, ponieważ celem jest upewnienie się, że możesz połączyć się ze SparkPost za pomocą TLS 1.2. Jeśli twoje połączenie obsługuje TLS 1.2 to jest to, czego potrzebujemy w tym momencie, więc wszystko jest tutaj dobrze. Idź kupić temu SysAdminowi piwo i podziękuj.
Wyślij do nas email i daj nam znać, że Ci się udało.
Sprawdzanie wsparcia na twoim Mac
Najczęstszym powodem, dla którego możesz potrzebować sprawdzić wsparcie na swoim Macu, jest to, że używasz go do lokalnego rozwoju, więc załóżmy to i sprawdź swoje wsparcie.
Najmniej inwazyjną metodą jest użycie curl, który powinien być wbudowany w każdego Maca. Uruchom aplikację Terminal i użyj flagi protokołu, aby przetestować konkretnie TLS1.2.
curl https://api.sparkpost.com/ --tlsv1.2 --verbose * Próba połączenia 54.213.185.174... * Ustawiono TCP_NODELAY * Połączono z api.sparkpost.com (54.213.185.174) port 443 (#0) * ALPN, oferowanie h2 * ALPN, oferowanie http/1.1 * Wybór szyfrów: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH * Pomyślnie ustawiono lokalizacje zweryfikować certyfikat: * CAfile: /etc/ssl/cert.pem CApath: none * TLSv1.2 (OUT), Uścisk dłoni TLS, Klient hello (1): * TLSv1.2 (IN), Uścisk dłoni TLS, Serwer hello (2): * TLSv1.2 (IN), Uścisk dłoni TLS, Certyfikat (11): * TLSv1.2 (IN), Uścisk dłoni TLS, Wymiana klucza serwera (12): * TLSv1.2 (IN), Uścisk dłoni TLS, Serwer zakończony (14): * TLSv1.2 (OUT), Uścisk dłoni TLS, Wymiana klucza klienta (16): * TLSv1.2 (OUT), TLS zmienia szyfr, Klient hello (1): * TLSv1.2 (OUT), Uścisk dłoni TLS, Zakończono (20): * TLSv1.2 (IN), TLS zmienia szyfr, Klient hello (1): * TLSv1.2 (IN), Uścisk dłoni TLS, Zakończono (20): * Połączenie SSL używa TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256 * ALPN, serwer zaakceptował użycie h2 * Certyfikat serwera: * subject: CN=*.sparkpost.com * data rozpoczęcia: 30 stycznia 2020 00:00:00 GMT * data wygaśnięcia: 28 lutego 2021 12:00:00 GMT * subjectAltName: host "api.sparkpost.com" pasujący certyfikat "*.sparkpost.com" * nadawca: C=US; O=Amazon; OU=Server CA 1B; CN=Amazon * Weryfikacja certyfikatu SSL ok. * Używanie HTTP2, serwer wspiera multi-use * Zmiana stanu połączenia potwierdzona (HTTP/2) * Kopiowanie danych HTTP/2 w buforze strumienia do bufora połączenia po aktualizacji: len=0 * Używanie Stream ID: 1 (łatwa rączka 0x7fbd69805200) > GET / HTTP/2 > Host: api.sparkpost.com > User-Agent: curl/7.54.0 > Accept: */* > * Zmiana stanu połączenia (MAX_CONCURRENT_STREAMS zaktualizowany)! < HTTP/2 200 < data: cz, 07 maja 2020 15:14:30 GMT < typ zawartości: text/plain < długość zawartości: 95 < serwer: msys-http < * Połączenie #0 do hosta api.sparkpost.com zostało zakończone Oh hey! Powinieneś dołączyć do nas i budować niesamowite rzeczy!
Jeśli chcesz przetestować przy użyciu połączenia SMTP, możesz to zrobić za pomocą tej komendy:
openssl s_client -crlf -starttls smtp -tls1_2 -connect smtp.sparkpostmail.com:587
Zwroty zawierają wiele danych w tym:
SSL-Session: Protokół: TLSv1.2 Szyfr: ECDHE-RSA-AES256-GCM-SHA384
Sprawdzanie wsparcia w Windows
Podobnie jak w przypadku użycia Mac, najczęstszym powodem, dla którego możesz potrzebować sprawdzić wsparcie w swoim Windows, jest to, że używasz go do rozwoju lokalnego, więc przyjmijmy to założenie i sprawdźmy twoje wsparcie.
Windows 7 i Windows 10 używają zasadniczo tego samego procesu. Jeśli używasz czegoś wcześniejszego, zaktualizuj swoją wersję, ponieważ wcześniejsze wersje nie obsługują TLS 1.2.
Zacznij od kliknięcia START w lewym dolnym rogu (zazwyczaj).
Wpisz „Opcje internetowe” i wybierz dopasowanie z listy wynikowej.
Kliknij kartę Zaawansowane i przewiń na sam dół. Jeśli TLS 1.2 jest zaznaczone, wszystko jest już gotowe. Jeśli nie, zaznacz pole obok Użyj TLS 1.2, a następnie Zastosuj.
Czekaj, co? Nie 1.2?
Przykro mi, kolego. Twoja praca nie jest jeszcze skończona.
Jeśli masz tylko TLS1.1, powinieneś zaktualizować ustawienia Cipher.
Zakładając, że używasz Linuxa i Apache do zarządzania połączeniem TLS, możesz zaktualizować konfigurację SSL, modyfikując tę linię, aby dodać „+TLSv1.2”:
SSLProtocol -all +TLSv1 +TLSv1.1 +TLSv1.2
(Dygresja: Ponieważ nie są już naprawdę wspierane, ma sens również usunięcie ustawień 1.0 i 1.1, gdy już tu jesteś.)
Tę konfigurację zazwyczaj można znaleźć w /etc/httpd/conf.d/ssl.conf
Zrestartuj Apache i będzie gotowe.
service httpd restart
Jeśli używasz Nginx, będziesz chciał zmodyfikować tę linię w podobny sposób:
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
Tę konfigurację zazwyczaj można znaleźć w /etc/nginx/conf.d/
Zrestartuj Nginx i będzie gotowe.
service nginx restart
Jeśli napotkasz jakiekolwiek komunikaty o błędach podczas restartu, możesz mieć przestarzałą bibliotekę SSL. Upewnij się, że używasz co najmniej openssl v1.0.1g.
Jeśli używasz Windows, instrukcje dotyczące ustawienia TLS1.2 znajdują się w sekcji „Checking for support in Windows” powyżej.
Czy wszystko gotowe? Wyślij nam email i daj znać, że się udało.
Idąc o krok dalej
Dlaczego zatrzymywać się na TLS 1.2, kiedy wiesz – po prostu wiesz – że wszyscy będziemy musieli przejść na TLS 1.3 w ciągu najbliższego roku lub dwóch. Dlaczego nie przejść od razu na TLSv1.3, skoro już przy tym jesteśmy?
Niestety, AWS ALBs nie obsługują jeszcze TLS1.3, więc jeśli zaktualizujesz swoją konfigurację, twoje połączenie z SparkPost i innymi usługami AWS, które korzystają z warstwy ALB, będzie nadal ograniczone do TLS1.2. Osobiście uważam, że warto wyprzedzać trendy i zaktualizować do wersji 1.3, skoro i tak dokonujesz zmian.
Jeśli chcesz dodać obsługę TLS 1.3, prawdopodobnie będziesz musiał najpierw zaktualizować swoją bibliotekę OpenSSL do wersji V1.1.1 lub nowszej, a następnie dodać +TLSv1.3 do wspomnianej linii protokołu. Podobne instrukcje można znaleźć tutaj również dla Nginx i Cloudflare.
Bądźcie tam bezpieczni
W końcu, byłoby wspaniale, gdybyś mógł przesłać nam szybkiego e-maila, aby dać nam znać, że potwierdziłeś swoją zdolność do obsługi TLS 1.2. Naprawdę nie chcemy nikogo odciąć, a ostateczny termin to wrzesień 2020. Jeśli wiemy, że wszyscy jesteście w bezpiecznej strefie, poczujemy się znacznie lepiej, wyłączając stare wsparcie.
