Проверка tls соединения. Протокол TLS в Internet Explorer. Настройка nginx на использование клиентских сертификатов

Сеанс SMTP между сервером и клиентом по-умолчанию не шифруется. Это делает возможным перехват пакетов и получение конфиденциальной информации, передаваемой открытым текстом (если не применяются иные методы шифрования).

Исправить данную ситуацию нам поможет использование протокола TLS , что позволит обеспечить:

1. Конфиденциальность (Взаимодействие клиента и сервера происходит в зашифрованном
сеансе);

2. Целостность (невозможно внедриться в сеанс незаметно, искажение данных будет немедленно обнаружено);

3. Достоверность аутентификации (Клиент и сервер могут обменяться сертификатами, удостоверенными уполномоченным центром сертификации (Certification authority - CA).

Как работает TLS

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

1. Клиент устанавливает соединение с сервером.

2. Хосты начинают взаимодействие по протоколу SMTP.

3. Сервер с помощью ключевого слова STARTTLS предлагает использовать TLS в рамках SMTP взаимодействия.

4. Если клиент может использовать TLS, он отвечает серверу ключевым словом STARTTLS.

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

6. Клиент проверяет подлинность сертификата сервера, сверяя подпись центра сертификации с имеющейся у него в корневом хранилище открытой подписью центра сертификации.

7. Клиент проверяет сертификат сервера на соответствие содержащейся в нем строки Common Name доменному имени сервера.

8. Клиент и сервер включают режим шифрования данных.

9. Хосты выполняют обмен данными.

10. Сеанс заканчивается.

Приступим к созданию сертификатов для почтового сервера server.mydomain.ru , в качестве MTA на котором выступает Postfix , а роль MDA выполняет Dovecot .

Создать новый сертификат просто – достаточно запустить сценарий и выполнить несколько команд.

Сге нерируем 2 файла - секретный ключ сервера и запрос на подпись сертификата командой:

# openssl req -nodes -newkey rsa:2048 -keyout server.key -out server.csr

где server - имя сервера (в данном случае может быть любым)

Заполняем поля (нажатие «Enter» оставляет значение по-умолчанию):

Country Name (2 letter code) : RU
State or Province Name (full name) : Orenburg
Locality Name (eg, city) : Orsk
Organization Name (eg, company) : MyCompany
Organizational Unit Name (eg, section) : IT
Common Name (eg, YOUR name) : server.mydomain.ru
Email Address : postmaster @mydomain.ru
A challenge password :
An optional company name :

Очень важно указать в поле Common Name полное имя хоста (FQDN), соответствующее DNS-записям типа MX и A

Используем возможность бесплатного получения сертификатов COMODO со сроком действия 90 дней на сервисе FreeSSL.su . Эти сертификаты без проблем распознаются всеми браузерами и почтовыми клиентами.

На главной страничке заполняем все необходимые поля, в графе «Выберите используемое ПО» выбираем «Другое». В поле CSR вводим содержимое сгененированного ранее файла server.csr .

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

AddTrustExternalCARoot.crt;
server_mydomain_ru.crt;
ComodoUTNSGCCA.crt;
EssentialSSLCA_2.crt;
UTNAddTrustSGCCA.crt

Файл server_mydomain_ru.crt - это и есть требуемый сертификат. Что нам нужно делать с остальными файлами? Поступим так - объединим их содержимое в одном файле ca.txt (доверенный сертификат центра сертификации CA ) в следующем порядке:

EssentialSSLCA_2.crt
ComodoUTNSGCCA.crt
UTNAddTrustSGCCA.crt
AddTrustExternalCARoot.crt

Полученный файл ca.txt будем использовать в дальнейшем:

Конфигурируем наш почтовый сервер. Для этого вносим изменения в конфиги dovecot и postfix .

Для dovecot:

dovecot.conf:

protocols = pop3 imap imaps pop3s

protocol pop3 {
listen = *:110
ssl_listen = *:995
...........
}

protocol imap {
listen = *:143
ssl_listen = *:993
...........
}

disable_plaintext_auth = no # Не запрещаем логиниться открытым способом
ssl = yes # Включаем поддержку ssl
ssl_cert_file = /etc/ssl/certs/dovecot.pem # файл сертификата,
# выставим на него разрешения: root:root 0444
ssl_key_file = /etc/ssl/private/dovecot.pem # ключ сервера,
# рекомендуется выставить разрешения: root:root 0400

ssl_verify_client_cert = yes # проверка валидности клиентских сертификатов
ssl_parameters_regenerate = 1 # регенерация параметров каждый час
# (значение "0" отключает регенерацию)
ssl_cipher_list = ALL:!LOW:!SSLv2 # шифр SSL
verbose_ssl = yes # протоколировать в логе ошибки ssl

Чтобы получить ssl_cert_file нужно объединить содержимое файлов server_mydomain_ru.crt и ca.txt , переименовываем полученный файл в dovecot.pem. В роли ssl_key_file выступает переименованный файл секретного ключа сервера server.key , сгенерированный ранее.

Для postfix:

main.cf

Smtp_use_tls = yes # использовать TLS, если удаленный сервер сообщает о поддержке TLS
smtpd_use_tls = yes # сообщать клиентам о поддержке TLS
smtpd_tls_auth_only = no # использовать аутентификацию SMTP не только для TLS-соединений
smtp_tls_note_starttls_offer = yes # фиксировать в логе имена серверов,
# выдающих сообщение STARTTLS, поддержка TLS для которых не включена

smtpd_tls_CAfile = /etc/ssl/ca.txt # доверенный сертификат
smtpd_tls_key_file = /etc/ssl/smtpd.key # закрытый ключ сервера
smtpd_tls_cert_file = /etc/ssl/smtpd.crt # сертификат сервера

smtpd_tls_loglevel = 2 # детальность сообщений о TLS-активности
smtpd_tls_received_header = yes # запрашивать заголовки сообщений с информацией
# о версии протокола и алгоритме шифрования
smtpd_tls_session_cache_timeout = 3600s # время, в течение которого данные в кэше
# TLS-сессии считаются актуальными
tls_random_source = dev:/dev/urandom # имя устройства-генератора псевдослучайных чисел (PRNG)

Для того, чтобы Postfix принимал TLS-соединения на специальный порт (465/SMTPS, а не 25/SMTP), в файле master.cf необходимо раскомментировать строки:

master.cf

Smtps inet n - n - - smtpd
-o smtpd_tls_wrappermode=yes
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject

Перезапускаем postfix и dovecot, проверяем логи.

Не забываем открыть нужные порты в файерволе: 993 (imaps), 995 (pop3s), 465 (smtps)

Наш почтовый сервер готов к работе с TLS !

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

По окончании 90-дневного срока действия сертификатов следует проделать ту же самую процедуру, используя для запроса тот же файл server.csr , поэтому нужно сохранить его копию в надежном месте. Весь процесс обновления не займет больше 10 минут!

Описание

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

Так как большинство протоколов связи могут быть использованы как с, так и без TLS (или SSL), при установке соединения необходимо явно указать серверу, хочет ли клиент устанавливать TLS. Это может быть достигнуто либо с помощью использования унифицированного номера порта , по которому соединение всегда устанавливается с использованием TLS (как например порт 443 для HTTPS), либо с использованием произвольного порта и специальной команды серверу со стороны клиента на переключение соединения на TLS с использованием специальных механизмов протокола (как например STARTTLS для протоколов электронной почты). Как только клиент и сервер договорились об использовании TLS, им необходимо установить защищенное соединение. Это делается с помощью процедуры подтверждения связи (англ. Secure Socket Layers ). Во время этого процесса клиент и сервер принимают соглашение относительно различных параметров, необходимых для установки безопасного соединения.

Также существуют варианты атак, основанные непосредственно на программной реализации протокола, а не на его алгоритме .

Процедура подтверждения связи в TLS в деталях

Согласно протоколу TLS приложения обмениваются записями, инкапсулирующими (хранящими внутри себя) информацию, которая должна быть передана. Каждая из записей может быть сжата, дополнена, зашифрована или идентифицирована MAC (код аутентификации сообщения) в зависимости от текущего состояния соединения (состояния протокола). Каждая запись в TLS содержит следующие поля: content type (определяет тип содержимого записи), поле, указывающее длину пакета, и поле, указывающее версию протокола TLS.

Когда соединение только устанавливается, взаимодействие идет по протоколу TLS handshake, content type которого 22.

Простое подтверждение связи в TLS

Фаза переговоров:
- Клиент посылает сообщение ClientHello
- Сервер отвечает сообщением ServerHello
- Сервер посылает сообщение Certificate
- Сервер отсылает сообщение ServerHelloDone
- Клиент отвечает сообщением ClientKeyExchange , которое содержит открытый ключ PreMasterSecret(Этот PreMasterSecret шифруется с помощью открытого ключа сертификата сервера.) или ничего (опять же зависит от алгоритма шифрования);
- PreMasterSecret
Клиент посылает сообщение ChangeCipherSpec
- Клиент посылает сообщение Finished
Сервер посылает ChangeCipherSpec

Подтверждение связи с аутентификацией клиента

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

Фаза переговоров:
- Клиент посылает сообщение ClientHello , указывая последнюю версию поддерживаемого TLS протокола, случайное число и список поддерживаемых методов шифрования и сжатия, подходящих для работы с TLS;
- Сервер отвечает сообщением ServerHello , содержащим: выбранную сервером версию протокола, случайное число, посланное клиентом, подходящий алгоритм шифрования и сжатия из списка предоставленного клиентом;
- Сервер посылает сообщение Certificate , которое содержит цифровой сертификат сервера (в зависимости от алгоритма шифрования этот этап может быть пропущен);
- Сервер посылает сообщение CertificateRequest , которое содержит запрос сертификата клиента для взаимной проверки подлинности;
- [Не хватает пункта получения и проверки сертификата клиента] ;
- Сервер отсылает сообщение ServerHelloDone , идентифицирующее окончание подтверждения связи;
- Клиент отвечает сообщением ClientKeyExchange , которое содержит открытый ключ PreMasterSecret или ничего (опять же зависит от алгоритма шифрования);
- Клиент и сервер, используя ключ PreMasterSecret и случайно сгенерированные числа, вычисляют общий секретный ключ. Вся остальная информация о ключе будет получена из общего секретного ключа (и сгенерированных клиентом и сервером случайных значений);
Клиент посылает сообщение ChangeCipherSpec , которое указывает на то, что вся последующая информация будет зашифрована установленным в процессе подтверждения связи алгоритмом, используя общий секретный ключ. Это сообщения уровня записей и поэтому имеет тип 20, а не 22;
- Клиент посылает сообщение Finished , которое содержит хеш и MAC, сгенерированные на основе предыдущих сообщений процедуры подтверждения связи;
- Сервер пытается расшифровать Finished-сообщение клиента и проверить хеш и МАС. Если процесс расшифровки или проверки не удается, подтверждение связи считается неудавшимся, и соединение должно быть оборвано.
Сервер посылает ChangeCipherSpec и зашифрованное сообщение Finished, и в свою очередь клиент тоже выполняет расшифровку и проверку.

С этого момента подтверждение связи считается завершённым, протокол установленным. Все последующее содержимое пакетов идет с типом 23, а все данные будут зашифрованы.

Возобновление TLS-соединения

Алгоритмы а симметричного шифрования использующиеся при генерации сеансового ключа обычно являются дорогими с точки зрения вычислительных мощностей. Для того чтобы избежать их повторения при возобновлении соединения TLS создает специальный ярлык при подтверждении связи использующийся для возобновления соединения. При этом при обычном подтверждении связи клиент добавляет в сообщение ClientHello идентификатор предыдущей сессии session id . Клиент связывает идентификатор session id с IP-адресом сервера и TCP-портом так, чтобы при соединении к серверу можно было использовать все параметры предыдущего соединения. Сервер сопоставляет идентификатор предыдущей сессии session id c параметрами соединения, такими как использованный алгоритм шифрования и master secret. Обе стороны должны иметь одинаковый master secret, иначе соединение не будет установлено. Это предотвращает использование session id криптоаналитиком для получения несанкцианированного доступа. Случайные цифровые последовательности в сообщениях ClientHello и ServerHello позволяют гарантировать, что сгенерированный сеансовый ключ будет отличаться от сеансового ключа при предудущем соединении. В RFC такой тип подтверждения связи называется сокращенным .

Фаза переговоров:
- Клиент посылает сообщение ClientHello , указывая последнюю версию поддерживаемого TLS протокола, случайное число и список поддерживаемых методов шифрования и сжатия, подходящих для работы с TLS; Также в сообщение добавляется идентификатор предыдущего соединения session id .
- Сервер отвечает сообщением ServerHello , содержащим: выбранную сервером версию протокола, случайное число, посланное клиентом, подходящий алгоритм шифрования и сжатия из списка предоставленного клиентом. Если сервер узнал идентификатор сессии session id ServerHello тот же самый идентификатор session id . Это является сигналом для клиента о том, что можно использовать возобновление предыдущей сессии. Если сервер не узнал идентификатор сессии session id , то он добавляет в сообщение ServerHello другое значение вместо session id . Для клиента это означает, что использовать возобновленное соединение нельзя. Таким образом, сервер и клиент должны иметь одинаковый master secret и случайные числа для генерации сеансового ключа;
Клиент посылает сообщение ChangeCipherSpec , которое указывает на то, что вся последующая информация будет зашифрована установленным в процессе подтверждения связи общим секретным ключом. Это сообщения уровня записей и поэтому имеет тип 20, а не 22;
Клиент посылает сообщение ChangeCipherSpec , которое указывает на то, что вся последующая информация будет зашифрована установленным в процессе подтверждения связи алгоритмом, используя общий секретный ключ. Это сообщения уровня записей и поэтому имеет тип 20, а не 22;
- Клиент посылает сообщение Finished , которое содержит хеш и MAC, сгенерированные на основе предыдущих сообщений процедуры подтверждения связи;
- Сервер пытается расшифровать Finished-сообщение клиента и проверить хеш и МАС. Если процесс расшифровки или проверки не удается, подтверждение связи считается неудавшимся, и соединение должно быть оборвано;
Сервер посылает ChangeCipherSpec и зашифрованное сообщение Finished, и в свою очередь клиент тоже выполняет расшифровку и проверку.

Кроме преимуществ с точки зрения производительности алгоритм возобновления соединения может быть использован для реализации единого входа , поскольку гарантируется, что исходной сессия как и любая возобновленной сессия инициированы одним и тем же клиентом (RFC 5077). Это имеет особенно важное значение для реализации FTP через TLS/SSL протокола, который в противном случае был бы уязвим к атаке типа человек посередине, при которой злоумышленник мог бы перехватить содержание данных при установлении повторного соединения.

Алгоритмы, использующиеся в TLS

В данной текущей версии протокола доступны следующие алгоритмы:

Для обмена ключами и проверки их подлинности применяются комбинации алгоритмов: RSA (асимметричный шифр), Diffie-Hellman (безопасный обмен ключами), DSA (алгоритм цифровой подписи) и алгоритмы технологии Fortezza;
Для симметричного шифрования: RC2 , RC4 , IDEA , DES , Triple DES или AES ;

Алгоритмы могут дополняться в зависимости от версии протокола.

Сравнение с аналогами

Одной из областей применения TLS-соединения является соединение узлов в виртуальной частной сети . Кроме TLS также могут использоваться набор протоколов IPSec и SSH -соединение. Каждый из этих подходов к реализации виртуальной частной сети имеет свои преимущества и недостатки. .

TLS/SSL
- Преимущества:
  - Невидим для протоколов более высокого уровня;
  - Популярность использования в Интернет-соединениях и приложениях электронной коммерции;
  - Отсутствие постоянного соединения между сервером и клиентом;
  - TCP/IP , таких как электронная почта, инструменты программирования и т. д.
- Недостатки:
  - UDP и ICMP ;
  - Необходимость отслеживания состояния соединения;
  - Наличие дополнительные требований к программному обеспечению о поддержке TLS.
IPsec
- Преимущества:
  - Безопасность и надежность защиты данных протокола проверена и доказана, так как протокол был принят как Интернет-стандарт;
  - Работа в верхнем слое сетевого протокола и шифрование данных над уровнем сетевого протокола.
- Недостатки:
  - Сложность реализации;
  - Дополнительные требования к оборудованию сети (маршрутизаторы и т. п.);
  - Существует много различных реализаций не всегда корректно взаимодействующих друг с другом.
SSH
- Преимущества:
  - Позволяет создать туннель для приложений, использующих TCP/IP , таких как электронная почта, инструменты программирования и т. д.;
  - Слой безопасности невидим для пользователя.
- Недостатки:
  - Трудность использования в сетях с большим числом шлюзов, таких как маршрутизаторы или брандмауэры ;
  - Невозможность использования с протоколами UDP и ICMP .

См. также

Ссылки

T. Dierks, E. Rescorla The Transport Layer Security (TLS) Protocol, Version 1.2 (August 2008). Архивировано из первоисточника 9 февраля 2012.
The SSL Protocol: Version 3.0 Netscape’s final SSL 3.0 draft (November 18, 1996)
«SSL/TLS in Detail ». Microsoft TechNet . Updated July 31, 2003.
Dan Goodin . The Register (19 сентября 2011). Архивировано
Eric Rescorla Understanding the TLS Renegotiation Attack . Educated Guesswork (5 ноября 2009). Архивировано из первоисточника 9 февраля 2012. Проверено 7 декабря 2011.
McMillan, Robert . Security Pro Says New SSL Attack Can Hit Many Sites , PC World (20 ноября 2009). Проверено 7 декабря 2011.
SSL_CTX_set_options SECURE_RENEGOTIATION . OpenSSL Docs (25 февраля 2010). Архивировано из первоисточника 9 февраля 2012. Проверено 7 декабря 2010.
GnuTLS 2.10.0 released . GnuTLS release notes (25 июня 2010). Архивировано из первоисточника 9 февраля 2012. Проверено 7 декабря 2011.
NSS 3.12.6 release notes . NSS release notes (3 марта 2010). Проверено 24 июля 2011.
Various IE SSL Vulnerability . Educated Guesswork (10 августа 2002).

Протокол SSL TLS

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

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

Ошибка 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
Использовать TLS 1.0

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

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

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

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

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

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

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

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

КриптоПро TLS SSL

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

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

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

Настройка SSL TLS

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

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

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

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

По требованиям российского законодательства признается только использование TLS-соединений, установленных по российским криптографическим алгоритмам ГОСТ 28147-89, ГОСТ Р 34.10-94, ГОСТ Р 34.11-94 и ГОСТ Р 34.10-2001. Поэтому, если вам требуется использование сайтов, использующих шифрование по ГОСТ алгоритмам, необходимо установить программу «КриптоПро CSP» .

В операционных системах Windows используется программа КриптоПро CSP - набор криптографических утилит для генерации электронной подписи, работы с сертификатами

Для установки КриптоПро CSP воспользуйтесь материалами с официального сайта:

Дистрибутив КриптоПро CSP
Пакет инструкций по установке и использованию КриптоПро CSP

После установки КриптоПро CSP браузер проверяет наличие и работоспособность этой программы.

Сайты, запрашивающие шифрование ГОСТ TLS

Если сайт запрашивает шифрование ГОСТ TLS, браузер проверяет, установлено ли программа КриптоПро CSP. Если программа установлена, ей передается управление.

Примеры сайтов, запрашивающих шифрование: www.gosuslugi.ru , сайты на домене .gov.ru , .kamgov.ru , .nalog.ru .

Если сайта нет в списке, то запрашивается дополнительное подтверждение. Если вы доверяете сайту и соединение должно быть произведено с использованием шифрования ГОСТ TLS, нажмите кнопку Продолжить .

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

Включение и отключение поддержки КриптоПро CSP браузером

По умолчанию в браузере включена поддержка КриптоПро CSP. Рекомендуем убедиться в этом.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

TLS Handshake

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

TLS False Start

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

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

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

TLS Chain of trust

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

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

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

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

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

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

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

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

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

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

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

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