Przejście na TLS 1.2

Inżynieria

·

20 maj 2020

Przejście na TLS 1.2

Najważniejsze informacje

    • TLS 1.1 jest oficjalnie wycofywany. Bird (dawniej SparkPost) już nie obsługuje połączeń z użyciem TLS 1.1 po wrześniu 2020. Wszystkie systemy muszą obsługiwać TLS 1.2 lub wyższy, aby utrzymać bezpieczne połączenie.

    • Dlaczego aktualizacja ma znaczenie: TLS 1.2 jest rekomendowanym protokołem od ponad dekady. Oferuje silniejsze szyfrowanie, lepszą wydajność i zgodność z nowoczesnymi standardami bezpieczeństwa, podczas gdy starsze wersje są podatne na ataki.

    • Jak sprawdzić swój system:

      • Linux: Użyj nmap --script ssl-enum-ciphers -p 443 api.sparkpost.com lub openssl, aby zweryfikować wsparcie protokołu.

      • macOS: Uruchom curl https://api.sparkpost.com/ --tlsv1.2 --verbose w Terminalu.

      • Windows: Przejdź do Opcje internetowe → Zaawansowane i upewnij się, że zaznaczone jest „Użyj TLS 1.2”.

    • Jak włączyć TLS 1.2:

      • Na Apache zaktualizuj konfigurację SSL: SSLProtocol -all +TLSv1.2

      • Na Nginx zmodyfikuj ssl_protocols TLSv1.2; i zrestartuj swoją usługę.

    • Dlaczego nie TLS 1.3 (jeszcze)? Choć TLS 1.3 jest następnym krokiem naprzód, AWS Application Load Balancers (używane przez SparkPost/Bird) nie obsługiwały go w tym czasie. Mimo to, aktualizacja OpenSSL do v1.1.1+ przygotowuje cię do łatwego przejścia w przyszłości.

    • Uzyskanie uznania za dbałość o bezpieczeństwo. Bird zachęcał wcześnie przyjętych użytkowników do dzielenia się swoimi sukcesami w zakresie aktualizacji i dołączenia do ich „ściany wspaniałości” — świętując proaktywne przestrzeganie zasad bezpieczeństwa.

Podsumowanie pytań i odpowiedzi

  • Dlaczego TLS 1.2 jest wymagany?

    Wcześniejsze wersje (1.0 i 1.1) są niebezpieczne i zostały wycofane przez IETF. TLS 1.2 oferuje silniejsze szyfrowanie i ochronę integralności dla połączeń API i SMTP.

  • Kogo to dotyczy?

    Każdy klient łączący się z Bird (za pośrednictwem REST API, SMTP, webhooków lub punktów końcowych metryk) przy użyciu przestarzałej wersji TLS.

  • Jak mogę przetestować moje połączenie?

    Uruchom jedną z komend weryfikacyjnych dla swojego systemu operacyjnego (Linux, macOS lub Windows). Jeśli wynik pokazuje udane nawiązanie połączenia TLSv1.2, Twoje połączenie jest zgodne.

  • Co się stanie, jeśli nie zaktualizuję?

    Twoje połączenia zakończą się niepowodzeniem, gdy TLS 1.1 zostanie wyłączony. Stracisz możliwość wysyłania wiadomości lub dostępu do interfejsów API, dopóki Twój system nie będzie wspierał TLS 1.2.

  • Czy mogę teraz włączyć TLS 1.3?

    Możesz, ale może to nie być jeszcze wspierane przez AWS ALB. Uaktualnienie OpenSSL do wersji 1.1.1+ zapewnia zgodność, gdy TLS 1.3 stanie się dostępne.

  • Czy muszę coś zmieniać, jeśli korzystam z Bird przez bibliotekę lub SDK?

    Większość nowoczesnych SDK domyślnie używa już TLS 1.2. Sprawdź jednak konfigurację SSL swojego środowiska lub wersję biblioteki, jeśli jest starsza niż połowa 2018 roku.

  • Czy istnieje sposób, aby potwierdzić sukces?

    Tak — po przetestowaniu twojego połączenia, Bird zaprosił użytkowników do wysłania potwierdzenia mailowego do ich zespołu wsparcia, weryfikując gotowość przed datą graniczną.

Czy korzystasz z TLS starszego niż 1.2?  W porządku, opóźnienia w aktualizacji utrzymania zdarzają się każdemu.  Rozumiemy to.  Jednak nadszedł czas, aby iść dalej.

Pamiętasz, jak w czerwcu 2018 roku zrezygnowaliśmy z używania TLS 1.0? Jeśli nie, to nic nie szkodzi, możesz poczytać o tym w tej publikacji.  Cóż, oto jesteśmy, 2 lata później, a kolejna wersja ma zostać wycofana, więc chcemy, abyś był przygotowany i uniknął przerwy w usłudze.  Ten post dotyczy przygotowania cię do pracy bez użycia TLS1.1, abyśmy mogli ograniczyć dostęp tylko do TLS1.2.  Pokażemy ci, jak sprawdzić swoją obecną wersję i jak zaktualizować do najnowszej.  Tak na marginesie, naprawdę chcielibyśmy usłyszeć twoje uwagi i dodać cię do "ściany wspaniałości", na której znajdą się wszystkie te firmy dbające o bezpieczeństwo, które dokonują zmiany wcześniej.

Sprawdzanie dostępności wsparcia w systemie Windows

Podobnie jak w przypadku użycia Maca, najczęstszym powodem, dla którego musisz sprawdzić wsparcie w systemie Windows, jest to, że używasz go do lokalnego rozwoju, więc załóżmy to i sprawdź swoje wsparcie. 

Windows 7 i Windows 10 korzystają zasadniczo z tego samego procesu.  Jeśli używasz czegoś wcześniejszego, proszę zaktualizować, ponieważ wcześniejsze wersje nie obsługują TLS 1.2.

Rozpocznij od kliknięcia START w lewym dolnym rogu (zwykle).

Wpisz “Opcje Internetowe” i wybierz pasujący element z wynikowej listy.

Kliknij na zakładkę Zaawansowane i stamtąd przewiń na sam dół. Jeśli TLS 1.2 jest zaznaczone, to już wszystko w porządku. Jeśli nie, proszę zaznaczyć pole obok Użyj TLS 1.2, a następnie Zastosuj.

Czy to mnie dotyczy?

W 2018 roku prosiliśmy naszych klientów o aktualizację, a TLS 1.2 jest zalecany od dłuższej chwili, 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 (metryki lub webhooki itd.), 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 rzeczywiście łączą się z SparkPost.

Dlaczego to jest ważne

Dlaczego aktualizacja do TLS 1.2 ma znaczenie

Dlaczego aktualizacja do TLS 1.2 ma znaczenie

Szczegóły

Wsparcie dla TLS 1.1 dobiega końca

SparkPost nie będzie już akceptować połączeń TLS 1.1 po wrześniu 2020

Starsze wersje są niebezpieczne

Starsze protokoły TLS są podatne na nowoczesne metody ataku

Zgodność ze standardami branżowymi

TLS 1.2 jest zalecanym bezpiecznym protokołem od lat

Lepsza wydajność i niezawodność

Szybsze, bardziej stabilne połączenia szyfrowane

Oficjalnie wycofane

Standardy IETF klasyfikują TLS 1.1 jako przestarzały

Dlaczego aktualizacja do TLS 1.2 ma znaczenie

Dlaczego aktualizacja do TLS 1.2 ma znaczenie

Szczegóły

Wsparcie dla TLS 1.1 dobiega końca

SparkPost nie będzie już akceptować połączeń TLS 1.1 po wrześniu 2020

Starsze wersje są niebezpieczne

Starsze protokoły TLS są podatne na nowoczesne metody ataku

Zgodność ze standardami branżowymi

TLS 1.2 jest zalecanym bezpiecznym protokołem od lat

Lepsza wydajność i niezawodność

Szybsze, bardziej stabilne połączenia szyfrowane

Oficjalnie wycofane

Standardy IETF klasyfikują TLS 1.1 jako przestarzały

Dlaczego teraz?

Właściwie pytanie powinno brzmieć: “dlaczego wciąż to wspierasz?”  TLS 1.2 jest zalecanym bezpiecznym standardem od ponad dekady i dochodzimy do punktu, w którym ktokolwiek w ogóle oferuje wsparcie dla czegokolwiek poniżej TLS1.2. Czas na słabe wsparcie HTTPS, aby umrzeć raz na zawsze.  Jeśli wciąż używasz TLS 1.1 po marcu 2020 roku, będziesz miał trudności z połączeniem się z większością usług.  SparkPost zapewnił wystarczająco dużo czasu na aktualizację, a teraz wysyłamy ostatnie powiadomienia, aby zaktualizować to przed wrześniem, kiedy to wyłączymy go na dobre.

Ale jak, proszę powiedz, możesz to naprawić?

Bardzo możliwe, że twój administrator systemów IT lub administrator sieci zrobił to już za ciebie jako część ich zwykłej konserwacji.  Jeśli tak, powinieneś kupić im piwo i powiedzieć dziękuję.  Jeśli nie, możesz postępować zgodnie z kilkoma poniższymi krokami, aby to zrobić w systemach Linux, Windows i Mac.

Zauważ, że w całym tym dokumencie będziemy testować z punktem końcowym US SparkPost.

Jeśli zazwyczaj korzystasz z europejskiego wdrożenia, powinieneś zamiast tego użyć punktu końcowego EU.

Jak możesz to sprawdzić? (wersja Linux)

Najpierw sprawdźmy, czy twój przyjazny administrator systemu już się tym zajął. To jest część konfiguracji SSL, więc można to zarządzać w konfiguracji systemu.  Zakładając, że używasz Linuksa, najdokładniejszą metodą jest użycie nmap, ale możesz również użyć openssl.  Możesz użyć nmap w systemach Linux, Windows i Mac, ale zbadamy inne metody dla Windows i Mac, jeśli nie chcesz instalować nowego oprogramowania.

Aby to zrobić za pomocą nmap, przetestuj szyfry przeciwko znanemu hoście HTTPS.  Ponieważ chodzi o to, aby upewnić się, że łączymy się z SparkPost w sposób bezpieczny, przetestujmy ten punkt końcowy. Upewnij się, że wykonujesz następujące testy na serwerach, które faktycznie łączą się z SparkPost. 

nmap --script ssl-enum-ciphers -p 443 api.sparkpost.com

To zostało wykonane na moim własnym serwerze deweloperskim i możesz łatwo zobaczyć, że moja konfiguracja obsługuje TLS 1.1 i 1.2, ale nie 1.3.  Ważne jest, aby w tym momencie zauważyć, że AWS ALB i w związku z tym połączenia ze SparkPostem, jeszcze nie obsługują TLS1.3, ale jest to na drodze rozwoju AWS.

Starting Nmap 6.40 ( http://nmap.org ) at 2020-05-06 22:41 UTC
                    
Nmap scan report for api.sparkpost.com (52.13.246.255)
Host is up (0.00059s latency).
Other addresses for api.sparkpost.com (not scanned):
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 for 52.13.246.255: ec2-52-13-246-255.us-west-2.compute.amazonaws.com

PORT    STATE SERVICE
443/tcp open  https
| ssl-enum-ciphers:
|   TLSv1.1:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_RSA_WITH_AES_256_CBC_SHA - strong
|     compressors:
|       NULL
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 - strong
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - strong
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 - strong
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - strong
|       TLS_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_RSA_WITH_AES_128_CBC_SHA256 - strong
|       TLS_RSA_WITH_AES_128_GCM_SHA256 - strong
|       TLS_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_RSA_WITH_AES_256_CBC_SHA256 - strong
|       TLS_RSA_WITH_AES_256_GCM_SHA384 - strong
|     compressors:
|       NULL
|_  least strength: strong

Nmap done: 1 IP address (1 host up) scanned in 0.11 seconds

Na tym etapie możesz faktycznie przestać, jeśli chcesz, ponieważ chodzi o to, aby upewnić 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 wszyscy jesteśmy tu w porządku.  Kup temu administratorowi systemu piwo i podziękuj mu.

Wyślij nam email i daj nam znać, że osiągnąłeś sukces.

Najpierw sprawdźmy, czy twój przyjazny administrator systemu już się tym zajął. To jest część konfiguracji SSL, więc można to zarządzać w konfiguracji systemu.  Zakładając, że używasz Linuksa, najdokładniejszą metodą jest użycie nmap, ale możesz również użyć openssl.  Możesz użyć nmap w systemach Linux, Windows i Mac, ale zbadamy inne metody dla Windows i Mac, jeśli nie chcesz instalować nowego oprogramowania.

Aby to zrobić za pomocą nmap, przetestuj szyfry przeciwko znanemu hoście HTTPS.  Ponieważ chodzi o to, aby upewnić się, że łączymy się z SparkPost w sposób bezpieczny, przetestujmy ten punkt końcowy. Upewnij się, że wykonujesz następujące testy na serwerach, które faktycznie łączą się z SparkPost. 

nmap --script ssl-enum-ciphers -p 443 api.sparkpost.com

To zostało wykonane na moim własnym serwerze deweloperskim i możesz łatwo zobaczyć, że moja konfiguracja obsługuje TLS 1.1 i 1.2, ale nie 1.3.  Ważne jest, aby w tym momencie zauważyć, że AWS ALB i w związku z tym połączenia ze SparkPostem, jeszcze nie obsługują TLS1.3, ale jest to na drodze rozwoju AWS.

Starting Nmap 6.40 ( http://nmap.org ) at 2020-05-06 22:41 UTC
                    
Nmap scan report for api.sparkpost.com (52.13.246.255)
Host is up (0.00059s latency).
Other addresses for api.sparkpost.com (not scanned):
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 for 52.13.246.255: ec2-52-13-246-255.us-west-2.compute.amazonaws.com

PORT    STATE SERVICE
443/tcp open  https
| ssl-enum-ciphers:
|   TLSv1.1:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_RSA_WITH_AES_256_CBC_SHA - strong
|     compressors:
|       NULL
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 - strong
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - strong
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 - strong
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - strong
|       TLS_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_RSA_WITH_AES_128_CBC_SHA256 - strong
|       TLS_RSA_WITH_AES_128_GCM_SHA256 - strong
|       TLS_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_RSA_WITH_AES_256_CBC_SHA256 - strong
|       TLS_RSA_WITH_AES_256_GCM_SHA384 - strong
|     compressors:
|       NULL
|_  least strength: strong

Nmap done: 1 IP address (1 host up) scanned in 0.11 seconds

Na tym etapie możesz faktycznie przestać, jeśli chcesz, ponieważ chodzi o to, aby upewnić 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 wszyscy jesteśmy tu w porządku.  Kup temu administratorowi systemu piwo i podziękuj mu.

Wyślij nam email i daj nam znać, że osiągnąłeś sukces.

Najpierw sprawdźmy, czy twój przyjazny administrator systemu już się tym zajął. To jest część konfiguracji SSL, więc można to zarządzać w konfiguracji systemu.  Zakładając, że używasz Linuksa, najdokładniejszą metodą jest użycie nmap, ale możesz również użyć openssl.  Możesz użyć nmap w systemach Linux, Windows i Mac, ale zbadamy inne metody dla Windows i Mac, jeśli nie chcesz instalować nowego oprogramowania.

Aby to zrobić za pomocą nmap, przetestuj szyfry przeciwko znanemu hoście HTTPS.  Ponieważ chodzi o to, aby upewnić się, że łączymy się z SparkPost w sposób bezpieczny, przetestujmy ten punkt końcowy. Upewnij się, że wykonujesz następujące testy na serwerach, które faktycznie łączą się z SparkPost. 

nmap --script ssl-enum-ciphers -p 443 api.sparkpost.com

To zostało wykonane na moim własnym serwerze deweloperskim i możesz łatwo zobaczyć, że moja konfiguracja obsługuje TLS 1.1 i 1.2, ale nie 1.3.  Ważne jest, aby w tym momencie zauważyć, że AWS ALB i w związku z tym połączenia ze SparkPostem, jeszcze nie obsługują TLS1.3, ale jest to na drodze rozwoju AWS.

Starting Nmap 6.40 ( http://nmap.org ) at 2020-05-06 22:41 UTC
                    
Nmap scan report for api.sparkpost.com (52.13.246.255)
Host is up (0.00059s latency).
Other addresses for api.sparkpost.com (not scanned):
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 for 52.13.246.255: ec2-52-13-246-255.us-west-2.compute.amazonaws.com

PORT    STATE SERVICE
443/tcp open  https
| ssl-enum-ciphers:
|   TLSv1.1:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_RSA_WITH_AES_256_CBC_SHA - strong
|     compressors:
|       NULL
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 - strong
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - strong
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 - strong
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - strong
|       TLS_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_RSA_WITH_AES_128_CBC_SHA256 - strong
|       TLS_RSA_WITH_AES_128_GCM_SHA256 - strong
|       TLS_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_RSA_WITH_AES_256_CBC_SHA256 - strong
|       TLS_RSA_WITH_AES_256_GCM_SHA384 - strong
|     compressors:
|       NULL
|_  least strength: strong

Nmap done: 1 IP address (1 host up) scanned in 0.11 seconds

Na tym etapie możesz faktycznie przestać, jeśli chcesz, ponieważ chodzi o to, aby upewnić 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 wszyscy jesteśmy tu w porządku.  Kup temu administratorowi systemu piwo i podziękuj mu.

Wyślij nam email i daj nam znać, że osiągnąłeś sukces.

Sprawdzanie wsparcia na twoim Macu

Najczęstszym powodem, dla którego możesz potrzebować sprawdzić wsparcie na swoim Macu, jest to, że używasz go do lokalnego rozwoju, załóżmy więc to i sprawdź wsparcie. 

Najmniej inwazyjną metodą jest użycie curl, który powinien być wbudowany w każdy Mac. Uruchom aplikację Terminal i użyj flagi protokołu, aby przetestować konkretnie TLS1.2.

curl https://api.sparkpost.com/ --tlsv1.2 --verbose

* Trying 54.213.185.174...
* TCP_NODELAY set
* Connected to api.sparkpost.com (54.213.185.174) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
    CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1)
* TLSv1.2 (IN), TLS handshake, Server hello (2)
* TLSv1.2 (IN), TLS handshake, Certificate (11)
* TLSv1.2 (IN), TLS handshake, Server key exchange (12)
* TLSv1.2 (IN), TLS handshake, Server finished (14)
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16)
* TLSv1.2 (OUT), TLS change cipher, Client hello (1)
* TLSv1.2 (OUT), TLS handshake, Finished (20)
* TLSv1.2 (IN), TLS change cipher, Client hello (1)
* TLSv1.2 (IN), TLS handshake, Finished (20)
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2

* Server certificate:
*   subject: CN=*.sparkpost.com
*   start date: Jan 30 00:00:00 2020 GMT
*   expire date: Feb 28 12:00:00 2021 GMT
*   subjectAltName: host "api.sparkpost.com" matched cert's "*.sparkpost.com"
*   issuer: C=US; O=Amazon; OU=Server CA 1B; CN=Amazon
*   SSL certificate verify ok.
      
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7fbd69805200)

> GET / HTTP/2
> Host: api.sparkpost.com
> User-Agent: curl/7.54.0
> Accept: /

*  Connection state changed (MAX_CONCURRENT_STREAMS updated)!
  
< HTTP/2 200
< date: Thu, 07 May 2020 15:14:30 GMT
< content-type: text/plain
< content-length: 95
< server: msys-http
  
Oh hey! You should come work with us and build awesome stuff


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: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384

Najczęstszym powodem, dla którego możesz potrzebować sprawdzić wsparcie na swoim Macu, jest to, że używasz go do lokalnego rozwoju, załóżmy więc to i sprawdź wsparcie. 

Najmniej inwazyjną metodą jest użycie curl, który powinien być wbudowany w każdy Mac. Uruchom aplikację Terminal i użyj flagi protokołu, aby przetestować konkretnie TLS1.2.

curl https://api.sparkpost.com/ --tlsv1.2 --verbose

* Trying 54.213.185.174...
* TCP_NODELAY set
* Connected to api.sparkpost.com (54.213.185.174) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
    CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1)
* TLSv1.2 (IN), TLS handshake, Server hello (2)
* TLSv1.2 (IN), TLS handshake, Certificate (11)
* TLSv1.2 (IN), TLS handshake, Server key exchange (12)
* TLSv1.2 (IN), TLS handshake, Server finished (14)
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16)
* TLSv1.2 (OUT), TLS change cipher, Client hello (1)
* TLSv1.2 (OUT), TLS handshake, Finished (20)
* TLSv1.2 (IN), TLS change cipher, Client hello (1)
* TLSv1.2 (IN), TLS handshake, Finished (20)
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2

* Server certificate:
*   subject: CN=*.sparkpost.com
*   start date: Jan 30 00:00:00 2020 GMT
*   expire date: Feb 28 12:00:00 2021 GMT
*   subjectAltName: host "api.sparkpost.com" matched cert's "*.sparkpost.com"
*   issuer: C=US; O=Amazon; OU=Server CA 1B; CN=Amazon
*   SSL certificate verify ok.
      
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7fbd69805200)

> GET / HTTP/2
> Host: api.sparkpost.com
> User-Agent: curl/7.54.0
> Accept: /

*  Connection state changed (MAX_CONCURRENT_STREAMS updated)!
  
< HTTP/2 200
< date: Thu, 07 May 2020 15:14:30 GMT
< content-type: text/plain
< content-length: 95
< server: msys-http
  
Oh hey! You should come work with us and build awesome stuff


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: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384

Najczęstszym powodem, dla którego możesz potrzebować sprawdzić wsparcie na swoim Macu, jest to, że używasz go do lokalnego rozwoju, załóżmy więc to i sprawdź wsparcie. 

Najmniej inwazyjną metodą jest użycie curl, który powinien być wbudowany w każdy Mac. Uruchom aplikację Terminal i użyj flagi protokołu, aby przetestować konkretnie TLS1.2.

curl https://api.sparkpost.com/ --tlsv1.2 --verbose

* Trying 54.213.185.174...
* TCP_NODELAY set
* Connected to api.sparkpost.com (54.213.185.174) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
    CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1)
* TLSv1.2 (IN), TLS handshake, Server hello (2)
* TLSv1.2 (IN), TLS handshake, Certificate (11)
* TLSv1.2 (IN), TLS handshake, Server key exchange (12)
* TLSv1.2 (IN), TLS handshake, Server finished (14)
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16)
* TLSv1.2 (OUT), TLS change cipher, Client hello (1)
* TLSv1.2 (OUT), TLS handshake, Finished (20)
* TLSv1.2 (IN), TLS change cipher, Client hello (1)
* TLSv1.2 (IN), TLS handshake, Finished (20)
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2

* Server certificate:
*   subject: CN=*.sparkpost.com
*   start date: Jan 30 00:00:00 2020 GMT
*   expire date: Feb 28 12:00:00 2021 GMT
*   subjectAltName: host "api.sparkpost.com" matched cert's "*.sparkpost.com"
*   issuer: C=US; O=Amazon; OU=Server CA 1B; CN=Amazon
*   SSL certificate verify ok.
      
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7fbd69805200)

> GET / HTTP/2
> Host: api.sparkpost.com
> User-Agent: curl/7.54.0
> Accept: /

*  Connection state changed (MAX_CONCURRENT_STREAMS updated)!
  
< HTTP/2 200
< date: Thu, 07 May 2020 15:14:30 GMT
< content-type: text/plain
< content-length: 95
< server: msys-http
  
Oh hey! You should come work with us and build awesome stuff


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: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384

Idąc o krok dalej

Dlaczego zatrzymywać się na TLS 1.2, kiedy wiesz – po prostu wiesz – że wszyscy będziemy musieli zaktualizować do TLS 1.3 w ciągu najbliższego roku lub dwóch. Dlaczego po prostu nie zaktualizować się do TLSv1.3, kiedy już przy tym jesteśmy?

Niestety, AWS ALB nie obsługują jeszcze TLS1.3, więc jeśli zaktualizujesz swoją konfigurację, twoje połączenie z SparkPost i jakąkolwiek inną usługą AWS, która korzysta z warstwy ALB, będzie nadal ograniczone do TLS1.2. Osobiście uważam, że to dobry pomysł, aby wyprzedzić trend i zaktualizować do 1.3, gdy już wprowadzasz zmiany.

Aby dodać wsparcie dla 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 wspomnianej wyżej linii protokołu. Podobne instrukcje można znaleźć tutaj dla Nginx i Cloudflare również.

Zostań bezpieczny tam na zewnątrz

Na koniec byłoby wspaniale, gdybyś mógł wysłać nam szybki e-mail, aby dać nam znać, że potwierdziłeś, że jesteś w stanie korzystać z TLS 1.2.  Naprawdę nie chcemy nikogo odcinać, a ostateczny termin to wrzesień 2020.  Jeśli będziemy wiedzieli, że wszyscy jesteście w strefie bezpieczeństwa, znacznie lepiej poczujemy się z wyłączeniem starego wsparcia.

Inne wiadomości

Przeczytaj więcej z tej kategorii

Sztuczna inteligencja

·

17 wrz 2024

Jak Aegean Taxi używa sztucznej inteligencji, aby poprawić obsługę klienta

15 sie 2024

Jak dostosować swojego asystenta AI, aby poprawić wsparcie dla klientów

31 mar 2025

Tworzenie chatbotów AI, które klienci naprawdę chcą używać

A person is standing at a desk while typing on a laptop.

Kompletna platforma oparta na sztucznej inteligencji, która rośnie wraz z Twoim biznesem.

Skontaktuj się z działem sprzedaży

Zacznij za darmo

© 2026 Ptak

Skontaktuj się z pomocą techniczną

A person is standing at a desk while typing on a laptop.

Kompletna platforma oparta na sztucznej inteligencji, która rośnie wraz z Twoim biznesem.

Skontaktuj się z działem sprzedaży

Zacznij za darmo

© 2026 Ptak

Skontaktuj się z pomocą techniczną

A person is standing at a desk while typing on a laptop.

Kompletna platforma oparta na sztucznej inteligencji, która rośnie wraz z Twoim biznesem.

Skontaktuj się z działem sprzedaży

Zacznij za darmo

© 2026 Ptak

Skontaktuj się z pomocą techniczną