Чтобы принять правильное решение, просмотрите , так как некоторые функции Salesforce поддерживаются только конкретными версиями веб-обозревателей. Обратите внимание, что в 2016 году компания Microsoft будет предоставлять техническую поддержку и обновления системы безопасности только для самой последней версии обозревателя Internet Explorer. Использование версии веб-обозревателя, которая не поддерживается поставщиком веб-обозревателя, не рекомендуется.

Чтобы быстро проверить обозреватель на совместимость с TLS 1.1 и TLS 1.2, откройте страницу посредством обозревателя Internet Explorer. При отображении веб-страницы (см. изображение ниже), содержащей следующий текст: "TLS 1.0 Deactivation Test Passed", используемый веб-обозреватель Internet Explorer уже поддерживает деактивацию TLS 1.0, запланированную компанией Salesforce на начало 2016 года.

Найдите используемую операционную систему ниже и выберите текущую версию обозревателя Internet Explorer. Чтобы быстро определить используемую операционную систему и версию веб-обозревателя, откройте страницу http://windows.microsoft.com/ru-ru/internet-explorer/which-version-am-i-using .

Internet Explorer 10

Windows 10, Server 2016 или более поздней версии

Данные операционные системы уже полностью поддерживают TLS 1.1 и TLS 1.2. При использовании стандартной конфигурации, включающей TLS 1.1 и TLS 1.2, дополнительные настройки не требуются. Несмотря на доступность обозревателя Internet Explorer 11 по умолчанию, исходным стандартным веб-обозревателем является Edge. Оба веб-обозревателя поддерживают TLS 1.1 и TLS 1.2 по умолчанию.

Internet Explorer 11

Доступ к системе Salesforce посредством обозревателя Internet Explorer 11 в операционной системе Windows 10 предоставляется при условии использования его стандартной конфигурации.

https://tls1test.salesforce.com

Edge

Доступ к системе Salesforce посредством обозревателя Edge в операционной системе Windows 10 предоставляется при условии использования его стандартной конфигурации.

Windows 8.1 и Server 2012 R2

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

Internet Explorer 11

Доступ к системе Salesforce посредством обозревателя Internet Explorer 11 в операционной системе Windows 8.1 или Server 2012 R2 предоставляется при условии использования его стандартной конфигурации.

При неудачной загрузке системы Salesforce или тестовой страницы https://tls1test.salesforce.com посредством обозревателя Internet Explorer 11 рекомендуем включить параметры "Использовать TLS 1.1" и "Использовать TLS 1.2" на вкладке "Дополнительно" диалогового окна "Свойства обозревателя", доступного путем выбора пункта "Свойства обозревателя" меню "Сервис". Меню "Сервис" может отображаться при нажатии значка шестеренки в верхнем правом углу окна обозревателя Internet Explorer 11. Для повторного включения TLS 1.1 и TLS 1.2 в обозревателе Internet Explorer 11 рекомендуем использовать кнопку "Сброс..." на вкладке "Дополнительно" диалогового окна "Свойства обозревателя".

Windows 8 и Server 2012

Данные операционные системы поддерживают только обозреватель Internet Explorer 10. Для обеспечения совместимости с TLS 1.1 и TLS 1.2 выполните одно из указанных ниже действий. Чтобы принять правильное решение, просмотрите

При наличии Windows 8 установите Windows 8.1. При наличии Windows Server 2012 установите Windows Server 2012 R2. (предпочтительно)

Internet Explorer 10

Чтобы включить TLS 1.1 и TLS 1.2 для обозревателя Internet Explorer, воспользуйтесь одним из разделов ниже (в зависимости от количества компьютеров: диалоговое окно "Свойства обозревателя" для одного компьютера или Active Directory для нескольких компьютеров).

После включения TLS 1.1 и TLS 1.2 доступ к системе Salesforce должен быть предоставлен посредством обозревателя Internet Explorer 10 в операционной системе Windows 8 или Windows Server 2012.

Windows 7 и Server 2008 R2

Данные операционные системы поддерживают версии 8-11 обозревателя Internet Explorer. Для оптимальной работы рекомендуем использовать обозреватель Internet Explorer 11 или более поздней версии. Выполните инструкции ниже для установленной версии обозревателя Internet Explorer.

Internet Explorer 11

Данная версия уже полностью поддерживает TLS 1.1 и TLS 1.2. При использовании стандартной конфигурации, включающей TLS 1.1 и TLS 1.2, дополнительные настройки не требуются.

Доступ к системе Salesforce посредством обозревателя Internet Explorer 11 в операционной системе Windows 7 или Windows Server 2008 R2 предоставляется при условии использования его стандартной конфигурации.

При неудачной загрузке системы Salesforce или тестовой страницы https://tls1test.salesforce.com посредством обозревателя Internet Explorer 11 рекомендуем включить параметры "Использовать TLS 1.1" и "Использовать TLS 1.2" на вкладке "Дополнительно" диалогового окна "Свойства обозревателя", доступного путем выбора пункта "Свойства обозревателя" меню "Сервис". Меню "Сервис" может отображаться при нажатии значка шестеренки в верхнем правом углу окна обозревателя Internet Explorer 11. Для повторного включения TLS 1.1 и TLS 1.2 в обозревателе Internet Explorer 11 рекомендуем использовать кнопку "Сброс..." на вкладке "Дополнительно" диалогового окна "Свойства обозревателя".

Internet Explorer 10

Так как некоторые функции поддерживаются только конкретными версиями веб-обозревателей.

Включите TLS 1.1 и TLS 1.2 для обозревателя Internet Explorer 10.

Воспользуйтесь последней версией обозревателя Google Chrome или Mozilla Firefox для доступа к системе Salesforce.

Включение TLS 1.1 и TLS 1.2 в диалоговом окне "Свойства обозревателя" обозревателя Internet Explorer 10

Воспользуйтесь данным разделом при наличии одного компьютера или небольшого количества компьютеров (особенно, если настройка параметров TLS 1.1 и TLS 1.2 не выполняется посредством групповых политик Active Directory).

Выберите пункт "Свойства обозревателя" меню "Сервис", отображаемого при нажатии значка шестеренки в верхнем правом углу окна обозревателя Internet Explorer 10 (см. изображение ниже).

Выберите вкладку "Дополнительно" вверху диалогового окна "Свойства обозревателя". Прокрутите список до конца и установите квадратные флажки напротив параметров "Использовать TLS 1.1" и "Использовать TLS 1.2" (при их отсутствии). Для дополнительной безопасности снимите квадратный флажок напротив параметра "Использовать SSL 3.0". По завершении настройки диалоговое окно должно напоминать изображение ниже (наличие флажков напротив параметров "Использовать TLS 1.0", "Использовать TLS 1.1" и "Использовать TLS 1.2"; отсутствие флажков напротив параметров "Использовать SSL 2.0" и "Использовать SSL 3.0"). Чтобы сохранить внесенные изменения, нажмите кнопку "OK".

После включения TLS 1.1 и TLS 1.2 доступ к системе Salesforce должен быть предоставлен посредством обозревателя Internet Explorer 10 в операционной системе Windows 7 или Windows Server 2008 R2.

Включение TLS 1.1 и TLS 1.2 посредством групповых политик Active Directory

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

Чтобы включить TLS 1.1 и TLS 1.2 посредством Active Directory, выполните инструкции, указанные компанией Microsoft в разделе "Выключение SSL 3.0 и включение TLS 1.0, TLS 1.1 и TLS 1.2 для обозревателя Internet Explorer посредством групповой политики" .

Internet Explorer 9

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

Установите Internet Explorer 11 (предпочтительно).

Включите TLS 1.1 и TLS 1.2 для обозревателя Internet Explorer 9.

Воспользуйтесь последней версией обозревателя Google Chrome или Mozilla Firefox для доступа к системе Salesforce.

Чтобы включить TLS 1.1 и TLS 1.2 для обозревателя Internet Explorer, воспользуйтесь одним из разделов ниже (в зависимости от количества компьютеров: для одного компьютера или нескольких компьютеров).

Включение TLS 1.1 и TLS 1.2 в диалоговом окне "Свойства обозревателя" обозревателя Internet Explorer 9

Воспользуйтесь данным разделом при наличии одного компьютера или небольшого количества компьютеров (особенно, если настройка параметров TLS 1.1 и TLS 1.2 не выполняется посредством групповых политик Active Directory).

Выберите пункт "Свойства обозревателя" меню "Сервис", отображаемого при нажатии значка шестеренки в верхнем правом углу окна обозревателя Internet Explorer 9 (см. изображение ниже).

Выберите вкладку "Дополнительно" вверху диалогового окна "Свойства обозревателя". Прокрутите список до конца и установите квадратные флажки напротив параметров "Использовать TLS 1.1" и "Использовать TLS 1.2" (при их отсутствии). Для дополнительной безопасности снимите квадратный флажок напротив параметра "Использовать SSL 3.0". По завершении настройки диалоговое окно должно напоминать изображение ниже (наличие флажков напротив параметров "Использовать TLS 1.0", "Использовать TLS 1.1" и "Использовать TLS 1.2"; отсутствие флажков напротив параметров "Использовать SSL 2.0" и "Использовать SSL 3.0"). Чтобы сохранить внесенные изменения, нажмите кнопку "OK".

После включения TLS 1.1 и TLS 1.2 доступ к системе Salesforce должен быть предоставлен посредством обозревателя Internet Explorer 9 в операционной системе Windows 7 или Windows Server 2008 R2.

Включение TLS 1.1 и TLS 1.2 посредством групповых политик Active Directory

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

Чтобы включить TLS 1.1 и TLS 1.2 посредством Active Directory, выполните инструкции, указанные компанией Microsoft в разделе "Выключение SSL 3.0 и включение TLS 1.0, TLS 1.1 и TLS 1.2 для обозревателя Internet Explorer посредством групповой политики" .

Internet Explorer 8

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

Установите Internet Explorer 11 (предпочтительно).

Установите Internet Explorer 9 или 10.

Включите TLS 1.1 и TLS 1.2 для обозревателя Internet Explorer 8.

Воспользуйтесь последней версией обозревателя Google Chrome или Mozilla Firefox для доступа к системе Salesforce.

Чтобы включить TLS 1.1 и TLS 1.2 для обозревателя Internet Explorer, воспользуйтесь одним из разделов ниже (в зависимости от количества компьютеров: для одного компьютера или нескольких компьютеров).

Ранее компанией Salesforce сообщалось о некорректной работе системы Salesforce в обозревателе Internet Explorer 8 на базе операционной системы Windows 7 при выключении TLS 1.0. Позже компанией Salesforce были внесены изменения, необходимые для корректной работы подключений HTTPS в обозревателе Internet Explorer 8 на базе операционной системы Windows 7. Обратите внимание, что, несмотря на корректную работу подключений HTTPS в обозревателе Internet Explorer 8 на базе операционной системы Windows 7, компания Salesforce прекращает официальную поддержку обозревателя Internet Explorer 8.

Включение TLS 1.1 и TLS 1.2 в диалоговом окне "Свойства обозревателя" обозревателя Internet Explorer 8

Воспользуйтесь данным разделом при наличии одного компьютера или небольшого количества компьютеров (особенно, если настройка параметров TLS 1.1 и TLS 1.2 не выполняется посредством групповых политик Active Directory).

Выберите пункт "Свойства обозревателя" меню "Сервис", отображаемого при нажатии кнопки "Сервис" в верхнем правом углу окна обозревателя Internet Explorer 8 (см. изображение ниже).

Выберите вкладку "Дополнительно" вверху диалогового окна "Свойства обозревателя". Прокрутите список до конца и установите флажки напротив параметров "Использовать TLS 1.1" и "Использовать TLS 1.2" (при их отсутствии). Для дополнительной безопасности снимите флажок напротив параметра "Использовать SSL 3.0". По завершении настройки диалоговое окно должно напоминать изображение ниже (наличие флажков напротив параметров "Использовать TLS 1.0", "Использовать TLS 1.1" и "Использовать TLS 1.2"; отсутствие флажков напротив параметров "Использовать SSL 2.0" и "Использовать SSL 3.0"). Чтобы сохранить внесенные изменения, нажмите кнопку "OK".

После включения TLS 1.1 и TLS 1.2 доступ к системе Salesforce должен быть предоставлен посредством обозревателя Internet Explorer 8 в операционной системе Windows 7 или Windows Server 2008 R2.

Включение TLS 1.1 и TLS 1.2 посредством групповых политик Active Directory

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

Чтобы включить TLS 1.1 и TLS 1.2 посредством Active Directory, выполните инструкции, указанные компанией Microsoft в разделе "Выключение SSL 3.0 и включение TLS 1.0, TLS 1.1 и TLS 1.2 для обозревателя Internet Explorer посредством групповой политики" .

Windows XP, Vista, Server 2008, Server 2003 или более ранней версии

Данные операционные системы не поддерживают TLS 1.1 и TLS 1.2. Чтобы продолжить использование Salesforce в данных операционных системах, выполните одно из указанных ниже действий.

Установите Windows 7 или более поздней версии и воспользуйтесь Internet Explorer 11 или более поздней версии (предпочтительно).

Установите Windows 7 или более поздней версии и воспользуйтесь Internet Explorer 9 или 10.

• Чтобы включить TLS 1.1 и TLS 1.2, настройте конфигурацию. Чтобы включить TLS 1.1 и TLS 1.2 для обозревателя Internet Explorer 9 или 10 в операционной системе Windows 7, 8, Server 2008 R2 или Server 2012, просмотрите инструкции, указанные в данном документе.

Воспользуйтесь последней версией обозревателя Google Chrome или Mozilla Firefox для доступа к системе Salesforce.

• Данного действия будет недостаточно для сохранения функциональных возможностей API-клиентов (например, приложение Salesforce for Outlook или интеграции Salesforce на основе платформы.NET). API-клиенты, использующие безопасный канал Microsoft, не смогут использовать TLS 1.1 или TLS 1.2 в данных операционных системах. Internet Explorer 9

  Доступ к системе Salesforce посредством обозревателя Internet Explorer 9 в операционной системе Windows Vista возвращает сообщение об общей ошибке ниже.

  Internet Explorer 8

  Доступ к системе Salesforce посредством обозревателя Internet Explorer 8 в операционной системе Windows XP возвращает сообщение об общей ошибке ниже.

  Internet Explorer 7

  Доступ к системе Salesforce посредством обозревателя Internet Explorer 7 в операционной системе Windows XP возвращает сообщение об общей ошибке ниже.

  Internet Explorer 6

  Доступ к системе Salesforce посредством обозревателя Internet Explorer 6 в операционной системе Windows XP возвращает сообщение об общей ошибке ниже.

Главы замечательной книги «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.
 

TSL 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 зашифрован ключом, известным только на сервере.
 

TSL 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 (Secure Sockets Layer - уровень защищённых сокетов) - криптографический протокол, который обеспечивает установление безопасного соединения между клиентом и сервером. Впоследствии на основании протокола SSL 3.0 был разработан и принят стандарт RFC , получивший имя TLS .

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

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

Аутентификация и обмен ключами.

SSL поддерживает три типа аутентификации: Аутентификация обеих сторон (клиент - сервер), аутентификация сервера с неаутентифицированным клиентом и полная анонимность. Всякий раз, когда сервер аутентифицируется, канал безопасен против атаки человек посредине, но полностью анонимная сессия по своей сути уязвима к такой атаке. Анонимный сервер не может аутентифицировать клиента. Если сервер аутентифицирован, то его сообщение сертификации должно обеспечить верную сертификационную цепочку, ведущую к приемлемому центру сертификации. Проще говоря, аутентифицированный клиент должен предоставить допустимый сертификат серверу. Каждая сторона отвечает за проверку того, что сертификат другой стороны еще не истек и не был отменен. Главная цель процесса обмена ключами - это создание секрета клиента (pre_master_secret), известного только клиенту и серверу. Секрет (pre_master_secret) используется для создания общего секрета (master_secret). Общий секрет необходим для того чтобы создать сообщение для проверки сертификата, ключей шифрования, секрета MAC (message authentication code) и сообщения «finished». При посылке верного сообщения «finished», тем самым стороны докажут что они знают верный секрет (pre_master_secret).

SSL-сертификат. Центр сертификации.

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

Центр сертификации или Удостоверяющий центр (англ. Certification authority, CA) - это организация или подразделение организации, которая выпускает сертификаты ключей электронной цифровой подписи, это компонент глобальной службы каталогов, отвечающий за управление криптографическими ключами пользователей. Открытые ключи и другая информация о пользователях хранится центрами сертификации в виде цифровых сертификатов, имеющих следующую структуру:

Серийный номер сертификата;

Объектный идентификатор алгоритма электронной подписи;

Имя удостоверяющего центра;

Срок годности;

Имя владельца сертификата (имя пользователя, которому принадлежит сертификат);

Открытые ключи владельца сертификата (ключей может быть несколько);

Сертификат также содержит полностью определенное имя домена (FQDN RFC 821) в строке Common Name. Одна из возможных атак - подмена DNS - будет обнаружена до отправки данных.

Виды SSL- сертификатов

Выделяют различные виды SSL- сертификатов в зависимости от типа проверки:

Сертификаты с проверкой домена – подтверждают подлинность доменного имени. Не содержат информации о компании.

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

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

Сертификаты с расширенной проверкой организации (Extended Validation SSL (EV SSL)) – обеспечивают наивысшее доверие клиентов. Когда пользователь находится на сайте с EV SSL сертификатом, браузер подсвечивает адресную строку зеленым цветом.

Wildcard SSL - сертификаты - это сертификаты, защищающие не только основной домен(ваш_домен.ру), но и поддомены(www.ваш_домен.ру, ssl.ваш_домен.ру, secure.ваш_домен.ру и т.д.). Может использоваться на веб-сервере и почтовом сервере. При генерации запроса на Wildcard сертификат в качестве Common Name (CN) используйте "*.domain.com", где domain.com - это ваше доменное имя.

Бесплатные Центры сертификации

Какой центр сертификации вам нужен? Все зависит от варианта использования сертификата.

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

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

Бесплатный сертификат (центр выдачи сертификатов) должен поддерживаться браузером, иначе проще генерировать самому. Главное сертификат правильно создать. При правильном создании самоподписанного сертификата будет выводится только ошибка он невозможности проверить сертификат, например Thunderbird : "Верификация сертификата не возможна - выдавшая сертификат сторона ненадежна".

От сертификата есть польза только если он выдан доверенным центром сертификации(которые встроены в windows) и если он обеспечен обязательствами (обычно от 10.000 у.е.). Все остальные сертификаты ничем не отличаются от самоподписанного, который можно сгенерировать самому на любой срок.

Бесплатные центры сертификации SSL:

• # nano /etc/dovecot/dovecot.conf ... ## SSL settings ssl_cert_file = /etc/dovecot/certs/imapd.pem ssl_key_file = /etc/dovecot/certs/imapd.pem ssl_ca_file = /etc/dovecot/certs/imapd.pem ...

  Вывести все доступные сертификаты

  Openssl s_client -connect 10.26.95.225:443 -showcerts SSLEngine on # запретить использование устаревшего протокол SSLv2 и SSLv3 SSLProtocol all -SSLv2 -SSLv3 # или запретить можно запретить все и включить только требуемые #SSLProtocol -all +TLSv1 +TLSv1.1 +TLSv1.2 SSLCertificateFile / etc/ apache2/ certs/ httpsd.pem SSLCertificateKeyFile / etc/ apache2/ certs/ httpsd.pem # SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem # SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key ...

Добрый день, уважаемые подписчики, уверен, что в подавляющем большинстве вы слышали такие слова как сертификат безопасности или шифрования, либо SSL сертификат, и я уверен, что большинство из вас даже знает их назначение., если нет, то я вам об этом очень подробно расскажу на личных примерах, все как полагается, после этого вы уже будите более тонко понимать все рубежи безопасности, которые предоставляют нам SSL сертификаты, без них сейчас уже не возможно представить современный IT мир, с его банковскими переводами, электронной почтой smime или интернет магазинами.

Что такое SSL и TLS

Secure Socket Layer или ssl это, технология, призванная сделать доступ к сайтам более надежным и безопасным. Сертификат шифрования позволяет, надежно защитить трафик, передаваемый между браузером пользователя и веб ресурсом (сервером), к которому браузер обращается, все это происходит за счет протокола https. Сделано, это все после того, как бурное развитие интернета привело к огромному количеству сайтов и ресурсов, которые требуют от пользователя ввод личных, персональных данных:

• Пароли
• Номера кредитных карт
• Переписка

Именно эти данные и являются добычей для хакеров, сколько уже было громких дел, с кражей персональной информации и сколько еще будет, ssl сертификат шифрования, призван это минимизировать. Разработкой технологии SSL выступила компания Netscape Communications, позднее она представила Transport Layer Security или проще TLS, это протокол основанный по спецификации SSL 3.0. И Secure Socket Layer и Transport Layer Security призваны обеспечить передачу данных между двумя узлами по интернету.

SSL и TLS не имеют принципиальных различий в своей работе, могут даже быть использованы на одном сервере одновременно, делается это исключительно из соображений обеспечения работы новых устройств и браузеров, так и устаревших, где Transport Layer Security не поддерживается.

Если рассматривать современный интернет, то там в качестве сертификата безопасности сервера и шифрования используется TLS, просто знайте это

Для примера откройте сайт Яндекса, я это делаю в Google Chrome, там на против адресной строки есть значок замка, щелкаем по нему. Тут будет написано, что подключение к веб-сайту защищено и можно нажать подробнее.

сразу видим значок Secure TLS connection, как я и говорил, большая часть интернет ресурсов именно на этой технологии. Давайте посмотрим сам сертификат, для этого жмем View certificate.

В поле о сведениях о сертификате видим его предназначение:

1. Обеспечивает получение идентификации от удаленного компьютера
2. Подтверждает удаленному компьютеру идентификацию вашего компьютера
3. 1.2.616.1.113527.2.5.1.10.2

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

• SSL 1.0 > данная версия в народ так и не попала, причины, возможно нашли его уязвимость
• SSL 2.0 > эта версия ssl сертификата была представлена в 1995 году, на стыке тысячелетий, она так же была с кучей дыр безопасности, сподвигнувшие компанию Netscape Communications к работе над третье версией сертификата шифрования
• SSL 3.0 > пришел на смену SSL 2.0 в 1996 году. Стало это чудо развиваться и в 1999 году крупные компании Master Card и Visa купили коммерческую лицензию на его использование. Из 3.0 версии появился TLS 1.0
• TLS 1.0 > 99 год, выходит обновление SSL 3.0 под названием TLS 1.0, проходит еще семь лет, интернет развивается и хакеры не стоят на месте, выходит следующая версия.
• TLS 1.1 > 04.2006 это его отправная точка, было исправлено несколько критичных ошибок обработки, а так же появилась защита от атак, где делался режим сцепления блоков шифротекста
• TLS 1.2 > появился в августе 2008
• TLS 1.3 > появится в конце 2016 года

Принцип работы TLS и SSL

Давайте разбираться как работает протоколы SSL и TLS. Начнем с основ, все сетевые устройства имеют четко прописанный алгоритм общения друг с другом, называется он OSI, который порезан на 7 уровней. В ней есть транспортный уровень отвечающий за доставку данных, но так как модель OSI это некая утопия, то сейчас все работаю по упрощенной модели TCP/IP, из 4 уровней. Стек TCP/IP, сейчас стандарт передачи данных в компьютерных сетях и он включает в себя, большое количество известных вам протоколов прикладного уровня:

Список можно продолжать очень долго, так их более 200 наименований. Ниже представлена схема сетевых уровней.

Ну и схема стека SSL/TLS, для наглядности.

Теперь все тоже самое простым языком, так как не всем понятны эти схемы и принцип работы ssl и tls не понятен. Когда вы открываете например мой блог сайт, то вы обращаетесь по прикладному протоколу http, при обращении сервер видит вас и передает на ваш компьютер данные. Если это представить схематично, то это будет простая матрешка, прикладной протокол http, кладется в стек tcp-ip.

Если бы на сайт стоял бы сертификат шифрования TLS, то матрешка протоколов была бы посложнее и выглядела бы вот так. Тут прикладной протокол http, кладется в SSL/TLS, который в свою очередь кладется в стек TCP/IP. Все тоже самое, но уже зашифровано, и если хакер перехватит эти данные по пути их передачи, то получит всего навсего цифровой мусор, а вот расшифровать данные может только та машина, которая устанавливала соединение с сайтом.

Этапы установки соединения SSL/TLS

Вот еще одна красивая и наглядная схема создания защищенного канала.

Установка соединения SSL/TLS на уровне сетевых пакетов

На иллюстрации, черные стрелки показывают сообщения, которые отправляются открытым текстом, синие - это сообщения, подписанные открытым ключом, а зеленые - это сообщения, отправленные с помощью шифрования объёмных данных и того MAC, о которых стороны договорились в процессе переговоров.

Ну и подробно про каждый этап обмена сетевых сообщений протоколов SSL/TLS.

• 1. ClientHello > пакет ClientHello делает предложение со списком поддерживаемых версий протоколов, поддерживаемые наборы шифров в порядке предпочтения и список алгоритмов сжатия (обычно NULL). Еще от клиента приходит случайное значение 32 байта, его содержимое указывает отметку текущего времени, его позже будут использовать для симметричного ключа и идентификатора сессии, который будет иметь значение ноль, при условии, что не было предыдущих сессий.
• 2. ServerHello > пакет ServerHello, отсылается сервером, в данном сообщении идет выбранный вариант, алгоритма шифрования и сжатия. Тут так же будет случайное значение 32 байта (отметка текущего времени), его также используют для симметричных ключей. Если ID текущей сессии в ServerHello имеет значение ноль, то создаст и вернёт идентификатор сессии. Если в сообщении ClientHello был предложен идентификатор предыдущей сессии, известный данному серверу, то протокол рукопожатия будет проведён по упрощённой схеме. Если клиент предложил неизвестный серверу идентификатор сессии, сервер возвращает новый идентификатор сессии и протокол рукопожатия проводится по полной схеме.
• 3.Certificate (3) > в данном пакете сервер отправляет клиенту свой открытый ключ (сертификат X.509), он совпадает с алгоритмом обмена ключами в выбранном наборе шифров. Вообще можно сказать в протоколе, запроси открытый ключ в DNS, запись типа KEY/TLSA RR. Как я писал выше этим ключом будет шифроваться сообщение.
• 4. ServerHelloDone > Сервер говорит, что сессия установилось нормально.
• 5. ClientKeyExchange > Следующим шагом идет отсылка клиентом ключа pre-master key, используя случайные числа (или отметки текущего времени) сервера и клиента. Данный ключ (pre-master key) как раз и шифруется открытым ключом сервера. Данное сообщение может расшифровать только сервер, с помощью закрытого ключа. Теперь оба участника вычисляют общий секретный ключ master key из ключа pre-master.
• 6. ChangeCipherSpec - клиент > смысл пакета, указать на то, что теперь весь трафик, который идет от клиента, будет шифроваться, с помощью выбранного алгоритма шифрования объёмных данных и будет содержать MAC, вычисленный по выбранному алгоритму.
• 7. Finished - клиент > Это сообщение содержит все сообщения, отправленные и полученные во время протокола рукопожатия, за исключением сообщения Finished. Оно шифруется с помощью алгоритма шифрования объемных данных и хэшируется с помощью алгоритма MAC, о которых договорились стороны. Если сервер может расшифровать и верифицировать это сообщение (содержащее все предыдущие сообщения), используя независимо вычисленный им сеансовый ключ, значит диалог был успешным. Если же нет, на этом месте сервер прерывает сессию и отправляет сообщение Alert с некоторой (возможно, неконкретной) информацией об ошибке
• 8. ChangeCipherSpec - сервер > пакет, говорит, что теперь весь исходящий трафик с данного сервера, будет шифроваться.
• 9.Finished - сервер >Это сообщение содержит все сообщения, отправленные и полученные во время протокола рукопожатия, за исключением сообщения Finished
• 10. Record Protocol (протокол записи) > теперь все сообщения шифруются ssl сертификатом безопасности

Как получить ssl сертификат безопасности

Давайте теперь поймем где взять сертификат шифрования, или как получить ssl сертификат безопасности. Способов конечно несколько, есть как платные, так и бесплатные.

Бесплатный способ получить tls сертификат безопасности

Этот способ, подразумевает использование самоподписного сертификата (self-signed), его можно сгенерировать на любом веб-сервере с ролью IIS или Apache. Если рассматривать современные хостинги, то в панелях управления, таких как:

• Directadmin
• ISPmanager
• Cpanel

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

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

Давайте смотреть как можно получить ssl сертификат безопасности, для этого формируется запрос на выпуск сертификата, называется он CSR запрос (Certificate Signing Request). Делается это чаще всего у специальной компании в веб форме, которая спросит вас несколько вопросов, про ваш домен и вашу компанию. Как только вы все внесете, сервер сделает два ключа, приватный (закрытый) и публичный (открытый). Напоминаю открытый ключ не является конфиденциальным, поэтому вставляется в CSR запрос. Вот пример Certificate Signing Request запроса.

Все эти не понятные данные легко можно интерпретировать специальными CSR Decoder сайтами.

Примеры двух сайтов CSR Decoder:

• http://www.sslshopper.com/csr-decoder.html
• http://certlogik.com/decoder/

Состав CSR запроса

• Common Name: доменное имя, которое мы защищаем таким сертификатом
• Organization: название организации
• Organization Unit: подразделение организации
• Locality: город, где находится офис организации
• State: область или штат
• Country:двухбуквенный код, страны офиса
• Email: контактный email технического администратора или службы поддержки

Как только Certificate Signing Request сгенерирован, можно начинать оформлять заявку на выпуск сертификата шифрования. Центр сертификации будет производить проверку, всех данных указанных вами в CSR запросе, и если все хорошо, вы получите свой ssl сертификат безопасности и вы его сможете использовать для https. Теперь ваш сервер, автоматом сопоставит выпущенный сертификат, со сгенерированным приватным ключом, все вы можете шифровать трафик подключения клиента к серверу.

Что такое центр сертификации

Что такое CA - Certification Authority или центр сертификации, читайте по ссылке слева, я подробно рассказал об этом там.

Какие данные содержит в себе SSL сертификат

В сертификате хранится следующая информация:

• полное (уникальное) имя владельца сертификата
• открытый ключ владельца
• дата выдачи ssl сертификата
• дата окончания сертификата
• полное (уникальное) имя центра сертификации
• цифровая подпись издателя

Какие существуют виды SSL сертификатов шифрования

Основных видов сертификатов безопасности три:

• Domain Validation - DV > Это сертификат шифрования, который только подтверждает доменное имя ресурса
• Organization Validation - OV > Это сертификат шифрования, который подтверждает организацию и домен
• Extendet Validation - EV > Это сертификат шифрования, который имеет расширенную проверку

Назначение Domain Validation - DV

И так сертификаты шифрования, подтверждающие только домен ресурса, это самые распространенные в сети сертификаты, их делают всех быстрее, автоматически. Когда вам нужно проверить такой сертификат безопасности, отправляется email с гиперссылкой, кликая по которой подтверждается выпуск серта. Хочу отметить, что письмо вам отправят, только не подтвержденный email (approver email), указанный при заказе сертификата шифрования.

approver email так же имеет требования, логично, что если вы заказываете сертификаты шифрования для домена, то и электронный ящик должен быть из него, а не mail или rambler, либо он должен быть указан в whois домена и еще одно требование название approver email, должно быть по такому шаблону:

• webmaster@ваш домен
• postmaster@ваш домен
• hostmaster@ваш домен
• administrator@ваш домен
• admin@

Я обычно беру ящик postmaster@ваш домен

Сертификат tls-ssl подтверждающие доменное имя выпускаются, когда CA произвел валидацию того, что заказчик обладает правами на доменное имя, все остальное, что касается организации в сертификате не отображается.

Назначение Organization Validation - OV

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

Назначение Extendet Validation - EV

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

• Могут посмотреть есть ли организация международных желтых страницах, кто не знает, что это такое, то это телефонные справочники в Америке. Проверяют так не все CA.
• Смотрят whois домена у вашей организации, делают это все центры сертификации, если в whois нет ни слова о вашей организации, то с вас будут требовать гарантийное письмо, что домен ваш.
• Свидетельство о государственной регистрации ЕГРИП или ЕГРЮЛ
• Могут проверить ваш номер телефона, запросив счет у вашей телефонной компании, в котором будет фигурировать номер.
• Могут позвонить и проверить наличие компании по этому номеру, попросят к телефону человека указанного администратором в заказе, так что смотрите, чтобы человек знал английский.

Сам сертификат шифрования extendet Validation - EV, самый дорогой и получается всех сложнее, у них кстати есть green bar, вы его точно видели, это когда на сайте в адресной строке посетитель видит зеленую стоку с названием организации. Вот пример клиент банка от сбербанка.

К расширенным сертификатам шифрования (extendet Validation - EV) самое большое доверие, это и логично вы сразу видите, что компания существует и прошла жесткие требования к выдаче сертификата. SSL cертификаты extendet Validatio делаются CA, только при выполнении двух требований, что организация владеет нужным доменом и, что она сама существует в природе. При выпуске EV SSL сертификатов, существует строгий регламент, в котором описаны требования перед выпуском EV сертификата

• Должен проверить правовую, физическую и операционную деятельности субъекта
• Проверка организации и ее документов
• Право владения доменом, организации
• Проверить, что организация полностью авторизована для выпуска EV сертификата

SSL cертификаты extendet Validatio выпускаются примерно от 10-14 дней, подходят как для некоммерческих организаций, так и для государственных учреждений.

Типы SSL сертификатов шифрования

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

• Обычные SSL сертификаты > это самые распространенные сертификаты, делаются автоматически, для подтверждения только домена. Стоят в среднем 18-22 доллара.
• SGC сертификаты > это SSL - TLS сертификаты с поддержкой, более высокого уровня шифрования. Они в основном идут для старперных браузеров, у которых есть поддержка только 40-56 битное шифрование. SGC принудительно повышает уровень шифрования, до 128 бит, что в несколько раз выше. Так как XP доживает свои последние годы, скоро SGC сертификаты шифрования не будут нужны. Стоит это чудо около 300-ста баксов за год.
• Wildcard сертификаты > Требуются, для субдоменов вашего основного домена. Простой пример мой блог сайт, если я покупаю Wildcard, то имею возможно его вешать на все домены 4 уровня у себя, *.сайт. Стоимость Wildcard сертификатов шифрования варьируется от количества поддоменов, от 190 баксов.
• SAN сертификаты > Допустим у вас есть один сервер, но на нем хостятся много разных доменов, вот SAN сертификат можно повесить на сервер и все домены будут использовать его, стоит от 400 баксов в год.
• EV сертификаты > про расширенные мы уже все обсудили выше, стоят от 250 баксов в год.
• Сертификаты c поддержкой IDN доменов

список сертификатов, у которых есть такая поддержка, IDN доменов:

• Thawte SSL123 Certificate
• Thawte SSL Web Server
• Symantec Secure Site
• Thawte SGC SuperCerts
• Thawte SSL Web Server Wildcard
• Thawte SSL Web Server with EV
• Symantec Secure Site Pro
• Symantec Secure Site with EV
• Symantec Secure Site Pro with EV

Полезные утилиты:

1. OpenSSL - самая распространенная утилита для генерации открытого ключа (запроса на сертификат) и закрытого ключа.
   http://www.openssl.org/
2. CSR Decoder - утилита для проверки CSR и данных, которые в нем содержаться, рекомендую использовать перед заказом сертификата.
   http://www.sslshopper.com/csr-decoder.html или http://certlogik.com/decoder/
Как посмотреть SSL сертификат сайта в Google Chrome Выпущено обновление для устранения критической уязвимости в Microsoft Secure Channel
3. 

Протоколы обеспечения аутентичности и конфиденциальности могут использоваться в двух режимах: транспортном и туннельном. В первом случае защищается только содержимое пакетов и, быть может, некоторые поля заголовков. Как правило, транспортный режим используется хостами. В туннельном режиме защищается весь пакет — он инкапсулируется в другой IP-пакет. На транспортном уровне аутентичность, конфиденциальность и целостность потоков данных обеспечивается протоколом TLS (Transport Layer Security, RFC 2246). Объектом защиты являются не отдельные сетевые пакеты, а потоки данных (последовательности пакетов). Злоумышленник не сможет переупорядочить пакеты, удалить некоторые из них или вставить свои. На основе TLS могут строиться защищенные протоколы прикладного уровня.

TLS — дальнейшее развитие протокола SSL

TLS — это протокол, который был введен в действие на основе протокола SSL организацией IETT, подготовившей соответствующий стандарт. Он обеспечивает возможность повторного подключения без повторной аутентификации и согласования ключей сеанса. Обеспечивается согласование допустимых алгоритмов генерирования ключей (DH), шифрования (3DES-CBC, RC2, RC4, IDEA, DES, Triple-DES, AES, Blowfish), цифровой подписи и аутентификации (DSS, RSA, анонимный доступ с последующей дополнительной аутентификацией), хеширования (SHA-1, MD5).

Протокол имеет два уровня: протокол записей TLS и протокол диалога TLS. На нижнем уровне, работающем поверх надежного транспортного протокола (например, TCP ), размещается протокол записей TLS. Этот протокол обеспечивает безопасность соединений, которые имеют два основных свойства:

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

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

Стандартный TLS не предусматривает поддержки российских алгоритмов

В соответствии со стандартом RFC 2246, протокол TLS поддерживает различные алгоритмы шифрования, широко распространенные в мире. Но не поддерживает российские алгоритмы. В связи с этим возникают проблемы использования этого протокола в ситуациях, когда требуется выполнение регламентирующих документов ФАПСИ по использованию сертифицированных алгоритмов. В числе таких документов следующие:

• ГОСТ 28147-89 — "Системы обработки информации. Защита криптографическая".
• ГОСТ Р 34.11 — "Информационная технология. Криптографическая защита информации. Функция хеширования".
• ГОСТ Р 34.10-94 — "Информационная технология. Криптографическая защита информации. Система электронной цифровой подписи на базе асимметричного криптографического алгоритма".
• ГОСТ Р34.10-2001 — "Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи".

Для решения вопросов поддержки протоколом TLS российских алгоритмов в 2002-м году ряд компаний, занимающихся разработкой систем защиты информации, электронной цифровой подписи, объединили свои усилия и подписали соглашение о сотрудничестве . В числе этих компаний были ФГУП НТЦ "Атлас", ООО "Крипто-Про", ООО "Фактор-ТС", ЗАО "МО ПНИЭИ" и ОАО "Инфотекс", ЗАО "Санкт-Петербургский региональный центр защиты информации", ООО "Криптоком", ООО "Р-Альфа", "КриптоПРО". Компании договорились об объединении усилий в целях достижения совместимости криптографических продуктов, разработки рекомендаций по стандартизации форматов сертификатов открытых ключей, списков отозванных сертификатов, криптографических сообщений с учетом использования российских алгоритмов.

В рамках "Соглашения о совместимости СКЗИ" были разработаны пять проектов информационных документов. Первые версии трех из них были представлены сотрудником компании "Крипто-Про" в июле 2003 года на 57-ой конференции IETF в Вене и с интересом встречены интернет-сообществом. Два документа уже получили статус документов рабочих групп IETF.

Решение по поддержке российских криптоалгоритмов стало дополнением к RFC 2246

Один из них представляет интерес в рамках рассматриваемого вопроса. Это — проект "Addition of GOST Ciphersuites to Transport Layer Security (TLS)", который является дополнением к спецификации RFC 2246 в части описания применения российских алгоритмов. Документ описывает четыре механизма, реализующих ключевые протоколы при использовании открытых ключей ГОСТ Р 34.10-94 и ГОСТ Р 34.10-2001. Первая пара использует шифрование ГОСТ 28147-89 и контроль целостности с помощью имитовставки, вторая пара не использует шифрования и контролирует целостность с помощью ключевого хеша (MAC) на основе алгоритма ГОСТ Р 34.11-94.

Выработав единые предложения по расширению возможностей протокола TLS, компании, занимающиеся разработкой СКЗИ, приступили к их реализации. В результате такой деятельности появилось несколько решений.

Одно из решений предложено компанией "Новый Адам", выпустившей «Удостоверяющий центр сертификатов цифровой подписи Инега УЦ ». Создаваемые в нем сертификаты могут участвовать в организации защищенного соединения по протоколу Transport Layer Security (TLS) (RFC 2246 The TLS Protocol Version 1.0.) с российскими криптографическими алгоритмами (хеш-функция — ГОСТ Р34.11-94, подпись — ГОСТ Р34.10-94, шифрование и выработка имитовставки — ГОСТ 28147-89).

Свое решение предлагает и компания «КриптоПРО ». Модуль поддержки сетевой аутентификации "КриптоПро TLS", входящий в состав СКЗИ "КриптоПро CSP", реализует протокол Transport Layer Security (TLS v. 1.0, RFC 2246) с использованием российских криптографических стандартов. Протокол TLS предназначен для обеспечения криптографическими средствами аутентификации отправителя (клиента) — адресата (сервера), контроля целостности и шифрования данных информационного обмена. В механизме защиты реализации протокола TLS (аутентификация клиента и сервера, шифрование информации, контроль целостности информации) применяются криптографические алгоритмы шифрования в соответствии с ГОСТ 28147-89, обмена ключей по алгоритму Диффи-Хеллмана, хеширования в соответствии с ГОСТ Р 34.11-94.

Модуль поддержки сетевой аутентификации "Крипто-Про TLS" функционирует совместно со средством криптографической защиты информации (СКЗИ) "КриптоПро CSP" в операционных средах Windows 95, Windows 95 OSR2, Windows 98. Windows 98 SE, Windows ME, Windows NT 4.0, Windows 2000/ XP. А для операционных систем Linux, FreeBSD, а также Windows аналогичный продукт, полностью совместимый с "Крипто-Про TLS", разработала компания "Цифровые технологии". Он называется Trusted TLS и представляет собой доработанное программное решение ModSSL, позволяющее использовать российские стандарты криптографической защиты информации в веб-сервере Apache. В качестве сертифицированных ГОСТ алгоритмов используются российские стандарты шифрования.

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

И хотелось бы затронуть еще один момент, связанный с использованием защищенных протоколов. Всегда ли можно доверять сервисам, которые их применяют? Компания Microsoft предупреждает, что верить можно далеко не в каждом случае. По этому поводу ею был выпущен специальный документ — «Как обнаруживать опасные веб-узлы и гиперссылки и защищаться от них ». В нем, в частности, говорится следующее.

"Чтобы защититься от подложных веб-узлов, необходимо выполнять следующие инструкции:

• перед отправкой важной информации убедитесь, что веб-узел использует протокол SSL/TLS (Secure Sockets Layer/Transport Layer Security), и проверьте имя сервера. Как правило, протокол SSL/TLS применяется для шифрования данных при пересылке через Интернет. Кроме того, с его помощью можно проверить, что данные передаются на нужный сервер. Имя сервера, на котором размещается текущая веб-страница, можно проверить по соответствующему имени пользователя цифрового сертификата SSL/TLS. Для этого необходимо, чтобы в правом нижнем углу окна обозревателя Internet Explorer появился значок в виде замка.
• чтобы проверить имя сервера на цифровом сертификате, дважды щелкните значок замка и запомните имя рядом с надписью "Кому выдан". Не отправляйте важные данные или данные, содержащие личные сведения, на веб-узлы, которые не используют протокол SSL/TLS. Если имя в поле "Кому выдан" отличается от имени веб-узла, на котором предположительно должна размещаться просматриваемая веб-страница, закройте окно обозревателя и покиньте данный узел".

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