Le 20 juin 2018, nous cesserons la prise en charge de plusieurs catégories de trafic réseau non sécurisé pour Adobe Sign. Cette cessation de prise en charge est nécessaire pour répondre à certaines exigences spécifiques en vue de la conformité PCI.

Foire aux questions

Quel est le type de trafic réseau affecté par les nouvelles règles de chiffrement ?

Tout le trafic :

ENTRANT

Le terme de trafic entrant fait référence aux connexions établies entre un client et nos serveurs. Nous cesserons de prendre en charge les connexions non chiffrées à nos API, -autrement dit, les requêtes qui utilisent l’en-tête "http:" au lieu de "https:".

Une fois que nous aurons effectué ce changement, les applications des clients et partenaires échoueront à établir des connexions non chiffrées. Le comportement erroné sera spécifique à chaque application.

Messages d’erreur :

L’erreur est spécifique à chaque application, mais peut être signalée comme une erreur de connexion réseau.

Pour corriger ce problème, les clients doivent modifier leurs applications en spécifiant des adresses URL « https: ». Les clients doivent également prendre en charge le protocole TLS v1.2. (Depuis le 9 avril, il s’agit de la seule version du protocole SSL/TLS qui soit prise en charge par nos serveurs).

 

SORTANT

Le trafic sortant fait référence aux connexions établies entre nos serveurs et des serveurs clients. Il existe deux catégories :

• Rappels de chargement pour les téléchargements de documents en amont (tels que décrits ici pour notre API REST, mais ce modèle s’applique également à l’API SOAP héritée).

• Rappels d’état pour informer le client d’un changement de statut de l’accord (décrit ici pour notre API REST, mais ce modèle s’applique également à l’API SOAP héritée).

 

Pour les deux catégories de rappels, nous cesserons la prise en charge des :

a. Connexions non chiffrées (URL utilisant « http: » plutôt que « https : »).

b. Connexions aux serveurs ne prenant pas en charge le protocole TLS v1.2 (en d’autres termes, TLSv1.0 et TLSv1.1 ne seront plus pris en charge).

c. Connexions aux serveurs ayant des certificats non valides. Ceci inclut les certificats auto-signés ou ayant expiré, ainsi que les cas dans lesquels une adresse URL utilise une adresse IP au lieu d’un nom d’hôte.

Messages d’erreur :

• Rappel de chargement : le chargement en amont doit renvoyer une erreur d’API. 

• Rappels de statut :

Pour solutionner ce problème :

• Dans les applications Sign partenaire/client, les adresses URL spécifiées pour les rappels doivent utiliser l’en-tête « https : » au lieu de « http: ». Les adresses URL doivent également utiliser un nom d’hôte plutôt qu’une adresse IP.

• Les serveurs référencés par ces adresses URL doivent prendre en charge le protocole TLS v1.2 et comporter des certificats valides.


Comment savoir si ma connexion à Adobe Sign est sécurisée ?

Nous générons des rapports afin d’identifier les clients existant dont le trafic entrant ou sortant n’est pas sécurisé. Ces clients seront avisés directement.

Les clients qui souhaitent tester la conformité de leur serveur peuvent utiliser une variété d’outils gratuits ou commerciaux, y compris Qualys SSLLabs Server Test, afin de s’assurer que leur serveur accepte le protocole TLS v1.2 et dispose d’un certificat valide.


Une liste des méthodes prises en charge a-t-elle été publiée par Adobe ?

Voici le tableau qui recense tous les cas problématiques :

  • Cas qui seront bloqués le 20 juin (en caractères gras)
  • Cas qui ont été déjà bloqués en avril (en italique)
  • Cas que nous bloquerons plus tard cette année au 3e trimestre (tout le reste)

Catégorie

Type de requête

Non chiffré

TLS 1.0

TLS 1.1

Certificat incorrect

Requêtes d’API entrantes

Toutes les requêtes

Bloqué le 20 juin

Bloqué en avril 2018

Bloqué en avril 2018

Sans objet

Requêtes d’API sortantes

Rappel de chargement de document en amont

Bloqué le 20 juin

Blocage prévu au 3e trim. 2018

Blocage prévu au 3e trim. 2018

Blocage prévu au 3e trim. 2018

Rappel d’état

Bloqué le 20 juin

Bloqué le 20 juin

Bloqué le 20 juin

Bloqué le 20 juin


Y a-t-il autre chose à savoir à propos des modifications apportées aux normes de chiffrement ?

Rappels d’état

Pour les rappels d’état, en plus de prendre en charge le protocole TLS 1.2, le serveur du client doit prendre en charge l’une des suites de chiffrement ci-après :

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

Ce produit est distribué sous licence Creative Commons Attribution - Pas d’utilisation commerciale - Partage à l’identique 3.0 non transposé  Les publications Twitter™ et Facebook ne sont pas couvertes par les dispositions Creative Commons.

Mentions légales   |   Politique de confidentialité en ligne