El 20 de junio de 2018, dejaremos de admitir varias categorías de tráfico de red no seguro para Adobe Sign. Esto es necesario para cumplir los requisitos concretos del cumplimiento de PCI.

PMF

¿A qué tipo de tráfico de red afectan las nuevas reglas de cifrado?

A todo el tráfico:

ENTRANTE

El tráfico entrante se refiere a las conexiones realizadas desde un cliente a nuestros servidores. Dejaremos de admitir las conexiones sin cifrar a nuestras API; es decir, las solicitudes que utilizan "http:" en lugar de "https:".

Una vez realizado este cambio, las aplicaciones de los clientes y los socios producirán un error al intentar establecer conexiones sin cifrar. El comportamiento del error será específico de la aplicación.

Mensajes de error:

El error será específico de la aplicación, pero puede interpretarse como error de conexión de red.

Para corregir esto, los clientes deben cambiar sus aplicaciones para especificar direcciones URL "https:". Sus equipos cliente también deben admitir TLS versión 1.2. (A partir del 9 de abril, esa es la única versión de SSL/TLS que nuestros servidores aceptan).

 

SALIENTE

El tráfico saliente se refiere a las conexiones realizadas desde nuestros servidores a los servidores especificados por los clientes. Existen dos categorías:

• Retrollamadas de carga para las cargas de documentos (descrito aquí para nuestra REST API, pero también se aplica a la SOAP API heredada).

• Retrollamadas de estado para notificar al cliente un cambio en el estado del acuerdo (descrito aquí para nuestra REST API, pero también se aplica a la SOAP API heredada).

 

Para ambas categorías de retrollamadas, dejaremos de admitir:

a. Conexiones sin cifrar (las que utilicen "http:" en lugar de direcciones URL "https:").

b. Las conexiones a servidores que no admitan TLS versión 1.2 (es decir, TLS versión 1.0 y TLS versión 1.1 ya no se admitirán).

c. Conexiones con servidores que tengan certificados no válidos. Esto incluye los certificados autofirmados o caducados, así como los casos en que una dirección URL utiliza una dirección IP en lugar de un nombre de host.

Mensajes de error:

• Retrollamada de carga: la carga debe devolver un error de la API. 

• Rellamadas de estado:

Para corregir esto:

• En las aplicaciones Sign de socios o clientes, las direcciones URL especificadas para las retrollamadas deben utilizar "https:" en lugar de "http:". La dirección URL también debe utilizar un nombre de host en lugar de una dirección IP.

• Los servidores a los que hacen referencia estas direcciones URL deben admitir TLS versión 1.2 y contar con certificados válidos.


¿Cómo sé si mi conexión a Adobe Sign es segura?

Estamos generando informes para identificar a los clientes cuyo tráfico entrante o saliente existente no sea seguro. Se informará directamente a esos clientes.

Los clientes que deseen comprobar que su servidor es conforme pueden utilizar diversas herramientas gratuitas o comerciales, incluidas las pruebas del servidor de Qualys SSLLabs, para asegurarse de que su servidor acepta TLS versión 1.2 y tiene un certificado válido.


¿Ha publicado Adobe una lista de métodos admitidos?

Esta es la tabla en que muestran todos los casos del problema:

  • Casos que se bloquearán el 20 de junio (en negrita).
  • Casos que ya se han bloqueado desde abril (en cursiva).
  • Casos que bloquearemos más adelante durante el tercer trimestre de este año (todo lo demás).

Categoría

Tipo de solicitud

Sin cifrar

TLS 1.0

TLS 1.1

Certificado incorrecto

Solicitudes de API entrantes

Todas las solicitudes

Bloqueado el 20 de junio

Bloqueado en abril de 2018

Bloqueado en abril de 2018

N. D.

Solicitudes de API salientes

Retrollamada de carga del documento

Bloqueado el 20 de junio

Se bloqueará durante el tercer trimestre de 2018

Se bloqueará durante el tercer trimestre de 2018

Se bloqueará durante el tercer trimestre de 2018

Retrollamada de estado

Bloqueado el 20 de junio

Bloqueado el 20 de junio

Bloqueado el 20 de junio

Bloqueado el 20 de junio


¿Debo saber algo más sobre los cambios en los estándares de cifrado?

Retrollamadas de estado

Para las retrollamadas de estado, además de admitir TLS 1.2, el servidor del cliente debe ser compatible con uno de los paquetes de cifrado que se indican a continuación:

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

Esta obra está autorizada con arreglo a la licencia de Reconocimiento-NoComercial-CompartirIgual 3.0 Unported de Creative Commons.  Los términos de Creative Commons no cubren las publicaciones en Twitter™ y Facebook.

Avisos legales   |   Política de privacidad en línea