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
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 dohody (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
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 nikoliv
• Servery, na které tyto adresy URL odkazují, musí podporovat TLSv1.2 a mít platné certifikáty.
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.
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 |
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