TLS

Материал из Википедии — свободной энциклопедии
Перейти к: навигация, поиск

TLS (англ. Transport Layer Security) — безопасность транспортного уровня, как и его предшественник SSL (англ. Secure Socket Layers — уровень защищённых сокетов) — криптографические протоколы, обеспечивающие защищённую передачу данных между узлами в сети Интернет[1]. TLS и SSL используют асимметричную криптографию для аутентификации, симметричное шифрование для конфиденциальности и коды аутентичности сообщений для сохранения целостности сообщений.

Данный протокол широко используется в приложениях, работающих с сетью Интернет, таких как Веб-браузеры, работа с электронной почтой, обмен мгновенными сообщениями и IP-телефония (VoIP)

TLS-протокол основан на спецификации протокола SSL версии 3.0, разработанной компанией Netscape Communications[2]. Сейчас развитием стандарта TLS занимается IETF. Последнее обновление протокола было в RFC 5246.

Описание[править | править исходный текст]

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

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

Основные шаги процедуры создания защищённого сеанса связи:

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

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

При возникновении ошибки на любом из вышеуказанных шагов подтверждение связи завершится с ошибкой и соединение не будет установлено.

Безопасность[править | править исходный текст]

TLS имеет множество мер безопасности:

  • Защита от понижения версии протокола к предыдущей (менее защищённой) версии или менее надёжному алгоритму шифрования;
  • Нумерация последовательных записей приложения и использование порядкового номера в коде аутентификации сообщения (MAC);
  • Использование ключа в идентификаторе сообщения (только владелец ключа может проверить код аутентификации сообщения). Хеш-код идентификации сообщений (HMAC), используемый в большинстве шифров из набора шифров TLS был определён в RFC 2104;
  • Сообщение, которым заканчивается подтверждение связи («Finished»), содержит в себе хэш всех сообщений, которыми обменялись стороны в процессе подтверждения связи;
  • Псевдослучайная функция разбивает входные данные на две части и обрабатывает каждую разной хэш-функцией (MD5 и SHA-1), а затем вычисляет XOR от двух полученных свёрток, чтобы создать код аутентификации сообщения. Это обеспечивает безопасность даже в случае уязвимости одной из хэш-функций.

Уязвимость протокола TLS 1.0, которая считалась теоретической, была продемонстрирована на конференции Ekoparty в сентябре 2011 года. Демонстрация включала в себя дешифрование cookies, использованных для аутентификации пользователя[4].

Уязвимость в фазе возобновления соединения, обнаруженная в августе 2009 года, позволяла криптоаналитику, способному взломать https-соединение, добавлять собственные запросы в сообщения, отправленные от клиента к серверу[5]. Так как криптоаналитик не может дешифровать переписку сервера и клиента, этот тип атаки отличается от стандартной атаки, типа человек посередине. В случае, если пользователь не обращает внимания на индикацию браузера о том, что сессия является безопасной (обычно значок замка), уязвимость может быть использована для атаки типа человек посередине.[6]. Для устранения этой уязвимости было предложено как на стороне клиента, так и на стороне сервера добавлять информацию о предыдущем соединении и осуществлять проверку при возобновлении соединения. Это было представлено в стандарте RFC 5746, а также реализовано в последних версиях OpenSSL[7] и других библиотеках [8][9].

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

Процедура подтверждения связи в TLS в деталях[править | править исходный текст]

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

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

Простое подтверждение связи в TLS[править | править исходный текст]

Далее показан простой пример установления соединения, при котором сервер (но не клиент) проходит аутентификацию по его сертификату.

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

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

Подтверждение связи с аутентификацией клиента[править | править исходный текст]

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

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

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

Возобновление TLS-соединения[править | править исходный текст]

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

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

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

Кроме преимуществ с точки зрения производительности[11], алгоритм возобновления соединения может быть использован для реализации единого входа, поскольку гарантируется, что исходной сессия, как и любая возобновлённая сессия, инициирована тем же самым клиентом (RFC 5077). Это имеет особенно важное значение для реализации FTPS протокола, который в противном случае был бы уязвим к атаке типа человек посередине, при которой злоумышленник мог бы перехватить содержание данных при установлении повторного соединения[12].

Мандаты сессий[править | править исходный текст]

RFC 5077 расширяет TLS через использование мандатов сессий (англ. session tickets), вместо идентификаторов соединений (session id). Он определяет способ возобновления сеанса TLS, не требуя session id придыдущей сессии, состояние которой хранится на TLS сервере.

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

Одна из слабостей этого метода — для шифрования и аутентификации передаваемых сессионных мандатов всегда используется только метод AES128-CBC-SHA256, независимо от того, какие параметры TLS выбраны и используются для самого TLS соединения[13]. Это означает, что информация о TLS сессии (сохраняемая в сессионном мандате) не так хорошо защищена, как в рамках самой TLS сессии. Особую озабоченность вызывает хранение OpenSSL ключей в контексте приложения (SSL_CTX) в течении времени жизни приложения, не позволяя их повторного ввода из AES128-CBC-SHA256 сессионных мандатов, без сброса OpenSSL контекста всего приложения (что редкость, подвержено ошибкам и часто требует ручного вмешательства администратора)[14][15].

Алгоритмы, использующиеся в TLS[править | править исходный текст]

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

  • Для обмена ключами и проверки их подлинности применяются комбинации алгоритмов: RSA (асимметричный шифр), Diffie-Hellman (безопасный обмен ключами), DSA (алгоритм цифровой подписи), ECDSA;
  • Для симметричного шифрования: RC4, IDEA, Triple DES, SEED, Camellia или AES;
  • Для хеш-функций: MD5, SHA, SHA-256/384.

Алгоритмы могут дополняться в зависимости от версии протокола. До последней версии протокола TLS 1.2 были доступны также следующие алгоритмы симметричного шифрования, но они были убраны как небезопасные: RC2, IDEA, DES.

Сравнение с аналогами[править | править исходный текст]

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

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

См. также[править | править исходный текст]

Ссылки[править | править исходный текст]

  1. T. Dierks, E. Rescorla. The Transport Layer Security (TLS) Protocol, Version 1.2 (August 2008). Архивировано из первоисточника 9 февраля 2012.
  2. The SSL Protocol: Version 3.0 Netscape’s final SSL 3.0 draft (November 18, 1996)
  3. «SSL/TLS in Detail». Microsoft TechNet. Updated July 31, 2003.
  4. Dan Goodin. Hackers break SSL encryption used by millions of sites. The Register (19 сентября 2011). Проверено 7 декабря 2011. Архивировано из первоисточника 9 февраля 2012.
  5. Eric Rescorla. Understanding the TLS Renegotiation Attack. Educated Guesswork (5 ноября 2009). Проверено 7 декабря 2011. Архивировано из первоисточника 9 февраля 2012.
  6. McMillan, Robert. Security Pro Says New SSL Attack Can Hit Many Sites, PC World (20 ноября 2009). Проверено 7 декабря 2011.
  7. SSL_CTX_set_options SECURE_RENEGOTIATION. OpenSSL Docs (25 февраля 2010). Проверено 7 декабря 2010. Архивировано из первоисточника 9 февраля 2012.
  8. GnuTLS 2.10.0 released. GnuTLS release notes (25 июня 2010). Проверено 7 декабря 2011. Архивировано из первоисточника 9 февраля 2012.
  9. NSS 3.12.6 release notes. NSS release notes (3 марта 2010). Проверено 24 июля 2011.
  10. Various. IE SSL Vulnerability. Educated Guesswork (10 августа 2002). Проверено 7 декабря 2010. Архивировано из первоисточника 9 февраля 2012.
  11. A. Pehhrson. TLS session resumption impact on HTTP performance (March 2008). Архивировано из первоисточника 9 февраля 2012.
  12. vsftpd-2.1.0 released Using TLS session resume for FTPS data connection authentication. Retrieved on 2009-04-28.
  13. Daignière, Florent TLS "Secrets": Whitepaper presenting the security implications of the deployment of session tickets (RFC 5077) as implemented in OpenSSL. Matta Consulting Limited. Проверено 7 августа 2013.
  14. Daignière, Florent TLS "Secrets": What everyone forgot to tell you.... Matta Consulting Limited. Проверено 7 августа 2013.
  15. Langley, Adam How to botch TLS forward secrecy (27 June 2013).
  16. O. M. Dahl. Limitations and Differencies of using IPsec, TLS/SSL or SSH as VPN-solution (October 2004). Архивировано из первоисточника 9 февраля 2012.