Veelgestelde vragen over onveilig uitgaand netwerkverkeer

Welk type netwerktraffic wordt beïnvloed door de TLS-coderingsregels van Adobe Acrobat Sign?

Al het verkeer:

BINNENKOMEND

Binnenkomend netwerkverkeer verwijst naar verbindingen die een client tot stand brengt met onze servers. Niet-gecodeerde verbindingen naar onze API's worden niet langer ondersteund, hiermee bedoelen we verbindingen die gebruikmaken van " http :" in plaats van "https:".

Nadat deze wijziging is doorgevoerd, mislukken pogingen van klant- en partnertoepassingen om niet-gecodeerde verbindingen tot stand te brengen. Het foutgedrag varieert per toepassing.

Foutberichten:

Fouten zijn specifiek voor een toepassing, maar er kan een probleem met de netwerkverbinding worden gerapporteerd.

Om dit probleem te verhelpen, moeten gebruikers hun toepassingen wijzigen en "https:"-URL's gebruiken. Hun clients moeten bovendien ondersteuning bieden voor TLSv1.2. (Vanaf 9 april is dat de enige versie van SSL/TLS die onze servers accepteren.)

UITGAAND

Uitgaand netwerkverkeer verwijst naar verbindingen van onze servers terug naar door de klant opgegeven servers. Er zijn twee categorieën:

• Uploadcallbacks voor documentuploads (hier beschreven voor onze REST-API, maar ook van toepassing op de verouderde SOAP-API)

• Statuscallbacks om de klant op de hoogte te stellen van een wijziging in de overeenkomststatus (hier beschreven voor onze REST-API, maar ook van toepassing op de verouderde SOAP-API)

Voor beide categorieën callbacks wordt het volgende niet langer ondersteund:

a. Niet gecodeerde verbindingen (die " http :"- in plaats van "https:"-URL's gebruiken)

b. Verbindingen naar servers die geen ondersteuning bieden voor TLSv1.2 (met andere woorden TLSv1.0 en TLSv1.1 worden niet meer ondersteund)

c. Verbindingen naar servers die ongeldige certificaten hebben. Dit omvat certificaten die automatisch zijn ondertekend of die zijn verlopen, evenals gevallen waarin een URL een IP-adres gebruikt in plaats van een hostnaam.

Foutberichten:

• Uploadcallback: de upload retourneert een API-fout 

• Statuscallbacks: 

Om dit probleem te verhelpen:

• In Sign-toepassingen van partners/klanten moeten de URL's die worden opgegeven voor callbacks gebruikmaken van "https:" en niet van " http :".  De URL's moeten bovendien een hostnaam gebruiken in plaats van een IP-adres.

• De servers waar deze URL's naar verwijzen, moeten TLSv1.2 ondersteunen en geldige certificaten hebben.

Hoe weet ik of mijn verbinding met Acrobat Sign veilig is?

We genereren rapporten om de klanten te identificeren van wie het bestaande inkomende of uitgaande verkeer niet veilig is. Deze klanten worden rechtstreeks op de hoogte gesteld.

Klanten die willen testen of hun server compatibel is, kunnen verschillende gratis of commerciële tools gebruiken, zoals de Qualys SSLLabs Servertest, om te controleren of hun server TLSv1.2 accepteert en een geldig certificaat heeft.

Is er nog iets wat ik moet weten over de wijzigingen inzake coderingsstandaarden?

Statuscallbacks

Voor statuscallbacks dient de server van de klant niet alleen ondersteuning te bieden voor TLS 1.2, maar ook voor een van de volgende versleutelingssuites:

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