Preguntas frecuentes sobre tráfico saliente no seguro

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.

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.

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).

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