К 20 июня 2018 г. мы отменим поддержку нескольких категорий незащищенного сетевого трафика Adobe Sign. Это необходимо для соблюдения специальных требований PCI.

Часто задаваемые вопросы

Какой тип сетевого трафика затрагивают новые правила шифрования?

Любой трафик:

ВХОДЯЩИЙ

Входящий трафик относится к подключениям, выполняемым от клиента к нашим серверам. Мы прекратим поддержку незашифрованных подключений к нашим API — то есть запросов, использующих «http:» вместо «https:».

После внесения данного изменения клиентские и партнерские приложения не смогут устанавливать незащищенные подключения. Поведение в случае ошибки будет зависеть от приложения.

Сообщения об ошибке

Ошибка будет зависеть от приложения, но может поступить уведомление как об ошибке сетевого подключения.

Чтобы это исправить, клиентам необходимо изменить свои приложения, указав URL-адреса «https:». Их клиенты также должны поддерживать TLSv1.2. (По состоянию на 9 апреля, наши серверы поддерживают только эту версию SSL/TLS.)

 

ИСХОДЯЩИЙ

Исходящий трафик относится к подключениям, выполняемым от наших серверов к серверам, указанным клиентами. Существует две категории.

• Обратные вызовы загрузки для загрузок документов (здесь приведено описание для REST API, но также применяется к устаревшему SOAP API)

• Обратные вызовы состояния для уведомления клиента об изменении состояния соглашения (здесь приведено описание для REST API, но также применяется к устаревшему SOAP API)

 

Обе категории обратных вызовов не будут поддерживать:

а. незащищенные подключения (использующие URL-адреса «http:» вместо «https:»);

б. подключения к серверам, не поддерживающие TLSv1.2 (другими словами, будет прекращена поддержка TLSv1.0 и TLSv1.1);

в. подключения к серверам с недействительными сертификатами. Это включает в себя автоматические или просроченные сертификаты, а также случаи, когда URL-адрес использует IP-адрес вместо имени хоста.

Сообщения об ошибке

• Обратный вызов загрузки: загрузка должна возвращать ошибку API. 

• Обратные вызовы состояния 

Способы исправления

• В партнерских/клиентских приложениях Sign в URL-адресах, указанных для обратных вызовов, необходимо использовать «https:» вместо «http:».  В URL-адресах также необходимо использовать имя хоста вместо IP-адреса.

• Серверы, на которые ссылаются данные URL-адреса, должны поддерживать TLSv1.2 и иметь действительные сертификаты.


Как мне узнать, является ли подключение к Adobe Sign защищенным?

Мы создаем отчеты для указания клиентам, является ли их трафик существующего входящего или исходящего подключения защищенным. Данные клиенты будут уведомлены непосредственно.

Клиенты, желающие проверить соответствие своего сервера, могут воспользоваться различными бесплатными или коммерческими инструментами, в том числе Qualys SSLLabs Server Test, для подтверждения, что их сервер поддерживает TLSv1.2 и имеет действительный сертификат.


Опубликовала ли компания Adobe список поддерживаемых методов?

Ниже приведена таблица с указанием всех проблемных случаев.

  • Случаи, которые будут заблокированы 20 июня (жирным шрифтом)
  • Случаи, заблокированные в апреле (курсивом)
  • Случаи, которые мы заблокируем в третьем квартале текущего года (остальные)

Категория

Тип запроса

Незашифрованные

TLS 1.0

TLS 1.1

Несоответствующий сертификат

Входящие запросы API

Все запросы

Заблокировано 20 июня

Заблокировано в апреле 2018 г.

Заблокировано в апреле 2018 г.

Исходящие запросы API

Обратный вызов загрузки документа

Заблокировано 20 июня

Блокировка в третьем квартале 2018 г.

Блокировка в третьем квартале 2018 г.

Блокировка в третьем квартале 2018 г.

Обратный вызов состояния

Заблокировано 20 июня

Заблокировано 20 июня

Заблокировано 20 июня

Заблокировано 20 июня


Что еще необходимо знать об изменениях в стандартах шифрования?

Обратные вызовы состояния

Для обратных вызовов соглашения клиентский сервер должен поддерживать один из перечисленных ниже наборов шифров (помимо поддержки TLS 1.2):

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

Эта работа лицензируется в соответствии с лицензией Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported  На посты, размещаемые в Twitter™ и Facebook, условия Creative Commons не распространяются.

Правовые уведомления   |   Политика конфиденциальности в сети Интернет