Редактирование: TLS

'''TLS''' ({{lang-en|transport layer security}} — Протокол защиты транспортного уровня<ref>ГОСУДАРСТВЕННЫЙ СТАНДАРТ СТБ 34.101.65-2014</ref>), как и его предшественник [[SSL]] ({{lang-en|secure sockets layer}} — слой защищённых сокетов), — [[Криптографический протокол|криптографические протоколы]], обеспечивающие защищённую передачу данных между узлами в сети [[Интернет]]<ref>{{cite web|url=http://tools.ietf.org/html/rfc5246|title=The Transport Layer Security (TLS) Protocol, Version 1.2|date=August 2008|author=T. Dierks, E. Rescorla|archiveurl=https://www.webcitation.org/65JSRyvms?url=http://tools.ietf.org/html/rfc5246|archivedate=2012-02-09}}; ГОСУДАРСТВЕННЫЙ СТАНДАРТ СТБ 34.101.65-2014</ref>. TLS и SSL используют [[Асимметричная криптография|асимметричное шифрование]] для аутентификации, [[Симметричные криптосистемы|симметричное шифрование]] для конфиденциальности и [[Имитовставка|коды аутентичности сообщений]] для сохранения целостности сообщений.

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

TLS-протокол основан на спецификации протокола [[SSL]] версии 3.0, разработанной компанией [[Netscape Communications]]<ref>[http://www.mozilla.org/projects/security/pki/nss/ssl/draft302.txt The SSL Protocol: Version 3.0] Netscape’s final SSL 3.0 draft (November 18, 1996)</ref>.
Сейчас развитием стандарта TLS занимается [[IETF]]. Последнее обновление протокола было в RFC 5246 (август 2008) и RFC 6176 (март 2011).

== Описание ==
TLS даёт возможность клиент-серверным приложениям осуществлять связь в сети таким образом, что нельзя производить [[Сниффинг пакетов|прослушивание]] пакетов и осуществить [[несанкционированный доступ]].

Так как большинство протоколов связи может быть использовано как с, так и без TLS (или SSL), при установке соединения необходимо явно указать серверу, хочет ли клиент устанавливать TLS. Это может быть достигнуто либо с помощью использования унифицированного [[Порт (TCP/IP)|номера порта]], по которому соединение всегда устанавливается с использованием TLS (как, например, порт 443 для [[HTTPS]]), либо с использованием произвольного порта и специальной команды серверу со стороны клиента на переключение соединения на TLS с использованием специальных механизмов протокола (как, например, [[STARTTLS]] для протоколов [[E-mail|электронной почты]]).
Как только клиент и сервер договорились об использовании TLS, им необходимо установить защищённое соединение. Это делается с помощью процедуры подтверждения связи<ref>[https://web.archive.org/web/20141202095453/https://technet.microsoft.com/en-us/library/cc781476(v=ws.10).aspx Overview of SSL/TLS Encryption] ''[[Microsoft TechNet]]''. Updated July 31, 2003.</ref><ref>[https://web.archive.org/web/20141205153312/https://technet.microsoft.com/en-us/library/cc785811(v=ws.10).aspx SSL/TLS in Detail] ''[[Microsoft TechNet]]''. Updated July 31, 2003.</ref>. Во время этого процесса клиент и сервер принимают соглашение относительно различных параметров, необходимых для установки безопасного соединения.

Основные шаги процедуры создания защищённого сеанса связи:
* клиент подключается к серверу, поддерживающему TLS, и запрашивает защищённое соединение;
* клиент предоставляет список поддерживаемых [[шифрование|алгоритмов шифрования]] и [[Хеширование|хеш-функций]];
* сервер выбирает из списка, предоставленного клиентом, наиболее надёжные алгоритмы среди тех, которые поддерживаются сервером, и сообщает о своём выборе клиенту;
* сервер отправляет клиенту цифровой сертификат для собственной аутентификации. Обычно [[цифровой сертификат]] содержит имя сервера, имя [[Центр сертификации|удостоверяющего центра сертификации]] и [[открытый ключ]] сервера;
* клиент, до начала передачи данных, проверяет валидность (аутентичность) полученного серверного сертификата относительно имеющихся у клиента корневых сертификатов удостоверяющих центров (центров сертификации). Клиент также может проверить, не отозван ли серверный сертификат, связавшись с сервисом доверенного удостоверяющего центра;
* для шифрования сессии используется [[сеансовый ключ]]. Получение общего секретного сеансового ключа клиентом и сервером проводится по протоколу [[Протокол Диффи — Хеллмана|Диффи-Хеллмана]]. Существует исторический метод передачи сгенерированного клиентом секрета на сервер при помощи шифрования асимметричной криптосистемой RSA (используется ключ из сертификата сервера). Данный метод не рекомендован, но иногда продолжает встречаться на практике.

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

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

== История и версии ==
{| class="wikitable sortable" style="float:right; text-align:center; margin-left:1em;"
|+Протоколы SSL и TLS
|-
!scope="col"| Протокол
!scope="col"| Дата публикации
!scope="col"| Состояние
|-
!scope="row"| SSL 1.0
| не публиковался
| не публиковался
|-
!scope="row"| SSL 2.0
| 1995
| Признан устаревшим в 2011 году (RFC 6176)
|-
!scope="row"| SSL 3.0
| 1996
| Признан устаревшим в 2015 году (RFC 7568)
|-
!scope="row"| TLS 1.0
| 1999
| Признание устаревшим ожидается в 2020 году<ref name=":2"/>
|-
!scope="row"| TLS 1.1
| 2006
| Признание устаревшим ожидается в 2020 году<ref name=":2" />
|-
!scope="row"| TLS 1.2
| 2008
|
|-
!scope="row"| TLS 1.3
| 2018
|
|}
Первые попытки реализовать зашифрованные сетевые сокеты предпринимались в 1993 году<ref name="Woo94">Thomas Y. C. Woo, Raghuram Bindignavle, Shaowen Su and [[Simon S. Lam]], [//www.cs.utexas.edu/users/lam/Vita/Cpapers/WBSL94.pdf ''SNP: An interface for secure network programming''] Proceedings USENIX Summer Technical Conference, June '''1994'''</ref>. Оригинальные протоколы SSL были разработаны Netscape: версия 1.0 в силу ряда недостатков не была опубликована, версия 2.0 представлена в 1995 году и замещена версией 3.0 в 1996 году<ref name="Oppliger">{{cite book |title=SSL and TLS: Theory and Practice |edition=2nd |last=Oppliger |first=Rolf |year=2016 |chapter=Introduction |chapter-url=https://books.google.com/books?id=jm6uDgAAQBAJ&pg=PA15 |page=13 |publisher=[[Artech House]] |isbn=978-1-60807-999-5 |via=Google Books |access-date=2018-03-01}}</ref>. Версия 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]] имел иные проблемы с безопасностью в том виде, как он использовался.<ref name="Poodle">{{cite web |url= https://access.redhat.com/articles/1232123 |title=POODLE: SSLv3 vulnerability (CVE-2014-3566) |accessdate=21 October 2014 |deadurl=no |archiveurl= https://web.archive.org/web/20141205124712/https://access.redhat.com/articles/1232123 |archivedate=5 December 2014}}</ref> В июне 2015 года SSL 3.0 был признан устаревшим (RFC 7568).

TLS 1.0 появился в 1999 году в виде обновления для SSL 3.0 и описан в RFC 2246. В 2018 году PCI DSS призывала корпорации отказаться от TLS 1.0<ref>{{cite web |url=https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls |title=Date Change for Migrating from SSL and Early TLS |author=Laura K. Gray |date=2015-12-18 |website=[[Payment Card Industry Security Standards Council]] blog |access-date=2018-04-05}}</ref> и в октябре 2018 крупнейшие игроки на рынке браузеров и ОС (Apple, Google, [[Microsoft]], [[Mozilla]]) объявили, что прекратят поддержку TLS версий 1.0 и 1.1 в марте 2020 года.<ref name=":2">{{cite web|url=https://arstechnica.com/gadgets/2018/10/browser-vendors-unite-to-end-support-for-20-year-old-tls-1-0/|title=Apple, Google, Microsoft, and Mozilla come together to end TLS 1.0|last=Bright|first=Peter|date=17 October 2018|accessdate=17 October 2018}}</ref> 

TLS 1.1 был описан в RFC 4346 в апреле 2006 года<ref>{{cite web |author1=Dierks, T. |author2=E. Rescorla |lastauthoramp=yes |title=The Transport Layer Security (TLS) Protocol Version 1.1 |rfc=4346 |date=April 2006 |url=//tools.ietf.org/html/rfc5246#ref-TLS1.1 |deadurl=no |archiveurl=https://web.archive.org/web/20171224222709/https://tools.ietf.org/html/rfc5246#ref-TLS1.1 |archivedate=2017-12-24}}</ref>. Он добавил к TLS 1.0 ряд защит от атак на CBC режимы шифрования и на ошибки [[Дополнение (криптография)|дополнения данных до размера блока]], начал использовать явный [[Режим_шифрования#Initialization_vector_(IV)|вектор инициализации]] и регистрацию числовых кодов для параметров в IANA<ref name="urlnvlpubs.nist.gov">{{cite web|url=http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r1.pdf |title=Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations|authors=Polk, Tim; McKay, Terry; Chokhani, Santosh|date=April 2014 |publisher=National Institute of Standards and Technology|page=67 |archiveurl=https://web.archive.org/web/20140508025330/http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r1.pdf |archivedate=2014-05-08 |dead-url=yes|accessdate=2014-05-07}}</ref>.

TLS 1.2 появился в августе 2008 года как обновление версии 1.1, описан в RFC 5246. Были запрещены устаревшие криптографические хэш-функции [[MD5]] и [[SHA-1]] (заменены на SHA-256), улучшен механизм согласования сторонами списков поддерживаемых методов, введены методы [[AEAD-режим блочного шифрования|AEAD]] ([[Galois/Counter Mode|GCM]] и [[CCM mode|CCM]] для [[AES]]).<ref>{{cite IETF |rfc=5246|title=The Transport Layer Security (TLS) Protocol Version 1.2|section=7.4.9|sectionname=Finished|date=August 2008|author=T. Dierks, E. Rescorla}}</ref>

В марте 2011 года документ RFC 6176 запретил реализацию обратной совместимости со старыми версиями SSL во всех протоколах TLS.

Новейшим обновлением стал TLS 1.3, описанный в августе 2018 года в RFC 8446. В этой версии были разделены процессы согласования ключей, аутентификации и наборы шифрования; запрещены слабые и редкие эллиптические кривые, хэши MD5 и SHA-224; введена обязательность цифровой подписи; внедрена {{iw|HKDF}} и полуэфемерная система DH. Вместо механизма возобновления применен [[TLS-PSK|PSK]] и система <!-- tickets = крипто-->мандатов, ускорены процессы соединения (1-RTT и 0-RTT), постулирована обязательность [[perfect forward secrecy]] для сессионных ключей через протоколы генерации DH и ECDH. Были запрещены такие устаревшие и небезопасные опции как сжатие данных, пересогласование, шифры без аутентификации сообщений (т.е. не [[AEAD-режим блочного шифрования|AEAD]] режимы), несекретные методы получения сессионных ключей (RSA, статический DH, группы DHE), вспомогательные сообщения (Change Cipher Spec, [[Heartbleed|HELLO]], поле длины AD). Прекращена обратная совместимость с SSL или RC4. Появились поточный шифр [[ChaCha20]] с MAC кодом [[Poly1305]], подписи [[Ed25519]] и Ed448, протоколы обмена ключами [[x25519]] и x448.

Поддержка TLS 1.3 появилась в Mozilla [[Network Security Services]] (NSS) в феврале 2017 года (включено в Firefox 60).<ref name=NSS-3.29>{{cite web|url=https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.29_release_notes|title=NSS 3.29 release notes|date=February 2017|publisher=Mozilla Developer Network|deadurl=no|archiveurl=https://web.archive.org/web/20170222052829/https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.29_release_notes|archivedate=2017-02-22}}</ref><ref>{{Cite web|url=https://www.mozilla.org/en-US/firefox/60.0/releasenotes/|title=Firefox — Notes (60.0)|website=Mozilla|language=en-US|access-date=2018-05-10}}</ref> [[Google Chrome]] некоторое время поддерживал TLS 1.3 в 2017 но отключил его ради [[Blue Coat Systems|Blue Coat web proxу]].<ref>{{cite web |url=http://bluecoat.force.com/knowledgebase/articles/Technical_Alert/000032878 |title=ProxySG, ASG and WSS will interrupt SSL connections when clients using TLS 1.3 access sites also using TLS 1.3 |date=16 May 2017 |work=BlueTouch Online |accessdate=11 September 2017 |deadurl=no |archiveurl=https://web.archive.org/web/20170912061432/http://bluecoat.force.com/knowledgebase/articles/Technical_Alert/000032878 |archivedate=12 September 2017}}</ref> [[OpenSSL]] добавил эту версию в выпуск 1.1.1 от сентября 2018 года.<ref>{{cite web|url=https://www.openssl.org/blog/blog/2018/09/11/release111/|title=OpenSSL 1.1.1 Is Released|date=11 Sep 2018 <!-- 12:00:00 GMT --> |publisher=Matt Caswell|accessdate=19 Dec 2018 <!-- 05:44:54 GMT --> }}</ref> [[Electronic Frontier Foundation]] похвалил TLS 1.3 и предостерег от путаницы с сходным [[клептография|клептографическим]] протокольным гибридом "ETS" или "eTLS" (в нём намерено выключены важные свойства безопасности из TLS 1.3)<ref>{{Cite web|url=https://www.eff.org/deeplinks/2019/02/ets-isnt-tls-and-you-shouldnt-use-it|title=ETS Isn't TLS and You Shouldn't Use It|last=Hoffman-Andrews|first=Jacob|date=2019-02-26|website=[[Electronic Frontier Foundation]]|language=en|archive-url=|archive-date=|dead-url=|access-date=2019-02-27}}</ref>.

== Безопасность ==
TLS имеет множество мер безопасности:
* Защита от понижения версии протокола к предыдущей (менее защищённой) версии или менее надёжному алгоритму шифрования;
* Нумерация последовательных записей приложения и использование порядкового номера в коде аутентификации сообщения ([[Имитовставка|MAC]]);
* Использование ключа в идентификаторе сообщения (только владелец ключа может сгенерировать [[Имитовставка|код аутентификации сообщения]]). Алгоритм вычисления кода аутентификации ([[HMAC]]), используемый во многих сессиях TLS, определён в RFC 2104;
* Сообщение, которым заканчивается подтверждение связи («Finished»), используется для подтверждения аутентичности ранее переданных сообщений и, таким образом, выбранных параметров TLS-соединения.

Уязвимость протокола TLS 1.0, которая считалась теоретической, была продемонстрирована на конференции Ekoparty в сентябре 2011 года. Демонстрация включала в себя дешифрование cookies, использованных для аутентификации пользователя<ref>{{Cite web
 |author      = Dan Goodin
 |title       = Hackers break SSL encryption used by millions of sites
 |work        = The Register
 |accessdate  = 2011-12-07
 |date        = 2011-09-19
 |url         = https://www.theregister.co.uk/2011/09/19/beast_exploits_paypal_ssl/
 |archiveurl  = https://www.webcitation.org/65JSSbOus?url=http://www.theregister.co.uk/2011/09/19/beast_exploits_paypal_ssl/
 |archivedate = 2012-02-09
}}</ref>.

Уязвимость в фазе возобновления соединения, обнаруженная в августе 2009 года, позволяла [[криптоаналитик]]у, способному взломать [[HTTPS|https-соединение]], добавлять собственные запросы в сообщения, отправленные от клиента к серверу<ref>{{Cite web|author=Eric Rescorla|title=Understanding the TLS Renegotiation Attack|work=Educated Guesswork|accessdate=2011-12-07|date=2009-11-05|url=http://www.educatedguesswork.org/2009/11/understanding_the_tls_renegoti.html|archiveurl=https://www.webcitation.org/65JSTKRCA?url=http://www.educatedguesswork.org/2009/11/understanding_the_tls_renegoti.html|archivedate=2012-02-09}}</ref>. Так как [[криптоаналитик]] не может дешифровать переписку сервера и клиента, этот тип атаки отличается от стандартной атаки, типа [[человек посередине]]. В случае, если пользователь не обращает внимания на индикацию браузера о том, что сессия является безопасной (обычно значок замка), уязвимость может быть использована для атаки типа [[человек посередине]]<ref>{{Cite news| last = McMillan| first = Robert| title = Security Pro Says New SSL Attack Can Hit Many Sites| work = PC World| accessdate = 2011-12-07| date = 2009-11-20| url = http://www.pcworld.com/article/182720/security_pro_says_new_ssl_attack_can_hit_many_sites.html}}</ref>. Для устранения этой уязвимости было предложено как на стороне клиента, так и на стороне сервера добавлять информацию о предыдущем соединении и осуществлять проверку при возобновлении соединения. Это было представлено в стандарте RFC 5746, а также реализовано в последних версиях [[OpenSSL]]<ref>{{Cite web|title=SSL_CTX_set_options SECURE_RENEGOTIATION|work=OpenSSL Docs|accessdate=2010-12-07|date=2010-02-25|url=http://www.openssl.org/docs/ssl/SSL_CTX_set_options.html#SECURE_RENEGOTIATION|archiveurl=https://www.webcitation.org/65JSTpBgx?url=http://www.openssl.org/docs/ssl/SSL_CTX_set_options.html#SECURE_RENEGOTIATION|archivedate=2012-02-09|deadlink=yes}}</ref> и других библиотеках<ref>{{Cite web|title=GnuTLS 2.10.0 released|work=GnuTLS release notes|accessdate=2011-12-07|date=2010-06-25|url=http://article.gmane.org/gmane.network.gnutls.general/2046|archiveurl=https://www.webcitation.org/65JSUYEDA?url=http://article.gmane.org/gmane.network.gnutls.general/2046|archivedate=2012-02-09}}</ref><ref>{{Cite web| title = NSS 3.12.6 release notes| work = NSS release notes| accessdate = 2011-07-24| date = 2010-03-03| url = https://developer.mozilla.org/NSS_3.12.6_release_notes| archiveurl = https://web.archive.org/web/20120306184633/https://developer.mozilla.org/NSS_3.12.6_release_notes| archivedate = 2012-03-06}}</ref>.

Также существуют варианты атак, основанные непосредственно на программной реализации протокола, а не на его алгоритме<ref>{{Cite web|author=Various|title=IE SSL Vulnerability|work=Educated Guesswork|accessdate=2010-12-07|date=2002-08-10|url=http://www.mail-archive.com/bugtraq@securityfocus.com/msg08807.html|archiveurl=https://www.webcitation.org/65JSVGzqK?url=http://www.mail-archive.com/bugtraq@securityfocus.com/msg08807.html|archivedate=2012-02-09|deadlink=yes}}</ref>.

=== Процедура подтверждения связи в TLS в деталях ===
Согласно протоколу TLS, приложения обмениваются записями, инкапсулирующими (хранящими внутри себя) информацию, которая должна быть передана. Каждая из записей может быть сжата, дополнена, зашифрована или идентифицирована [[Message authentication code|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''');
#* Клиент и сервер, используя ключ '''PreMasterSecret''' и случайно сгенерированные числа, вычисляют общий секрет. Вся остальная информация о сеансовом ключе будет получена из общего секрета;
# Клиент посылает сообщение '''ChangeCipherSpec''', которое указывает на то, что вся последующая информация будет зашифрована установленным в процессе подтверждения связи алгоритмом, используя общий секретный ключ. Это сообщение уровня записей и поэтому имеет тип 20, а не 22;
#* Клиент посылает сообщение '''Finished''', которое содержит хеш и MAC, сгенерированные на основе предыдущих сообщений процедуры подтверждения связи;
#* Сервер пытается расшифровать Finished-сообщение клиента и проверить хеш и МАС. Если процесс расшифровки или проверки не удаётся, подтверждение связи считается неудавшимся, и соединение должно быть оборвано;
# Сервер посылает '''ChangeCipherSpec''' и зашифрованное сообщение Finished, и в свою очередь клиент тоже выполняет расшифровку и проверку.
С этого момента подтверждение связи считается завершённым, протокол - установленным. Всё последующее содержимое пакетов идёт с типом 23, а все данные будут зашифрованы.

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

# Фаза переговоров:
#* Клиент посылает сообщение '''ClientHello''', указывая последнюю версию поддерживаемого TLS-протокола, случайное число и список поддерживаемых методов шифрования и сжатия, подходящих для работы с TLS;
#* Сервер отвечает сообщением '''ServerHello''', содержащим: выбранную сервером версию протокола, случайное число, посланное клиентом, подходящий алгоритм шифрования и сжатия из списка предоставленного клиентом;
#* Сервер посылает сообщение '''Certificate''', которое содержит цифровой сертификат сервера (в зависимости от алгоритма шифрования этот этап может быть пропущен);
#* Сервер посылает сообщение '''CertificateRequest''', которое содержит запрос сертификата клиента для взаимной проверки подлинности;
#* Клиент посылает сообщение '''Certificate''', которое содержит цифровой сертификат клиента;
#* Сервер отсылает сообщение '''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 такой тип подтверждения связи называется ''сокращённым''.

# Фаза переговоров:<ref>http://www.ict.kth.se/courses/IK1550/Sample-papers/2G1305_Assignment_Asa_Pehrsson_050908.pdf figure 3</ref>
#* Клиент посылает сообщение '''ClientHello''', указывая последнюю версию поддерживаемого TLS-протокола, случайное число и список поддерживаемых методов шифрования и сжатия, подходящих для работы с TLS; Также в сообщение добавляется идентификатор предыдущего соединения '''session id'''.
#* Сервер отвечает сообщением '''ServerHello''', содержащим: выбранную сервером версию протокола, случайное число, посланное клиентом, подходящий алгоритм шифрования и сжатия из списка предоставленного клиентом. Если сервер узнал идентификатор сессии '''session id''', то он добавляет в сообщение '''ServerHello''' тот же самый идентификатор '''session id'''. Это является сигналом для клиента о том, что можно использовать возобновление предыдущей сессии. Если сервер не узнал идентификатор сессии '''session id''', то он добавляет в сообщение '''ServerHello''' другое значение вместо '''session id'''. Для клиента это означает, что использовать возобновлённое соединение нельзя. Таким образом, сервер и клиент должны иметь одинаковый master secret и случайные числа для генерации сеансового ключа;
# Сервер посылает сообщение '''ChangeCipherSpec''', которое указывает на то, что вся последующая информация будет зашифрована установленным в процессе подтверждения связи алгоритмом, используя общий секретный ключ. Это сообщения уровня записей и поэтому имеет тип 20, а не 22;
#* Сервер посылает зашифрованное сообщение '''Finished''', которое содержит хеш и MAC, сгенерированные на основе предыдущих сообщений процедуры подтверждения связи;
#* Клиент пытается расшифровать '''Finished''' сообщение сервера и проверить хеш и МАС. Если процесс расшифровки или проверки не удаётся, подтверждение связи считается неудавшимся, и соединение должно быть оборвано;
# Клиент посылает сообщение '''ChangeCipherSpec''', которое указывает на то, что вся последующая информация будет зашифрована установленным в процессе подтверждения связи алгоритмом, используя общий секретный ключ.
#* Клиент посылает своё зашифрованное сообщение '''Finished''';
#* Сервер схожим образом пытается расшифровать '''Finished'''-сообщение клиента и проверить хеш и MAC;
# С этого момента подтверждение связи считается завершённым, протокол - установленным. Всё последующее содержимое пакетов идёт с типом 23, а все данные будут зашифрованы.

Кроме преимуществ с точки зрения производительности<ref>{{cite web|url=http://www.ict.kth.se/courses/IK1550/Sample-papers/2G1305_Assignment_Asa_Pehrsson_050908.pdf|title=TLS session resumption impact on HTTP performance|date=March 2008|author=A. Pehhrson|archiveurl=https://www.webcitation.org/65JSVoArr?url=http://www.ict.kth.se/courses/IK1550/Sample-papers/2G1305_Assignment_Asa_Pehrsson_050908.pdf|archivedate=2012-02-09}}</ref>, алгоритм возобновления соединения может быть использован для реализации [[Технология единого входа|единого входа]], поскольку гарантируется, что исходная сессия, как и любая возобновлённая сессия, инициирована тем же самым клиентом (RFC 5077). Это имеет особенно важное значение для реализации [[FTPS]] протокола, который в противном случае был бы уязвим к атаке типа "человек посередине", при которой злоумышленник мог бы перехватить содержание данных при установлении повторного соединения<ref>[http://scarybeastsecurity.blogspot.com/2009/02/vsftpd-210-released.html vsftpd-2.1.0 released] Using TLS session resume for FTPS data connection authentication. Retrieved on 2009-04-28.</ref>.

===== Мандаты сессий =====
RFC 5077 расширяет TLS через использование мандатов сессий ({{lang-en|session tickets}}) вместо идентификаторов соединений (session id). Он определяет способ возобновления сеанса TLS, не требуя '''session id''' предыдущей сессии, состояние которой хранится на TLS-сервере.

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

Одна из слабостей этого метода — для шифрования и аутентификации передаваемых сессионных мандатов всегда используется только метод AES128-CBC-SHA256, независимо от того, какие параметры TLS выбраны и используются для самого TLS-соединения<ref name="ticketsecwp">{{cite web|title=TLS "Secrets": Whitepaper presenting the security implications of the deployment of session tickets (RFC 5077) as implemented in OpenSSL|first=Florent|last=Daignière|publisher=Matta Consulting Limited|accessdate=7 August 2013|url=https://media.blackhat.com/us-13/US-13-Daigniere-TLS-Secrets-WP.pdf}}</ref>. Это означает, что информация о TLS-сессии (сохраняемая в сессионном мандате) не так хорошо защищена, как в рамках самой TLS-сессии. Особую озабоченность вызывает хранение OpenSSL-ключей в контексте приложения (SSL_CTX) в течение времени жизни приложения, не допуская их повторного ввода из AES128-CBC-SHA256 сессионных мандатов без сброса OpenSSL-контекста всего приложения (что редкость, подвержено ошибкам и часто требует ручного вмешательства администратора)<ref name="ticketsecslides">{{cite web|title=TLS "Secrets": What everyone forgot to tell you...|first=Florent|last=Daignière|publisher=Matta Consulting Limited|accessdate=7 August 2013|url=https://media.blackhat.com/us-13/US-13-Daigniere-TLS-Secrets-Slides.pdf}}</ref><ref name="botchingpfs">{{cite web|title=How to botch TLS forward secrecy|first=Adam|last=Langley|website=imperialviolet.org|date=27 June 2013|url=https://www.imperialviolet.org/2013/06/27/botchingpfs.html}}</ref>.

== Алгоритмы, использующиеся в TLS ==
В текущей версии протокола доступны следующие алгоритмы:
* Для обмена ключами и проверки их подлинности применяются комбинации алгоритмов: [[RSA]] (асимметричный шифр), [[Diffie-Hellman]] (безопасный обмен ключами), [[DSA]] (алгоритм цифровой подписи), [[ECDSA]];
* Для симметричного шифрования: [[RC4]], [[IDEA]], [[Triple DES]], [[SEED]], [[Camellia (алгоритм)|Camellia]] или [[Advanced Encryption Standard|AES]];
* Для [[Хеширование|хеш-функций]]: [[MD5]], [[SHA-1|SHA]], [[SHA-2|SHA-256/384]].
Алгоритмы могут дополняться в зависимости от версии протокола. До версии протокола TLS 1.2 были доступны также следующие алгоритмы симметричного шифрования, но они были убраны как небезопасные: [[RC2]], [[IDEA]], [[DES]]<ref>{{cite web|url=https://www.ietf.org/proceedings/70/slides/tls-0.pdf|title=TLS 1.2 Update|author=Eric Rescorla|quote=Other changes ... Removed RC2, DES, and IDEA|publisher=70 proceedings IETF |lang=en|accessdate=2018-01-03}}</ref>.

== Сравнение с аналогами ==
Одной из областей применения TLS-соединения является соединение узлов в [[VPN|виртуальной частной сети]]. Кроме TLS, также могут использоваться набор протоколов [[IPSec]] и [[SSH]]-соединение. Каждый из этих подходов к реализации [[VPN|виртуальной частной сети]] имеет свои преимущества и недостатки<ref>{{cite web|url=http://olemartin.com/projects/VPNsolutions.pdf|title=Limitations and Differencies of using IPsec, TLS/SSL or SSH as VPN-solution|date=October 2004|author=O. M. Dahl|archiveurl=https://www.webcitation.org/65JSWNiWC?url=http://olemartin.com/projects/VPNsolutions.pdf|archivedate=2012-02-09}}</ref>.

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

== Удостоверяющие центры ==
Выдачей TLS-сертификатов занимаются удостоверяющие центры с аккредитацией WebTrust. Функция удостоверяющих центров — осуществить проверку пользователя и заверить подлинность ресурса. В настоящее время среди доверенных центров сертификации можно выделить:

* GlobalSign <ref>{{Cite web|url=https://www.globalsign.com/ru-ru/|title=GlobalSign|author=|website=|date=|publisher=}}</ref>(головной офис в Японии. в 2013 г. УЦ открыл представительство в России)
* Sectigo (ранее более известен, как Comodo, который 2017 году был приобретен <ref>{{Cite web|url=https://www.eweek.com/security/francisco-partners-acquires-comodo-s-certificate-authority-business|title=Francisco Partners Acquires Comodo's Certificate Authority Business|publisher=eWEEK|accessdate=2019-07-01}}</ref>Francisco Partners, через год последовала смена названия)
* Digicert (после инцидента с [https://techcrunch.com/2017/03/27/google-is-fighting-with-symantec-over-encrypting-the-internet/ отзывом 30000 сертификатов Symantec], в 2017 году Symantec продал свой SSL-бизнес<ref>{{Cite web|url=https://www.sslshopper.com/symantec-sells-ca-business-to-digicert.html|title=Symantec sells its CA business to DigiCert|publisher=www.sslshopper.com|accessdate=2019-07-01}}</ref>, куда входили бренды  Symantec, Thawte, GeoTrust, RapidSSL, удостоверяющему центру Digicert.)

== См. также ==

* [[SSL]]
* [[Server Name Indication]] (SNI)
* [[JSSE]]
* [[STARTTLS]]

== Примечания ==
{{примечания|2}}

== Ссылки ==
* {{cite web|date=|url=http://datatracker.ietf.org/wg/tls/|title=Transport Layer Security (tls) — Documents|accessdate=2011-02-18|lang=en|archiveurl=https://www.webcitation.org/65JSWsey8?url=http://datatracker.ietf.org/wg/tls/|archivedate=2012-02-09}}
* Александр Венедюхин, [https://tls.dxdt.ru/tls.html Ключи, шифры, сообщения: как работает TLS] (Техническое описание TLS), 04/09/2015 
* [https://technet.microsoft.com/en-us/library/cc784450(v=ws.10).aspx What is TLS/SSL?: Logon and Authentication]{{ref-en}}
* [https://technet.microsoft.com/en-us/library/cc783349(v=ws.10).aspx How TLS/SSL Works: Logon and Authentication]{{ref-en}}

{{rq|wikify|source}}
{{IPstack}}
{{Механизмы безопасности в Интернете}}

[[Категория:Криптографические протоколы]]
[[Категория:Стандарты Интернета]]
[[Категория:Интернет-протоколы]]
[[Категория:Электронная коммерция]]
[[Категория:Протоколы прикладного уровня]]