Até 20 de junho de 2018, encerraremos o suporte para várias categorias de tráfego de rede não protegido do Adobe Sign. Essa ação é obrigatória para fins de conformidade com o PCI.

Perguntas frequentes

Que tipo de tráfego de rede é afetado pelas novas regras de criptografia?

Todo o tráfego:

DE ENTRADA

Tráfego de entrada se refere a conexões feitas de um cliente com nossos servidores. Encerraremos o suporte a conexões não criptografadas em nossas APIs, isso é, solicitações que usam "http:" em vez de "https:".

Uma vez que fizemos essa alteração, os aplicativos do cliente e do parceiro terão falhas em tentativas de estabelecer conexões não criptografadas. O comportamento de erro será específico do aplicativo.

Mensagens de erro:

O erro será específico do aplicativo, mas pode ser reportado como um erro de conexão de rede.

Para corrigir isso, os clientes devem alterar seus aplicativos para especificar URLS "https:". Os clientes deles também devem ser compatíveis com TLSv1.2. (Desde 9 de abril, essa é a única versão do SSL/TLS que nossos servidores aceitam.)

 

DE SAÍDA

Tráfego de saída se refere a conexões feitas de nossos servidores de volta aos servidores especificados pelos clientes. Há duas categorias:

• Retornos de upload para uploads de documento (descritos aqui para nossa API REST, mas também se aplica à API SOAP herdada)

• Retornos de status para notificar o cliente de uma alteração no status do contrato (descrito aqui para nossa API REST, mas também se aplica à API SOAP herdada)

 

Para ambas as categorias de retornos, encerraremos o suporte a:

a. Conexões não criptografadas (que usam "http:" em vez de URLs "https:")

b. Conexões a servidores que não suportam TLSv1.2 (ou seja, TLSv1.0 e TLSv1.1 não serão mais suportadas)

c. Conexões a servidores com certificados inválidos. Isso inclui os certificados que são auto-assinados ou foram expirados, bem como os casos em que um URL usa um endereço IP em vez de um nome de host.

Mensagens de erro:

• Retorno de upload: o upload deve retornar um erro de API. 

• Retornos de status:

Para corrigir isso:

• Em aplicativos Sign do parceiro/cliente, os URLs especificados para retornos devem usar "https:" em vez de "http:". URLs também devem usar um nome de host em vez de um endereço IP.

• Os servidores referenciados por esses URLs devem oferecer suporte a TLSv1.2 e ter certificados válidos.


Como faço para saber se minha conexão com o Adobe Sign é segura?

Estamos gerando relatórios para identificar clientes cuja entrada ou saída de tráfego existente não é confiável. Esses clientes serão notificados diretamente.

Os clientes que desejam testar se seu servidor é compatível podem usar uma variedade de ferramentas gratuitas ou comerciais, incluindo o Qualys SSLLabs Server Test, para garantir que seu servidor aceite TLSv1.2 e tem um certificado válido.


A Adobe tem uma lista publicada de métodos compatíveis?

Esta é a tabela que mostra todos os casos do problema:

  • Casos que serão bloqueados em 20 de junho (em negrito)
  • Casos que foram bloqueados em abril (em itálico)
  • Casos que serão bloqueados no terceiro trimestre deste ano (todos os outros)

Categoria

Tipo de solicitação

Não criptografado

TLS 1.0

TLS 1.1

Certificado inválido

Solicitações de entrada de APIs

Todas as solicitações

Bloqueado em 20 de junho

Bloqueado em abril de 2018

Bloqueado em abril de 2018

N/A

Solicitações de saída de APIs

Retorno do upload do documento

Bloqueado em 20 de junho

Será bloqueado no terceiro trimestre de 2018

Será bloqueado no terceiro trimestre de 2018

Será bloqueado no terceiro trimestre de 2018

Retorno de status

Bloqueado em 20 de junho

Bloqueado em 20 de junho

Bloqueado em 20 de junho

Bloqueado em 20 de junho


Há algo mais que devo saber sobre as modificações nos padrões de criptografia?

Retornos de status

Para retornos de status, além do suporte a TLS 1.2, o servidor do cliente deve oferecer suporte a uma das cipher suites abaixo:

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á licenciada sob uma licença não adaptada da Creative Commons Attribution-Noncommercial-Share Alike 3.0  As publicações do Twitter™ e do Facebook não são cobertas pelos termos do Creative Commons.

Avisos legais   |   Política de privacidade online