Niezabezpieczony ruch wychodzący – często zadawane pytania

Cały ruch:

PRZYCHODZĄCY

Ruch przychodzący odnosi się do połączeń od klienta do naszych serwerów. Wycofujemy wsparcie nieszyfrowanych połączeń z naszymi interfejsami API – tj. takich, które żądają użycia protokołu „http:” zamiast „https:”.

Po dokonaniu tej zmiany, aplikacje klientów i partnerów nie będą w stanie nawiązać nieszyfrowanych połączeń. Błędne działanie będzie miało miejsce w przypadku określonych aplikacji.

Komunikaty o błędzie:

Błąd będzie występować w przypadku określonej aplikacji, ale nie będzie go można zgłosić jako błędu połączenia sieciowego.

Aby rozwiązać ten problem, klienci muszą zmienić swoje aplikacje tak, aby określały adresy URL „https:”. Ich klienci muszą także obsługiwać protokół TLS w wersji 1.2. (Na dzień 9 kwietnia jest to jedyna wersja protokołu SSL/TLS akceptowana przez nasze serwery).

WYCHODZĄCY

Ruch wychodzący odnosi się do połączeń z naszych serwerów z powrotem do serwerów określonych przez klienta. Dzielą się one na dwie kategorie:

• wywołania zwrotne przesyłania dla przesyłanych dokumentów (opisane tutaj dla naszego interfejsu REST API, ale dotyczy to także starego interfejsu SOAP API);

• wywołania zwrotne stanu w celu powiadomienia klienta o zmianie w stanu umowy (opisane tutaj dla naszego interfejsu REST API, ale dotyczy to także starego interfejsu SOAP API).

Dla obu kategorii wywołań zwrotnych wycofane zostanie wsparcie:

a. niezaszyfrowanych połączeń (używających adresów URL z „http:” zamiast „https:”);

b. połączeń z serwerami, które nie obsługują protokołu TLS w wersji 1.2 (czyli protokoły TLS 1.0 i TLS 1.1 nie będą już obsługiwane);

c. połączeń z serwerami o nieprawidłowych certyfikatach. Obejmuje to certyfikaty podpisane automatycznie lub wygasłe, jak również przypadki, w których adres URL używa adresu IP zamiast nazwy hosta.

Komunikaty o błędzie:

• wywołania zwrotne przesyłania: przesyłanie powinno spowodować wystąpienie błędu interfejsu API. 

• wywołania zwrotne stanu: 

aby rozwiązać ten problem:

• W aplikacjach Adobe Sign partnera/klienta adresy URL określane dla wywołań zwrotnych muszą używać protokołu „https:” zamiast „http:”.  Adresy URL muszą używać nazwy hosta zamiast adresu IP.

• Serwery, do których odwołują się te adresy URL, muszą obsługiwać protokół TLS 1.2 i posiadać ważne certyfikaty.

Generujemy raporty identyfikujące klientów, których istniejący ruch przychodzący lub wychodzący jest niezabezpieczony. Tacy klienci zostaną powiadomieni bezpośrednio.

Klienci, którzy chcą sprawdzić zgodność swojego serwera, mogą użyć do tego celu wielu bezpłatnych lub komercyjnych narzędzi, w tym programu Qualys SSLLabs Server Test, aby upewnić się, że dany serwer akceptuje protokół TLS 1.2 i posiada ważny certyfikat.

W poniższej tabeli przedstawiono wszystkie problematyczne przypadki:

• Przypadki, które zostaną zablokowane 20 czerwca (tekst pogrubiony)
• Przypadki, które zostały zablokowane w kwietniu (kursywa)
• Przypadki, które zostaną zablokowane w 3 kwartale tego roku (pozostałe)

Wywołania zwrotne stanu

W przypadku wywołań zwrotnych statusu oprócz protokołu TLS 1.2 serwer klienta musi obsługiwać jeden z poniższych zestawów szyfrów:

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

TLS_RSA_WITH_AES_128_CBC_SHA256

TLS_RSA_WITH_AES_128_GCM_SHA256

TLS_RSA_WITH_AES_256_CBC_SHA256

TLS_RSA_WITH_AES_256_GCM_SHA384