Что такое TLS / Хабр

Что такое ssl-сертификат?

SSL-сертификат – это цифровой сертификат, удостоверяющий подлинность веб-сайта и позволяющий использовать зашифрованное соединение. Аббревиатура SSL означает Secure Sockets Layer – протокол безопасности, создающий зашифрованное соединение между веб-сервером и веб-браузером.

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

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

С момента создания протокола SSL около 25 лет назад, он был доступен в нескольких версиях. При использовании каждой из этих версий в определенный момент возникали проблемы безопасности. Затем появилась обновленная переименованная версия протокола – TLS (Transport Layer Security), которая используется до сих пор. Однако аббревиатура SSL прижилась, поэтому новая версия протокола по-прежнему часто называется старым именем.

Что такое ssl сертификат для сайта, почты [айти бубен]

# cp /etc/ssl/openssl.cnf /etc/ssl/openssl.cnf.orig
# nano openssl.cnf
...
[ CA_default ]

dir             = ./demoCA
# cacert.pem- Это открытый ключ центра сертификации. Он должен находиться в корневых хранилищах ваших хостов,
# чтобы они могли проверить родпись в открытом сертификате (например, Postfix).
certificate     = $dir/cacert.pem
# cakey.pem - это секретный ключ центра сертификации. Он должен быть хорошо защищен,
# доступ к нему на чтение и запись должен иметь только администратор центра сертификации.
private_key     = $dir/private/cakey.pem
# Время жизни сертификата (по умолчанию 1 год)
default_days    = 1095
[ req ]
# длина RSA ключа (по умолчанию 1024 bit). Длину ключа можете настроить по своему усмотрению.
default_bits            = 1024
[ req_distinguished_name ]
countryName_default             = UA
0.organizationName_default      = Example INC
stateOrProvinceName_default     = Example
organizationalUnitName_default  = Example

# В подавляющем большинстве случае должно соответствовать полному доменному имени хоста.
# Common Name (eg, your name or your server's hostname) []:OpenVPN-CA

commonName                      = Common Name (eg, YOUR name)
commonName_default              = mail.example.com
...
# /usr/lib/ssl/misc/CA.pl -newca

# mkdir /etc/postfix/certs
# cd /etc/postfix/certs
# openssl req -new -nodes -x509 -out smtpd.pem -keyout smtpd.pem -days 3650
# chmod 644 smtpd.pem

smtp_use_tls = yes
smtpd_use_tls = yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_tls_auth_only = yes
smtp_tls_note_starttls_offer = yes
smtpd_tls_key_file = /etc/postfix/certs/smtpd.pem              
smtpd_tls_cert_file = /etc/postfix/certs/smtpd.pem              
smtpd_tls_CAfile = /etc/postfix/certs/smtpd.pem
smtpd_tls_CApath = /etc/ssl/certs
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom

smtps inet n - n - - smtpd
  -o smtpd_tls_wrappermode=yes
  -o smtpd_sasl_auth_enable=yes

Certificate

Сервер отправляет сообщение Certificate, в котором в поле certificate_list передаётся список сертификатов (certificate chain), где первым идёт сертификат самого сервера, за ним сертификаты цепочки доверия (chain of trust) в порядке очереди. Корневые сертификаты не передаются, т.к. предполагается, что клиент уже ими располагает.

Например – в  Linux они располагаются в каталоге /etc/ssl/certs/:

У браузеров политика валидации сертификатов и поиска корневых сертификатов отличается. Для Chrome/Crhomium – см тут>>> и тут>>>.

Сообщение Certificate описывается в разделе 7.4.2.

Certificate в результатах Wireshark:

Тут хорошо просматривается цепочка:

1. сертификат сервера RTFM: Certificate: (id-at-commonName=rtfm.co.ua)
2. который пописан Certificate: (id-at-commonName=Let’s Encrypt Authority X3,id-at-organizationName=Let’s Encrypt,id-at-countryName=US)
3. а сертификат Let’s Encrypt Authority выдан и подписан (id-at-commonName=DST Root CA X3,id-at-organizationName=Digital Signature Trust Co.)

Корневой сертификат DST Root CA X3 расположен в системе, в /etc/ssl/certs:

Changecipherspec и finish

Обе стороны – и клиент, и сервер, вычисляют общий master key длиной 48 байт, используя строки из ClientRandom и ServerRandom pre_master_secret, используя Pseudorandom Function (PRF):

master_secret = PRF(pre_master_secret, "master secret", ClientHello.random   ServerHello.random) [0..47];

Далее этот master_key используется для генерации набора ключей (см. 6.3. Key Calculation):

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

Клиент отправляет серверу сообщение ChangeCipherSpec, указывая серверу на то, что все данные, начиная с этого сообщения, будут зашифрованы.

После отправки ChangeCipherSpec – клиент отправляет сообщение Finished, в которой в поле finished_label содержится строка “client finished”, которую сервер должен расшифровать и проверить целостность самого сообщения.

После успешной проверки Finished сообщения от клиента – сервер отправляет своё сообщение ChangeCipherSpec, а затем своё сообщение Finished, в котором в поле finished_label содержится строка “server finished”, которую клиент должен расшифровать и проверить целостность самого сообщения.

В результатах Wireshark – ChangeCipherSpec и зашифрованная строка:

С этого момента все остальные данные (Application data) передаются в зашифрованном виде.

UPD

Clientkeyexchange

Клиент отправляет сообщение ClientKeyExchange, в котором вырабатывается pre-master secret key.

В случае использования RSA – pre-master ключ отправляется серверу зашифрованным с помощью публичного ключа сервера. В случае использования алгоритма Diffie-Hellman – передаются DF параметры со стороны клиента, позволяющие согласовать pre-master ключ.

В случае использования EDF (ephemeral Diffie-Hellman) – клиент передаёт публичный ключ. В случае использования DF (static Diffie-Hellman) – поле ClientDiffieHellmanPublic передаётся пустым.

Структура ClientKeyExchange:

      struct {
          select (KeyExchangeAlgorithm) {
              case rsa:
                  EncryptedPreMasterSecret;
              case dhe_dss:
              case dhe_rsa:
              case dh_dss:
              case dh_rsa:
              case dh_anon:
                  ClientDiffieHellmanPublic;
          } exchange_keys;
      } ClientKeyExchange;

Описывается в разделе 7.4.7.

Wireshark и публичный ключ клиента для DF:

На этом фаза Key Exchange завершена, и начинается процесс “активации” защищённого соединения.

Tsl vs ssl: история

Основное отличие между ними – TLS является наследником протокола SSL, и использует более безопасные способы обеспечения безопасности.

Аббревиатуры:

• SSL – Secure Socket Layer
• TLS – Transport Layer Security

Краткая история SSL/TLS:

1. SSL был разработан компанией Netscape, но версия 1.0 не была опубликована и использована из-за проблем безопасности в её реализации
2. SSL 2.0 была выпущена в феврале 1995, но так же содержала уязвимости, потому:
3. в 1996 появилась версия SSL 3.0

SSL 2.0 официально признан устаревшей версией в 2021 году (см. RFC 6176), а SSL 3.0 – в 2021 (RFC 7568), хотя версия 3.0 была объявлена небезопасной для использования ещё в 2004 году из-за обнаружения уязвимости POODLE.

Из-за проблем с безопасностью, а так же из-за проблем с Netscape, связанных с юридическими вопросами, в 1999 на смену SSL пришёл протокол TLS, основанный на SSL v3.0.

TLS являлся окрытым стандартном (в отличии от SSL, поддерживаемого компанией Netscape) и в результате полностью заменил собой SSL.

1. TLS 1.0 выпущен в январе 1999, RFC 2246, и использовался вплоть до 2021 года, когда первый раз был объявлен устаревшим (позже его “устаревание” продлили до 2021 года).
2. TSL 1.1 выпущен в апреле 2006, RFC 4346, с 30-го июня 2021 полностью заменит TLS 1.0
3. TLS 1.2 появился в августе 2008, RFC 5246, с 30-го июня 2021 полностью заменит TLS 1.0 и будет являться рекомендуемым протоколом для использования
4. TLS 1.3 ещё находится в состоянии черновика

Аббревиатуры SSL и TLS используются взаимозаменяемы, и под SSL как правило подразумевается TLS, т.к. в большистве случаев (а особенно в 2021) клиенты предлагают (см ClientHello) использовать версии TLS 1.1 и 1.2.

По теме:

Как обеспечить безопасность онлайн-сеанса

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

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

Ознакомьтесь с политикой конфиденциальности веб-сайта. Это позволяет понять, как будут использоваться ваши данные. Законопослушные компании обычно прозрачно описывают сбор и действия с данными.

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

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

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

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

Получение SSL-сертификата включает следующие шаги:

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

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

Какой ssl-сертификат выбрать?

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

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

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

• насколько SSL совместим с основными браузерами;
• на каком уровне происходит защита данных пользователей;
• насколько масштабная проверка организации проводится;
• есть ли печать доверия.

Можно ли использовать ssl-сертификат на нескольких серверах?

Один SSL-сертификат можно использовать для нескольких доменов на одном сервере. В зависимости от поставщика, можно также использовать один SSL-сертификат на нескольких серверах. Это позволяют мультидоменные SSL-сертификаты, описанные выше.

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

Мультидоменные SSL-сертификаты также называются SAN-сертификатами. SAN означает альтернативное имя субъекта. Каждый мультидоменный сертификат имеет дополнительные поля (например, альтернативные имена субъектов), которые можно использовать для перечисления дополнительных доменов, чтобы на них распространялся один сертификат.

Сертификаты унифицированных коммуникаций (UCC) и Wildcard-сертификаты также можно применять на нескольких доменах и, в последнем случае, на неограниченном количестве поддоменов.

Обзор ssl/tls соединения

Любое SSL-соединение использует набор протоколов, описанных в RFC 5246 (тут и ниже рассматривается TLS v 1.2 и этот RFC, как последняя актуальная версия на момент написания этого поста – март 2021).

В RFC 5246 они описаны в обратном порядке, но тут рассмотрим их начиная с Handshake Protocol, т.к. именно в нём описывается процесс установления сессии и создания ключей, которые далее используются в TLS Record Protocol.

Структура получается следующая:

• The TLS Handshaking Protocols
  • Handshake Protocol
  • Change Cipher Spec Protocol
  • Alert Protocol
• The TLS Record Protocol

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

Ссылки по теме

Transport Layer Security

The Transport Layer Security (TLS) Protocol Version 1.2

Secure Sockets Layer (SSL) and Transport Layer Security (TLS) concepts

SSL Introduction with Sample Transaction and Packet Exchange

TLS/SSL Explained – TLS/SSL terminology and basics, Part 3

TLS/SSL Explained – Establishing a TLS Connection, Part 5