Соединение с использованием tls или. Бесплатные Центры сертификации. Подробные сведения об обновлении

протокол записей TLS . Этот протокол обеспечивает безопасность соединений, которые имеют два основных свойства.

• Соединение является конфиденциальным. Для шифрования данных используется симметричная криптография (напр., DES , RC4 , и т.д.). Ключи для шифрования генерируются независимо для каждого соединения и базируются на секретном коде, получаемом с помощью другого протокола (такого, как протокол диалога TLS ). Протокол записей может использоваться и без шифрования.
• Соединение является надежным. Процедура передачи сообщения включает в себя проверку целостности с помощью вычисления MAC. Для расчета MAC используются хэш-функции (напр., SHA, MD5 и т.д.). Протокол записей может работать и без MAC, но в этом режиме он применяется только в случае, когда другой протокол использует протокол записей в качестве транспортного при выяснении параметров безопасности.

Протокол записей TLS используется для инкапсуляции различных протоколов высокого уровня. Один из таких инкапсулируемых объектов, протокол диалога TLS , позволяет серверу и клиенту аутентифицировать друг друга и согласовать алгоритм шифрования и крипто-ключи, до того как приложение передаст или примет первый байт информации. Протокол диалога TLS обеспечивает безопасное соединение, которое имеет три базовых свойства.

• Идентичность партнеров может быть выяснена с использованием асимметричной криптографии (например, RSA , DSS и т.д.). Эта аутентификация может быть сделана опционной, но она необходима, по крайней мере, для одного из партнеров.
• Выявление общего секретного кода является безопасным: этот секретный код недоступен злоумышленнику, даже если он ухитрится подключиться к соединению.
• Диалог надежен: атакующий не может модифицировать соединение без того, чтобы быть обнаруженным партнерами обмена.

Одним из преимуществ TLS является то, что он не зависит от протокола приложения. Протоколы верхнего уровня могут размещаться поверх протокола TLS прозрачным образом. Стандарт TLS , однако, не специфицирует то, как протоколы увеличивают безопасность с помощью TLS ; решение о том, как инициализировать TLS -диалог и как интерпретировать сертификаты аутентификации, оставляется на усмотрение разработчиков протоколов и программ, которые работают поверх TLS .

Цели

Целями протокола TLS в порядке приоритетности являются:

1. Криптографическая безопасность . TLS должен применяться для установления безопасного соединения между двумя партнерами.
2. Совместимость . Независимые программисты должны быть способны разрабатывать приложения, использующие TLS , которые смогут успешно обмениваться криптографическими параметрами без знания особенностей программ друг друга.
3. Расширяемость . TLS ищет способ, как при необходимости встроить в систему новые ключи и методы шифрования. Здесь имеются две побочные цели: исключить необходимость создания нового протокола (что может быть сопряжено с введением новых слабых мест) и сделать ненужным внедрение новой библиотеки, обеспечивающей безопасность.
4. Относительная эффективность . Криптографические операции требуют больших мощностей ЦПУ, особенно этим славятся операции с открытыми ключами. По этой причине протокол TLS имеет опционную схему кэширования сессии, что позволяет уменьшить число соединений, устанавливаемых с использованием новых временных буферов.

Язык представления

Представление данных в этом документе напоминает синтаксис языка Си и XDR [ XDR ], но эти параллели достаточно приблизительны и не имеют никакого отношения к самому протоколу TLS . Эти представления применены лишь для целей упрощения восприятия материала.

Базовым блоком данных считается один байт (т.e. 8 бит ). Многобайтовые информационные элементы представляют собой объединение последовательности байтов слева направо и сверху вниз. Многобайтовые элементы извлекаются из байтового потока (используя нотацию Си ) следующим образом:

value = (байт << 8*(n-1)) | (байт << 8*(n-2)) | ... | байт;

Этот порядок байтов для многобайтовых последовательностей является стандартным для сетей (big endian ).

Комментарии начинаются с "/*" и завершаются "*/". Опционные компоненты выделяются с помощью помещения их в двойные квадратные скобки "". Однобайтовые объекты, содержащие не интерпретируемые данные, имеют непрозрачный тип (opaque).

Вектор (одномерный массив ) является потоком однородных информационных элементов. Размер вектора может быть специфицирован во время документирования или оставаться не специфицированным вплоть до начала работы. В любом случае длина определяет число байтов, а не число элементов в векторе. Синтаксис спецификации нового типа T" , который является вектором фиксированной длины типа T , имеет вид TT"[n] ;

Здесь T" занимает в информационном потоке n байт , где n кратно размеру T . Длина вектора не включается в кодированный поток .

В следующем примере Datum определен как три последовательные байта, которые не интерпретируются протоколом, в то время как Data представляет собой три вектора Datum , состоящие из девяти байт .

opaque Datum; /* три не интерпретируемые байта */ Datum Data; /* 3 последовательных 3-байтовых вектора */

Векторы переменной длины определяются путем спецификации субдиапазона легальных длин, используя нотацию . При кодировании реальная длина предшествует потоку байтов, образующих вектор . Длина имеет форму числа, занимающего столько байт , сколько нужно, чтобы специфицировать максимально возможную длину вектора (ceiling ). Вектор переменной длины с действительным полем длины равным нулю является пустым вектором.

T T" ;

В следующем примере, обязательным является вектор , который должен содержать от 300 до 400 байт непрозрачного типа. Он не должен быть пустым. Поле действительной длины занимает два байта, uint16 , достаточных, чтобы представить значение 400. С другой стороны, longer может представить до 800 байт данных, или 400 uint16 элементов, и может быть пустым. Его кодовое представление будет включать два байта поля реальной длины, за которым будет следовать вектор . Длина закодированного вектора должна быть четной, кратной длине одиночного элемента (например: 17-байтовый вектор uint16 будет нелегальным ).

opaque mandatory<300..400>; /* поле длины имеет 2 байта, не может быть пустым */ uint16 longer<0..800>; /* 0 - 400 16-битовое целое число без знака */

Базовый числовой тип данных представляет собой байт без знака (uint8 ). Все более длинные типы цифровых данных образуются из фиксированной последовательности байт без знака, объединенных вместе. Следующие числовые типы являются предопределенными.

Сетевые протоколы SSL и TLS являются криптографическими протоколами, обеспечивающими аутентификацию и защиту от несанкционированного доступа, нарушения целостности передаваемых данных. Протоколы SSL/TLS предназначены для исключения подмены идентификатора на клиентской или серверной стороне, раскрытия или искажения данных. Для этих целей используется надежный метод аутентификации, применяются шифрование канала связи и коды целостности сообщений. Стандартным портом, устанавливаемым по умолчанию для SSL/TLS, является порт 443 для HTTPS, 465 для SMTPS (электронная почта), 636 для LDAPS, 563 для NNTPS, 994 для IRCS (чат), 995 для POP3S.

Протокол SSL

Протокол SSL разработан компанией Netscape для защиты данных между сервисными и транспортными протоколами. Первая обнародованная версия была выпущена в 1995 году. Широко используется для VoIP-приложений, сервисов обмена мгновенными сообщениями. SSL представляет собой безопасный канал, имеющий следующие свойства:

• Частный канал. Обеспечивается шифрование всех сообщений после диалога, необходимого для определения ключа шифрования.
• Канал является аутентифицированным. Для клиентской стороны аутентификация выполняется опционально, а с серверной — обязательна.
• Надежность канала. При транспортировке сообщений осуществляется проверка целостности с использованием MAC.

Протокол SSL использует как симметричный, так и асимметричный ключи.

Особенности и назначение протокола SSL

Протокола SSL обеспечивает решение двух задач — шифрование передаваемой информации и передача информации именно туда, куда требуется (аутентификация). Основное назначение протокола — предоставление надежного способа обмена данными между приложениями. Реализация SSL выполнена в виде многослойной среды, которая используется для безопасной передачи информации посредством незащищенных каналов связи.

Многослойная структура представлена слоем протокола подтверждения подключения и слоем протокола записи. Первым слоем выступает транспортный протокол, например, TCP — вместе с SSL Record Protocol данные слои образуют ядро SSL, которое впоследствии участвует в формировании сложных инфраструктур.

Среди основных особенностей протокола SSL следует отметить программно-платформенную независимость. В настоящее время протокол SSL не обеспечивает должную защиту — на смену ему пришел протокол TLS.

Протокол TLS

Протокол TLS представляет собой криптографический протокол, который применяется для защищенной передачи данных между различными узлами в сети интернет. Данный протокол нашел применение в VoIP-приложениях, веб-браузерах, приложениях для мгновенного обмена сообщениями. TLS реализован на спецификации SSL 3.0. Разработкой и развитием протокола занимается компания IETF.

К основным мерам безопасности, которые обеспечивает протокол TLS, относятся:

• Применение ключа для проверки кода аутентификации сообщения.
• Исключена вероятность понижения версии TLS или подмены на менее защищенный сетевой протокол.
• Сообщение с подтверждением связи содержит хэш всех сообщений, которыми обменивались стороны.
• Использование нумерации записей приложения с применением MAC.
• Применение псевдослучайной функции, разбивающей входные сообщения на 2 части, каждая из которых обрабатывается разной хэш-функцией.

Особенности и назначение протокола TLS

В протоколе TLS используются следующие алгоритмы:

• RC4, Triple DES, SEED, IDEA и др. для симметричного шифрования.
• RSA, DSA, Diffie-Hellman и ECDSA для проверки подлинности ключей.
• MD5, SHA и SHA-256/384 для хэш-функций.

Приложения осуществляют обмен записями, которые хранят в себе данные. Записи могут быть сжаты, дополнены, зашифрованы или же идентифицированы. При этом в каждой записи указываются данные о длине пакета и используемой версии TLS.

В общем случае применение криптографии в протоколах SSL/TLS значительно снижает производительность приложений, зато обеспечивает надежную защиту передачи данных. Протоколы не требуют практически никаких настроек с клиентской стороны, считаются самыми распространенными протоколами защиты в сети интернет.

Главы замечательной книги «High Performance Browser Networking» авторства Ильи Григорика. Перевод выполнялся в рамках написания курсовой работы, потому очень вольный, но тем не менее будет полезен тем, кто слабо представляет что такое TLS, и с чем его едят.

Общие сведения о TLS

Протокол TLS (transport layer security) основан на протоколе SSL (Secure Sockets Layer), изначально разработанном в Netscape для повышения безопасности электронной коммерции в Интернете. Протокол SSL был реализован на application-уровне, непосредственно над TCP (Transmission Control Protocol), что позволяет более высокоуровневым протоколам (таким как HTTP или протоколу электронной почты) работать без изменений. Если SSL сконфигурирован корректно, то сторонний наблюдатель может узнать лишь параметры соединения (например, тип используемого шифрования), а также частоту пересылки и примерное количество данных, но не может читать и изменять их.

Конкретное место TLS (SSL) в стеке протоколов Интернета показано на схеме:

После того, как протокол SSL был стандартизирован IETF (Internet Engineering Task Force), он был переименован в TLS. Поэтому хотя имена SSL и TLS взаимозаменяемы, они всё-таки отличаются, так как каждое описывает другую версию протокола.

Первая выпущенная версия протокола имела название SSL 2.0, но была довольно быстра заменена на SSL 3.0 из-за обнаруженных уязвимостей. Как уже упоминалось, SSL был разработан компанией Netscape, так что в январе 1999 года IETF открыто стандартизирует его под именем TLS 1.0. Затем в апреле 2006 года была опубликована версия TLS 1.1, которая расширяла первоначальные возможности протокола и закрывала известные уязвимости. Актуальная версия протокола на данный момент – TLS 1.2, выпущенная в августе 2008 года.

Как уже говорилось, TLS был разработан для работы над TCP, однако для работы с протоколами дейтаграмм, такими как UDP (User Datagram Protocol), была разработана специальная версия TLS, получившая название DTLS (Datagram Transport Layer Security).
 

Шифрование, аутентификация и целостность

Протокол TLS предназначен для предоставления трёх услуг всем приложениям, работающим над ним, а именно: шифрование, аутентификацию и целостность. Технически, не все три могут использоваться, однако на практике, для обеспечения безопасности, как правило используются все три:

• Шифрование – сокрытие информации, передаваемой от одного компьютера к другому;
• Аутентификация – проверка авторства передаваемой информации;
• Целостность – обнаружение подмены информации подделкой.

Для того чтобы установить криптографически безопасный канал данных, узлы соединения должны согласовать используемые методы шифрования и ключи. Протокол TLS однозначно определяет данную процедуру, подробнее это рассмотрено в пункте TLS Handshake. Следует отметить, что TLS использует криптографию с открытым ключом, которая позволяет узлам установить общий секретный ключ шифрования без каких-либо предварительных знаний друг о друге.

Также в рамках процедуры TLS Handshake имеется возможность установить подлинность личности и клиента, и сервера. Например, клиент может быть уверен, что сервер, которые предоставляет ему информацию о банковском счёте, действительно банковский сервер. И наоборот: сервер компании может быть уверен, что клиент, подключившийся к нему – именно сотрудник компании, а не стороннее лицо (данный механизм называется Chain of Trust и будет рассмотрен в соответствующем разделе).

Наконец, TLS обеспечивает отправку каждого сообщения с кодом MAC (Message Authentication Code), алгоритм создания которого – односторонняя криптографическая функция хеширования (фактически – контрольная сумма), ключи которой известны обоим участникам связи. Всякий раз при отправке сообщения, генерируется его MAC-значение, которое может сгенерировать и приёмник, это обеспечивает целостность информации и защиту от её подмены.

Таким образом, кратко рассмотрены все три механизма, лежащие в основе криптобезопасности протокола TLS.
 

TLS Handshake

Перед тем, как начать обмен данными через TLS, клиент и сервер должны согласовать параметры соединения, а именно: версия используемого протокола, способ шифрования данных, а также проверить сертификаты, если это необходимо. Схема начала соединения называется TLS Handshake и показана на рисунке:

Разберём подробнее каждый шаг данной процедуры:

1. Так как TLS работает над TCP, для начала между клиентом и сервером устанавливается TCP-соединение.
2. После установки TCP, клиент посылает на сервер спецификацию в виде обычного текста (а именно версию протокола, которую он хочет использовать, поддерживаемые методы шифрования, etc).
3. Сервер утверждает версию используемого протокола, выбирает способ шифрования из предоставленного списка, прикрепляет свой сертификат и отправляет ответ клиенту (при желании сервер может так же запросить клиентский сертификат).
4. Версия протокола и способ шифрования на данном моменте считаются утверждёнными, клиент проверяет присланный сертификат и инициирует либо RSA, либо обмен ключами по Диффи-Хеллману, в зависимости от установленных параметров.
5. Сервер обрабатывает присланное клиентом сообщение, сверяет MAC, и отправляет клиенту заключительное (‘Finished’) сообщение в зашифрованном виде.
6. Клиент расшифровывает полученное сообщение, сверяет MAC, и если всё хорошо, то соединение считается установленным и начинается обмен данными приложений.

Ясно, что установление соединения TLS является, вообще говоря, длительным и трудоёмким процессом, поэтому в стандарте TLS есть несколько оптимизаций. В частности, имеется процедура под названием “abbreviated handshake”, которая позволяет использовать ранее согласованные параметры для восстановления соединения (естественно, если клиент и сервер устанавливали TLS-соединение в прошлом). Данную процедура рассмотрена подробнее в пункте «Возобновление сессии».

Также имеется дополнительное расширение процедуры Handshake, которое имеет название TLS False Start. Это расширение позволяет клиенту и серверу начать обмен зашифрованными данными сразу после установления метода шифрования, что сокращает установление соединения на одну итерацию сообщений. Об этом подробнее рассказано в пункте “TLS False Start”.
 

Обмен ключами в протоколе TLS

По различным историческим и коммерческим причинам чаще всего в TLS используется обмен ключами по алгоритму RSA: клиент генерирует симметричный ключ, подписывает его с помощью открытого ключа сервера и отправляет его на сервер. В свою очередь, на сервере ключ клиента расшифровывается с помощью закрытого ключа. После этого обмен ключами объявляется завершённым. Данный алгоритм имеет один недостаток: эта же пара отрытого и закрытого ключей используется и для аутентификации сервера. Соответственно, если злоумышленник получает доступ к закрытому ключу сервера, он может расшифровать весь сеанс связи. Более того, злоумышленник может попросту записать весь сеанс связи в зашифрованном варианте и занять расшифровкой потом, когда удастся получить закрытый ключ сервера. В то же время, обмен ключами Диффи-Хеллмана представляется более защищённым, так как установленный симметричный ключ никогда не покидает клиента или сервера и, соответственно, не может быть перехвачен злоумышленником, даже если тот знает закрытый ключ сервера. На этом основана служба снижения риска компрометации прошлых сеансов связи: для каждого нового сеанса связи создаётся новый, так называемый «временный» симметричный ключ. Соответственно, даже в худшем случае (если злоумышленнику известен закрытый ключ сервера), злоумышленник может лишь получить ключи от будущих сессий, но не расшифровать ранее записанные.

На текущий момент, все браузеры при установке соединения TLS отдают предпочтение именно сочетанию алгоритма Диффи-Хеллмана и использованию временных ключей для повышения безопасности соединения.

Следует ещё раз отметить, что шифрование с открытым ключом используется только в процедуре TLS Handshake во время первоначальной настройки соединения. После настройки туннеля в дело вступает симметричная криптография, и общение в пределах текущей сессии зашифровано именно установленными симметричными ключами. Это необходимо для увеличения быстродействия, так как криптография с открытым ключом требует значительно больше вычислительной мощности.
 

Возобновление сессии TLS

Как уже отмечалось ранее, полная процедура TLS Handshake является довольно длительной и дорогой с точки зрения вычислительных затрат. Поэтому была разработана процедура, которая позволяет возобновить ранее прерванное соединение на основе уже сконфигурированных данных.

Начиная с первой публичной версии протокола (SSL 2.0) сервер в рамках TLS Handshake (а именно первоначального сообщения ServerHello) может сгенерировать и отправить 32-байтный идентификатор сессии. Естественно, в таком случае у сервера хранится кэш сгенерированных идентификаторов и параметров сеанса для каждого клиента. В свою очередь клиент хранит у себя присланный идентификатор и включает его (конечно, если он есть) в первоначальное сообщение ClientHello. Если и клиент, и сервер имеют идентичные идентификаторы сессии, то установка общего соединения происходит по упрощённому алгоритму, показанному на рисунке. Если нет, то требуется полная версия TLS Handshake.

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

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

Для обхода данной проблемы был разработан механизм «Session Ticket», который устраняет необходимость сохранять данные каждого клиента на сервере. Если клиент при первоначальной установке соединения указал, что он поддерживает эту технологию, то в сервер в ходе TLS Handshake отправляет клиенту так называемый Session Ticket – параметры сессии, зашифрованные закрытым ключом сервера. При следующем возобновлении сессии, клиент вместе с ClientHello отправляет имеющийся у него Session Ticket. Таким образом, сервер избавлен от необходимости хранить данные о каждом соединении, но соединение по-прежнему безопасно, так как Session Ticket зашифрован ключом, известным только на сервере.
 

TLS False Start

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

Для получения ещё большего быстродействия была разработана технология TLS False Start, являющаяся опциональным расширением протокола и позволяющая отправлять данные, когда TLS Handshake завершён лишь частично. Подробная схема TLS False Start представлена на рисунке:

Важно отметить, что TLS False Start никак не изменяет процедуру TLS Handshake. Он основан на предположении, что в тот момент, когда клиент и сервер уже знают о параметрах соединения и симметричных ключах, данные приложений уже могут быть отправлены, а все необходимые проверки можно провести параллельно. В результате соединение готово к использованию на одну итерацию обмена сообщениями раньше.
 

TLS Chain of trust

Аутентификация является неотъемлемой частью каждого TLS соединения. Рассмотрим простейший процесс аутентификации между Алисой и Бобом:

1. И Алиса, и Боб генерируют собственные открытые и закрытые ключи.
2. Алиса и Боб обмениваются открытыми ключами.
3. Алиса генерирует сообщение, шифрует его своим закрытым ключом и отправляет Бобу.
4. Боб использует полученный от Алисы ключ, чтобы расшифровать сообщение и таким образом проверяет подлинность полученного сообщения.

Очевидно, что данная схема построена на доверии между Алисой и Бобом. Предполагается, что обмен открытыми ключами произошёл, например, при личной встрече, и, таким образом, Алиса уверена, что получила ключ непосредственно от Боба, а Боб, в свою очередь, уверен, что получил открытый ключ Алисы.

Пусть теперь Алиса получает сообщение от Чарли, с которым она не знакома, но который утверждает, что дружит с Бобом. Чтобы это доказать, Чарли заранее попросил подписать собственный открытый ключ закрытым ключом Боба, и прикрепляет эту подпись к сообщению Алисе. Алиса же сначала проверяет подпись Боба на ключе Чарли (это она в состоянии сделать, ведь открытый ключ Боба ей уже известен), убеждается, что Чарли действительно друг Боба, принимает его сообщение и выполняет уже известную проверку целостности, убеждаясь, что сообщение действительно от Чарли:

Описанное в предыдущем абзаце и есть создание «цепочки доверия» (или «Chain of trust», если по-английски).
В протоколе TLS данные цепи доверия основаны на сертификатах подлинности, предоставляемых специальными органами, называемыми центрами сертификации (CA – certificate authorities). Центры сертификации производят проверки и, если выданный сертификат скомпрометирован, то данный сертификат отзывается.

Из выданных сертификатов складывается уже рассмотренная цепочка доверия. Корнем её является так называемый “Root CA certificate” – сертификат, подписанный крупным центром, доверие к которому неоспоримо. В общем виде цепочка доверия выглядит примерно таким образом:

Естественно, возникают случаи, когда уже выданный сертификат необходимо отозвать или аннулировать (например, был скомпрометирован закрытый ключ сертификата, или была скомпрометирована вся процедура сертификации). Для этого сертификаты подлинности содержат специальные инструкции о проверке их актуальности. Следовательно, при построении цепочки доверия, необходимо проверять актуальность каждого доверительного узла.

Механизм этой проверки прост и в его основе лежит т.н. «Список отозванных сертификатов» (CRL – «Certificate Revocation List»). У каждого из центров сертификации имеется данный список, представляющий простой перечень серийных номеров отозванных сертификатов. Соответственно любой, кто хочет проверить подлинность сертификата, попросту загружает данный список и ищет в нём номер проверяемого сертификата. Если номер обнаружится – это значит, что сертификат отозван.

Здесь очевидно присутствует некоторая техническая нерациональность: для проверки лишь одного сертификата требуется запрашивать весь список отозванных сертификатов, что влечёт замедление работы. Для борьбы с этим был разработан механизм под названием «Протокол статусов сертификатов» (OCSP – Online Certificate Status Protocol). Он позволяет осуществлять проверку статуса сертификата динамически. Естественно, это снижает нагрузку на пропускную способность сети, но в то же время порождает несколько проблем:

• Центры сертификации должны справляться с нагрузкой в режиме реального времени;
• Центры сертификации должны гарантировать свою доступность в любое время;
• Из-за запросов реального времени центры сертификации получают информацию о том, какие сайты посещал каждый конкретный пользователь.

Собственно, во всех современных браузерах оба решения (OCSP и CRL) дополняют друг друга, более того, как правило имеется возможность настройки предпочитаемой политики проверки статуса сертификата.

Таким образом, в данной статье рассмотрены все ключевые средства, предоставляемые протоколом TLS для защиты информации. За некоторую отсебятину в статье прошу прощения, это издержки изначальной цели выполнения перевода.

Если вы столкнулись с проблемой, при которой возникает ошибка доступа к определенному сайту, при этом в браузере появляется сообщение , этому есть разумное объяснение. Причины и способы устранения проблемы приведем в этой статье.

SSL TLS

Протокол SSL TLS

Пользователи бюджетных организаций, да и не только бюджетных, чья деятельность напрямую связана с финансами, во взаимодействии с финансовыми организациями, например, Минфином, казначейством и т.д., все свои операции проводят исключительно по защищенному протоколу SSL. В основном, в своей работе они используют браузер Internet Explorer. В некоторых случаях Mozilla Firefox.

Ошибка SSL

Основное внимание, при проведении данных операций, да и работе в целом, уделено системе защиты: сертификаты, электронные подписи. Для работы используется программное обеспечение КриптоПро актуальной версии. Что касается проблемы с протоколами SSL и TLS , если ошибка SSL появилась, вероятнее всего отсутствует поддержка данного протокола.

Ошибка TLS

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

Поддержка протоколов SSL и TLS

Итак, при использовании Microsoft Internet Explorer, чтобы посетить веб-сайт по защищенному протоколу SSL, в строке заголовка отображается Убедитесь что протоколы ssl и tls включены . В первую очередь, необходимо включить поддержку протокола TLS 1.0 в Internet Explorer.

Компьютерные новости, обзоры, решение проблем с компьютером, компьютерными играми, драйверами и устройствами и другими компьютерными программами." title="программы, драйверы, проблемы с компьютером, играми" target="_blank">

Если вы посещаете веб-сайт, на котором работает Internet Information Services 4.0 или выше, настройка Internet Explorer для поддержки TLS 1.0 помогает защитить ваше соединение. Конечно, при условии, что удаленный веб-сервер, который вы пытаетесь использовать поддерживает этот протокол.

Для этого в меню Сервис выберите команду Свойства обозревателя .

На вкладке Дополнительно в разделе Безопасность , убедитесь, что следующие флажки выбраны:

Использовать SSL 2.0
Использовать SSL 3.0
Использовать TLS 1.0

Нажмите кнопку Применить , а затем ОК . Перезагрузите браузер .

После включения TLS 1.0, попытайтесь еще раз посетить веб-сайт.

Системная политика безопасности

Если по-прежнему возникают ошибки с SSL и TLS , если вы все еще не можете использовать SSL, удаленный веб-сервер, вероятно, не поддерживает TLS 1.0. В этом случае, необходимо отключить системную политику , которая требует FIPS-совместимые алгоритмы.

Чтобы это сделать, в Панели управления выберите Администрирование , а затем дважды щелкните значок Локальная политика безопасности .

В локальных параметрах безопасности, разверните узел Локальные политики , а затем нажмите кнопку Параметры безопасности .

Компьютерные новости, обзоры, решение проблем с компьютером, компьютерными играми, драйверами и устройствами и другими компьютерными программами." title="программы, драйверы, проблемы с компьютером, играми" target="_blank">Компьютерная помощь, драйверы, программы, игры

В соответствии с политикой в ​​правой части окна, дважды щелкните Системная криптография: использовать FIPS-совместимые алгоритмы для шифрования, хеширования и подписывания , а затем нажмите кнопку Отключено .

Внимание! Изменение вступает в силу после того, как локальная политика безопасности повторно применяется. То есть включите ее и перезапустите браузер .

КриптоПро TLS SSL

Обновить КриптоПро

Далее, как одним из вариантов решения проблемы, является обновление КриптоПро, а также настройка ресурса. В данном случае, это работа с электронными платежами. Поэтому, переходим на Удостоверяющий центр для автоматической настройки ресурса. В качестве ресурса выбираем Электронные торговые площадки.

После запуска автоматической настройки рабочего места, останется только дождаться завершения процедуры , после чего перезагрузить браузер . Если необходимо ввести или выбрать адрес ресурса - выбирайте нужный. Также, по окончании настройки, возможно, потребуется перезагрузить компьютер.

Настройка SSL TLS

Настройка сети

Еще одним вариантом может быть отключение NetBIOS через TCP/IP - расположен в свойствах подключения.

Регистрация DLL

Запустить командную строку от имени администратора и ввести команду regsvr32 cpcng . Для 64-разрядной ОС необходимо использовать тот regsvr32 , который в syswow64 .

Согласно отраслевым рекомендациям по безопасности и целостности данных, компания Salesforce требует обновить текущий протокол шифрования на TLS 1.1 или более поздней версии начиная с 22 июля 2017 года.
Во избежание нестабильной работы экземпляра производственной среды, рекомендуемые действия должны быть выполнены до наступления данной даты. После выполнения всех необходимых действий и последующего обновления выключите TLS 1.0 путем активации критического обновления TLS 1.0. Инструкции по активации критического обновления см. .

Данная статья содержит всю доступную информацию о выключении протокола шифрования TLS 1.0. Данная статья будет обновляться по мере появления новой информации. Рекомендуем регулярно проверять наличие новых сведений по подготовке к выключению TLS 1.0. Выключение TLS 1.0 для других служб Salesforce (например, Marketing Cloud, Heroku, Pardot, SalesforceIQ и т. д.) в настоящее время оценивается. Дополнительная информация будет доступна после утверждения планов и крайних сроков.

Очередной этап планового выключения TLS 1.0 завершен компанией Salesforce 11 ноября 2017 года. При возникновении ошибок подключения между системой Salesforce и любыми интеграциями, обозревателями или другими сторонними приложениями зарегистрируйте обращение в службу поддержки посредством портала "Справка и обучение". Если возникшая проблема является критической и затрагивает всех пользователей, обратитесь в службу поддержки по телефону для регистрации обращения с уровнем серьезности 1.

Некоторым пользователям, пытающимся выполнить вход посредством обозревателей, которые не совместимы с протоколом TLS 1.1 или более поздней версии, может быть недоступна регистрация обращения на портале "Справка и обучение". В данном случае обращение может быть зарегистрировано по телефону 1-800-667-6389.

?

TLS расшифровывается как Transport Layer Security (безопасность транспортного уровня). Это протокол, обеспечивающий конфиденциальность и целостность данных между двумя взаимодействующими приложениями. На сегодняшний день данный протокол безопасности является наиболее распространенным, поэтому используется для веб-обозревателей и других приложений, требующих безопасного обмена данными по сети. TLS гарантирует правильность подключения к удаленной конечной точке посредством шифрования и проверки подлинности конечной точки. В настоящее время доступны следующие версии: TLS 1.0, TLS 1.1 и TLS 1.2.

Веб-подключения и API-подключения Salesforce, а также доставка эл. почты, используют TLS в качестве основного компонента безопасности. Протоколы HTTPS (веб) и STARTTLS SMTP (эл. почта) используют TLS в качестве основного компонента безопасности.

Что изменилось?

Компания Salesforce требует обновить текущий протокол шифрования на TLS 1.1 или более поздней версии начиная с 22 июля 2017 года. При наступлении данной даты начнется выключение протокола шифрования TLS 1.0, поэтому он не сможет использоваться клиентами для доступа к некоторым службам Salesforce.

Как повлияет данное изменение на клиентов?

После выключения TLS 1.0 любые входящие подключения к организации Salesforce или исходящие подключения от организации Salesforce, использующие протокол шифрования TLS 1.0, станут недействительными. Данное изменение повлияет на некоторые службы Salesforce (см. список ниже), включая доступ к веб-сайтам (например, сообщества Salesforce, клиентские и партнерские порталы, сайты Force.com и Site.com).

Как клиенты могут избежать сбоя системы?
Необходимые действия определяются каналами, используемыми для доступа к организации Salesforce, а также службами Salesforce, используемыми организацией. Щелкните соответствующую тему ниже для перехода на нужную страницу.

Что послужило причиной данного изменения?

Компания Salesforce уделяет особое внимание вопросу доверия, поэтому активно и непрерывно работает над повышением безопасности клиентов путем использования новейших протоколов безопасности. В целях соответствия высоким стандартам безопасности и обеспечения сохранности клиентских данных, начиная с 22 июля 2017 года компания Salesforce планирует требовать использование протокола шифрования TLS 1.1 или более поздней версии.

Действия для подверженных влиянию каналов:

Действия для справки/сообщества успеха Salesforce:

Действия для подверженных влиянию функций Salesforce:

Действия для подверженных влиянию приложений AppExchange:

Действия для подверженных влиянию инструментов разработчика:

Как и когда компания Salesforce будет внедрять данное изменение?

Компания Salesforce планирует начать поэтапное выключение протокола шифрования TLS 1.0 для соответствующих служб Salesforce в июле 2017 года.

Расписание выключения TLS 1.0 в используемой среде Salesforce см. ниже. Каждая упомянутая служба должна поддерживать TLS 1.1 или более поздней версии к указанным датам.

Служба	Расписание выключения TLS 1.0
Новые производственные организации, созданные в выпуске Summer"16 или позже	Протокол TLS 1.0 выключен по умолчанию. Параметр консоли критических обновлений "Требовать протокол TLS 1.1 или более поздней версии для подключений HTTPS" будет автоматически включен в новых производственных организациях, созданных в выпуске Summer"16 или позже. Протокол TLS 1.0 будет выключен по умолчанию. Данный параметр может быть деактивирован клиентом для включения TLS 1.0 в целях тестирования совместимости с TLS. Дополнительную информацию о полномочиях пользователя, необходимых для просмотра и изменения параметра, см. в данной .
Безопасные организации	После наступления указанного времени протокол TLS 1.0 будет выключен автоматически, поэтому все безопасные организации (текущие, обновленные или новые) будут требовать протокол TLS 1.1 или более поздней версии для входящих и исходящих подключений HTTPS. Параметр консоли критических обновлений "Требовать протокол TLS 1.1 или более поздней версии для подключений HTTPS" будет недоступен.
Производственные организации
login.salesforce.com, другие службы*	Подлежит определению (после завершения поэтапного выключения)

*К другим службам относятся: test.salesforce.com, www.salesforce.com , сайт, store.salesforce.com, success.salesforce.com, фирменный вход (*.cloudforce.com), Live Agent, UMPS/Chatter Messenger и эл. почта.

Ресурсы

При возникновении дополнительных вопросов зарегистрируйте обращение в службу поддержки посредством портала "Справка и обучение".

-Сведения-

Интернет-обозреватели

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

Как проверить обозреватель на совместимость?

При отсутствии ошибок во время просмотра тестовой страницы , которая не поддерживает TLS 1.0, действия не требуются, так как данное изменение не влияет на доступ к системе Salesforce посредством используемого обозревателя.

Действия, необходимые для совместимости обозревателя

При наличии ошибок убедитесь в совместимости используемых обозревателей с протоколом TLS 1.1 или более поздней версии. При несовместимости обозревателя с протоколом TLS 1.1 или более поздней версии после выполнения данного изменения система Salesforce будет НЕДОСТУПНА пользователям

ПРИМЕЧАНИЕ. Включите протокол шифрования TLS 1.1 или TLS 1.2 в параметрах безопасности обозревателя. Компания Salesforce также рекомендует выключить TLS 1.0 для более надежной работы обозревателя (данное действие не является обязательным). Например, при включении протоколов TLS 1.0, TLS 1.1 и TLS 1.2 в параметрах безопасности обозревателя пользователи смогут подключаться к системе Salesforce посредством данного обозревателя после начала выключения TLS 1.0, запланированного на 22 июля 2017 года.

Обозреватель	Примечания по совместимости
Microsoft Internet Explorer Дополнительную информацию см. в статье Knowledge .
Internet Explorer 11 (настольная и мобильная версии)	При отображении сообщения об ошибке "Требуется более высокая безопасность" рекомендуем выключить параметр TLS 1.0 на вкладке "Дополнительно" диалогового окна "Свойства обозревателя".
Internet Explorer 8, 9 и 10 (настольная версия)	Совместимо только при наличии операционной системы Windows 7 или более поздней версии, но не по умолчанию. Дополнительную информацию о включении шифрования TLS 1.1 или более поздней версии см. в статье . Операционная система Windows Vista, XP или более ранней версии является несовместимой и не может быть настроена для поддержки TLS 1.1 или TLS 1.2.
Internet Explorer 7 или более ранней (настольной) версии
Internet Explorer 10 или более ранней (мобильной) версии	Несовместимо при использовании шифрования TLS 1.1 или более поздней версии.
Microsoft Edge	Совместимо при использовании TLS 1.1 или более поздней версии по умолчанию.
Mozilla Firefox
Firefox 27 или более поздней версии	Совместимо при использовании TLS 1.1 или более поздней версии по умолчанию.
	Совместимо, но не по умолчанию. Чтобы использовать about:config для включения TLS 1.1 или TLS 1.2, обновите значение конфигурации security.tls.version.max на "2" для TLS 1.1 или "3" для TLS 1.2.
Firefox 22 или более ранней версии	Несовместимо при использовании шифрования TLS 1.1 или более поздней версии.
Google Chrome Совместимо с последней версией (независимо от операционной системы).
Google Chrome 38 или более поздней версии	Совместимо при использовании TLS 1.1 или более поздней версии по умолчанию.
Google Chrome 22-37	Совместимо при наличии операционной системы Windows XP SP3, Vista или более поздней (настольной) версии, OS X 10.6 (Snow Leopard) или более поздней (настольной) версии, Android 2.3 (Gingerbread) или более поздней (мобильной) версии.
Google Chrome 21 или более ранней версии	Несовместимо при использовании шифрования TLS 1.1 или более поздней версии.
Обозреватель операционной системы Google Android
Android 5.0 (Lollipop) или более поздней версии	Совместимо при использовании TLS 1.1 или более поздней версии по умолчанию.
Android 4.4 (KitKat)-4.4.4	Может быть совместимо при использовании TLS 1.1 или более поздней версии. Некоторые устройства, оснащенные операционной системой Android 4.4.x, могут не поддерживать TLS 1.1 или более поздней версии.
Android 4.3 (Jelly Bean) или более ранней версии	Несовместимо при использовании шифрования TLS 1.1 или более поздней версии.
Apple Safari
Safari 7 или более поздней (настольной) версии для операционной системы OS X 10.9 (Mavericks) или более поздней версии	Совместимо при использовании TLS 1.1 или более поздней версии по умолчанию.
Safari 6 или более ранней (настольной) версии для операционной системы OS X 10.8 (Mountain Lion) или более ранней версии	Несовместимо при использовании шифрования TLS 1.1 или более поздней версии.
Safari 5 или более поздней (мобильной) версии для операционной системы iOS 5 или более поздней версии	Совместимо при использовании TLS 1.1 или более поздней версии по умолчанию.
Safari (мобильная версия) для операционной системы iOS 4 или более ранней версии	Несовместимо при использовании шифрования TLS 1.1 или более поздней версии.

Использование веб-обозревателя

В зависимости от точки доступа, пользователю, пытающемуся получить доступ к организации посредством веб-обозревателя, использующего TLS 1.0 после включения параметра "Требовать протокол TLS 1.1 или более поздней версии для подключений HTTPS", отображается сообщение об ошибке, содержащее рекомендации по дальнейшим действиям для исправления данной несовместимости.

См. сводную таблицу ниже.

Точка доступа	Сообщение об ошибке пользователя	Язык сообщения
login.salesforce.com	Сообщение об ошибке отображается только после входа пользователя посредством данной страницы.	Отображается на языке Salesforce пользователя.
Страница входа для функции "Мой домен"		Отображается на стандартном языке организации.
Сайт или сообщество	Сообщение об ошибке отображается при посещении данной страницы.	Отображается на языке Salesforce пользователя-гостя сайта.
Web-to-Lead или Web-to-Case	Сообщение об ошибке отображается при отправке данных с внешней страницы в систему Salesforce. Отправленные данные архивируются без создания интереса или обращения. Чтобы повторить данные архивные отправки, обратитесь в службу поддержки Salesforce и зарегистрируйте соответствующее обращение.
Страница входа или восстановления пароля клиентского или партнерского портала (не посредством сайта)	Сообщение об ошибке отображается при посещении данной страницы.	Отображается на стандартном языке портала.

Дополнительную информацию см. ниже (в зависимости от используемого обозревателя и операционной системы).

Internet Explorer в операционной системе Windows 7 или более поздней версии

При использовании TLS 1.0 после включения параметра "Требовать протокол TLS 1.1 или более поздней версии для подключений HTTPS" пользователям Internet Explorer в операционной системе Windows 7 или более поздней версии отображается следующее сообщение:

Internet Explorer в операционной системе Windows Vista, XP или более ранней версии

При использовании TLS 1.0 после включения параметра "Требовать протокол TLS 1.1 или более поздней версии для подключений HTTPS" пользователям Internet Explorer в операционной системе Windows Vista, XP или более ранней версии отображается следующее сообщение:

Google Chrome или Mozilla Firefox

При использовании TLS 1.0 после включения параметра "Требовать протокол TLS 1.1 или более поздней версии для подключений HTTPS" пользователям Google Chrome или Mozilla Firefox отображается следующее сообщение:

Мобильные обозреватели

При использовании TLS 1.0 после включения параметра "Требовать протокол TLS 1.1 или более поздней версии для подключений HTTPS" пользователям iOS (например, Safari), Android, Windows Mobile, BlackBerry и большинства других мобильных обозревателей отображается следующее сообщение:

Неизвестный веб-обозреватель или операционная система

При использовании TLS 1.0 после включения параметра "Требовать протокол TLS 1.1 или более поздней версии для подключений HTTPS" пользователям неизвестных веб-обозревателей или операционных систем отображается следующее сообщение:

Интеграции API (входящие подключения)

Интеграции API - это интерфейсы или приложения (включая мобильные и настольные клиентские приложения), независимые от системы Salesforce, но использующие данные Salesforce. При наличии интеграций API убедитесь, что данные интеграции поддерживают протоколы шифрования TLS 1.1 и/или TLS 1.2.

Действия, необходимые для интеграций API (входящих подключений)

При использовании входящих подключений к системе Salesforce без включения TLS 1.1 и/или TLS 1.2 после выполнения данного изменения интеграции могут работать нестабильно . Рекомендуем включить поддержку TLS 1.1 и TLS 1.2 как можно раньше.

Платформа или библиотека	Примечания по совместимости
Совместимо с последней версией (независимо от операционной системы).
Java 8 (1.8) или более поздней версии	Совместимо при использовании TLS 1.1 или более поздней версии по умолчанию.
	Включите TLS 1.1 и TLS 1.2 посредством системного свойства Java (https.protocols) для HttpsURLConnection. Чтобы включить TLS 1.1 и TLS 1.2 для подключений, отличных от HttpsURLConnection, настройте включенные протоколы в созданных экземплярах SSLSocket и SSLEngine внутри исходного кода приложения. При отсутствии возможности внедрения более новой версии Oracle Java рекомендуем временно использовать IBM Java.
Java 6 (1.6) (обновление 111) или более поздней версии	Включите TLS 1.1 посредством системного свойства Java (https.protocols) для HttpsURLConnection. Чтобы включить TLS 1.1 для подключений, отличных от HttpsURLConnection, настройте включенные протоколы в созданных экземплярах SSLSocket и SSLEngine внутри исходного кода приложения. Данное обновление Java 6 и более поздние обновления не являются общедоступными и требуют наличия контракта на поддержку Java 6 от корпорации Oracle .
Java 6 (1.6) или более ранней версии (общедоступная версия)	Несовместимо при использовании шифрования TLS 1.1 или более поздней версии. При отсутствии возможности внедрения более новой версии Oracle Java рекомендуем временно использовать IBM Java.
Java (IBM)
	Совместимо при использовании TLS 1.1 или более поздней версии по умолчанию. При необходимости задайте , если вызываемое приложение или библиотека использует SSLContext.getinstance("TLS").
Java 7 или более поздней версии, Java 6.0.1 Service Refresh 1 (J9 VM2.6) или более поздней версии, Java 6 Service Refresh 10 или более поздней версии	Включите TLS 1.2 посредством системного свойства Java (https.protocols) для HttpsURLConnection и системного свойства Java (com.ibm.jsse2.overrideDefaultProtocol) для подключений SSLSocket и SSLEngine (согласно рекомендациям, указанным в документации IBM). При необходимости задайте com.ibm.jsse2.overrideDefaultTLS=true .
NET 4.6 или более поздней версии	Совместимо при использовании TLS 1.1 или более поздней версии по умолчанию.
	NET 4.5, 4.5.1 и 4.5.2 не поддерживают TLS 1.1 и TLS 1.2 по умолчанию. Включение может быть выполнено двумя описанными ниже способами. Способ 1. Приложения.NET могут включать TLS 1.1 и TLS 1.2 прямо в коде программного обеспечения путем настройки System.Net.ServicePointManager.SecurityProtocol для включения SecurityProtocolType.Tls12 и SecurityProtocolType.Tls11. Ниже приведен пример кода C#. System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls; Способ 2. Чтобы включить TLS 1.2 по умолчанию без изменения исходного кода, задайте значение "1" параметру DWORD (SchUseStrongCrypto) в следующих двух разделах реестра (при их отсутствии создаются пользователем): "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" и "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319". Несмотря на наличие версии 4.0.30319 в данных разделах реестра, .NET 4.5, 4.5.1 и 4.5.2 также используют данные значения. Тем не менее, данные разделы реестра будут включать TLS 1.2 по умолчанию во всех установленных приложениях.NET 4.0, 4.5, 4.5.1 и 4.5.2 используемой системы. Именно поэтому, рекомендуем проверить данное изменение перед его развертыванием на производственных серверах. Кроме того, данное изменение доступно в виде файла импорта реестра . Тем не менее, данные значения реестра не повлияют на приложения.NET, которые задают значение System.Net.ServicePointManager.SecurityProtocol.
	NET 4.0 не поддерживает TLS 1.2 по умолчанию. Чтобы включить TLS 1.2 по умолчанию, установите.NET Framework 4.5 или более поздней версии и задайте значение "1" параметру DWORD (SchUseStrongCrypto) в следующих двух разделах реестра (при их отсутствии создаются пользователем): "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" и "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319". Тем не менее, данные разделы реестра могут включать TLS 1.2 по умолчанию во всех установленных приложениях.NET 4.0, 4.5, 4.5.1 и 4.5.2 используемой системы. Рекомендуем проверить данное изменение перед его развертыванием на производственных серверах. Кроме того, данное изменение доступно в виде файла импорта реестра . Тем не менее, данные значения реестра не повлияют на приложения.NET, которые задают значение System.Net.ServicePointManager.SecurityProtocol.
NET 3.5 или более ранней версии	Несовместимо при использовании шифрования TLS 1.1 или более поздней версии.
Совместимо с последней версией (при наличии операционной системы, поддерживающей TLS 1.1 или TLS 1.2).
Python 2.7.9 или более поздней версии	Совместимо при использовании TLS 1.1 или более поздней версии по умолчанию.
Python 2.7.8 или более ранней версии	Несовместимо при использовании шифрования TLS 1.1 или более поздней версии.
Совместимо с последней версией (при связывании с OpenSSL 1.0.1 или более поздней версии).
	TLS 1.2 включается по умолчанию при наличии OpenSSL 1.0.1 или более поздней версии. Использование символа:TLSv1_2 (предпочтительно) или:TLSv1_1 с параметром ssl_version объекта SSLContext гарантирует выключение TLS 1.0 или более ранней версии.
Ruby 1.9.3 или более ранней версии	Несмотря на отсутствие символа:TLSv1_2 в Ruby 1.9.3 или более ранней версии, Ruby поддерживает его добавление и компиляцию с OpenSSL 1.0.1 или более поздней версии.
Microsoft WinInet
	Совместимо при использовании TLS 1.1 или более поздней версии по умолчанию.
Windows Server 2008 R2-2012	Совместимо по умолчанию (при наличии обозревателя Internet Explorer 11). При наличии обозревателя Internet Explorer 8, 9 или 10 протоколы TLS 1.1 и TLS 1.2 включаются пользователем или администратором. Дополнительную информацию о включении шифрования TLS 1.1 или более поздней версии см. в статье .
	Несовместимо при использовании шифрования TLS 1.1 или более поздней версии.
Безопасный канал Microsoft Совместимо с последней версией.
Windows Server 2012 R2 или более поздней версии Windows 8.1 или более поздней версии	Совместимо при использовании TLS 1.1 или более поздней версии по умолчанию.
Windows Server 2012	По умолчанию протоколы TLS 1.1 и TLS 1.2 выключены, но доступны при их поддержке приложением. Протоколы TLS 1.1 и TLS 1.2 могут быть включены по умолчанию внутри реестра файла импорта реестра .
Windows Server 2008 R2	Совместимо по умолчанию в режиме клиента (при наличии обозревателя Internet Explorer 11). При отсутствии обозревателя Internet Explorer 11 или при необходимости подключения системы Salesforce к службе, выполняемой в системе данного типа, протоколы TLS 1.1 и TLS 1.2 могут быть включены по умолчанию внутри реестра . Кроме того, данные параметры реестра доступны в виде файла импорта реестра .
Windows Server 2008 или более ранней версии Windows Vista или более ранней версии	Несовместимо при использовании шифрования TLS 1.1 или более поздней версии.
Microsoft WinHTTP и Webio
Windows Server 2012 R2 или более поздней версии Windows 8.1 или более поздней версии	Совместимо при использовании TLS 1.1 и TLS 1.2 по умолчанию.
Windows Server 2008 R2 SP1 и 2012	Как помочь конечным пользователям в управлении данным изменением? При получении доступа к системе Salesforce посредством TLS 1.0 пользователям (включая внутренних и внешних участников сообщества) может отображаться уведомление о необходимости обновления веб-обозревателя или его параметров. Для этого, воспользуйтесь указанными ниже методами. Пакет AppExchange. Установите и настройте пакет TLS 1.0 Compatibility User Message из каталога AppExchange для удобной доставки пользователям TLS 1.0 внутрипрограммных уведомлений, содержащих подробные инструкции по обеспечению совместимости с TLS 1.1 или более поздней версии. Инструкции по установке доступны из списка AppExchange. Контроллер страницы Visualforce. При наличии опыта разработки Visualforce и Apex проверьте значение ApexPages.currentPage().getHeaders().get("CipherSuite"), если не является нулевым, для подстроки " TLSv1 " (включая начальные и конечные пробелы). При его наличии используется TLS 1.0, а страница Visualforce может отображать уведомление о необходимости обновления веб-обозревателя или его параметров. ПРИМЕЧАНИЕ. Отчет по журналу входов для всех пользователей организации может просматриваться и выполняться только пользователями с полномочием "Управление пользователями". При отсутствии полномочия "Управление пользователями" обратитесь к администратору, имеющему необходимые полномочия на выполнение отчета "Журнал входов" для всех пользователей. Ниже перечислены другие способы отслеживания входов TLS 1.0, которые компания Salesforce планирует внедрить в выпуске Summer"16. Файлы журналов событий (эффективное средство для загрузки событий входа и выхода прямо в CSV-формате посредством общедоступного интерфейса API) Как выполнить общее тестирование перед выключением TLS 1.0? При необходимости воспользуйтесь новым параметром консоли критических обновлений "Требовать протокол TLS 1.1 или более поздней версии для подключений HTTPS", позволяющим заранее тестировать выключение TLS 1.0 для безопасных и производственных организаций. Прежде чем тестировать данное обновление в производственной организации, рекомендуем выполнить его тестирование в безопасной среде для подтверждения сквозной совместимости. Что делать при использовании перехватывающего HTTPS прокси-сервера в сети? Некоторые сети перехватывают исходящий трафик HTTPS путем использования прокси-сервера, создающего собственные сертификаты, поэтому обмен данными с системой Salesforce и другими конечными точками, который не шифруется, может тщательно контролироваться. Данные прокси-серверы создают собственные подключения TLS к системе Salesforce. Сети, использующие данный тип прокси-сервера, должны гарантировать поддержку TLS 1.2 и выбор TLS 1.2 при подключении к системе Salesforce. Отклонения от стандартного режима работы могут возникать при условии, что прокси-сервер не поддерживает TLS 1.0 или выбирает TLS 1.0 вместо TLS 1.2 при подключении к удаленным конечным точкам. Кроме того, ниже перечислены продукты интеграции Microsoft, на которые повлияет выключение TLS 1.0. Connect for Office. Поддержка Connect for Office будет прекращена и может не предоставляться при выключении TLS 1.0. Дополнительную информацию см. в документе Spring"16 Release Notes . Настоятельно рекомендуем пользователям заменить данное приложение альтернативным решением ниже. Надстройка Microsoft Word Ввод полей слияния Salesforce в шаблоны Word вручную; или Надстройка Microsoft Excel Экспорт CSV-файла прямо из системы Salesforce (только Salesforce Classic); или Решение AppExchange (клиенты должны напрямую подтверждать у партнера AppExchange совместимость выбранного решения с TLS 1.1 или более поздней версии) Microsoft Power BI или Microsoft Power Query Стандартные письма. Поддержка стандартных писем будет прекращена и может не предоставляться при выключении TLS 1.0. Настоятельно рекомендуем пользователям включить расширенные стандартные письма, поддерживающие протокол TLS 1.1. Дополнительную информацию см. в документе Spring"16 Release Notes . Connect for Outlook. Поддержка данной функции прекращена в выпуске Winter"16 , поэтому ее совместимость с TLS 1.1 или более поздней версии не подлежит проверке. Рекомендуем подготовить пользователей путем предоставления им возможности использования функций, совместимых с TLS 1.1 (например, Lightning for Outlook, Lightning Sync или Salesforce for Outlook). Мобильные приложения Salesforce Ниже перечислены мобильные операционные системы и версии приложений Salesforce, необходимые для использования указанных ниже мобильных приложений Salesforce после выключения TLS 1.0. Мобильное приложение Требуемая операционная система iOS и версия приложения Salesforce Требуемая операционная система Android и версия приложения Salesforce Salesforce Classic* * После выключения TLS 1.0 приложение Salesforce Classic не будет поддерживаться устройствами Blackberry. Salesforce Classic 4.6.10 (последняя версия) и операционная система iOS 7.x или более поздней версии Текущие версии Salesforce Classic будут поддерживаться устройствами iOS, оснащенными операционной системой iOS 5.x или более поздней версии Операционная система Android 5.x или более поздней версии Нет минимальной версии Salesforce Classic Salesforce1 (загружаемое приложение + веб-приложение) Salesforce1 для устройств iOS версии 7.3.4 Операционная система iOS 8.x или более поздней версии Salesforce1 для устройств Android версии 8.0 Операционная система Android 4.4.x или более поздней версии SalesforceA SalesforceA для устройств iOS версии 3.0.0 или более поздней версии Операционная система iOS 8.x или более поздней версии SalesforceA для устройств Android версии 3.0.0 или более поздней версии Операционная система Android 4.4.x или более поздней версии Data Loader Чтобы обеспечить бесперебойное использование приложения Data Loader, клиентам необходимо загрузить последнюю версию приложения Data Loader , представленную в выпуске Spring"16. Протокол TLS 1.1 или более поздней версии поддерживается только данной версией приложения. Identity Connect Выключение TLS 1.0 повлияет на возможности инициализации Identity Connect. Клиенты, которые не обновят Identity Connect до версии 2.1.0 до выключения TLS 1.0, не смогут передавать изменения, связанные с учетными записями или правами, включая создание и выключение пользователей, из Active Directory в систему Salesforce. Обратите внимание, что влияние на проверку подлинности для текущих пользователей отсутствует. Обновление Identity Connect должно быть выполнено во внепиковые часы работы ввиду временной недоступности служб. Прежде чем выполнить обновление, рекомендуем сделать резервную копию текущей установки, которая при необходимости может использоваться для отката. Кроме того, рекомендуем установить Java 8 на всех серверах, размещающих Identity Connect. Чтобы загрузить последнюю версию для системы Windows или Linux, последовательно выберите пункты "Настройка" | "Средства управления безопасностью" | "Identity Connect" в системе Salesforce. Дополнительную информацию об обновлении клиенты могут просмотреть в разделе 2.6 ("Обновление экземпляра Identity Connect") . Дополнительную информацию см. в статье . Сообщества и сайты ПРИМЕЧАНИЕ. Сроки выключения TLS 1.0 для сообществ Salesforce продлены до марта 2018 года. Данные продленные сроки применяются к сообществам Lightning и Visualforce. Дополнительную информацию см. в статье . Настраиваемые домены HTTPS Чтобы подготовиться к включению TLS 1.1 или более поздней версии, рекомендуем заранее проверить последствия выключения TLS 1.0 для пользователей организации посредством нового параметра консоли критических обновлений: "Требовать протокол TLS 1.1 или более поздней версии для подключений HTTPS". Дополнительную информацию см. в статье . CTI Toolkit и Open CTI CTI Toolkit CTI Toolkit не будет поддерживать TLS 1.1 или более поздней версии, а после прекращения поддержки продукта в выпуске Spring"17 не будут работать все функции CTI Toolkit. Дополнительную информацию см. в статье . Ранее компанией Salesforce было отправлено уведомление о в выпуске Spring"15 (февраль 2015 года). Поддержка CTI Toolkit будет прекращена в выпуске Spring"17*. Работа любых функций интегрированной телефонии, использующих CTI Toolkit, будет остановлена. Телефонные компании-партнеры не смогут поддерживать CTI Toolkit после выпуска Spring"17. Рекомендуем заменить CTI Toolkit альтернативным решением Salesforce Open CTI во избежание возможных сбоев при использовании данной функции. Несмотря на отсутствие платы за использование решения Salesforce Open CTI, рекомендуем получить от телефонной компании-партнера дополнительные сведения о любых расходах или услугах, которые требуются для внедрения Salesforce Open CTI. Open CTI Open CTI - это облачное решение, поэтому пользователи должны убедиться, что их обозреватели поддерживают протокол TLS 1.1 или TLS 1.2 в целях поддержки функций интегрированной интерактивной телефонии. Подробные рекомендации см. в разделе "Интернет-обозреватели" выше. Подключение локального коннектора Open CTI из АТС/системы телефонии к системе Salesforce также должно поддерживать протокол TLS 1.1 или TLS 1.2. Chatter Desktop Windows Для поддержки TLS 1.1 или более поздней версии пользователям Chatter Desktop в операционной системе Windows рекомендуется обновить конфигурацию Internet Explorer. При необходимости протоколы TLS 1.1 и TLS 1.2 могут быть включены посредством групповых политик Active Directory. Дополнительную информацию см. в статье . Mac Для поддержки TLS 1.1 или более поздней версии и обеспечения бесперебойной работы Chatter Desktop в операционной системе Mac пользователям рекомендуется выполнить указанные ниже действия. Установите последнюю версию приложения Chatter Desktop для операционной системы Mac. Установите Adobe AIR 21.0.0.176 или более поздней версии. Дополнительную информацию о процессе установки см. в разделах справки и . Salesforce File Sync Для поддержки TLS 1.1 или более поздней версии и обеспечения бесперебойной работы File Sync пользователи должны установить последнюю версию (1.9), доступную для загрузки прямо из клиентского приложения. Дополнительную информацию см. в статье . SalesforceIQ Продукт Требования к совместимости с TLS 1.1 или более поздней версии SalesforceIQ Inbox для операционной системы iOS Разрешается использовать любую версию SalesforceIQ Inbox для операционной системы iOS ввиду поддержки только операционной системы iOS 5 или более поздней версии, которая поддерживает протоколы TLS 1.1 и TLS 1.2. SalesforceIQ Inbox для операционной системы Android Устройства, оснащенные операционной системой Android KitKat (4.4.x), требуют использования версии 2.5.1 приложения SalesforceIQ Inbox для операционной системы Android. Устройства, оснащенные операционной системой Android Lollipop (5.x), поддерживают протоколы TLS 1.1 и TLS 1.2 по умолчанию, поэтому не требуют использования конкретной версии приложения SalesforceIQ Inbox для операционной системы Android. Расширение SalesforceIQ Inbox Chrome Обозреватель Chrome поддерживает протоколы TLS 1.1 и TLS 1.2. Поддержка расширения Chrome предоставляется клиентам без дополнительных действий. Надстройка SalesforceIQ Inbox for Outlook Desktop Обозреватель Internet Explorer 11 SalesforceIQ Inbox for Outlook Mac Обозреватели Internet Explorer 11 и Microsoft Edge Последние версии обозревателей Chrome и Firefox Надстройка SalesforceIQ Inbox for Office 365 Обозреватель Safari 9 или более поздней (настольной) версии для операционной системы OS X 10.9 (Mavericks) или более поздней версии Marketing Cloud Дополнительную информацию и обновления по поддержке TLS см. в документации Marketing Cloud. Автоматизация маркетинга среди организаций Pardot Обновление коннектора Pardot в системе Salesforce для совместимости с более поздними версиями TLS выполнено 25 июня 2016 года. Участие клиентов не требуется. Вопросы и обновления см. . Единая регистрация Выключение TLS 1.0 повлияет на все способы проверки подлинности в системе Salesforce. Делегированная проверка подлинности Выноска, отправляемая системой Salesforce на конечную точку делегированной проверки подлинности и являющаяся URL-адресом HTTPS, должна поддерживать TLS 1.1 или TLS 1.2. SAML Salesforce как поставщик удостоверений SAML. При использовании Salesforce в качестве поставщика удостоверений SAML и выключении TLS 1.0 пользователи, использующие несовместимые веб-обозреватели, которые поддерживают только TLS 1.0, не смогут получать доступ к поставщику удостоверений. Salesforce как поставщик услуг SAML. При использовании Salesforce в качестве поставщика услуг SAML и выключении TLS 1.0 пользователи, использующие несовместимые веб-обозреватели, которые поддерживают только TLS 1.0, не смогут получать доступ к организации. Force.com Offline Connect Force.com Offline Connect поддерживает протокол TLS 1.1 или более поздней версии только при наличии обозревателя Internet Explorer 8 в операционной системе Windows 7 или более поздней версии, но не по умолчанию. Просмотрите статью . Операционная система Windows Vista, XP или более ранней версии является несовместимой и не может быть настроена для поддержки TLS 1.1 или TLS 1.2. Web-to-Case и Web-to-Lead . Пользователю, отправляющему данные об обращении или интересе в систему Salesforce посредством веб-обозревателя, поддерживающего TLS 1.0, будет отображаться сообщение об ошибке. Отправленные данные архивируются без создания интереса или обращения. Чтобы повторить данные архивные отправки, обратитесь в службу поддержки Salesforce и зарегистрируйте соответствующее обращение. Архивирование отправок будет продолжено до середины 2018 года (точная дата будет опубликована после ее определения). Поддержка клиентом агента Email-to-Case протокола TLS 1.1 и более новых версий возможна только после обновления Java. Обновите среду Java до версии 8, как указано в таблице ниже, чтобы обеспечить работоспособность Email-to-Case. ПОСЛЕДСТВИЯ ДЛЯ ПРИЛОЖЕНИЙ APPEXCHANGE Определите совместимость приложений AppExchange с процессом выключения TLS 1.0 компанией Salesforce путем налаживания непосредственного контакта с поставщиком и/или партнером. ПОСЛЕДСТВИЯ ДЛЯ ИНСТРУМЕНТОВ РАЗРАБОТЧИКА Мобильные приложения, разработанные посредством пакета Salesforce Mobile SDK При отсутствии поддержки TLS 1.1 или более поздней версии текущие мобильные приложения, созданные посредством пакета Salesforce Mobile SDK, не смогут взаимодействовать с системой Salesforce после выключения TLS 1.0. Во избежание потери функциональности приложения, рекомендуем применить указанные ниже изменения как можно раньше. При использовании приложений, созданных посредством пакета Salesforce Mobile SDK в операционной системе iOS 5.0 или более поздней версии, изменения не требуются. Более ранние приложения могут поддерживаться операционной системой iOS 5.0 или более поздней версии только после обновления. Ранее версии 4.4.x (KitKat). Версии Android, предшествующие версии 4.4, не поддерживают TLS 1.1 и TLS 1.2, поэтому больше не поддерживаются пакетом Salesforce Mobile SDK. Текущие приложения, предназначенные для данных платформ, прекратят свою работу при выключении TLS 1.0. Версия 4.4.x (KitKat). Приложения, предназначенные для платформы 4.4.x, потребуют исправления и повторной публикации в интернет-магазине Google Play до выключения TLS 1.0 в начале 2017 года. Дополнительную информацию см. в разделе "Applying the Mobile SDK Fix on Android 4.4 (KitKat)" . Версия 5.x (Lollipop) или более поздняя. Версия 5.x или более поздняя использует TLS 1.1 и TLS 1.2 по умолчанию, поэтому не потребует обновления пакета Salesforce Mobile SDK. Текущие приложения, предназначенные для данных платформ, продолжат свою работу без изменений. Force.com Migration Tool Force.com Migration Tool (начиная с версии 36.0) поддерживает TLS 1.1 и TLS 1.2 автоматически при обнаружении Java 7 (1.7). Java 8 (1.8) поддерживает TLS 1.1 и TLS 1.2 по умолчанию. Использование Java 7 (1.7) Чтобы включить TLS 1.1 и TLS 1.2, загрузите Force.com Migration Tool 36.0 или более поздней версии. При использовании более ранней версии Force.com Migration Tool рекомендуем самостоятельно включить TLS 1.1 и TLS 1.2 и выключить TLS 1.0. Для этого, дополните переменную среды ANT_OPTS следующей строкой: -Dhttps.protocols=TLSv1.1,TLSv1.2. ПРИМЕЧАНИЕ. Данный параметр также включает TLS 1.1 и TLS 1.2 для любых других инструментов Ant в локальной системе. Модуль Force.com IDE для Eclipse При использовании Java 7 создание или редактирование проектов посредством модуля Force.com IDE для Eclipse может выполняться только после выключения TLS 1.0. (Протокол TLS 1.0 выключен в Java 8 по умолчанию.) Обновите файл eclipse.ini путем добавления указанной ниже строки. Dhttps.protocols=TLSv1.1,TLSv1.2 Расположение файла eclipse.ini определяется операционной системой. Дополнительную информацию см. по следующей ссылке: https://wiki.eclipse.org/Eclipse.ini . Связанные статьи на портале "Справка и обучение"