Ssl vs. tls

Протокол SSL

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

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

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

A brief about TLS

TLS means Transport Layer Security, which is a cryptographic protocol successor of SSL 3.0, which was released in 1999.

TLS 1.0	TLS 1.0 which was upgrade of SSL v.3.0 released in January 1999 but it allows connection downgrade to SSL v.3.0.
TLS 1.1	After that, TLS v1.1 was released in April 2006, which was an update of TLS 1.0 version. It added protection against CBC (Cipher Block Chaining) attacks. In March 2020, Google, Apple, Mozilla and Microsoft has announced for deprecation of TLS 1.0 and 1.1 versions.
TLS 1.2	TLS v1.2 was released in 2008 that allows to specification of hash and algorithm used by the client and server. It allows authenticated encryption, which was added more support with extra data modes. TLS 1.2 was able to verify length of data based on cipher suite.
TLS 1.3	TLS v1.3 was released in August 2018 and had major features that differentiate it with its earlier version TLS v1.2 like removal of MD5 and SHA-224 support, require digital signature when earlier configuration used, compulsory use of Perfect forward secrecy in case of public-key based key exchange, handshake messages will now be encrypted after “Server Hello”.

Создание клиентского сертификата

Клиентский сертификат создается примерно так же, как серверный.

$ openssl genrsa -out client.key 2048

Generating RSA private key, 2048 bit long modulus
........................+++
..................................................+++
e is 65537 (0x10001)

$ openssl req -new -key client.key -out client.csr

You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) :RU
State or Province Name (full name) :Saint-Petersburg
Locality Name (eg, city) []:^C
mnorin@mnorin-work:~/Temp/certs/CA$ openssl req -new -key client.key -out client.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) :RU
State or Province Name (full name) :N/A
Locality Name (eg, city) []:Saint-Petrersburg  
Organization Name (eg, company) :My Company
Organizational Unit Name (eg, section) []:Engineering
Common Name (e.g. server FQDN or YOUR name) []:Ivan Ivanov
Email Address []:iivanov@mycompany.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

$ openssl x509 -req -in client.csr -CA root.pem -CAkey root.key -CAcreateserial -out client.pem -days 365

Signature ok
subject=/C=RU/ST=N/A/L=Saint-Petrersburg/O=My Company/OU=Engineering/CN=Ivan Ivanov/emailAddress=iivanov@mycompany.com
Getting CA Private Key

$ openssl x509 -noout -issuer -subject -enddate -in client.pem
issuer= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=My Company Root Certificate/emailAddress=it@mycompany.com
subject= /C=RU/ST=N/A/L=Saint-Petrersburg/O=My Company/OU=Engineering/CN=Ivan Ivanov/emailAddress=iivanov@mycompany.com
notAfter=Jan 25 13:17:15 2016 GMT

Если необходим клиентский сертификат в формате PKCS12, создаем его:

$ openssl pkcs12 -export -in client.pem -inkey client.key -certfile root.pem -out iivanov.p12

Enter Export Password:
Verifying - Enter Export Password:

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

Как проверить сертификаты SSL/TLS

Мы рассмотрим 5 наиболее популярных онлайн-инструментов для обнаружения слабых мест веб-сайта. Что ж, давайте приступим.  

SeoLik

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

Проверяем наличие HTTPS соединения:

1. Открываем в браузере сервис Seolik и вводим ссылку на необходимый сайт, затем кликаем по кнопке «Анализ». 
2. В результате анализа рассматриваемого ресурса, перед нами отобразится вся необходимая информация: название сертификата, срок действия, серийный номер и другие атрибуты, которые могут быть полезны для разработчиков. 

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

SSL Shopper

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

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

Wormly Web Server Tester

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

1. Открываем сайт и вводим в запрос «Web Server URL» нужную ссылку, затем кликаем по красной кнопке.
2. Далее будет запущен глубокий анализ, который можно пропустить. Уже на первых этапах тестирования будет сообщено о безопасности ресурса в строке «Expires». 

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

Immuni Web

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

При необходимости можно сохранить все результаты в формате PDF. Для этого следует кликнуть по кнопке «Download report». 

SSL Checker

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

На этом моя статья подходит к концу. Теперь вы знаете, как можно проверить SSL и TLS сертификаты на сайте

Спасибо за внимание!

Про установку SSL-сертификатов вы можете почитать тут и тут.

Параметры безопасности протокола TLS

Любое действие в сети представляет собой обмен данными между компьютером (сервером) пользователя и сервером, на котором хранится информация. При каждом вводе запроса в поисковую строку, авторизации в аккаунте или переходе с одной страницы сайта на другую, пользователь и сервер взаимодействуют друг с другом. Такие взаимодействия называются транзакциями, а их совокупность — сессией. TLS отвечает за безопасность транзакций и сессии в целом.

Протокол TLS обеспечивает защиту в три этапа:

На этапе TLS Handshake (рукопожатие) происходит согласование параметров соединения (версии протокола, способа шифрования и соединения) между клиентом и сервером. Для этого используется обмен ключами по алгоритму RSA:

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

TLS False Start (фальстарт) — процедура возобновления сессии. Если транзакции выполняются в пределах одной запущенной сессии, данный этап позволяет пропустить процедуру Handshake. Протокол повторно использует те данные, которые уже были обработаны и подтверждены в начале сессии. При этом каждая сессия имеет свой срок жизни. Как только срок сессии истекает, с помощью TLS Handshake запускается новая сессия.

Также обязательная процедура TLS-соединения — TLS Chain of trust (цепочка доверия). Она отвечает за аутентификацию между клиентом и сервером. «Цепочка доверия» работает на основе регулярной проверки подлинности — соответствия сертификатов стандартам Сертификационных центров, которые их выдают. Подлинность сертификата регулярно проверяется в течение сессии. Если обнаружится, что сертификат скомпрометирован (то есть данные под его защитой были перехвачены), данные будут отозваны, транзакция не состоится и сессия будет прервана.

Таким образом, при передаче данных сначала вызывается процедура Handshake или False Start, которая согласовывает параметры, а затем Chain of trust, которая обеспечивает аутентификацию (проверку авторства передаваемой информации). Подробнее о принципах работы TLS читайте в официальной документации Datatracker.

Оглавление

• Краткая история вопроса – SSL
• Версии и преимущества TLS
  • Про TLS 1.0
  • Про TLS 1.1
  • Про TLS 1.2
  • Про TLS 1.2 и Windows XP SP3
  • Про TLS 1.2 и Windows 2003 SP2
• BEAST: как работает атака на SSL 2.0/3.0 и TLS 1.0
• Включаем TLS на Windows-системе
• Отключаем SSL на Windows-системе
• Закручиваем гайки: Включаем безопасное пересогласование TLS на Windows-системе
• Атака на SSL/TLS – THC-SSL-DOS
• Закручиваем гайки: настройки криптоалгоритмов на хосте
• Управляем настройками согласования SSL/TLS в браузерах
• Проверяем работу TLS 1.1 и 1.2
• Что делать, если у меня нет возможности включить TLS новых версий

Приступим.

Управляем настройками согласования SSL/TLS в браузерах

Internet Explorer

Если Вы дочитали до этого места и всё поняли, но не знаете, как включить TLS в IE, то это, по сути, уникальная ситуация. Но тем не менее. Для включения поддержки TLS старших версий необходимо зайти в меню Internet Options -> Advanced, там в списке промотать до раздела Security и сделать соответствующие изменения (как минимум отключить SSL 2.0 и включить TLS 1.1 и TLS 1.2, остальное – на усмотрение).

Google Chrome

У меня под рукой кроме IE только хром, но, как известно из фольклора, оно не браузер. Что хорошо подтверждается тем, что никакого TLS 1.1 и TLS 1.2 в доступной сейчас рабочей версии (14.0.835.137) нет. Т.е. можно сказать проще – на сегодняшний день, 2.10.2011, все поддерживаемые хромом виды безопасных соединений на основе SSL/TLS уязвимы для сентябрьской атаки и данный инструмент не имеет смысла использовать для, допустим, финансовых транзакций, онлайн-платежей и прочих security sensitive штук.

Opera

Поставил оперу 11.51. Пожалуй, тут лучше всех сделано – можно не только выставить нужные протоколы (доступен выбор из SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2), но и нужные комплекты алгоритмов. Делается это зайдя в меню, там – Settings -> Preferences -> Advanced -> Security -> Security Protocols -> Details.
Правда, сделано плохо, потому что при включенном варианте “TLS 1.0 + 1.1 + 1.2” согласовывать начинает с TLS 1.0. Специально перепроверил, плюс посмотрел через netmon – удивительно, реально начинает с 1.0, согласовывает и успокаивается. Т.е. если включить все эти 3 протокола в Internet Explorer, то на тестовых сайтах клиент будет определяться как “TLS 1.2 compatible”, а в случае оперы – “TLS 1.0”. Плохо, по сути перечеркивает всё преимущество тонкой настройки – т.е. ну поддерживает она 1.2, что с того-то, если согласовывать пробует 1.0 для начала. То есть или надо вручную выключать TLS 1.0 (тогда большинство публичных https-сайтов типа gmail или facebook отвалятся), или сидеть с уязвимой версией.

После таких “мелочей” люди удивляются, почему IE является корпоративным стандартом.

A Brief History of SSL and TLS

SSL and TLS are both cryptographic protocols that provide authentication and data encryption between servers, machines, and applications operating over a network (e.g. a client connecting to a web server).  In reality, SSL is only about 25 years old. But in internet years, that’s ancient. The first iteration of SSL, version 1.0, was first developed in 1995 by Netscape but was never released because it was riddled with serious security flaws. SSL 2.0 wasn’t a whole lot better, so just a year later SSL 3.0 was released. Again, it had serious security flaws.

At that point, the guys at Consensus Development took a crack at it and developed TLS 1.0. TLS 1.0 was incredibly similar to SSL 3.0 – in fact it was based on it – but still different enough to require a downgrade before SSL 3.0 could be used. As the creators of the TLS protocol wrote:
 

“The differences between this protocol and SSL 3.0 are not dramatic, but they are significant enough that TLS 1.0 and SSL 3.0 do not interoperate.”

Downgrading to SSL 3.0 was still dangerous, though, given its known, exploitable vulnerabilities. All an attacker needed to do to target a website was downgrade the protocol to SSL 3.0. Hence, the birth of downgrade attacks. That ended up being the nail in the coffin for TLS 1.0.

TLS 1.1 came out seven years later in 2006, replaced by TLS 1.2 in 2008. That hurt TLS 1.1 adoption as many websites simply upgraded from 1.0 to TLS 1.2. We are now at TLS 1.3, which was finalized in 2018 after 11 years and nearly 30 IETF drafts. 

TLS 1.3 makes significant improvements over its predecessors and right now major players around the internet are pushing for its proliferation. Microsoft, Apple, Google, Mozilla, and Cloudflare all announced plans to deprecate both TLS 1.0 and TLS 1.1 in January 2020, making TLS 1.2 and TLS 1.3 the only game in town. 

At any rate, we’ve been using TLS for the past couple decades. At this point, if you’re still using SSL you’re years behind, metaphorically living in a forlorn era where people still use phone lines to dial on to the internet. 

Серверный сертификат

Для подписи сертификата для сервера нам нужно выполнить следующие действия:

1) Сгенерировать ключ
2) Сгенерировать запрос на подпись
3) Отправить CSR-файл в авторизационный центр или подписать самостоятельно

В серверный сертификат может включаться цепочка сертификатов, которыми подписан сертификат сервера, но ее можно также хранить в отдельном файле. В принципе, выглядит всё примерно так же, как и при генерации корневого сертификата

$ openssl genrsa -out server.key 2048
Generating RSA private key, 2048 bit long modulus
...................................................................................+++
..........................+++
e is 65537 (0x10001)

$ openssl req -new -key server.key -out server.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) :RU
State or Province Name (full name) :N/A
Locality Name (eg, city) []:Saint-Petersburg
Organization Name (eg, company) :My Company
Organizational Unit Name (eg, section) []:IT Service
Common Name (e.g. server FQDN or YOUR name) []:www.mycompany.com
Email Address []:webmaster@mycompany.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

$ openssl x509 -req -in server.csr -CA root.pem -CAkey root.key -CAcreateserial -out server.pem -days 365
Signature ok
subject=/C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=www.mycompany.com/emailAddress=webmaster@mycompany.com
Getting CA Private Key

$ openssl x509 -noout -issuer -subject -enddate -in server.pem
issuer= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=My Company Root Certificate/emailAddress=it@mycompany.com
subject= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=www.mycompany.com/emailAddress=webmaster@mycompany.com
notAfter=Jan 25 12:22:32 2016 GMT

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

Откуда берутся сертификаты?

Еще совсем недавно было всего 2 способа заполучить X.509 сертификат, но времена меняются и с недавнего времени есть и третий путь.

1. Создать свой собственный сертификат и самому же его подписать. Плюсы — это бесплатно, минусы — сертификат будет принят лишь вами и, в лучшем случае, вашей организацией.
2. Приобрести сертификат в УЦ. Это будет стоить денег в зависимости от различных его характеристик и возможностей, указанных выше.
3. Получить бесплатный сертификат LetsEncrypt, доступны только самые простые DV сертификаты.

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

Далее, создает CSR — запрос на подписание сертификата.

И подписываем.

Результат можно посмотреть командой:

имеет огромное количество опций и команд. Man страница не очень полезна, справочник удобнее использовать так:

Ровно то же самое можно сделать с помощью утилиты .

Следует серия вопросов, чтобы было чем запомнить поля и

Конвертируем связку ключей из проприетарного формата в PKCS12.

Смотрим на результат:

Значению соответствует определение ASN.1, согласно RFC 3280 оно всегда . Точно так же можно узнать смысл и возможные значения других , которые присутствуют в сертификате X.509.

LetsEncrypt

Можно бесплатно получить X.509 сертификат LetsEncrypt и для этого не нужно даже заходить на вебсайт, достаточно установить .

Включенный экспериментальный протокол QUIC

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

Показываем как отключить QUIC на примере браузера Google Chrome:

• Откройте браузер и введите команду chrome://flags/#enable-quic;
• В появившемся окне будет выделен параметр: Experimental QUIC protocol (Экспериментальный протокол QUIC). Под названием этого параметра вы увидите выпадающее меню, в котором нужно выбрать опцию: Disable.

Этот способ работает и в Windows и в Mac OS.

Преимущества внедрения HTTPS

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

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

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

Это важно при ведении бизнеса в Интернете.

Целостность данных — Кроме того, с помощью SSL вы можете гарантировать целостность данных
Например, без SSL можно не только перехватывать данные, поступающие на веб-сервер и с него, но и изменять их!

Google и SEO — И последнее, но не менее важное: вы должны принять во внимание недавние объявления Google о том, что они будут использовать, независимо от того, использует ли сервер SSL в качестве сигнала ранжирования.

Как усилить безопасность SSL, TLS

Бывает так, что сертификат установлен, а тестирование ssllabs показывает не лучший грейд безопасности.
Чтобы добиться заветного , нужно правильно настроить NGINX.
Для этого, сначала запускаем следующую команду, которая сгенерирует нужные ключи для Forward Secrecy (прямая секретность означает, что если третья сторона узнает какой-либо сеансовый ключ, то она сможет получить доступ только к тем к данным, что защищены этим ключом, не более):

openssl dhparam -out /etc/letsencrypt/dhparam.pem 2048

Затем, необходимо присутствие следующих записей в конфигурации сервера:

server {
  server_name sheensay.ru www.sheensay.ru;

  ssl_session_cache   shared:SSL:10m; # Разделяемый между всеми процесами кеш сессий на 10 байт с названием SSL. 1 Мб вмещает около 4000 сессий
  ssl_session_timeout 10m; # 10 минут - максимальное время жизни сессии

  add_header Strict-Transport-Security "max-age=31536000;"; # Заголовок, принудительно включающий защищённое соединение, минуя небезопасный HTTP

  # Заголовок Content Security Policy - отвечает за то, что считать безопасным подгружаемым контентом на странице
  add_header Content-Security-Policy-Report-Only "default-src https:; script-src https: 'unsafe-eval' 'unsafe-inline' *.yandex.ru; style-src https: 'unsafe-inline' fonts.googleapis.com; img-src https: data:; font-src https: data: fonts.googleapis.com; child-src https: www.youtube.com; report-uri /csp-report";

  ssl_stapling on;
  ssl_stapling_verify on;
  ssl_trusted_certificate /etc/letsencrypt/live/sheensay.ru/chain.pem; # домен меняете на свой
  resolver 8.8.4.4 8.8.8.8 valid=300s;
  resolver_timeout 10s;

  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:DES-CBC3-SHA:!RC4:!aNULL:!eNULL:!MD5:!EXPORT:!EXP:!LOW:!SEED:!CAMELLIA:!IDEA:!PSK:!SRP:!SSLv:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
  ssl_prefer_server_ciphers on;

  ### Чтобы у нас заработал Forward Secrecy, сгенерируем ключ командой ниже:
  ## openssl dhparam -out /etc/letsencrypt/dhparam.pem 2048
  ### После генерации расскомментируем строку ниже
  ssl_dhparam /etc/letsencrypt/dhparam.pem;
  
  ### Дальше другие настройки сервера
  ### ...

После всех манипуляций, не забудьте перезагрузить NGINX

service nginx reload

2016

При выдаче SSL-сертификатов в РФ будут использоваться отечественные алгоритмы шифрования

Правительство РФ планирует отказаться от зарубежных средств шифрования и заменить их отечественными. В частности, разработанные в России алгоритмы шифрования будут использоваться при выдаче SSL-сертификатов. Данную позицию поддерживают Минкомсвязи и ФСБ, сообщает «КоммерсантЪ» со ссылкой на главу рабочей подгруппы «Интернет + суверенитет» при администрации президента Илью Массуха.

По словам эксперта, в РФ есть свои средства шифрования и готовые версии протокола TLS с использованием соответствующих ГОСТу криптографических алгоритмов. Как сообщил Массух, уже существуют бета-версии браузеров «Спутник» и «Яндекс» с использованием отечественных алгоритмов шифрования. Правда, представители «Яндекса» данную информацию опровергают.

Ранее уже сообщалось о рассмотрении администрацией президента РФ возможности создания государственного удостоверяющего центра (УЦ). По словам Массуха, выдачей SSL-сертификатов с разработанными в РФ алгоритмами шифрования будет заниматься удостоверяющий центр НИИ «Восход» или другой аккредитованный Минкомсвязи УЦ. В отечественных браузерах данные УЦ будут по умолчанию добавлены в список доверенных.

Как пояснил Массух, в первую очередь SSL-сертификаты с российскими алгоритмами шифрования от местного удостоверяющего центра будут использовать правительственные ресурсы и портал госуслуг. В связи с этим будут внесены изменения в Федеральный закон «Об обеспечении доступа к информации о деятельности государственных органов и органов местного самоуправления».

90% публичных SSL VPN-серверов используют ненадежное или устаревшее шифрование

Компания High-Tech Bridge провела исследование с целью выяснить текущее состояние дел на рынке SSL VPN-сервисов. Исследование проводилось с использованием бесплатного SSL-сканера, разработанного компанией.

Эксперты проверили 10 436 выбранных в случайном порядке общедоступных SSL VPN-серверов вендоров Cisco, Fortinet и Dell.

77% проверенных SSL VPN-серверов используют ненадежный протокол SSLv3, тогда как несколько десятков серверов применяют версию SSLv2. Ряд стандартов безопасности, в том числе PCI DSS или NIST SP 800-52 запрещает использование протокола SSLv3 в связи с наличием многочисленных уязвимостей.

Как оказалось, 76% SSL VPN-серверов используют недоверенные SSL-сертификаты. Данные сертификаты позволяют удаленному атакующему при помощи атаки «человек посередине» осуществить перехват трафика. 74% сертификатов подписаны с применением SHA-1, а 5% используют устаревший хеш-алгоритм MD5, показало исследование.

Согласно полученным данным, 41% SSL VPN-серверов используют цифровые сертификаты, содержащие ключи RSA длиной 1024 бита, а 10% серверов, поддерживающих OpenSSL, подвержены уязвимости Heartbleed. Как выяснилось, только 3% серверов соответствуют стандартам PCI DSS, однако ни один из проверенных серверов не соответствует требованиям Национального института стандартов и технологий США (The National Institute of Standards and Technology, NIST).

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

Certificates Are Not the Same as Protocols

Before anyone starts worrying that they need to replace their existing SSL Certificates with TLS Certificates, it’s important to note that certificates are not dependent on protocols. That is, you don’t need to use a TLS Certificate vs. an SSL Certificate. While many vendors tend to use the phrase “SSL/TLS Certificate,” it may be more accurate to call them “Certificates for use with SSL and TLS,» since the protocols are determined by your server configuration, not the certificates themselves.

That goes for encryption strength, too. Many certificates advertise encryption strength, but truly it’s the capabilities of the server and the client that determine that. At the beginning of each connection, a process called a handshake occurs. During this process, the client authenticates the server’s TLS certificate and the two decide on a mutually supported cipher suite. Cipher suites are a collection of algorithms that all work together to securely encrypt your connection with that website. When the cipher suite is negotiated during the handshake, that’s when the version of the protocol and the supporting algorithms are determined. Your certificate just facilitates the process. 

Historically there have been four algorithms in a cipher suite:

• Key Exchange
• Digital Signature
• Message Authentication
• Hashing Algorithm

(If that seems a little in the weeds, it won’t in a second when we discuss the differences between SSL and TLS.)

For now, it’s likely you will continue to see certificates referred to as SSL Certificates because at this point that’s the term more people are familiar with. We’re beginning to see increased usage of the term TLS across the industry, and SSL/TLS is a common compromise until TLS becomes more widely accepted.

Проверяем работу TLS 1.1 и 1.2

Если Вы выяснили, что после отключения поддержки TLS 1.0 вы никуда не можете зайти, и подозреваете, что браузер сломался, есть отличный тестовый сайт:

Это специальный сайт, который зарегистрирован на одну из вымышленных и использующихся в курсах Microsoft организаций – Woodgrove Bank, а по сути – голый IIS с самоподписанным сертификатом, который поддерживает все виды SSL/TLS и нужен для диагностики. Зайдите на него, установите сертификат (их, кстати, несколько – специально для проверки поддержки различных криптоалгоритмов подписи) и проверите, что и как работает.

Есть второй вариант – https://www.mikestoolbox.net/. Тут возможностей поменьше, но зато быстрее и нагляднее видно – какой протокол поддерживается, что согласовалось.