20. června 2018 ukončíme podporu řady kategorií nezabezpečených síťových přenosů ve službě Adobe Sign. Je to z důvodu splnění konkrétních požadavků standardů PCI.

Časté dotazy

Jaký typ síťových přenosů bude novými pravidly šifrování ovlivněn?

Veškeré přenosy:

PŘÍCHOZÍ

Příchozí přenosy jsou připojení uskutečňovaná z klienta do našich serverů. Ukončíme podporu nešifrovaných připojení k našim rozhraním API – tzn. požadavků, které používají protokol http a nikoliv https.

Po provedení této změny se zákaznickým a partnerským aplikacím nebudou dařit pokusy o navázání nešifrovaného připojení. Chybové chování bude záviset na konkrétní aplikaci.

Chybové zprávy:

Chyba bude specifická pro danou aplikaci, bude ji však možné nahlásit jako chybu síťového připojení.

Aby ji bylo možné opravit, zákazníci budou muset změnit aplikace tak, aby uváděly adresy URL s protokolem „https“. Jejich klienti také musí podporovat TLSv1.2. (Od 9. dubna je to jediná verze protokolu SSL/TLS, kterou naše servery akceptují.)

 

ODCHOZÍ

Odchozí přenosy jsou připojení uskutečňovaná z našich serverů zpět na servery zadané zákazníkem. Existují dvě kategorie:

• Zpětná volání při odesílání pro odesílání dokumentů (popsána zde pro naše rozhraní REST API, platí však i pro starší rozhraní SOAP API)

• Zpětná volání týkající se stavu, která zákazníka upozorňují na změnu stavu smlouvy (popsána zde pro naše rozhraní REST API, platí však i pro starší rozhraní SOAP API)

 

U obou kategorií zpětných volání ukončíme podporu:

a. Nešifrovaných připojení (pomocí adres URL s protokolem http, nikoliv https)

b. Připojení k serverům, které nepodporují TLSv1.2 (jinými slovy již nebudou podporovány protokoly TLSv1.0 a TLSv1.1)

c. Připojení k serverům, které nemají platné certifikáty. To zahrnuje certifikáty s vlastním podpisem nebo ukončenou dobou platnosti a rovněž případy, kdy adresa URL používá IP adresu, a nikoliv název hostitele.

Chybové zprávy:

• Zpětné volání při odesílání: odesílání by mělo vrátit chybu rozhraní API. 

• Zpětné volání týkající se stavu:

Postup opravy:

• V partnerských/zákaznických aplikacích Sign musí adresy URL zadané pro volání používat protokol https, a nikolivhttp.  Adresy URL musí rovněž používat název hostitele namísto IP adresy.

• Servery, na které tyto adresy URL odkazují, musí podporovat TLSv1.2 a mít platné certifikáty.


Jak zjistím, zda je mé připojení ke službě Adobe Sign zabezpečené?

Generujeme zprávy identifikující zákazníky, jejichž stávající příchozí nebo odchozí přenosy jsou nezabezpečené. Tito zákazníci obdrží upozornění.

Zákazníci, kteří chtějí otestovat soulad serveru s tímto požadavkem, mohou použít řadu bezplatných i komerčních nástrojů, např. Qualys SSLLabs Server Test, a ujistit se, zda jejich server akceptuje TLv1.2 a má platný certifikát.


Publikovala společnost Adobe seznam podporovaných metod?

Níže je tabulka uvádějící všechny problémové případy:

  • Případy, které budou zablokovány 20. června (tučně)
  • Případy, které byly zablokovány v dubnu (kurzívou)
  • Případy, které budou zablokovány ve 3. čtvrtletí tohoto roku (vše ostatní)

Kategorie

Typ požadavku

Nešifrovaný

TLS 1.0

TLS 1.1

Nesprávný certifikát

Příchozí požadavky rozhraní API

Všechny požadavky

Zablokováno 20. června

Zablokováno v dubnu 2018

Zablokováno v dubnu 2018

Není k dispozici

Výchozí požadavky rozhraní API

Zpětné volání při odesílání dokumentu

Zablokováno 20. června

Bude zablokováno ve 3. čtvrtletí 2018

Bude zablokováno ve 3. čtvrtletí 2018

Bude zablokováno ve 3. čtvrtletí 2018

Zpětné volání týkající se stavu

Zablokováno 20. června

Zablokováno 20. června

Zablokováno 20. června

Zablokováno 20. června


Je zde něco dalšího, co bychom měli vědět o změnách šifrovacích standardů?

Zpětná volání týkající se stavu

V případě zpětných volání týkajících se stavu musí zákaznické servery kromě protokolu TLS 1.2 podporovat i jednu z šifrovacích sad níže:

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

Tato práce podléhá licenci Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.  Na příspěvky ze služeb Twitter™ a Facebook se nevztahují podmínky licence Creative Commons.

Právní upozornění   |   Zásady ochrany osobních údajů online