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, jak w czerwcu 2018 roku znieśliśmy użycie TLS 1.0? Jeśli nie, to w porządku, możesz poczytać o tym w tym poście. Cóż, oto jesteśmy, 2 lata później, a następna wersja ma zostać odstawiona na bok, więc chcemy, abyś był przygotowany i unikał jakichkolwiek przerw w usłudze. Ten post jest całkowicie poświęcony temu, aby przygotować cię do działania bez użycia TLS 1.1, abyśmy mogli ograniczyć dostęp tylko do TLS 1.2. Poprowadzimy cię przez to, jak sprawdzić swoją obecną wersję i jak zaktualizować do najnowszej. Tak tylko dla zabawy, naprawdę chcielibyśmy usłyszeć twój feedback i dodać cię do "ściany wyjątkowości" z wszystkimi tymi świadomymi bezpieczeństwa firmami, które dokonują zmiany wcześnie.
Czy to mnie dotyczy?
W 2018 roku poprosiliśmy naszych klientów o aktualizację, a TLS 1.2 jest rekomendowanym standardem już od dłuższego czasu, więc bardzo prawdopodobne, że NIE jesteś dotknięty. Jednak jeśli korzystasz z jakiejkolwiek metody do wstrzykiwania wiadomości (SMTP lub REST API) lub zbierania danych (metryki lub webhooki itp.), powinieneś teraz sprawdzić, aby upewnić się, że twój system może obsługiwać TLS 1.2. Upewnij się, że przeprowadzasz następujące testy na serwerach, które rzeczywiście łączą się z SparkPost.
Dlaczego to ważne
SparkPost nie będzie akceptować połączeń na TLS 1.1 po wrześniu 2020 roku
Starsze wersje nie są bezpieczne
TLS 1.2 jest rekomendowanym protokołem od ponad dekady
Wszyscy fajni ludzie to robią
Dlaczego teraz?
Tak naprawdę pytanie powinno brzmieć: dlaczego nadal to wspierasz? TLS 1.2 jest rekomendowanym bezpiecznym standardem od ponad dekady, a teraz dotarliśmy do granicy, gdzie praktycznie nikt nie oferuje wsparcia dla czegokolwiek poniżej TLS 1.2. Czas na słabe wsparcie HTTPS, aby zniknęło raz na zawsze. Jeśli nadal korzystasz z TLS 1.1 po marcu 2020 roku, będziesz miał trudności z łączeniem się z większością usług. SparkPost zapewnił wystarczająco dużo czasu, aby to zaktualizować, a teraz wysyłamy ostateczne powiadomienia, aby to zaktualizować przed wrześniem, kiedy to wyłączymy raz na zawsze.
Ale jak, prośbę mówiąc, możesz to naprawić?
Jest bardzo prawdopodobne, że twój administrator IT lub administrator sieci zrobił to już za ciebie w ramach swojej normalnej konserwacji. Jeśli tak, powinieneś kupić im piwo i powiedzieć dziękuję. Jeśli nie, możesz wykonać niektóre z poniższych kroków, aby to zrobić w Linuxie, Windowsie i Macu.
Zauważ, że w tym dokumencie przetestujemy z punktem końcowym SparkPost w USA.
Jeśli zwykle korzystasz z europejskiego wdrożenia, powinieneś użyć punktu końcowego UE zamiast tego.
Jak możesz to sprawdzić? (wersja Linux)
Pierwsze, sprawdźmy, czy twój życzliwy sąsiedzki administrator systemu już się tym zajął. To jest w rzeczywistości część konfiguracji SSL, więc można to zarządzać w konfiguracji systemu. Zakładając, że używasz Linuxa, najbardziej opisowa metoda to użycie nmap, ale możesz także użyć openssl. Możesz używać nmap w Linuxie, Windowsie i Macu, ale również zbadamy inne metody dla Windows i Maców, jeśli nie chcesz instalować nowego oprogramowania.
Aby to zrobić za pomocą nmap, przetestuj szyfry przeciwko znanemu hoście HTTPS. Ponieważ celem jest zapewnienie, że łączymy się z SparkPost w sposób bezpieczny, przetestujmy z tym punktem końcowym. Upewnij się, że wykonujesz następujące testy na serwerach, które rzeczywiście łączą się z SparkPost.
nmap --script ssl-enum-ciphers -p 443 api.sparkpost.com
To zostało zrobione na moim własnym serwerze deweloperskim i możesz łatwo zobaczyć, że moja konfiguracja wspiera TLS 1.1 i 1.2, ale nie 1.3. Ważne jest, aby zauważyć w tym momencie, że AWS ALB i zatem połączenia SparkPost, jeszcze nie obsługują TLS 1.3, ale jest to na liście AWS.
Rozpoczęcie Nmap 6.40 ( http://nmap.org ) w 2020-05-06 22:41 UTC Raport skanowania Nmap dla api.sparkpost.com (52.13.246.255) Host jest aktywny (0.00059s latencji). 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 rDNS record dla 52.13.246.255: ec2-52-13-246-255.us-west-2.compute.amazonaws.com PORT STAN USŁUGA 443/tcp otwarte https | ssl-enum-ciphers: | TLSv1.1: | szyfry: | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - mocny | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - mocny | TLS_RSA_WITH_AES_128_CBC_SHA - mocny | TLS_RSA_WITH_AES_256_CBC_SHA - mocny | kompresory: | NULL | TLSv1.2: | szyfry: | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - mocny | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 - mocny | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - mocny | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - mocny | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 - mocny | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - mocny | TLS_RSA_WITH_AES_128_CBC_SHA - mocny | TLS_RSA_WITH_AES_128_CBC_SHA256 - mocny | TLS_RSA_WITH_AES_128_GCM_SHA256 - mocny | TLS_RSA_WITH_AES_256_CBC_SHA - mocny | TLS_RSA_WITH_AES_256_CBC_SHA256 - mocny | TLS_RSA_WITH_AES_256_GCM_SHA384 - mocny | kompresory: | NULL |_ najmocniejsza siła: mocna Nmap zakończone: 1 adres IP (1 host aktywny) skanowanie zajęło 0.11 sekundy
W tym momencie możesz właściwie przestać, jeśli chcesz, ponieważ celem jest upewnienie się, że możesz połączyć się z SparkPost przy użyciu TLS 1.2. Jeśli twoje połączenie obsługuje TLS 1.2, to jest to, czego potrzebujemy w tym momencie, więc wszystko dobrze. Kup temu administratorowi systemu piwo i powiedz dziękuję.
Wyślij nam email i daj nam znać, że ci się udało.
Sprawdzanie wsparcia na Macu
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, że tak jest i sprawdźmy twoje wsparcie.
Najmniej inwazyjną metodą jest użycie curl, który powinien być zainstalowany w każdym Macu. Uruchom aplikację Terminal i użyj flagi protokołu, aby przetestować konkretnie dla TLS 1.2.
curl https://api.sparkpost.com/ --tlsv1.2 --verbose * Próbując 54.213.185.174... * TCP_NODELAY ustawione * Połączono z api.sparkpost.com (54.213.185.174) port 443 (#0) * ALPN, oferując h2 * ALPN, oferując http/1.1 * Wybór szyfrów: WSZYSTKIE:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH * pomyślnie ustawiono lokalizacje weryfikacji certyfikatu: * CAfile: /etc/ssl/cert.pem CApath: brak * TLSv1.2 (OUT), TLS handshake, Klient mówi cześć (1): * TLSv1.2 (IN), TLS handshake, Serwer mówi cześć (2): * TLSv1.2 (IN), TLS handshake, Certyfikat (11): * TLSv1.2 (IN), TLS handshake, Wymiana klucza serwera (12): * TLSv1.2 (IN), TLS handshake, Serwer zakończony (14): * TLSv1.2 (OUT), TLS handshake, Wymiana klucza klienta (16): * TLSv1.2 (OUT), TLS zmiana szyfru, Klient mówi cześć (1): * TLSv1.2 (OUT), TLS handshake, Zakończono (20): * TLSv1.2 (IN), TLS zmiana szyfru, Klient mówi cześć (1): * TLSv1.2 (IN), TLS handshake, Zakończono (20): * Połączenie SSL przy użyciu TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256 * ALPN, serwer zaakceptował użycie h2 * Certyfikat serwera: * podmiot: CN=*.sparkpost.com * data początkowa: 30 stycznia 00:00:00 2020 GMT * data wygaśnięcia: 28 lutego 12:00:00 2021 GMT * subjectAltName: host "api.sparkpost.com" dopasowany do certyfikatu "*.sparkpost.com" * wystawca: C=US; O=Amazon; OU=Server CA 1B; CN=Amazon * Weryfikacja certyfikatu SSL ok. * Używając HTTP2, serwer obsługuje wiele użyć * Stan połączenia zmieniony (HTTP/2 potwierdzony) * Kopiowanie danych HTTP/2 w buforze strumieniowym do bufora połączenia po aktualizacji: len=0 * Używając ID Strumienia: 1 (łatwy uchwyt 0x7fbd69805200) > GET / HTTP/2 > Host: api.sparkpost.com > User-Agent: curl/7.54.0 > Accept: */* > * Stan połączenia zmieniony (MAX_CONCURRENT_STREAMS zaktualizowany)! < HTTP/2 200 < data: czwartek, 07 maja 2020 15:14:30 GMT < content-type: text/plain < content-length: 95 < server: msys-http < * Połączenie #0 z hostem api.sparkpost.com pozostało nienaruszone Cześć! Powinieneś z nami pracować i budować niesamowite rzeczy!
Jeśli chcesz przetestować używając połączenia SMTP, możesz to również zrobić za pomocą tego polecenia:
openssl s_client -crlf -starttls smtp -tls1_2 -connect smtp.sparkpostmail.com:587
Zwraca wiele danych, w tym:
SSL-Session: Protokół : TLSv1.2 Szyfr : ECDHE-RSA-AES256-GCM-SHA384
Sprawdzanie wsparcia w Windows
Podobnie jak w przypadku Maca, najczęstszym powodem, dla którego możesz potrzebować sprawdzić wsparcie w swoim Windowsie, jest to, że używasz go do lokalnego rozwoju, więc załóżmy, że tak jest i sprawdźmy twoje wsparcie.
Windows 7 i Windows 10 używają zasadniczo tego samego procesu. Jeśli używasz czegoś wcześniejszego, proszę zaktualizować, ponieważ wcześniejsze wersje nie obsługują TLS 1.2.
Zacznij od kliknięcia START w lewym dolnym rogu (zwykle).
Wpisz "Opcje internetowe" i wybierz pasującą opcję z listy wyników.
Kliknij zakładkę Zaawansowane, a następnie przewiń na sam dół. Jeśli protokół TLS 1.2 jest zaznaczony, jesteś już gotowy. Jeśli nie, zaznacz pole obok Użyj TLS 1.2, a następnie Zastosuj.
Chwileczkę, co? Nie 1.2?
Szkoda kolego. Twoja praca jeszcze się nie skończyła.
Jeśli masz tylko TLS 1.1, powinieneś zaktualizować swoje ustawienia szyfru.
Zakładając, że korzystasz z 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
(dodatkowa informacja: Ponieważ nie są już w rzeczywistości obsługiwane, sensownie jest również usunąć ustawienia 1.0 i 1.1 podczas gdy jesteś w tej konfiguracji.)
Ta konfiguracja jest zazwyczaj zlokalizowana w /etc/httpd/conf.d/ssl.conf
Uruchom ponownie Apache i jesteś gotów do działania.
service httpd restart
Jeśli używasz Nginx, będziesz chciał w ten sam sposób zmodyfikować tę linię:
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
Ta konfiguracja jest zazwyczaj zlokalizowana w /etc/nginx/conf.d/
Uruchom ponownie Nginx i jesteś gotów do działania.
service nginx restart
Jeśli napotkasz jakiekolwiek komunikaty o błędach podczas ponownego uruchamiania, możesz mieć przestarzałą bibliotekę SSL. Upewnij się, że używasz przynajmniej openssl v1.0.1g.
Jeśli używasz Windowsa, instrukcje dotyczące ustawienia TLS 1.2 znajdują się w powyższej sekcji „Sprawdzanie wsparcia w Windows”.
Już wszystko gotowe? Wyślij nam email i daj nam znać, że ci się udało.
Idąc o krok dalej
Dlaczego zatrzymywać się na TLS 1.2, gdy wiesz – tylko wiesz – że wszyscy będziemy musieli przejść na TLS 1.3 w ciągu najbliższego roku lub dwa. Dlaczego nie przejść od razu na TLSv1.3?
Niestety, AWS ALB jeszcze nie obsługuje TLS 1.3, więc jeśli zaktualizujesz swoją konfigurację, twoje połączenie z SparkPost i każda inna usługa AWS, która korzysta z warstwy ALB, nadal będzie ograniczone do TLS 1.2. Osobiście nadal uważam, że to dobry pomysł, aby wyprzedzić konkurencję i przejść na 1.3, gdy już dokonujesz zmian.
Jeśli chcesz dodać wsparcie dla 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 linii protokołu wspomnianej powyżej. Podobne instrukcje można znaleźć tutaj dla Nginx i Cloudflare.
Zachowaj bezpieczeństwo
Na koniec, byłoby świetnie, gdybyś mógł wysłać nam szybki email, aby dać nam znać, że potwierdziłeś, że możesz obsługiwać TLS 1.2. Naprawdę nie chcemy nikogo odcinać, a ostateczny termin to wrzesień 2020. Jeśli wiemy, że wszyscy są w strefie bezpieczeństwa, będziemy się czuć o wiele lepiej, wyłączając starą obsługę.