Ssh vs ssl/tls

Введение

Если говорить о формате настройки сертификатов для безопасной передачи данных. Как правило, данные действия производят на каком-либо веб-сервере типа nginx или apache, стоящем на входе во внутреннюю сеть компании и dmz. Благодаря ему можно разделить защищенную внутреннюю сеть и внешнюю сеть интернет. Далее, внутри доверенной сети каждый поступает по-разному. Кто-то считает, что все внутренние сервисы могут взаимодействовать друг с другом без каких-то ограничений, и контроль пользователей управляется уже в GUI посредством логина и пароля для конкретного приложения с разграничением ролей в рамках приложения. Кто-то идет дальше, подключая LDAP и используя логин, пароль пользователя из общего хранилища.

Существуют различные протоколы и технологии типа RADIUS, Kerberos или OAuth/OpenID для работы с вопросами аутентификации. Кто-то использует схемы с базовой аунтефикацией, передавая логин и пароль в base64, кто-то использует JsonWebToken, еще существует возможность использования сертификатов для проверки не только сервера и клиента. В результате получается ситуация, что мы формируем защищенное соединение клиента и сервера, в котором шифруем передаваемые данные и доверяем не только серверу, с которого эти данные забираем, но и знаем о том, кто именно забирает эти данные с нашего сервера, так как он предоставляет клиентский сертификат.

В рамках моей работы в ТехЦентре Дойче Банка мы в обязательном порядке для всех межсервисных взаимодействий используем SSL-сертификаты — даже в UAT окружении. В Java используем JKS, как более привычный контейнер сертификатов и паролей для этой системы.

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

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

Проверка сайта на SSL/TLS

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

Рассмотрим вариант проверки сайта с помощью сервиса SSL Server Test. Для этого:

Такой результат показывает, что сайт работает по безопасному подключению TLS версии 1.2. Если в результатах выдачи вы увидите «Yes» напротив пунктов SSL 2 или 3 — значит сайту нельзя доверять.

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

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

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

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

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

Как усилить безопасность 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

Introduction

Secure Socket Layer (SSL) and Transport Layer Security (TLS) are both cryptographic protocols providing communication security over a network; for example a client connecting to a web server. A «handshake» is done at the start of a TLS or SSL connection. During this handshake the client and server will work out what mutual ciphers and hash algorithms are supported. This is also where a server will provide its digital certificate to a connecting client.
TLS is the continuation of SSL. Over the years vulnerabilities have been and continue to be discovered in the deprecated SSL and TLS protocols. For this reason, you should disable SSLv2, SSLv3, TLS 1.0 and TLS 1.1 in your server configuration, leaving only TLS protocols 1.2 and 1.3 enabled.

4 причины установить SSL-сертификат

Безопасность данных

Конечно же, стоит начать с этого пункта, ведь в этом заключается основная цель использования SSL-сертификатов. Если вы работаете с персональными данными пользователей, вам просто необходимо их шифровать при передаче к серверу. Само по себе использование сертификата не лекарство от всех бед, злоумышленники могут перехватить данные ещё до момента передачи их на сервер на заражённом компьютере или устройстве посетителя сайта. Однако использование протокола шифрования — значительный вклад в снижение уязвимости сайта.

Доверие к сайту

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

Поддержка сторонних сервисов

Некоторые платёжные системы (Яндекс.Деньги) и сервисы (Голосовой помощник Google Chrome) работают только с сайтами с HTTPS протоколом. Если специфика вашей работы подразумевает взаимодействие с аналогичными сервисами, рекомендуем вам установить SSL-сертификат.

Фактор ранжирования

Google не раз заявлял, что поддержка HTTPS протокола станет одним из факторов ранжирования. Для Яндекса сайты по HTTP и HTTPS протоколам участвуют в ранжировании на равных, однако, поисковик обозначает, что подключать SSL стоит, если на сайте можно совершать покупки и другие финансовые операции.

⌘⌘⌘

SSL-сертификат от авторитетного УЦ говорит о надёжной защите пользовательских данных — это не только хороший способ заслужить доверие пользователей и поисковых систем, но и большой вклад в стабильное продвижение и развитие сайта. 

И не забывайте, что часто SSL бывают включены в пакеты с доменом и хостингом, что позволит ещё и сэкономить. Например, в REG.RU вы можете получить SSL-сертификат и хостинг в подарок к домену или любому из тарифов конструктора REG.Site. Также до 25 апреля 2021 года действуют скидки до 42% на SSL-сертификаты. Успейте купить SSL и больше не рискуйте ни своими клиентами, ни прибылью. 

Как настроить 301 редирект с HTTP на HTTPS

Для NGINX мы настраивали редирект выше, поэтому если редирект настроили в нём, в Apache ничего не меняем. Но, для примера, покажу блок, ответственный за него

301 редирект с HTTP на HTTPS в NGINX

Тут нужно указать 2 блока , для http (там мы настраиваем редирект) и для https

server {
 server_name example.com www.example.com;  # Можно указать любые домены и поддомены, смотря как вы настроили сертификат
 listen 1.2.3.4:80; #где 1.2.3.4 - айпи вашего сервера
 rewrite ^(.*) https://$host$1 permanent; # Редирект HTTP/1.1 301 Moved Permanently с http на https
}

server {
 server_name example.com www.example.com;  # Можно указать любые домены и поддомены, смотря как вы настроили сертификат
 listen 1.2.3.4:443 ssl; #где 1.2.3.4 - айпи вашего сервера
 ### Остальные правила
}

301 редирект с HTTP на HTTPS в .htaccess (Apache)

Если у Вас основной сервер Apache, в его конфигурационном файле () или в в корне сайта прописываем

RewriteEngine On
RewriteBase /
RewriteCond %{HTTP:SSL} !=1 
RewriteRule ^(.*) https://%{SERVER_NAME}/$1 

Или

RewriteEngine On
RewriteCond %{SERVER_PORT} !^443$
RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} 

Эта конструкция отлавливает все запросы к портам, отличным от 443 (а именно на 443 порту сидит SSL), и редиректит на нужную версию сайта с HTTPS.

301 редирект с HTTP на HTTPS в WordPress

Чтобы сделать 301 редирект на https в wordpress, достаточно найти в корне сайта и прописать там в любом месте (если ещё не прописано, меняете на свой домен):

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

В большинстве ситуаций этого достаточно.

<?php // Эту строку удалить, если код вставляется в существующий файл php

/**
  Plugin Name: Sheensay HTTP HTTPS Redirect
  Plugin URI: http://sheensay.ru/?p=2013
  Description: Плагин, который редиректит с HTTP на HTTPS
  Version: 1.0.0
  Author: Sheens
  Author URI: http://sheensay.ru/
  License: GPLv2
 */

defined( 'ABSPATH' ) or exit;

// Редирект с HTTP на HTTPS
add_action( 'template_redirect', function () {

	if ( 'on' != $_SERVER ) {

		$url = get_option( 'siteurl' ) . $_SERVER;

		wp_redirect( $url, 301 );

		exit;
	}
} );

О самоподписанных сертификатах

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

Это примерно как позвонить в дверь и сказать «это я» – если непонятно кто это, то это «я» ни о чем не скажет. Браузер предупредит, что он не знает организацию, выдавшую сертификат, однако если пользователь согласится с тем, что доверяет этому сайту, подключение будет работать.

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

Влияние SSL/TLS на SEO

SEO (Search Engine Optimization, поисковая оптимизация) – это всестороннее развитие и продвижение сайта для его выхода на первые позиции в результатах выдачи поисковых систем (SERPs). Поисковая оптимизация способствует увеличению посещаемости сайта.

Использование SSL-сертификата влияет на SEO-показатели, однако это влияние является скорее косвенным. С 2015 года Google отдаёт приоритет ранжирования (то есть назначения сайту места в поисковой выдаче) тем сайтам, которые работают по протоколу HTTPS. Такой же политики придерживается компании Яндекс и Mozilla.

Браузер Google Chrome — один из самых популярных браузеров в рунете. С недавнего времени Chrome отмечает HTTP-сайты как небезопасные:

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

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

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

$ 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:

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

Что такое TLS

TLS — это протокол, который используется для обеспечения безопасной связи. Он используется для просмотра веб-страниц, электронной почты, передачи голоса по IP (VoIP) и т. Д. Он в основном обеспечивает конфиденциальность и целостность данных между двумя или более сторонами связи.

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

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

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

TLS 1.3 против TLS 1.2

Инженерная рабочая группа по Интернету (IETF) — это группа, отвечающая за определение протокола TLS, которая прошла через множество различных итераций. Предыдущая версия TLS, TLS 1.2, была определена в RFC 5246 и использовалась в течение последних восьми лет большинством всех веб-браузеров. 21 марта 2018 года TLS 1.3 был доработан после прохождения 28 проектов. А по состоянию на август 2018 года окончательная версия TLS 1.3 уже опубликована (RFC 8446).

Такие компании, как Cloudflare, уже делают TLS 1.3 доступным для своих клиентов. Филиппо Валсорда провел большую беседу (см. Презентацию ниже) о различиях между TLS 1.2 и TLS 1.3. Короче говоря, основные преимущества TLS 1.3 по сравнению с TLS 1.2 — это более высокие скорости и повышенная безопасность.

Внедрение TLS приложениями

Поддержка браузерами

Большинство браузеров также являются клиентами TLS. Веб-браузеры, поддерживающие последнюю версию TLS 1.2 по умолчанию:

• Apple Safari 7 и новее;
• Google Chrome и Chromium 30 и последующие версии;
• Microsoft Internet Explorer 11 и выше;
• Mozilla Firefox 27 и более поздние версии;
• Opera 17 и последующие;
• Microsoft Edge.

Основные разработчики веб-браузеров объявили о прекращении поддержки TLS 1.1 и более ранних версий с весны 2020 года.

HTTPS Everywhere — это расширение для веб-браузера, которое позволяет расширить использование SSL / TLS на определенных сайтах. Он включает шифрование на страницах, где оно обычно отключено. Очевидно, это может работать только в том случае, если рассматриваемый сайт уже поддерживает TLS. Расширение поддерживается совместно проектом Tor и EFF с 2010 года.

Аутентификация цифрового сертификата

В большинстве случаев пользователь аутентифицирует сервер TLS, к которому он подключается. Эта аутентификация достигается за счет использования цифрового сертификата X.509, выпущенного центром сертификации (CA). Веб-приложения могут использовать аутентификацию клиентской рабочей станции с помощью TLS. Затем можно предложить взаимную аутентификацию между клиентом и сервером. Сертификат клиента может храниться в программном формате на клиентской рабочей станции или предоставляться аппаратным устройством ( смарт-карта , USB-токен). Это решение позволяет предлагать надежные механизмы аутентификации .

Принцип работы в веб-браузерах

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

Когда пользователь входит на веб-сайт, использующий TLSv1.2 (или ниже), выполняются следующие шаги:

1. браузер клиента отправляет серверу запрос на установку соединения, защищенного TLS.
2. Сервер отправляет клиенту свой сертификат  : он содержит его открытый ключ , его информацию (название компании, почтовый адрес, страну, контактный адрес электронной почты …), а также цифровую подпись.
3. Браузер клиента пытается проверить цифровую подпись сертификата сервера, используя открытые ключи, содержащиеся в сертификатах центра сертификации (CA), встроенных по умолчанию в браузер.
   1. Если один из них работает, веб-браузер определяет имя центра сертификации, подписавшего сертификат, отправленный сервером. Он проверяет, не истек ли срок его действия, а затем отправляет в этот орган запрос OCSP, чтобы убедиться, что сертификат сервера не был отозван.
   2. Если ни один из них не работает, веб-браузер пытается проверить цифровую подпись сертификата сервера, используя содержащийся в сертификате сервера .
      1. В случае успеха это означает, что сам веб-сервер подписал свой сертификат. Затем в веб-браузере отображается предупреждающее сообщение, предупреждающее пользователя о том, что идентификация сервера не была проверена центром сертификации и, следовательно, потенциально может быть мошенническим сайтом.
      2. Если это не удается, сертификат недействителен, соединение не может быть установлено.
4. Браузер клиента генерирует симметричный ключ шифрования , называемый сеансовым ключом , который он шифрует с использованием открытого ключа, содержащегося в сертификате сервера, а затем передает этот сеансовый ключ на сервер.
5. Сервер расшифровывает сеансовый ключ, отправленный клиентом, используя свой закрытый ключ.
6. Клиент и сервер начинают обмениваться данными, шифруя данные с помощью общего ключа сеанса. С этого момента считается, что между клиентом и сервером устанавливается TLS-соединение.
7. После завершения соединения (добровольное отключение пользователя или слишком долгий период бездействия) сервер аннулирует сеансовый ключ.

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

Начиная с TLSv1.3 , обмен сеансовым ключом должен производиться через Диффи-Хеллмана с эллиптическими кривыми ( ECDHE ): RSA больше не может использоваться для этого.

Какие виды SSL-сертификатов есть и кто их выдаёт?

Есть специальные центры сертификации или как ещё называют — удостоверяющие центры (УЦ). Вы могли встречать названия таких УЦ: Symantec, Comodo, GlobalSign, Thawte, GeoTrust, DigiCert. Они подтверждают подлинность ключей шифрования с помощью сертификатов электронной подписи.

Кроме того, есть проекты, CloudFlare или LetsEncrypt, где можно получить сертификат бесплатно и самостоятельно. Такой сертификат выпускается на 3 месяца и далее требует продления. Однако во время их установки и дальнейшей работы есть ряд нюансов, которые стоит учитывать. Например, при выборе сертификата Cloudflare учтите, что он выдаётся сразу на 50 сайтов. Тем самым сертификат будет защищать не только ваш домен, но и ещё несколько чужих, что несёт за собой риски безопасности. Также у Cloudflare нет печати доверия. Если говорить о недостатках LetsEncrypt, то сюда можно отнести поддержку далеко не всех браузеров, отсутствие гарантии сохранности данных сайта и печати доверия.

Итак, существует несколько типов SSL-сертификатов по источнику подписи и типу проверки данных.

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

Подписанные доверенным центром сертификации (валидные). Речь о тех самых авторитетных УЦ выше. Сертификат корректно отображается во всех браузерах. Данные сертификата проверены и подтверждены в сертифицирующем центре.

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

Подписанные доверенным центром сертификаты, в свою очередь, тоже подразделяются по типу проверки данных:

• DV (Domain Validation) — базовый уровень сертификата, который обеспечивает только шифрование данных, но не подтверждает существование организации. Такие бюджетные сертификаты подойдут физическим и юридическим лицам.
• OV (Organization Validation) — обеспечивает не только шифрование данных, но и подтверждает существование организации. Такие сертификаты доступны только для юридических лиц.
• EV (Extended Validation) — это эффективное решение с самым высоким классом защиты, которое активно применяется в онлайн-бизнесе. Для оформления требуется пройти процедуру расширенной проверки, подтвердить законность организации и право собственности на домен.

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

• WildCard — защищает соединение с доменом и всеми его поддоменами.
• SAN — защищает домены по списку, указанному при получении SSL-сертификата.

SSL 1.0, 2.0, 3.0 и TLS[править]

Версия 1.0 никогда не была обнародована. Версии 2.0 была выпущена в феврале 1995 года, но содержала много недостатков по безопасности, которые привели к разработке SSL 3.0 версии.

Как только различные компании (Microsoft) начали предпринимать попытки разработки собственных безопасных протоколов транспортировки, IETF решило вмешаться и определить стандарт протокола шифрования. Впоследствии, при поддержке множества компаний, на основании протокола SSL 3.0 был разработан и принят стандарт RFC, получивший имя TLS 1.0. Его также часто называют SSL 3.1.

Хотя TLS и SSL имеют существенные различия в реализации, разработчики обычно замечают лишь немногие из них, а конечные пользователи вовсе их не различают. Тем не менее TLS 1.0 и SSL 3.0 несовместимы. Значительное различие состоит в том, что TLS требует определенные алгоритмы шифрования, которые SSL не поддерживает. Таким образом TLS сервер должен “откатиться” (downgrade) до SSL 3.0 для работы с клиентами, использующими SSL 3.0.

Какие типы сертификатов бывают и как выбрать нужный?

Domain Validation (DV)

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

Organization Validation (OV)

Такой сертификат подтверждает организацию, владеющую сайтом. Выпускается такой сертификат в течение недели, +/- 3 дня

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

Кому подойдут такие сертификаты — сказать сложно. Дело в том, что для конечного пользователя (посетителя сайта) разницы между OV и DV нет. Неплохо иметь такой тип сертификата в случае, если с сайта осуществляются платежи, а бюджета на EV нет. Но в подобной ситуации обычно используются интегрируемые решения (например, https://www.robokassa.ru), которые переводят посетителя на сайт сервиса (там обычно EV). Сертификаты OV, например, используются Яндексом и Google.

Extended Validation (EV)

Красиво, дорого, мощно! EV-сертификаты отличаются внешним видом для посетителя. В адресной строке такого сертификата будут отображаться данные о компании.

Если вы делаете что-то глобальное, вам нужен такой сертификат: например, если вы банк, если вы платежная система, если у вас собственный сервис приема платежей (данные карты вводятся на вашем сайте) и так далее. Такие сертификаты дороги. Даже у Сбербанка этот сертификат стоит только для https:\/\/online\.sberbank\.ru\/, а для используется простой OV.

Оглавление

• Краткая история вопроса – 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 новых версий

Приступим.

TLS-рукопожатие

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

TLS False Start

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

TLS Chain of trust

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

Настройка Apache на использование клиентских сертификатов

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

# Директория, содержащая корневые сертификаты для проверки клиентов
SSLCARevocationPath /etc/apache2/ssl.crl/
# или файл, содержащий сертификаты
SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl
# Опция верификации клиента. Возможные варианты:
# none, optional, require and optional_no_ca
SSLVerifyClient require
# Глубина просмотра цепочки подписей. По умолчанию 1
SSLVerifyDepth  2

Как видите, опции примерно такие же, как и для nginx, поскольку процесс проверки организован единообразно.

Проверка сертификата ssl/tls в почтовом сервере

Способов проверить сертификат в почтовом сервере множество. Например, у меня есть статья, где я настраиваю мониторинг сертификатов с помощью Zabbix. Там же есть примеры и для почтового сервера. Вот так с помощью openssl в консоли сервера можно посмотреть текущие сертификаты.

# openssl s_client -starttls smtp -connect mail.site.ru:25 | openssl x509 -noout -dates 2>/dev/null | grep notAfter | cut -d'=' -f2

Это самый простой и быстрый способ. Можете проверить прямо из консоли почтового сервера. Так же можно воспользоваться каким-то готовым сервисом, например https://ssl-tools.net/mailservers.

Если у вас все в порядке, значит настройка ssl в postfix закончена. Остался последний штрих.

Static vs ephemeral DH

Last but not least, the DH algorithm comes in two flavours in the context of TLS: static Diffie-Hellman (DH) and ephemeral Diffie-Hellman (DHE).

As you can imagine, DH is fantastic for exchanging a secret such as an encryption key and this is how it is used in TLS. But, there can be a problem if the server is later compromised. Suppose Alice is the server and Bob the client. We also have Eve, a malicious adversary.

Suppose that the parameter from Alice never changes (it is static). Eve records the session between Alice and Bob, including . Suppose that somehow, Eve manages to get a hold on , say by hacking Alice.

Now we have a problem, because Eve can compute the value that is the secret. So Eve has the key to decrypt the communication between Alice and Bob. Eve can also compromise future TLS sessions with Alice by simply listening on the channel since she knows the static .

In order to secure future communication in the event of being compromised, DH has to account for a dynamic, or ephemeral, parameter . And this is what DHE is. The additional security provided by DHE is known as perfect forward secrecy. Unlike DH, DHE provides damage control if the server is compromised.

The inner workings of TLS

The purpose of TLS is to achieve secure communication. How you define secure is a very broad topic but generally speaking, you make use of encryption to enforce two fundamental properties:

• privacy — nobody can successfully eavedrop on the channel
• data integrity — nobody can alter the data in the communication without making it immediately noticeable by the parties

Given these constraints, here is how the protocol works:

1. Establish communication, agree on some cryptographic parameters and compute a shared master secret. This part is called the TLS Handshake Protocol.
2. Communicate with symetric encryption — the TLS Application Data Protocol.
3. Additionnally there are two other subprotocols to convey specific information:

• ChangeCipherSpec protocol: to transition ciphering strategies between the server and the client
• Alert protocol: to report errors and/or notifications between the client and the server

The TLS Handshake

TLS Handshake from the RFC

The TLS Handshake involves multiple back and forths between the client and the server. Here is an overview of what happens, taken from the RFC.

Some steps are optional or situation-dependent, as indicated by the .