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.
Business in a box.
Odkryj nasze rozwiązania.
Porozmawiaj z naszym zespołem sprzedaży
Czy używasz TLS starszego niż 1.2? W porządku, opóźnienia w aktualizacjach mogą się każdemu zdarzyć. Rozumiemy to. Jednak teraz czas na zmianę.
Pamiętasz jeszcze czerwiec 2018, kiedy wycofaliśmy użycie TLS 1.0? Jeśli nie, to nic nie szkodzi, możesz przeczytać o tym w tym poście. No cóż, jesteśmy teraz 2 lata później, a kolejna wersja jest bliska wycofania, więc chcemy, abyś był przygotowany i uniknął jakichkolwiek przerw w działaniu. Ten post dotyczy przygotowania cię do pracy bez użycia TLS 1.1, abyśmy mogli ograniczyć dostęp tylko do TLS 1.2. Przeprowadzimy cię przez sposób sprawdzenia aktualnej wersji oraz sposób aktualizacji do najnowszej. Tak dla zabawy, chcielibyśmy naprawdę usłyszeć twoją opinię i dodać cię do „ściany wspaniałości” prezentującej wszystkie firmy dbające o bezpieczeństwo, które dokonają zmiany wcześnie.
Czy to mnie dotyczy?
Już w 2018 roku poprosiliśmy naszych klientów o aktualizację, a TLS 1.2 jest zalecany od jakiegoś czasu, więc bardzo prawdopodobne jest, że NIE jesteś dotknięty. Jednak jeśli używasz jakiejkolwiek metody do wstrzykiwania wiadomości (SMTP lub REST API) lub zbierania danych (metryki lub webhooki itp.), to naprawdę powinieneś teraz sprawdzić, czy Twój system może obsługiwać TLS 1.2. Upewnij się, że przeprowadzasz następujące testy na serwerach, które faktycznie łączą się z SparkPost.
Dlaczego to jest ważne
SparkPost nie będzie akceptować połączeń na TLS 1.1 po wrześniu 2020
Starsze wersje nie są bezpieczne
TLS 1.2 jest zalecanym protokołem od ponad dekady
Wszyscy fajni ludzie tak robią
Dlaczego teraz?
Właściwie pytanie powinno brzmieć „czemu nadal go wspierasz?” TLS 1.2 jest zalecanym bezpiecznym standardem od ponad dekady i jesteśmy na etapie, kiedy ktokolwiek w ogóle oferuje jakiekolwiek wsparcie dla czegokolwiek mniej niż TLS1.2. Czas, aby słabe wsparcie HTTPS umarło raz na zawsze. Jeśli nadal używasz TLS 1.1 po marcu 2020 r., będziesz miał trudności z łączeniem się z większością usług. SparkPost zapewnił wystarczająco dużo czasu na aktualizację, a teraz wysyłamy ostateczne powiadomienia, aby dokonać tej aktualizacji przed wrześniem, kiedy to usuniemy 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 Mac, najczęstszym powodem, dla którego możesz potrzebować sprawdzić wsparcie w swoim Windows, jest to, że używasz go do lokalnego rozwoju, więc załóżmy to i sprawdźmy Twoje wsparcie.
Windows 7 i Windows 10 używają w zasadzie tego samego procesu. Jeśli używasz czegoś starszego, zaktualizuj, 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 odpowiedni wynik z wyświetlonej listy.
Kliknij kartę Zaawansowane, a następnie przewiń do samego dołu. Jeśli TLS 1.2 jest zaznaczone, to już jesteś gotowy. Jeśli nie jest, 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, gdy wiesz – po prostu wiesz – że wszyscy będziemy musieli zaktualizować do TLS 1.3 w ciągu najbliższego roku lub mniej. Dlaczego po prostu nie zaktualizować do TLSv1.3, skoro już to robimy?
Niestety, AWS ALB nie obsługują jeszcze TLS1.3, więc jeśli zaktualizujesz swoją konfigurację, twoje połączenie ze SparkPost i każdą inną usługą AWS używającą warstwy ALB będzie nadal ograniczone do TLS1.2. Osobiście wciąż uważam, że to dobry pomysł, aby wyprzedzić krzywą i zaktualizować do 1.3, robiąc przy okazji inne zmiany.
Jeśli chcesz dodać obsługę TLS 1.3, prawdopodobnie będziesz musiał najpierw zaktualizować swoją bibliotekę OpenSSL do 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.
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.
