TLS ( — протокол защиты транспортного уровняГОСУДАРСТВЕННЫЙ СТАНДАРТ СТБ 34.101.65-2014, как и его предшественник SSL, — слой защищённых сокетов) — криптографические протоколы, обеспечивающие защищённую передачу данных между узлами в сети Интернет; ГОСУДАРСТВЕННЫЙ СТАНДАРТ СТБ 34.101.65-2014. TLS и SSL используют асимметричное шифрование для аутентификации, симметричное шифрование для конфиденциальности и коды аутентичности сообщений для сохранения целостности сообщений.
Данный протокол широко используется в приложениях, работающих с сетью Интернет, таких как веб-браузеры, работа с электронной почтой, обмен мгновенными сообщениями и IP-телефония (VoIP).
TLS-протокол основан на спецификации протокола SSL версии 3.0, разработанной компанией Netscape CommunicationsThe SSL Protocol: Version 3.0 Netscape’s final SSL 3.0 draft (November 18, 1996). Сейчас развитием стандарта TLS занимается IETF. Последнее обновление протокола было в RFC 8446 (август 2018 года).
Описание TLS даёт возможность клиент-серверным приложениям осуществлять связь в сети таким образом, что при возможном прослушивании пакетов нельзя осуществить несанкционированный доступ.
Так как большинство протоколов связи может быть использовано как с TLS (или SSL), так и без них, при установке соединения необходимо явно указать серверу, хочет ли клиент устанавливать TLS. Это может быть достигнуто либо с помощью использования унифицированного номера порта, по которому соединение всегда устанавливается с использованием TLS (как, например, порт 443 для HTTPS), либо с использованием произвольного порта и специальной команды серверу со стороны клиента на переключение соединения на TLS с использованием специальных механизмов протокола (как, например, STARTTLS для протоколов электронной почты). Как только клиент и сервер договорились об использовании TLS, им необходимо установить защищённое соединение. Это делается с помощью процедуры подтверждения связиOverview of SSL/TLS Encryption Microsoft TechNet. Updated July 31, 2003.SSL/TLS in Detail Microsoft TechNet. Updated July 31, 2003.. Во время этого процесса клиент и сервер принимают соглашение относительно различных параметров, необходимых для установки безопасного соединения.
Основные шаги процедуры создания защищённого сеанса связи: клиент подключается к серверу, поддерживающему TLS, и запрашивает защищённое соединение; клиент предоставляет список поддерживаемых алгоритмов шифрования и хеш-функций; сервер выбирает из списка, предоставленного клиентом, наиболее надёжные алгоритмы среди тех, которые поддерживаются сервером, и сообщает о своём выборе клиенту; сервер отправляет клиенту цифровой сертификат для собственной аутентификации. Обычно цифровой сертификат содержит имя сервера, имя удостоверяющего центра сертификации и открытый ключ сервера; клиент, до начала передачи данных, проверяет валидность (аутентичность) полученного серверного сертификата относительно имеющихся у клиента корневых сертификатов удостоверяющих центров (центров сертификации). Клиент также может проверить, не отозван ли серверный сертификат, связавшись с сервисом доверенного удостоверяющего центра; для шифрования сессии используется сеансовый ключ. Получение общего секретного сеансового ключа клиентом и сервером проводится по протоколу Диффи — Хеллмана на эллиптических кривых. Существует исторический метод передачи сгенерированного клиентом секрета на сервер при помощи шифрования асимметричной криптосистемой RSA (используется ключ из сертификата сервера). Данный метод не рекомендован, но иногда продолжает встречаться на практике.
На этом заканчивается процедура подтверждения связи. Между клиентом и сервером установлено безопасное соединение, данные, передаваемые по нему, шифруются и расшифровываются с использованием симметричной криптосистемы до тех пор, пока соединение не будет завершено.
При возникновении проблем на некоторых из вышеуказанных шагов подтверждение связи может завершиться с ошибкой, а безопасное соединение не будет установлено.
История и версии +Протоколы SSL и TLSПротоколДата публикацииСостояниеscope=row scope=row 1995Признан устаревшим в 2011 году (RFC 6176)scope=row 1996Признан устаревшим в 2015 году (RFC 7568)scope=row 1999Признан устаревшим в 2021 годуscope=row 2006Признан устаревшим в 2021 годуscope=row 2008Используется с 2008 годаscope=row 2018Используется с 2018 года
Первые попытки реализовать зашифрованные сетевые сокеты предпринимались в 1993 годуThomas Y. C. Woo, Raghuram Bindignavle, Shaowen Su and Simon S. Lam, SNP: An interface for secure network programming Proceedings USENIX Summer Technical Conference, June 1994. Оригинальные протоколы SSL были разработаны Netscape: версия 1.0 в силу ряда недостатков не была опубликована, версия 2.0 представлена в 1995 году и замещена версией 3.0 в 1996 году. Версия SSL 3.0 представляла собой полную переработку протокола, выполненную Paul Kocher и сотрудниками Netscape Phil Karlton и Alan Freier и реализованную при участии компании Consensus Development. Последующие версии SSL и TLS основаны на SSL 3.0. Черновик стандарта 1996 года был опубликован IETF как RFC 6101. Использование SSL 2.0 было прекращено в 2011 году с выпуском документа RFC 6176. В 2014 году против блочных шифров SSL 3.0 была предложена атака POODLE, а единственный поддерживаемый потоковый шифр RC4 имел иные проблемы с безопасностью в том виде, как он использовался. В июне 2015 года SSL 3.0 был признан устаревшим (RFC 7568).
TLS 1.0 появился в 1999 году в виде обновления для SSL 3.0 и описан в RFC 2246. В 2018 году PCI DSS призывала корпорации отказаться от TLS 1.0 и в октябре 2018 крупнейшие игроки на рынке браузеров и ОС (Apple, Google, Microsoft, Mozilla) объявили, что прекратят поддержку TLS версий 1.0 и 1.1 в марте 2020 года.
TLS 1.1 был описан в RFC 4346 в апреле 2006 года. Он добавил к TLS 1.0 ряд защит от атак на CBC режимы шифрования и на ошибки дополнения данных до размера блока, начал использовать явный вектор инициализации и регистрацию числовых кодов для параметров в IANA.
TLS 1.2 появился в августе 2008 года как обновление версии 1.1, описан в RFC 5246. Были запрещены устаревшие криптографические хэш-функции MD5 и SHA-1 (заменены на SHA-256), улучшен механизм согласования сторонами списков поддерживаемых методов, введены методы AEAD (GCM и CCM для AES).
В марте 2011 года документ RFC 6176 запретил реализацию обратной совместимости со старыми версиями SSL во всех протоколах TLS.
Новейшим обновлением стал TLS 1.3, описанный в августе 2018 года в RFC 8446. В этой версии были разделены процессы согласования ключей, аутентификации и наборы шифрования; запрещены слабые и редкие эллиптические кривые, хэши MD5 и SHA-224; введена обязательность предоставления цифровой подписи; внедрена и полуэфемерная система DH. Вместо механизма возобновления применён PSK и система мандатов, ускорены процессы соединения (1-RTT и 0-RTT), постулирована обязательность perfect forward secrecy для сессионных ключей через протоколы генерации DH и ECDH. Были запрещены такие устаревшие и небезопасные опции как сжатие данных, пересогласование, шифры без аутентификации сообщений (то есть не AEAD режимы), несекретные методы получения сессионных ключей (RSA, статический DH, группы DHE), вспомогательные сообщения (Change Cipher Spec, HELLO, поле длины AD). Прекращена обратная совместимость с SSL или RC4. Появились поточный шифр ChaCha20 с MAC кодом Poly1305, подписи Ed25519 и Ed448, протоколы обмена ключами x25519 и x448.
Поддержка TLS 1.3 появилась в Mozilla Network Security Services (NSS) в феврале 2017 года (включено в Firefox 60). Google Chrome некоторое время поддерживал TLS 1.3 в 2017, но отключил его ради Blue Coat web proxу. OpenSSL добавил эту версию в выпуск 1.1.1 от сентября 2018 года. Electronic Frontier Foundation разрешил использовать TLS 1.3 и предостерёг от путаницы со сходным клептографическим протокольным гибридом ETS или eTLS (в нём намеренно выключены важные свойства безопасности из TLS 1.3).
Безопасность TLS имеет множество мер безопасности: защита от понижения версии протокола к предыдущей (менее защищённой) версии или менее надёжному алгоритму шифрования; нумерация последовательных записей приложения и использование порядкового номера в коде аутентификации сообщения (MAC); использование ключа в идентификаторе сообщения (только владелец ключа может сгенерировать код аутентификации сообщения). Алгоритм вычисления кода аутентификации (HMAC), используемый во многих сессиях TLS, определён в RFC 2104; сообщение, которым заканчивается подтверждение связи («Finished»), используется для подтверждения аутентичности ранее переданных сообщений и, таким образом, выбранных параметров TLS-соединения.
Уязвимость протокола TLS 1.0, которая считалась теоретической, была продемонстрирована на конференции Ekoparty в сентябре 2011 года. Демонстрация включала в себя дешифрование cookies, использованных для аутентификации пользователя.
Уязвимость в фазе возобновления соединения, обнаруженная в августе 2009 года, позволяла криптоаналитику, способному взломать https-соединение, добавлять собственные запросы в сообщения, отправленные от клиента к серверу. Так как криптоаналитик не может дешифровать переписку сервера и клиента, этот тип атаки отличается от стандартной атаки, типа человек посередине. В случае, если пользователь не обращает внимания на индикацию браузера о том, что сессия является безопасной (обычно значок замка), уязвимость может быть использована для атаки типа человек посередине. Для устранения этой уязвимости было предложено как на стороне клиента, так и на стороне сервера добавлять информацию о предыдущем соединении и осуществлять проверку при возобновлении соединения. Это было представлено в стандарте RFC 5746, а также реализовано в последних версиях OpenSSL и других библиотеках.
Также существуют варианты атак, основанные непосредственно на программной реализации протокола, а не на его алгоритме.
Процедура подтверждения связи в TLS в деталях Согласно протоколу TLS, приложения обмениваются записями, инкапсулирующими (хранящими внутри себя) информацию, которая должна быть передана. Каждая из записей может быть сжата, дополнена, зашифрована или идентифицирована MAC (код аутентификации сообщения) в зависимости от текущего состояния соединения (состояния протокола). Каждая запись в TLS содержит следующие поля: Content Type (определяет тип содержимого записи), Version (поле, указывающее версию протокола TLS) и Length (поле, указывающее длину пакета).
Когда соединение только устанавливается, взаимодействие идёт по протоколу TLS handshake, content type которого — 22.
Простое подтверждение связи в TLS Далее показан простой пример установления соединения, при котором сервер (но не клиент) проходит аутентификацию по его сертификату.
Фаза переговоров: Клиент посылает сообщение ClientHello, указывая последнюю версию поддерживаемого TLS-протокола, случайное число и список поддерживаемых шифронаборов (методов шифрования, англ. cipher suites), подходящих для работы с TLS; Сервер отвечает сообщением ServerHello, содержащим: выбранную сервером версию протокола, случайное число, сгенерированное сервером, выбранный шифронабор из списка, предоставленного клиентом; Сервер посылает сообщение Certificate, которое содержит цифровой сертификат сервера (в зависимости от алгоритма шифрования этот этап может быть пропущен); Если переданных сервером данных недостаточно для выработки общего симметричного секретного ключа в рамках выбранного шифронабора, сервер передаёт сообщение ServerKeyExchange, в котором передаются необходимые данные. Например, в ServerKeyExchange передаётся серверная часть обмена для протокола Диффи-Хеллмана; Сервер отсылает сообщение ServerHelloDone, идентифицирующее окончание первого раунда установления соединения; Клиент отвечает сообщением ClientKeyExchange, которое содержит клиентскую часть протокола Диффи-Хеллмана или зашифрованный открытым ключом из сертификата сервера секрет (PreMasterSecret);