Posted:
Янв 23, 2023
Comments:
0 Comments

Tls это: Что такое TLS / Хабр

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

Данный текст является вольным переводом вот этой главы замечательной книги «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 и показана на рисунке:

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

  1. Так как TLS работает над TCP, для начала между клиентом и сервером устанавливается TCP-соединение.

  2. После установки TCP, клиент посылает на сервер спецификацию в виде обычного текста (а именно версию протокола, которую он хочет использовать, поддерживаемые методы шифрования, etc).

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

  4. Версия протокола и способ шифрования на данном моменте считаются утверждёнными, клиент проверяет присланный сертификат и инициирует либо RSA, либо обмен ключами по Диффи-Хеллману, в зависимости от установленных параметров.

  5. Сервер обрабатывает присланное клиентом сообщение, сверяет MAC, и отправляет клиенту заключительное (‘Finished’) сообщение в зашифрованном виде.

  6. Клиент расшифровывает полученное сообщение, сверяет 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 соединения. Рассмотрим простейший процесс аутентификации между Алисой и Бобом:

  1. И Алиса, и Боб генерируют собственные открытые и закрытые ключи.

  2. Алиса и Боб обмениваются открытыми ключами.

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

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


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

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

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

В протоколе TLS данные цепи доверия основаны на сертификатах подлинности, предоставляемых специальными органами, называемыми центрами сертификации (CA – certificate authorities). Центры сертификации производят проверки и, если выданный сертификат скомпрометирован, то данный сертификат отзывается.

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

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

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

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

  • Центры сертификации должны справляться с нагрузкой в режиме реального времени;

  • Центры сертификации должны гарантировать свою доступность в любое время;

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


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

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

Протокол TLS | Microsoft Learn





Twitter




LinkedIn




Facebook




Адрес электронной почты










  • Статья


  • Чтение занимает 2 мин


Область применения: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows 10

В этом разделе для ИТ-специалистов описывается, как работает протокол TLS и приведены ссылки на RFC IETF для TLS 1. 0, TLS 1.1 и TLS 1.2.

Протоколы TLS (и SSL) находятся между уровнем протокола приложения и уровнем TCP/IP, где они могут защищать и отправлять данные приложения на транспортный уровень. Так как протоколы работают между уровнем приложения и транспортным уровнем, протоколы TLS и SSL могут поддерживать несколько протоколов прикладного уровня.

Tls и SSL предполагают, что используется транспорт, ориентированный на подключение, обычно TCP. Протокол позволяет клиентским и серверным приложениям обнаруживать следующие риски безопасности:

Протоколы TLS и SSL можно разделить на два уровня. Первый уровень состоит из протокола приложения и трех протоколов подтверждения: протокола подтверждения, протокола изменения спецификации шифра и протокола генерации оповещений. Второй уровень — протокол записи.

Уровни протокола TLS и SSL

Schannel SSP реализует протоколы TLS и SSL без изменений. Протокол SSL является частным, но целевая группа по интернет-инженерии создает общедоступные спецификации TLS. Сведения о том, какая версия TLS или SSL поддерживается в версиях Windows, см. в разделе «Протоколы» в tls/SSL (Schannel SSP). Каждая спецификация содержит следующие сведения:

  • Протокол записи TLS

  • Протокол подтверждения TLS: — изменение протокола спецификации шифра — протокол генерации оповещений

  • Криптографические вычисления

  • Обязательные комплекты шифров

  • Протокол данных приложения

RFC 5246 — версия 1.2 протокола TLS.

RFC 4346 — версия 1.1 протокола TLS;

RFC 2246 — версия 1.0 протокола TLS;

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

Представлено в Windows Server 2012 R2, Schannel SSP реализовал часть сеанса TLS на стороне сервера. Реализация RFC 5077 на стороне клиента добавлена в Windows 8.

Устройства, подключающие TLS к серверам, часто требуют переподключения. Возобновление сеанса TLS сокращает затраты на установку подключений TLS, так как возобновление включает сокращенное подтверждение TLS. Это упрощает дополнительные попытки возобновления, позволяя группе серверов TLS возобновлять сеансы TLS друг друга. Это изменение обеспечивает следующую экономию для любого клиента TLS, поддерживающего RFC 5077, включая Windows Phone и Windows RT устройства:

  • Сокращение использования ресурсов на сервере

  • Снижение пропускной способности, что повышает эффективность клиентских подключений

  • Сокращение времени, затраченного на подтверждение TLS из-за возобновления подключения

Сведения о возобновлении сеанса TLS без отслеживания состояния см. в документе IETF RFC 5077.

Согласование протокола приложения

Windows Server 2012 R2 и Windows 8.1 появилась поддержка, которая обеспечивает согласование протокола приложений TLS на стороне клиента. Приложения могут использовать протоколы в рамках стандартной разработки HTTP 2.0, а пользователи могут получать доступ к веб-службы, таким как Google и Twitter, с помощью приложений, использующих протокол SPDY.

Сведения о том, как работает согласование протокола приложений, см. в разделе Расширение согласования протокола прикладного уровня TLS.

Поддержка TLS для расширений указания имени сервера

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

Это обеспечивает следующие дополнительные функциональные возможности:

  • Позволяет размещать несколько веб-сайтов SSL в одном сочетании протоколов Интернета и портов.

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

  • Позволяет нескольким пользователям одновременно подключаться к веб-сайтам SSL






Что такое безопасность транспортного уровня (TLS)?

Безопасность на транспортном уровне более эффективна, чем его предшественник SSL, а его последняя версия — TLS 1.3 — повышает как конфиденциальность, так и производительность.

Зевс Керравала

Сетевой мир |

Thinkstock

Несмотря на цель сохранения конфиденциальности веб-коммуникаций, недостатки в разработке и реализации Transport Layer Security привели к нарушениям. Но последняя версия — TLS 1.3 — представляет собой капитальный ремонт, усиливающий и оптимизирующий криптопротокол.

Что такое TLS?

TLS — это криптографический протокол, который обеспечивает сквозную безопасность связи по сетям и широко используется для интернет-коммуникаций и онлайн-транзакций. Это стандарт IETF, предназначенный для предотвращения прослушивания, подделки и подделки сообщений. Общие приложения, использующие TLS, включают веб-браузеры, обмен мгновенными сообщениями, электронную почту и передачу голоса по IP.

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

Предшественник TLS, Secure Socket Layer (SSL), был разработан Netscape в 1995 году. Версия SSL 1.0 и 2.0 содержала множество недостатков безопасности, которые потребовали полной переработки протокола. В 1996 году Netscape выпустила SSL версии 3.0, которая стала основой для TLS1.0. В 1999 году Совет PCI предложил в конечном итоге прекратить поддержку SSL, поскольку TLS 1.0 был значительным обновлением SSL 3.0.

TLS по сравнению с SSL

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

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

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

Недостатки и нарушения TLS

Недостатки в протоколах и реализациях постоянно вызывают проблемы с инструментами и технологиями безопасности, и TLS, безусловно, имеет свою долю нарушений. Некоторые из наиболее значительных атак на TLS/SSL:

  • BEAST (2011): Эксплойт браузера против SSL/TLS — это эксплойт браузера, который воспользовался уязвимостью в цепочке блокировки шифрования (CBC) для извлечения незашифрованного открытого текста в зашифрованном сеансе.
  • CRIME and BREACH (2012 и 2013): Создатели BEAST разработали эксплойт безопасности Compression Ratio Info-link Made Easy, который позволяет хакеру извлекать содержимое веб-куки, даже если используются сжатие и TLS. Одним из гнусных вариантов использования этого является восстановление файлов cookie аутентификации, чтобы злоумышленники могли захватывать аутентифицированные веб-сеансы. Браузерная разведка и эксфильтрация с помощью адаптивного сжатия гипертекста, или BREACH, основана на CRIME и извлекает токены входа, адреса электронной почты и другую информацию.
  • Heartbleed (2014 г.): Heartbleed позволяет хакерам красть закрытые ключи с серверов, которые должны быть безопасными. Зараженные серверы были оставлены широко открытыми, чтобы любой в Интернете мог прочитать память в системах, защищенных уязвимой версией OpenSSL. Нарушение позволило злоумышленникам украсть данные с серверов или подслушать разговоры или даже подделать службы и других пользователей.

TLS 1.3 повышает безопасность, производительность и конфиденциальность

TLS 1.3 был первым крупным проектом, переработанным инженерной группой Интернета (IETF) для модернизации протокола. Думайте о предыдущих версиях как о пластырях, наложенных на дефектный код. Это может продержаться какое-то время, но в конце концов плохие парни придумали, как это обойти. Работа над TLS1.3 началась в апреле 2014 г., и потребовалось четыре года и 28 черновиков, прежде чем он был одобрен в марте 2018 г.

В дополнение к серьезному пересмотру IETF намеревалась внести то, что она назвала «значительными улучшениями в области безопасности, производительности и конфиденциальности». Самое большое изменение заключается в том, что TLS 1.3 значительно усложняет злоумышленникам расшифровку зашифрованного HTTPS-трафика и, следовательно, лучше защищает конфиденциальность.

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

Внедрение TLS 1.3 должно быть простым, поскольку он предназначен для плавной замены TLS 1.2 и использует те же сертификаты и ключи. Кроме того, клиенты и серверы могут автоматически согласовывать соединение, если оно поддерживается обеими сторонами.

В начале цикла разработки было несколько проблем, наиболее заметные из которых выявились в школьной системе в Мэриленде, где около 20 000 Chromebook перестали работать после обновления до TLS 1.3. Кроме того, финансовые организации были категорически против, потому что шифрование делало их слепыми к тому, что происходило в их собственных сетях. IETF внесла несколько улучшений, чтобы протокол мог работать с инструментами мониторинга, если он реализован правильно.

Помимо улучшений безопасности, TLS 1.3 устранил ряд старых алгоритмов, которые не делали ничего, кроме создания уязвимостей. К ним относятся:

  • RC4 Паровой шифр
  • ДЕС
  • 3DES
  • Транспортировка ключей RSA
  • SHA-1 хеширование
  • Шифры режима CBC
  • МД5
  • Группы Диффи-Хеллмана
  • ЭКСПОРТ шифров

Кроме того, в обновленный протокол добавлена ​​функция «возобновление 0-RTT», которая позволяет клиенту и серверу помнить, обменивались ли они данными ранее. Если существует предыдущая связь, можно использовать предыдущие ключи, проверки безопасности пропускаются, и клиент и сервер могут начать обмен данными немедленно. Считается, что некоторые из крупных технологических компаний настаивали на 0-RTT, потому что они выигрывают от более быстрых соединений, но специалисты по безопасности обеспокоены этим.

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

Связанный:

  • Сеть
  • Центр обработки данных
  • Безопасность

Зевс Керравала — основатель и главный аналитик ZK Research.

Copyright © 2018 IDG Communications, Inc.

10 самых влиятельных компаний в области корпоративных сетей 2022 г.

Что такое TLS? Определение и подробности

Объяснение ИТ:

Вернуться к оглавлению

Содержание

1. Что такое TLS?

2. История и версия

3. Функциональность TLS

4. Где используется?

5. Для чего он используется?

6. Как это работает?

7. Преимущества TLS 1.3

8. Недостатки TLS

9. Источники

 

Что такое TLS?

 

 

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

TLS обеспечивает безопасность передачи и доставки данных. Он не защищает данные на конечных точках и не шифрует данные. Это протокол безопасности для соединений HTTPS, а не для небезопасных соединений HTTP.

История и версии

 

TLS является преемником протокола Secure Sockets Layer (SSL). Netscape изначально разработала SSL в 1994 году для защиты своего браузера Netscape Navigator. Последней версией SSL был SSL 3.0. Первая версия TLS, выпущенная в 1999, основан на SSL 3.0.

Термины SSL и TLS часто используются взаимозаменяемо. Это связано с тем, что первая версия TLS, 1.0, изначально разрабатывалась как SSL версии 3.1. Это означает, что, если специально не указано иное, то, что сегодня продается как SSL-сертификат, обычно использует протокол TLS. Термин SSL все еще используется, потому что люди более знакомы с ним. Термин SSL/TLS часто используется для описания протокола.

Последней версией TLS является TLS 1.3, опубликованная в 2018 году Инженерной группой Интернета (IETF). IETF — международная организация по стандартизации, которой изначально было поручено организовать разработку нового протокола.

SSL 3.0 официально объявлен устаревшим в 2015 году. Однако TLS обеспечивает обратную совместимость для некоторых старых устройств, использующих SSL.

Apple, Microsoft и Google прекратят поддержку TLS 1.0 и TLS 1.1 в 2020 году. Отчасти это связано с тем, что в этих версиях TLS используются устаревшие технологии, включая такие алгоритмы, как SHA-1 и MD5. Первоначально веб-сайты, использующие старые версии TLS, будут отображать сообщение об ошибке. В конце концов, любой доступ к веб-сайтам, использующим устаревшие версии TLS, будет заблокирован.

Большинство современных веб-приложений используют TLS 1.2. Ожидается, что внедрение TLS 1.3 потребует времени. По оценкам Google, менее одного процента веб-сайтов используют TLS 1.0 или 1.1. Существуют обходные пути, например расширение LS_FALLBACK_SCSV, для устаревших приложений, несовместимых с технологией TLS.

 

Функциональность TLS

 

 

TLS имеет три основные функции и одну фактическую функциональность:

  • Шифрование — скрывает данные, передаваемые между двумя сторонами, сервером и веб-приложением. Это предотвращает подслушивание.
  • Аутентификация — удостоверяет личность двух сторон, общающихся через Интернет. Это предотвращает атаки олицетворения.
  • Целостность — проверяет, что данные, отправляемые по сети, не были подделаны в пути. Это предотвращает атаки типа «человек посередине». Целостность обеспечивается с помощью сертификата, выданного доверенным центром сертификации (ЦС).
  • Предотвращение повторного воспроизведения — защищает от атак грубой силы и атак типа «человек посередине».

 

Где используется?

 

 

TLS используется, например, для защиты протоколов прикладного уровня, таких как FTP, HTTP и SMTP. Эти протоколы обеспечивают большинство функций, используемых для общения в Интернете, таких как отправка электронной почты, общение в чате или загрузка данных.

TLS обеспечивает аутентификацию цифровых удостоверений. Типичные варианты корпоративного использования включают единый вход (SSO), проверку устройств в сети IoT, документы с цифровой подписью, шифрование электронной почты для защиты конфиденциальной бизнес-информации и аутентификацию доступа к сети.

 

Почему он используется?

 

 

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

Google Chrome недавно начал предупреждать пользователей, обращающихся к HTTP-страницам, о том, что эти страницы небезопасны. Для предприятий опасение заключается в том, что это может привести к снижению доверия клиентов. Поэтому Google, Apple и Microsoft рекомендуют использовать как минимум TLS 1.2.

TLS 1.0 и 1.1 уязвимы для атак CRIME, BEAST, FREAK, LogJam и POODLE, но TLS 1.2 и TLS 1.3 обеспечивают усиленную защиту при передаче данных. Кроме того, для соответствия стандарту безопасности данных индустрии платежных карт (PCI-DSS) требуется как минимум TLS 1.2.

TLS 1.2 и 1.3 поддерживают новейшие наборы шифров и алгоритмы и удаляют небезопасные хэш-функции, например SHA-1 и MD5.

 

Как это работает?

 

 

Квитирование TLS инициирует сеанс TLS. Это не само событие безопасного сеанса. Рукопожатие TLS не шифрует данные, но определяет метод шифрования. Шифрование данных происходит в сеансе с использованием общего секрета, сгенерированного во время рукопожатия TLS.

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

Рукопожатие использует асимметричное шифрование для установления соединения. Этот метод шифрования имеет некоторые накладные расходы с точки зрения ресурсов. Открытый ключ используется для шифрования, а закрытый ключ используется для расшифровки. В TLS пара ключей используется для создания общего ключа, иногда называемого общим секретом, предварительным главным ключом или главным ключом. После успешного завершения рукопожатия сеанс использует общий ключ или сеансовый ключ для шифрования данных в дальнейших сообщениях между клиентом и сервером. Затем сеанс использует симметричное шифрование. Это имеет гораздо меньшие накладные расходы, чем асимметричное шифрование, и является более эффективным.

An SSL/TLS handshake consists of the following messages and steps: ClientHello , ServerHello , Certificate (optional), ServerKeyExchange , ServerHelloDone , ClientKeyExchange , ChangeCipherSpec , ChangeCipherSpec , и Готово . До TLS 1.3 рукопожатие выглядело следующим образом.

 

  1. Клиент отправляет на сервер список всех доступных версий TLS. Предпочтительной версией является последняя версия. Клиент также отправляет список предлагаемых наборов шифров. Клиент генерирует случайное число, которое используется позже. Клиент также проверяет, не возобновляется ли сеанс.
  2. Сервер подтверждает, какие параметры приемлемы для соединения. Он также генерирует случайное число, которое используется позже.
  3. Сервер отправляет подписанный цифровой сертификат для проверки подлинности клиенту. Его открытый ключ встроен в сертификат. При создании TLS-соединения клиент проверяет наличие действительного сертификата, подписанного доверенным центром сертификации. Самоподписанный или недействительный сертификат вызовет предупреждающее сообщение.
  4. Сервер отправляет сообщение о завершении.
  5. Клиент создает предварительный мастер-ключ и отправляет его на сервер. Пре-мастер шифруется открытым ключом сервера. Этот ключ извлекается из сертификата, ранее предоставленного сервером. Поскольку это асимметричное шифрование, расшифровать сообщение может только сервер. После того, как сервер получил предварительный мастер-ключ, он использует свой закрытый ключ для его расшифровки. Этот процесс подтверждает, что обе стороны являются теми, за кого себя выдают. После того, как сервер получил предварительный мастер-ключ, и сервер , и клиент вычисляют мастер-ключ, используя ранее сгенерированные случайные числа и предварительный мастер-ключ.
  6. Клиент отправляет вычисленный главный ключ на сервер. Клиент соглашается использовать главный ключ с этого момента. Он изменяет метод шифрования на симметричный.
  7. Клиент отправляет сообщение о завершении.
  8. Сервер проверяет, совпадает ли вычисленный главный ключ с ключом клиента. Сервер соглашается использовать главный ключ с этого момента. Он изменяет метод шифрования на симметричный.
  9. Последнее сообщение Finished с сервера — это первое зашифрованное сообщение, передаваемое с использованием общего секрета. Общий секрет, который является сеансовым ключом, также используется в алгоритме кода аутентификации сообщений (MAC) для проверки того, что сообщение не было изменено.

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

 

Преимущества TLS 1.3

 

 

 

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

TLS 1.3 прекратил поддержку некоторых устаревших алгоритмов и шифров, таких как алгоритм DES, шифр RC4, хеширование SHA-1, шифр CBC, алгоритм MD5, обмен ключами RSA и некоторые (но не все) методы шифрования Диффи-Хеллмана. TLS 1.2 поддерживает 37 наборов шифров. TLS 1.3 поддерживает только пять наборов шифров.

Традиционно одним из самых популярных способов обмена безопасными сеансовыми ключами был алгоритм шифрования RSA. RSA был несколько дискредитирован, потому что он не обеспечивает эфемерный (временный или специфичный для сеанса) ключевой режим, что требуется для Perfect Forward Secrecy (PFS). PFS гарантирует, что если злоумышленник сохранит зашифрованную информацию и каким-то образом украдет связанный закрытый ключ, он все равно не сможет расшифровать информацию.

Четыре новые функции в TLS 1.3 помогают ускорить рукопожатие TLS. Возобновление сеанса TLS проверяет, обменивались ли сервер и клиент ранее, и если да, то некоторые проверки безопасности пропускаются. TLS False Start позволяет серверу и клиенту начать передачу данных до завершения рукопожатия TLS. Рукопожатие TLS 1.3 требует только одного кругового пути вместо двух, используемых в TLS 1.2. В TLS 1.2 и более ранних версиях первая поездка туда и обратно включает этапы встречи и приветствия. Второй круговой маршрут включает в себя обмен ключами и смену типа шифрования с асимметричного на симметричный. И, наконец, возобновление с нулевым временем приема-передачи (0-RTT) позволяет генерировать главный ключ возобновления.

 

Недостатки TLS

 

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

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

TLS может ошибочно принять брандмауэр за атаку «человек посередине». Разработанный для обеспечения комплексного сквозного шифрования и безопасности, TLS не позволяет средствам сетевой безопасности проверять трафик для обнаружения потенциальных вредоносных программ. Чтобы предотвратить атаку «человек посередине», клиент не может проверить свои собственные данные и убедиться, что они не содержат вредоносных программ. Средство для выполнения этой проверки — через промежуточный блок, но промежуточный блок может быть ошибочно идентифицирован TLS как человек посередине и иногда может препятствовать законному доступу к серверу. Финансовая индустрия лоббировала изменения в том, как работают посредники.

TLS также уязвим для атак с понижением версии. RSA — это алгоритм обмена ключами, используемый всеми версиями TLS, кроме версии 1. 3. RSA определяет, как клиент и сервер будут аутентифицировать свои учетные данные во время рукопожатия TLS с целью согласования общего секрета. Однако RSA уязвим для атак по сторонним каналам. Эти виды атак являются косвенными и непреднамеренными. Обычно они являются результатом неправильной реализации криптографической системы, которая непреднамеренно допускает утечку информации, которую злоумышленник может использовать для обнаружения закрытого ключа для разговора. Это можно сравнить с вором, которому противостоит охранная система вашего автомобиля. Вместо того, чтобы пытаться проникнуть в машину на месте, где вас предупредит сигнализация, вор просто загружает автомобиль на бортовой грузовик, отвозит его в другое место и проникает туда.

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

  • https://www.wst.space/ssl-part1-ciphersuite-hashing-encryption/
  • https://www.

    This entry was posted in Популярное