Od 20 czerwca 2018 roku pomoc techniczna dla kilku kategorii niezabezpieczonego ruchu sieciowego programu Adobe Sign zostanie wycofana. Jest to konieczne w celu spełnienia określonych wymogów zgodności z PCI.

Często zadawane pytania

Na jaki typ ruchu sieciowego mają wpływ nowe zasady szyfrowania?

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.


Jak można sprawdzić, czy połączenie z programem Adobe Sign jest bezpieczne?

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.


Czy firma Adobe opublikowała listę obsługiwanych metod?

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)

Kategoria

Typ żądania

Niezaszyfrowane

TLS 1.0

TLS 1.1

Nieprawidłowy certyfikat

Przychodzące żądania API

Wszystkie żądania

Zablokowane 20 czerwca

Zablokowane w kwietniu 2018 r.

Zablokowane w kwietniu 2018 r.

Nie dotyczy

Wychodzące żądania API

Wywołanie zwrotne przesyłania dokumentu

Zablokowane 20 czerwca

Do zablokowania w 3 kwartale 2018 r.

Do zablokowania w 3 kwartale 2018 r.

Do zablokowania w 3 kwartale 2018 r.

Wywołanie zwrotne stanu

Zablokowane 20 czerwca

Zablokowane 20 czerwca

Zablokowane 20 czerwca

Zablokowane 20 czerwca


Czy jest coś jeszcze, co warto wiedzieć o zmianach w standardach szyfrowania?

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

Ta zawartość jest licencjonowana na warunkach licencji Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License  Posty z serwisów Twitter™ i Facebook nie są objęte licencją Creative Commons.

Informacje prawne   |   Zasady prywatności online