Tls версии: Как работает TLS, в технических подробностях

alexxlab

Содержание

Что такое 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 c ГОСТ

Протокол TLS: Краткая справка

Протокол TLS (Transport Layer Security) является одним из наиболее популярных протоколов, предназначенных для установления защищенного канала связи в сети Интернет. Он основан на спецификации протокола SSL (Secure Sockets Layer) версии 3.0, но за время своего существования претерпел довольно много изменений. Самой актуальной версией протокола на текущий момент является недавно вышедшая версия TLS 1.3, однако версия TLS 1.2 все еще остается наиболее распространенной.

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

Что такое TLS с ГОСТ?

В процессе работы над задачей разработки протокола TLS с поддержкой российских криптонаборов при активном участии специалистов КриптоПро было создано два ключевых документа, регламентирующих порядок работы протоколов TLS 1.2 и TLS 1.3 с ГОСТ Р 34.12-2015 (с использованием алгоритмов Магма и Кузнечик) – рекомендации по стандартизации Р 1323565.1.020-2018 для TLS 1.2 и рекомендации по стандартизации Р 1323565.1.030-2020 для TLS 1.3. Документы определяют криптонаборы с российскими алгоритмами хэширования, шифрования и электронной подписи с учетом наиболее современных и безопасных практик использования криптоалгоритмов. Для регламентации работы протокола с использованием криптонаборов на базе ГОСТ 28147-89 ранее были разработаны методические рекомендации МР 26.2.001-2013. Отметим, что сами российские алгоритмы стандартизируются в международных организациях ISO и IETF, проходя экспертизу ведущих мировых специалистов.

Подробнее о TLS c ГОСТ и поддерживаемых КриптоПро CSP криптонаборах 

Процесс стандартизации TLS с российскими криптонаборами также активно идет и в рамках международных организаций IETF и IANA. Так, организация IANA, управляющая идентификаторами и параметрами протоколов сети Интернет, в том числе благодаря усилиям специалистов нашей компании, впервые зарегистрировала в своем реестре российские криптонаборы и другие сопутствующие параметры для протокола TLS 1.2, а затем и TLS 1.3. Это крайне важное событие, которое имеет непосредственное отношение к стабильности работы протокола TLS с ГОСТ, ведь без наличия международно признаваемых идентификаторов все предыдущие годы существовала опасность блокировки TLS с ГОСТ из-за захвата номеров сторонними криптонаборами, а внесение поддержки российских криптонаборов в свободное ПО было затруднено.

КриптоПро CSP и TLS с ГОСТ

Ниже приведен список поддерживаемых различными версиями нашего криптопровайдера КриптоПро CSP криптонаборов и соответствующих регламентирующих документов. Отдельно отметим, что с версии 5.0 R3 планируется реализация поддержки криптонаборов в соответствии с рекомендациями Р 1323565.1.030-2020 для обеспечения поддержки протокола TLS версии 1.3 с использованием отечественной криптографии.

Версия TLS

Поддерживаемые криптонаборы

Версия CSP

Регламентирующие документы

1.0

28147_CNT_IMIT (0xFF,0x85)

любая поддерживаемая

МР 26.2.001-2013

1.1

28147_CNT_IMIT (0xFF,0x85)

любая поддерживаемая

МР 26.2.001-2013

1.2

28147_CNT_IMIT (0xFF,0x85)

любая поддерживаемая

МР 26.2.001-2013

28147_CNT_IMIT (0xC1,0x02)

5.0 R2 и выше

Р 1323565.1.020-2018

draft-smyshlyaev-tls12-gost-suites

KUZNYECHIK_CTR_OMAC (0xC1,0x00)

MAGMA_CTR_OMAC (0xC1,0x01)

1.3

KUZNYECHIK_MGM_L (0xC1,0x03)

Планируется с 5.0 R3

Р 1323565.1.030-2020

draft-smyshlyaev-tls13-gost-suites

MAGMA_MGM_L (0xC1,0x04)

KUZNYECHIK_MGM_S (0xC1,0x05)

MAGMA_MGM_S (0xC1,0x06)

Криптонаборы с номерами (0xC1, 0x00) – (0xC1, 0x06) являются наборами, зарегистрированными в реестре организации IANA.

Внедрить TLS c ГОСТ? Легко!

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

Также на данной странице представлена информацию об услугах нашего удостоверяющего центра CryptoPro TLS-CA по выдаче сертификатов TLS →

Клиент-серверные решения

TLS-сервер с ГОСТ

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

  1. Если вам необходимо настроить работу для конкретного серверного ПО (IIS, Apache, nginx), вы можете на компьютере с указанным серверным ПО установить КриптоПро CSP и, следуя соответствующим инструкциям по настройке, получить TLS-сервер, дополнительно поддерживающий алгоритмы ГОСТ.
  2. Вы также можете воспользоваться решением КриптоПро NGate, представляющим собой самостоятельный TLS-шлюз (отдельная аппаратная или виртуальная платформа). Решение имеет большое количество преимуществ, одним из которых является удобство обеспечения классов защиты KC2-KC3: в отличие от предыдущего подхода, не требуется выполнение отдельных настроек, приобретение и конфигурирование электронных замков и прочих дополнительных мер защиты, все необходимое уже включено в аппаратные компоненты решения.

Ниже представлена сравнительная таблица характеристик каждого предлагаемого решения. В колонке “Cертификация” приведена информация о статусе сертификации решения: как самостоятельное СКЗИ или как решение, исследование которого было проведено в рамках сертификации КриптоПро CSP. Во втором случае указана соответствующая версия криптопровайдера.

Решение

Платформа

Сертификация

Класс защиты

CSP + IIS

Windows

любая поддерживаемая версия CSP

КС1, КС2*, КС3*

CSP + Apache

Linux

начиная с
CSP 5.0 R2

КС1, КС2*, КС3**

CSP + nginx

Linux

начиная с
CSP 5.0 R2

КС1, КС2*, КС3**

NGate

Усиленная ОС на базе Linux Debian

самостоятельное СКЗИ

КС1, КС2, КС3

 * – требуются дополнительные настройки и технические средства защиты
 ** – КС3 только под Astra Linux

TLS-клиент с ГОСТ

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

Решения для стационарных устройств 

Одним из популярных клиентских сценариев является взаимодействие клиента с сайтом, требующим защиту соединения с помощью отечественных алгоритмов (например, сайты банков). В этом случае необходимо, чтобы клиент со своей стороны, так же как и сервер, поддерживал работу по TLS с ГОСТ. Наиболее удобным решением является использование на стороне клиента криптопровайдера КриптоПро CSP совместно с одним из поддерживаемых браузеров.

Кратко о решении:

  • На стороне клиента устанавливается КриптоПро CSP и один из поддерживаемых браузеров
  • Решение не требует никакой дополнительной разработки
  • Такое использование бесплатно для клиента (если с его стороны нет аутентификации по ключу и сертификату).

Ниже представлена сравнительная таблица характеристик поддерживаемых браузеров. Прочерк в колонке «Cертификация» означает необходимость проведения тематических исследований.

Браузер

Платформа

Сертификация

Класс защиты

Internet Explorer

Windows

любая поддерживаемая версия CSP

КС1, КС2*, КС3*

Спутник Браузер

Windows, Astra Linux, ALT Linux

самостоятельное СКЗИ

КС1, КС2*

Chromium-Gost

Astra Linux

начиная с CSP 5.0 R2

КС1, КС2*, КС3*

Windows, Linux, MacOS

–

–

Яндекс.Браузер

Windows

–

–

 * – требуются дополнительные настройки и технические средства защиты

Решения для мобильных устройств

КриптоПро предоставляет возможность встраивания поддержки отечественных криптоалгоритмов в ваше мобильное приложение при помощи КриптоПро CSP для операционных систем iOS и Android.

Кратко о решении:

  • CSP встраивается в мобильное приложение, пользователю не требуется устанавливать дополнительное ПО
  • Приложение может использовать как российские, так и иностранные криптонаборы

Ниже представлен список поддерживаемых операционных систем и соответствующих классов защиты:

Операционная система

Сертификация

Класс защиты

iOS

любая поддерживаемая версия CSP

КС1

Android

начиная с CSP 5.0

КС1

В случае использования КриптоПро CSP версии 5.0 R2 встраивание не требует проведения тематических исследований. Для CSP 5.0 и более ранних версий требуются тематические исследования.

Другие решения

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

Приложение stunnel, входящее в дистрибутив КриптоПро CSP, позволяет устанавливать защищенный с помощью отечественных криптонаборов канал между любыми двумя незащищенными приложениями без дополнительной разработки.

Ниже представлен список наиболее популярных поддерживаемых операционных систем и соответствующих классов защиты:

Операционная система

Сертификация

Класс защиты

Windows

любая поддерживаемая версия CSP

КС1, КС2*, КС3*

Linux

КС1, КС2*, КС3**

MacOS

КС1

 * – требуются дополнительные настройки и технические средства защиты
 ** – КС3 только под Astra Linux

Как настроить доверие к сертификату?

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

Подробнее о том, что такое сертификат в TLS

Для того, чтобы механизм аутентификации функционировал корректно, необходимо, чтобы аутентифицирующая сторона могла убедиться, что информация, содержащаяся в переданном сертификате, является корректной и не была сформирована злоумышленником. Фактически, нам необходимо решить проблему доверия к открытым ключам. Это делается за счет наличия третьей стороны, которой доверяют все стороны информационного обмена – Удостоверяющего Центра (УЦ), выдающего сертификаты.

Строго говоря, когда мы говорим о передаче сертификата, мы имеем в виду передачу целой цепочки сертификатов («цепочку доверия»), где каждый сертификат подписывается закрытым ключом, соответствующим тому сертификату, который находятся выше в иерархии.

 

 

Если мы хотим проверить полученный сертификат, нам необходимо проверить подписи всех сертификатов в цепочке, опираясь на ключ проверки подписи из следующего по рангу сертификата. Следуя такому принципу, рано или поздно мы встретим сертификат, на котором цепочка заканчивается (т.е. сертификат, для которого нет сертификата с открытым ключом, который можно было бы использовать для проверки подписи). Такие сертификаты называются корневыми (root certificate). Корневые сертификаты устанавливаются доверенным образом, и в них указана информация, ассоциированная с доверенным УЦ.

В протоколе TLS предусмотрена возможность аутентификации и сервера, и клиента (двухсторонняя аутентификация), однако обязательной является только аутентификация сервера. Наиболее распространенным сценарием использования протокола является взаимодействие браузера с сайтом, в рамках которого обычно необходима только односторонняя аутентификация. Поэтому далее мы поговорим о том, как правильно и безопасно настроить доверие к сертификату сервера в рамках работы TLS c ГОСТ.

При работе по протоколу TLS с ГОСТ клиент может доверять сертификату, если его корневым сертификатом является либо сертификат головного удостоверяющего центра Минцифры России (сертификат ГУЦ), либо сертификат любого доверенного удостоверяющего центра (сертификат TLS-CA). Сертификаты, имеющие в качестве корневого сертификат ГУЦ, выдаются только аккредитованными удостоверяющими центрами по 63—ФЗ «Об электронной подписи». Отметим, что сертификат, использующийся для аутентификации сервера по протоколу TLS, не обязан быть полученным в аккредитованном удостоверяющем центре, достаточно, чтобы сертификат был выдан доверенным в рамках системы удостоверяющим центром.

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

Настроить в браузере доверие к сертификату сервера можно одним из следующих способов:

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

При установке КриптоПро CSP версии 4.0 R3 и выше для работы браузера по ГОСТ сертификат ГУЦ и сертификат удостоверяющего центра CryptoPro TLS-CA добавятся в список доверенных автоматически. Таким образом, доверие распространится на любой сертификат, выданный аккредитованным УЦ или CryptoPro TLS-CA, причем после прохождения полноценной проверки, не требующей принятия решений от человека.

Тестирование двустороннего ГОСТ TLS

КриптоПро TLS входит в состав КриптоПро CSP на всех ОС и не требует отдельной установки.

Для использования протокола TLS предварительно получите сертификат по шаблону «Сертификат пользователя УЦ». Это можно сделать на тестовом Удостоверяющем центре КриптоПро.

Тестовая страница для установления защищенного соединения с сервером с двусторонней аутентификацией. Для работы тестовой страницы необходимо разрешить порт 4444 для исходящих соединений.

Дополнительные стенды для тестирования TLS.

Документация

Онлайн-версия руководства программиста доступна на нашем сайте.

Защита сайта по протоколу TLS

TLS (Transport Layer Security) представляет собой стандартный протокол, который используется в целях создания защищенных онлайн-соединений или во внутренних сетях предприятий. Он дает возможность клиентам проводить проверку подлинности серверов. Серверы же с его помощью выполняют проверку подлинности клиентов (когда это важно). Протокол TLS также позволяет создать защищенный канал с помощью кодирования всех передаваемых данных. Принципы работы TLS напоминают SSL, что неудивительно — протокол TLS является более поздней версией протокола SSL (SSL 3.0). Иногда протокол TLS называют «SSL 3.1».

Различия между SSL 3.0 и TLS являются очень тонкими и по большей части техническими; стоит отметить, что TLS является более свежим и более отлаженным протоколом. Безопасность текущей версии SSL — 3.0 — сопоставима с безопасностью TLS 1.0, однако версии TLS 1.1 и 1.2 значительно обходят ее в этом вопросе.

Протокол TLS может применяться для защиты соединений почти по всем популярным интернет-протоколам. К примеру, протокол https — это интернет-соединение по http, которое защищено по протоколу TLS. Также по протоколу TLS могут защищаться соединения по FTP, IMAP, POP3 и SMTP и т.д.

Протокол TLS реализуют динамические библиотеки для кодирования. Если взять в качестве примера Windows, то в этой системе данный протокол может быть реализован при помощи Microsoft CryptoAPI. Помимо всего прочего, существует ряд OpenSource-библиотек, которые позволяют реализовать протокол TLS. Среди них особо выделяются библиотеки OpenSSL и GNU TLS. Самой популярной является библиотека OpenSSL, которая входит в большинство сегодняшних операционных систем.

TLS-соединение

Что представляет собой типичная сессия TLS-соединения? Такая сессия состоит из следующих шагов:

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

Как получить TLS сертификат

Чтобы сервер был аутентифицирован, ему нужно иметь сертификат и соответствующий ему закрытый ключ.

Администратор сервера может получить сертификат при помощи выполнения данных шагов:

  1. Воспользовавшись командой openssl req, сформировать заявку на сертификат и соответствующий закрытый ключ;
  2. Отправить сформированную заявку в удостоверяющий центр.

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

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

В том случае, если сервер имеет несколько хостов, аутентификация успешно завершается только тогда, когда предъявленный сервером сертификат отвечает именно тому имени сервера, которое клиент указывал для установления соединения.

Для защиты сайта по протоколу TLS используются SSL-сертификаты. Если вы хотите приобрести сертификат для создания TLS соединения, вы всегда можете обратиться для этого к компании ЛидерТелеком.


Обновление для того, чтобы включить протоколы TLS 1.1 и TLS 1.2 в качестве безопасных протоколов по умолчанию в WinHTTP в Windows

Это обновление поддерживает TLS 1.1 и TLS 1.2 в Windows Server 2012, Windows 7 Пакет обновления 1 (SP1) и Windows Server 2008 R2 SP1.

Об этом обновлении

Приложения и службы, написанные с помощью подключений WinHTTP для SSL, которые используют флаг WINHTTP_OPTION_SECURE_PROTOCOLS, не могут использовать протоколы TLS 1.1 или TLS 1.2. Это значит, что определение этого флага не включает эти приложения и службы.

Это обновление добавляет поддержку записи реестра DefaultSecureProtocols, с которой системный администратор может указать, какие протоколы SSL следует использовать WINHTTP_OPTION_SECURE_PROTOCOLS флажком.

Это позволяет некоторым приложениям, которые были встроены для использования флага WinHTTP по умолчанию, использовать новые протоколы TLS 1.2 или TLS 1.1 без необходимости обновления приложения.

Это касается некоторых Microsoft Office приложений, которые открывают документы из библиотеки SharePoint или веб-папки, туннель IP-HTTPS для подключения DirectAccess и другие приложения с помощью таких технологий, как WebClient, с помощью WebDav, WinRM и других приложений.

Для этого обновления необходимо настроить компонент Secure Channel (Schannel) в Windows 7 для поддержки TLS 1.1 и 1.2. Так как эти версии протоколов не включены по умолчанию в Windows 7, необходимо настроить параметры реестра, чтобы приложения Office могли работать с TLS 1.1 и 1.2.

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

Как получить это обновление

Важно!Если после установки обновления вы установили языковой пакет, необходимо переустановить это обновление. Поэтому мы рекомендуем установить все необходимые языковые пакеты перед установкой обновления. Дополнительные сведения см. в теме «Добавление языковых пакетов в Windows».

Способ 1. Обновление Windows

Это обновление предоставляется в качестве рекомендуемых обновлений для Windows. Дополнительные сведения о запуске Обновления Windows см. в сведениях о том, как получить обновление через Windows Update.

Способ 2. Каталог обновлений Майкрософт

Чтобы получить автономный пакет для этого обновления, перейдите на веб-сайт каталога обновлений Майкрософт.

Обновление подробных сведений

Предварительные условия

Чтобы применить это обновление, необходимо установить Пакет обновления 1 для Windows 7 или Windows Server 2008 R2.

Нет предварительных условий для применения этого обновления в Windows Server 2012.

Сведения о внесении изменений в реестр

Чтобы применить это обновление, необходимо добавить подкод DefaultSecureProtocols реестра.
Примечание Для этого можно добавить подкайку реестра вручную или установить «Простое исправление», чтобы заполнить его.

Требование перезагрузки

После установки этого обновления может потребоваться перезагрузить компьютер.

Сведения о замене обновлений

Это обновление не заменяет ранее выпущенное обновление.

Дополнительная информация

Для соответствия требованиям в отрасли платежных карт требуется TLS 1.1 или TLS 1.2.

Дополнительные сведения о флаге WINHTTP_OPTION_SECURE_PROTOCOLS см. в параметрах флажков.

Как работает запись реестра DefaultSecureProtocols

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

Когда приложение указывает WINHTTP_OPTION_SECURE_PROTOCOLS, система проверяет запись defaultSecureProtocols и, если есть, переопределяет протоколы по умолчанию, указанные приложением WINHTTP_OPTION_SECURE_PROTOCOLS, с протоколами, указанными в записи реестра. Если запись реестра не существует, winHTTP будет использовать существующие значения по умолчанию для Win WINHTTP_OPTION_SECURE_PROTOCOLS HTTP. Эти значения WinHTTP по умолчанию следуют за существующими правилами приоритета и имеют приоритет, за которые SCHANNEL отключил протоколы и протоколы, установленные для каждого приложения winHttpSetOption.

Примечание.Установщик hotfix не добавляет значение DefaultSecureProtocols. Администратор должен вручную добавить запись после определения протоколов переопределения. Вы также можете установить легкое исправление, чтобы автоматически добавить запись.

Запись реестра DefaultSecureProtocols можно добавить следующим образом:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp

На компьютерах с оси x64 к пути Wow6432Node также необходимо добавить defaultSecureProtocols:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp

Значением реестра является точная карта DWORD. Используемая величина определяется добавлением значений, соответствующих нужным протоколам.

Значение DefaultSecureProtocols

Протокол включен

0x00000008

Включить SSL 2.0 по умолчанию

0x00000020

Включить SSL 3.0 по умолчанию

0x00000080

Включить TLS 1.0 по умолчанию

0x00000200

Включить TLS 1.1 по умолчанию

0x00000800

Включить TLS 1.2 по умолчанию

Пример:

Администратор хочет переопрепреировать значения по умолчанию для WINHTTP_OPTION_SECURE_PROTOCOLS TLS 1.1 и TLS 1.2.

Возьмите значение TLS 1.1 (0x00000200) и значение TLS 1.2 (0x00000800), а затем сложить их на калькуляторе (в режиме программиста), и в результате в реестре будет 0x00000A00.

Простое исправление

Чтобы автоматически добавить подкаблику DefaultSecureProtocols реестра, щелкните здесь. В диалоговом окне Скачивание файла нажмите кнопку Выполнить или Открыть и следуйте инструкциям мастера простого исправления Easy Fix.

Примечания.

  • Мастер может быть доступен только на английском языке. При этом автоматическое исправление подходит для любых языковых версий Windows.

  • Если проблема не на компьютере, сохраните решение простого исправления на флэш-накопителе или компакт-диске, а затем запустите его на том компьютере, где возникла проблема.

Примечание.Помимо подкаблицы DefaultSecureProtocols реестра, в исправлении Easy Fix также добавляются secureProtocols в следующем расположении, чтобы помочь включить TLS 1.1 и 1.2 для Internet Explorer.

Запись реестра SecureProtocols со значением, 0xA80 для включения TLS 1.1 и 1.2, будет добавлена по следующим путям:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings

Включить TLS 1.1 и 1.2 в Windows 7 на уровне компонента SChannel

Согласно статье «Параметры TLS-SSL»,чтобы включить tLS 1.1 и 1.2 в Windows 7 и заключить соглашение о нем, необходимо создать запись DisabledByDefault в соответствующем подкайке (клиент) и установить для него 0. Эти подгруппы не будут созданы в реестре, так как по умолчанию эти протоколы отключены.

Создайте необходимые подмени для TLS 1.1 и 1.2; создайте значения DWORD disabledByDefault и установите для него значение 0 в следующих расположениях:

Для TLS 1.1

Расположение реестра: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client
Имя DWORD: DisabledByDefault
Значение DWORD: 0

Для TLS 1.2

Расположение реестра: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client
Имя DWORD: DisabledByDefault
Значение DWORD: 0

Сведения о файле

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

Windows 7 и Windows Server 2008 R2

Примечания.

  • Файлы, которые относятся к определенному продукту, вехе (RTM, SPn)и ветви обслуживания (LDR, GDR), можно определить, изучив номера версий файлов, как показано в таблице ниже.

    Версия

    Продукт

    Этап разработки

    Направление поддержки

    6.1.760 1.23 xxx

    Windows 7 или Windows Server 2008 R2

    SP1

    LDR

  • В выпусках обновлений для общего распространения (GDR) содержатся только общедоступные исправления, которые предназначены для устранения распространенных критических проблем. В выпусках обновлений LDR помимо общедоступных содержатся дополнительные исправления.

  • Файлы МАНИФЕСТА (МАНИФЕСТ) и ФАЙЛЫ, установленные в соответствии с данными, которые устанавливаются для каждой среды, перечислены в разделе «Дополнительные сведения о файле». ЧТОБЫ поддерживать состояние обновленных компонентов, очень важно иметь такие данные, как ПОСЛЕНВ, МАНИФЕСТ и связанные с ним файлы каталога безопасности (CAT). Файлы каталога безопасности, атрибуты для которых не указаны, подписаны цифровой подписью Майкрософт.

x86 Windows 7

Имя файла

Версия файла

Размер

дата

Время

Платформа

Webio.dll

6.1.7601.23375

316,416

09-мар-2016

18:40

x86

Winhttp.dll

6.1.7601.23375

351,744

09-мар-2016

18:40

x86


ia64 Windows Server 2008 R2

Имя файла

Версия файла

Размер

дата

Время

Платформа

Webio.dll

6.1.7601.23375

695,808

09-мар-2016

17:57

IA-64

Winhttp.dll

6.1.7601.23375

811,520

09-мар-2016

17:57

IA-64

Webio.dll

6.1.7601.23375

316,416

09-мар-2016

18:40

x86

Winhttp.dll

6.1.7601.23375

351,744

09-мар-2016

18:40

x86


x64 Windows 7 и Windows Server 2008 R2

Имя файла

Версия файла

Размер

дата

Время

Платформа

Webio.dll

6.1.7601.23375

396,800

09-мар-2016

19:00

x64

Winhttp.dll

6.1.7601.23375

444,416

09-мар-2016

19:00

x64

Webio.dll

6.1.7601.23375

316,416

09-мар-2016

18:40

x86

Winhttp.dll

6.1.7601.23375

351,744

09-мар-2016

18:40

x86

Windows Server 2012

Примечания.

  • Файлы, которые относятся к определенному продукту, вехе (RTM, SPn)и ветви обслуживания (LDR, GDR), можно определить, изучив номера версий файлов, как показано в таблице ниже.

    Версия

    Продукт

    Этап разработки

    Направление поддержки

    6.2.920 0.21 xxx

    Windows Server 2012

    RTM

    LDR

  • В выпусках обновлений для общего распространения (GDR) содержатся только общедоступные исправления, которые предназначены для устранения распространенных критических проблем. В выпусках обновлений LDR помимо общедоступных содержатся дополнительные исправления.

  • Файлы МАНИФЕСТА (МАНИФЕСТ) и ФАЙЛЫ, установленные в соответствии с данными, которые устанавливаются для каждой среды, перечислены в разделе «Дополнительные сведения о файле». ЧТОБЫ поддерживать состояние обновленных компонентов, очень важно иметь такие данные, как ПОСЛЕНВ, МАНИФЕСТ и связанные с ним файлы каталога безопасности (CAT). Файлы каталога безопасности, атрибуты для которых не указаны, подписаны цифровой подписью Майкрософт.

x64 Windows Server 2012

Имя файла

Версия файла

Размер

дата

Время

Платформа

Webio.dll

6.2.9200.21797

587,776

08-мар-2016

15:40

x64

Winhttp.dll

6.2.9200.21797

711,680

08-мар-2016

15:40

x64

Webio.dll

6.2.9200.21797

416,768

08-мар-2016

16:04

x86

Winhttp.dll

6.2.9200.21797

516,096

08-мар-2016

16:04

x86

Дополнительные сведения о файле


x86 Windows 7

Свойство «Файл(File))

Значение

Имя файла

Update.т.1

Версия файла

Not applicable

Размер

2,138

Дата (UTC)

09-мар-2016

Время (UTC)

21:58

Платформа

Not applicable

Имя файла

X86_431cdab002fb5e83e17b846b04fcaf65_31bf3856ad364e35_6.1.7601.23375_none_43266eeed47e442d.manifest

Версия файла

Not applicable

Размер

693

Дата (UTC)

09-мар-2016

Время (UTC)

21:58

Платформа

Not applicable

Имя файла

X86_74b492584f59e56bd20ffc14c5e5ba0f_31bf3856ad364e35_5.1.7601.23375_none_3e7a009385a3da4d.manifest

Версия файла

Not applicable

Размер

695

Дата (UTC)

09-мар-2016

Время (UTC)

21:58

Платформа

Not applicable

Имя файла

X86_microsoft-windows-webio_31bf3856ad364e35_6.1.7601.23375_none_5f3b2e545642f01b.manifest

Версия файла

Not applicable

Размер

2,484

Дата (UTC)

09-мар-2016

Время (UTC)

19:23

Платформа

Not applicable

Имя файла

X86_microsoft.windows.winhttp_31bf3856ad364e35_5.1.7601.23375_none_5ef020609ae7c078.manifest

Версия файла

Not applicable

Размер

50,395

Дата (UTC)

09-мар-2016

Время (UTC)

19:21

Платформа

Not applicable


ia64 Windows Server 2008 R2

Свойство «Файл(File))

Значение

Имя файла

Ia64_4d2eee3faf61ec5f12517a4957f4537f_31bf3856ad364e35_6.1.7601.23375_none_2a392926b32c8fac.manifest

Версия файла

Not applicable

Размер

1,034

Дата (UTC)

09-мар-2016

Время (UTC)

21:57

Платформа

Not applicable

Имя файла

Ia64_a7157a3864eb3625c6f2570464d8d82e_31bf3856ad364e35_5.1.7601.23375_none_cc5980c8656c3813.manifest

Версия файла

Not applicable

Размер

1,038

Дата (UTC)

09-мар-2016

Время (UTC)

21:57

Платформа

Not applicable

Имя файла

Ia64_microsoft-windows-webio_31bf3856ad364e35_6.1.7601.23375_none_5f3cd24a5640f917.manifest

Версия файла

Not applicable

Размер

2,486

Дата (UTC)

09-мар-2016

Время (UTC)

18:59

Платформа

Not applicable

Имя файла

Ia64_microsoft.windows.winhttp_31bf3856ad364e35_5.1.7601.23375_none_5ef1c4569ae5c974.manifest

Версия файла

Not applicable

Размер

50,400

Дата (UTC)

09-мар-2016

Время (UTC)

19:00

Платформа

Not applicable

Имя файла

Update.т.1

Версия файла

Not applicable

Размер

1,447

Дата (UTC)

09-мар-2016

Время (UTC)

21:57

Платформа

Not applicable

Имя файла

Wow64_microsoft-windows-webio_31bf3856ad364e35_6.1.7601.23375_none_c5ae742a4301234c.manifest

Версия файла

Not applicable

Размер

2,486

Дата (UTC)

09-мар-2016

Время (UTC)

18:56

Платформа

Not applicable

Имя файла

Wow64_microsoft.windows.winhttp_31bf3856ad364e35_5.1.7601.23375_none_c563663687a5f3a9.manifest

Версия файла

Not applicable

Размер

48,208

Дата (UTC)

09-мар-2016

Время (UTC)

18:57

Платформа

Not applicable


x64 Windows Server 2012

Свойство «Файл(File))

Значение

Имя файла

Amd64_9958f97250c31c67f643ef2fb115082b_31bf3856ad364e35_5.1.9200.21797_none_f923d4febdcecc46.manifest

Версия файла

Not applicable

Размер

699

Дата (UTC)

09-мар-2016

Время (UTC)

17:46

Платформа

Not applicable

Имя файла

Amd64_d36ca06f7655111911d5d7858096c818_31bf3856ad364e35_5.1.9200.21797_none_a2ac544257eab672.manifest

Версия файла

Not applicable

Размер

699

Дата (UTC)

09-мар-2016

Время (UTC)

17:46

Платформа

Not applicable

Имя файла

Amd64_f087a62cc82b760ae1e9fd7c56543a7b_31bf3856ad364e35_6.2.9200.21797_none_41ca502c248372a3.manifest

Версия файла

Not applicable

Размер

697

Дата (UTC)

09-мар-2016

Время (UTC)

17:46

Платформа

Not applicable

Имя файла

Amd64_f42986041442c9e99c4c4c4ae61a8e52_31bf3856ad364e35_6.2.9200.21797_none_d0b7a18b852fef62.manifest

Версия файла

Not applicable

Размер

697

Дата (UTC)

09-мар-2016

Время (UTC)

17:46

Платформа

Not applicable

Имя файла

Amd64_microsoft-windows-webio_31bf3856ad364e35_6.2.9200.21797_none_b6359e29819a8949.manifest

Версия файла

Not applicable

Размер

2,527

Дата (UTC)

08-мар-2016

Время (UTC)

17:49

Платформа

Not applicable

Имя файла

Amd64_microsoft.windows.winhttp_31bf3856ad364e35_5.1.9200.21797_none_edbbc2f127740085.manifest

Версия файла

Not applicable

Размер

51,759

Дата (UTC)

08-мар-2016

Время (UTC)

17:49

Платформа

Not applicable

Имя файла

Update.т.1

Версия файла

Not applicable

Размер

1,795

Дата (UTC)

09-мар-2016

Время (UTC)

17:46

Платформа

Not applicable

Имя файла

Wow64_microsoft-windows-webio_31bf3856ad364e35_6.2.9200.21797_none_c08a487bb5fb4b44.manifest

Версия файла

Not applicable

Размер

2,525

Дата (UTC)

08-мар-2016

Время (UTC)

16:28

Платформа

Not applicable

Имя файла

Wow64_microsoft.windows.winhttp_31bf3856ad364e35_5.1.9200.21797_none_f8106d435bd4c280.manifest

Версия файла

Not applicable

Размер

49,547

Дата (UTC)

08-мар-2016

Время (UTC)

16:28

Платформа

Not applicable


x64 Windows 7 и Windows Server 2008 R2

Свойство «Файл(File))

Значение

Имя файла

Amd64_6f902e1f26c1d885023f2728be29b310_31bf3856ad364e35_6.1.7601.23375_none_4011a397f4e0c754.manifest

Версия файла

Not applicable

Размер

697

Дата (UTC)

09-мар-2016

Время (UTC)

21:58

Платформа

Not applicable

Имя файла

Amd64_80b3c903f951066b9a3317caef015722_31bf3856ad364e35_5.1.7601.23375_none_f4346c5570187f00.manifest

Версия файла

Not applicable

Размер

1,040

Дата (UTC)

09-мар-2016

Время (UTC)

21:58

Платформа

Not applicable

Имя файла

Amd64_c2062bbf6a689a3048e6f61793b61cdd_31bf3856ad364e35_6.1.7601.23375_none_5e1a5c9308b3bb64.manifest

Версия файла

Not applicable

Размер

1,036

Дата (UTC)

09-мар-2016

Время (UTC)

21:58

Платформа

Not applicable

Имя файла

Amd64_d19a822d9b98f35a9157bafd2ad0441b_31bf3856ad364e35_5.1.7601.23375_none_6f3e7f9a649df87a.manifest

Версия файла

Not applicable

Размер

699

Дата (UTC)

09-мар-2016

Время (UTC)

21:58

Платформа

Not applicable

Имя файла

Amd64_ef2ea44ccf005d132e8a752d1e218e84_31bf3856ad364e35_6.1.7601.23375_none_23e107a24a3a80ce.manifest

Версия файла

Not applicable

Размер

697

Дата (UTC)

09-мар-2016

Время (UTC)

21:58

Платформа

Not applicable

Имя файла

Amd64_microsoft-windows-webio_31bf3856ad364e35_6.1.7601.23375_none_bb59c9d80ea06151.manifest

Версия файла

Not applicable

Размер

2,488

Дата (UTC)

09-мар-2016

Время (UTC)

20:04

Платформа

Not applicable

Имя файла

Amd64_microsoft.windows.winhttp_31bf3856ad364e35_5.1.7601.23375_none_bb0ebbe4534531ae.manifest

Версия файла

Not applicable

Размер

50,407

Дата (UTC)

09-мар-2016

Время (UTC)

20:03

Платформа

Not applicable

Имя файла

Update.т.1

Версия файла

Not applicable

Размер

2,774

Дата (UTC)

09-мар-2016

Время (UTC)

21:58

Платформа

Not applicable

Имя файла

Wow64_microsoft-windows-webio_31bf3856ad364e35_6.1.7601.23375_none_c5ae742a4301234c.manifest

Версия файла

Not applicable

Размер

2,486

Дата (UTC)

09-мар-2016

Время (UTC)

18:56

Платформа

Not applicable

Имя файла

Wow64_microsoft.windows.winhttp_31bf3856ad364e35_5.1.7601.23375_none_c563663687a5f3a9.manifest

Версия файла

Not applicable

Размер

48,208

Дата (UTC)

09-мар-2016

Время (UTC)

18:57

Платформа

Not applicable

Ссылки

Узнайте о терминологии, используемой Майкрософт для описания обновлений программного обеспечения.

Что такое SSL/TLS протокол и последняя версия TLS 1.3

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



Из статьи вы узнаете:

Что такое SSL

SSL или слой защищенных сокетов было оригинальным названием протокола, который разработала компания Netscape в середине 90-х. SSL 1.0 никогда не был публично доступным, а в версии 2.0 были серьезные недостатки. Протокол SSL 3.0, выпущенный в 1996, был полностью переделан и задал тон следующей стадии развития.

Что такое TLS

Когда следующую версию протокола выпустили в 1999, ее стандартизировала специальная рабочая группа проектирования сети Интернет и дала ей новое название: защита транспортного уровня, или TLS. Как говорится в TLS-документации, «разница между этим протоколом и SSL 3.0 не критичная». TLS и SSL формируют постоянно обновляемую серию протоколов, и их часто объединяют под названием SSL/TLS.

Протокол TLS шифрует интернет-трафик любого вида. Самый распространенный вид — веб-трафик. Вы знаете, когда ваш браузер устанавливает соединение по TLS — если ссылка в адресной строке начинается с «https».

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

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

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

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

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

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

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

Процесс TLS-рукопожатия

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

  1. Клиент связывается с сервером и запрашивает безопасное соединение. Сервер отвечает списком шифров — алгоритмическим набором для создания зашифрованных соединений — которым он знает, как пользоваться. Клиент сравнивает список со своим списком поддерживаемых шифров, выбирает подходящий и дает серверу знать, какой они будут использовать вдвоем.
  2. Сервер предоставляет свой цифровой сертификат — электронный документ, подписанный третьей стороной, который подтверждает подлинность сервера. Самая важная информация в сертификате — это публичный ключ к шифру. Клиент подтверждает подлинность сертификата.
  3. Используя публичный ключ сервера, клиент и сервер устанавливают ключ сессии, который они оба будут использовать на протяжении всей сессии, чтобы шифровать общение. Для этого есть несколько методов. Клиент может использовать публичный ключ, чтобы шифровать произвольное число, которое потом отправляется на сервер для расшифровки, и обе стороны потом используют это число, чтобы установить ключ сессии.

Ключ сессии действителен только в течение одной непрерывной сессии. Если по какой-то причине общение между клиентом и сервером прервется, нужно будет новое рукопожатие, чтобы установить новый ключ сессии.

Уязвимости протоколов TLS 1.2 и TLS 1.2

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

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

TLS 1.3

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

Как включить поддержку TLS 1.3 в браузерах Google Chrome и Firefox

Firefox и Chrome поддерживают TLS 1.3, но эта версия не включена по умолчанию. Причина в том, что она существует пока только в черновом варианте.

Mozilla Firefox

Введите about:config в адресную строку браузера. Подтвердите, что вы осознаете риски.

  1. Откроется редактор настроек Firefox.
  2. Введите в поиске security.tls.version.max
  3. Поменяйте значение на 4, сделав двойной щелчок мышью на нынешнее значение.


Google Chrome

  1. Введите chrome://flags/ в адресную строку браузера, чтобы открыть панель с экспериментами.
  2. Найдите опцию #tls13-variant
  3. Нажмите на меню и поставьте Enabled (Draft).
  4. Перезапустите браузер.

Как проверить, что ваш браузер использует версию 1.2

Напоминаем, что версия 1.3 еще не используется публично. Если вы не хотите
использовать черновой вариант, вы можете остаться на версии 1.2.

Чтобы проверить, что ваш браузер использует версию 1.2, проделайте те же шаги, что и в инструкциях выше, и убедитесь, что:

  • Для Firefox значение security.tls.version.max равно 3. Если оно ниже, поменяйте его на 3, сделав двойной щелчок мышью на нынешнее значение.
  • Для Google Chrome: нажмите на меню браузера — выберите Settings — выберите Show advanced settings — опуститесь до раздела System и нажмите на Open proxy settings…:

  • В открывшемся окне нажмите на вкладку Security и проверьте, чтобы для поля Use TLS 1.2 стояла галочка. Если не стоит — поставьте и нажмите OK:


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

Быстрый инструмент для проверки версии протокола SSL/TLS браузера

Зайдите в онлайн-инструмент проверки версии протокола SSL Labs. Cтраница покажет в реальном времени используемую версию протокола, и подвержен ли браузер каким-то уязвимостям.

Источники: перевод статьи из издания CSO и перевод статьи из технологического блога Ghacks

Протокол TLS, протокол SSL что это такое | Параметры безопасности протокола TLS | REG.RU

В основе функционирования интернета лежит работа различных протоколов (TCP, IP и других). Все они работают сообща и каждый из них выполняет конкретную функцию.

В 1995 году был внедрён SSL (англ. Secure Sockets Layer) — криптографический протокол, обеспечивающий безопасную связь между пользователем и сервером. Благодаря его работе можно было безопасно передавать информацию или обмениваться данными. Однако в 2014 году в его работе обнаружили уязвимости. И на основе SSL 3.0 был разработан новый стандарт — TLS.

Протокол TLS (англ. Transport Layer Security) — криптографический протокол, который обеспечивает защищённый обмен данными между сервером и клиентом. Протокол работает на трёх уровнях защиты:

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

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


Защита данных c SSL

Установите SSL-сертификат, и ваш сайт будет работать по протоколу безопасного соединения HTTPS

TLS-протокол лежит в основе безопасного обмена информацией, но не обеспечивает его сам по себе. Чтобы защищённое соединение состоялось, нужно настроить одно из безопасных интернет-соединений, например — FTP (для передачи и загрузки файлов), IMAP/POP3/SMTP (для почтовых протоколов) и HTTPS (для интернет-страниц).

HTTPS — самый известный протокол безопасного соединения, который защищает данные на уровне браузера.

Однако, чтобы сайт заработал по безопасному соединению HTTPS, нужно выбрать и установить для сайта SSL-сертификат. Подробнее об этом читайте в статье Что такое протокол https и принципы его работы и Что такое secure sockets layer и как работает SSL.

Параметры безопасности протокола TLS

Любое действие в сети представляет собой обмен данными между компьютером (сервером) пользователя и сервером, на котором хранится информация. При каждом вводе запроса в поисковую строку, авторизации в аккаунте или переходе с одной страницы сайта на другую, пользователь и сервер взаимодействуют друг с другом. Такие взаимодействия называются транзакциями, а их совокупность — сессией. TLS отвечает за безопасность транзакций и сессии в целом.

Протокол TLS обеспечивает защиту в три этапа:

  • Handshake,
  • False Start,
  • Chain of trust.

На этапе TLS Handshake (рукопожатие) происходит согласование параметров соединения (версии протокола, способа шифрования и соединения) между клиентом и сервером. Для этого используется обмен ключами по алгоритму RSA:

Для каждой такой проверки требуется большое количество вычислительных ресурсов. Чтобы не устанавливать новое соединение и не проверять сертификат повторно каждую транзакцию, была разработана процедура TLS False Start.

TLS False Start (фальстарт) — процедура возобновления сессии. Если транзакции выполняются в пределах одной запущенной сессии, данный этап позволяет пропустить процедуру Handshake. Протокол повторно использует те данные, которые уже были обработаны и подтверждены в начале сессии. При этом каждая сессия имеет свой срок жизни. Как только срок сессии истекает, с помощью TLS Handshake запускается новая сессия.

Также обязательная процедура TLS-соединения — TLS Chain of trust (цепочка доверия). Она отвечает за аутентификацию между клиентом и сервером. «Цепочка доверия» работает на основе регулярной проверки подлинности — соответствия сертификатов стандартам Сертификационных центров, которые их выдают. Подлинность сертификата регулярно проверяется в течение сессии. Если обнаружится, что сертификат скомпрометирован (то есть данные под его защитой были перехвачены), данные будут отозваны, транзакция не состоится и сессия будет прервана.

Таким образом, при передаче данных сначала вызывается процедура Handshake или False Start, которая согласовывает параметры, а затем Chain of trust, которая обеспечивает аутентификацию (проверку авторства передаваемой информации). Подробнее о принципах работы TLS читайте в официальной документации Datatracker.

Влияние SSL/TLS на SEO

SEO (Search Engine Optimization, поисковая оптимизация) – это всестороннее развитие и продвижение сайта для его выхода на первые позиции в результатах выдачи поисковых систем (SERPs). Поисковая оптимизация способствует увеличению посещаемости сайта.

Использование SSL-сертификата влияет на SEO-показатели, однако это влияние является скорее косвенным. С 2015 года Google отдаёт приоритет ранжирования (то есть назначения сайту места в поисковой выдаче) тем сайтам, которые работают по протоколу HTTPS. Такой же политики придерживается компании Яндекс и Mozilla.

Браузер Google Chrome — один из самых популярных браузеров в рунете. С недавнего времени Chrome отмечает HTTP-сайты как небезопасные:

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

Установка SSL/TLS

В компании REG.RU вы можете приобрести SSL-сертификат, который работает по TLS версии 1.2. Для этого выберите подходящий сертификат и выполните три шага — закажите, активируйте и установите его на сайт.

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

Проверка сайта на SSL/TLS

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

Рассмотрим вариант проверки сайта с помощью сервиса SSL Server Test. Для этого:

  1. 1. В браузере перейдите на страницу SSL Server Test.
  2. 2. В поле «Hostname» введите домен и нажмите Submit:
  3. 3.

    Дождитесь окончания проверки. В блоке «Configuration» вы увидите протоколы, которые поддерживает сайт:

Такой результат показывает, что сайт работает по безопасному подключению TLS версии 1.2. Если в результатах выдачи вы увидите «Yes» напротив пунктов SSL 2 или 3 — значит сайту нельзя доверять.

Защитите данные с помощью SSL

Защитите данные на вашем сайте от мошенников. Установите SSL-сертификат, чтобы сайт работал по HTTPS-протоколу.

Подробнее Помогла ли вам статья?

12 раз уже
помогла

параметры безопасности, шифрование и история версий TLS протокола

В середине 90-х компания Netscape выпустила протокол, который повышал безопасность электронных платежей. Протокол получил название SSL и являлся предшественником протокола TLS. Версия 1.0 так и не пошла «в народ», будучи отбракованной на этапе тестирования. Версия 2.0 вышла в свет, но имела дыры в защите.

В 1996 году недостатки v. 2.0 были устранены, и мир увидел уже вполне рабочую версию программы — SSL 3.0. Реализация протокола происходила на уровне application, над TCP. Это позволило протоколам высокого уровня, вроде http, функционировать в штатном режиме.

Если в настройке SSL не наблюдается погрешностей, сторонний наблюдатель не получит доступа к пакетным данным, в том числе не сможет их прочесть или подменить. Вся информация, которая окажется ему доступной – общая, не выходящая за рамки приватности: тип шифрования, примерный объем данных и частота пересылки.

  • В 1999 выходит последующая версия, которая стандартизируется инженерным советом сети Интернет (IETF). Протокол получает новое название — TLS 1.0.
  • Спустя 7 лет, весной 2006 года выходит следующая версия протокола — TLS 1.1. В ней значительно расширены функции и устранены актуальные уязвимости.
  • В 2008 году выходит TLS 1.2, в которой качественно изменились методы шифрования. Введены новые режимы блочного шифрования, а устаревшие методы криптографического хэширования запрещены.
  • Самая свежая версия протокола на сегодняшний день — TLS 1.3, выпущенная в 2018 году. Из нее убраны устаревшие хеши, шифры без аутентификации и открытые методы получения ключей к сессиям. Неактуальные опции, вроде вспомогательных сообщений и сжатия данных, также убраны. Введен режим обязательной цифровой подписи, разделены процессы согласования и аутентификации. Чтобы повысить параметры безопасности протокола TLS, версия 1.3 не имеет обратной совместимости с RC4 или SSL.

Параметры безопасности

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

  • Конфиденциальность. Пользуясь симметричными алгоритмами, протокол TLS шифрует данные, которые передаются. Если данные окажутся перехваченными, прочесть их будет невозможно.
  • Аутентификация. Гарантия, что обмен данными идет между теми узлами, для которых изначально создавался канал связи.
  • Контроль целостности. Односторонним хэшированием проверяется входящая информация, исключая возможность подмены или искажения.

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

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

TLS-рукопожатие

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

TLS False Start

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

TLS Chain of trust

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

Читайте также

Версии протокола

  • TLS 1.2 — на данный момент эта версия протокола TLS встречается чаще прочих. К сожалению, имеет уязвимости: чтобы поддерживать старые компьютеры, TLS 1.2 разрешает использование устаревших техник шифрования, которые малонадежны. Протокол сильно уязвим к активному вмешательству в соединение, когда взломщик перехватывает данные посреди сессии, а отправляет их уже после прочтения или подмены. Большинство уязвимостей обнаружены за последние 2 года, что и послужило толчком для создания обновленной версии.
  • Статистика протокола TLS 1.3. В этой версии не поддерживаются устаревшие системы шифрования, благодаря чему протокол справляется с большинством уязвимостей. TLS 1.3 совместим с более старыми версиями: если одна из сторон не имеет возможности пользоваться новой системой шифрования, соединение откатится до версии 1.2. Если же во время атаки активного вмешательства взломщик попытается принудительным образом откатить версию протокола посреди сессии – такое действие будет замечено и сессия прервется.

Сертификат и конверсия

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

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

Преимущества и недостатки протокола TLS

Еще в 1999 году, когда в SSL обнаружили уязвимости, было очевидно, что необходим обновленный протокол защиты данных. Это обстоятельство задало курс и тенденцию протоколу TLS. В 2014 POODLE успешно атаковал SSL 3.0, не оставив протоколу малейшего шанса. Что уж говорить о ранних версиях SSL.

Осенью 2014 Бодо Мёллер и его коллеги из Google Security Team обнаружили уязвимость в архитектуре протокола SSL 3.0. Атака POODLE подменяет пользовательские данные, и байт за байтом расшифровывает содержимое защищенного канала. Не существует способа обойти кодовую уязвимость, единственное логичное решение — блокировка использования протокола SSL 3.0 на всех рабочих системах.

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

Протокол TLS имеет ряд концептуальных отличий от SSL-протокола:

  • В TLS используются другие ключи и увеличенный набор шифров.
  • Улучшены стандарты формирования ключа на основе пароля.
  • Есть различия в хэшировании HMAC, которое выполняет функцию создания блока симметричных ключей.
  • Введены алгоритмы, увеличивающие безопасность канала.

Начинающие веб-разработчики сталкиваются с непростым вопросом: какой протокол выбрать? Для специалиста со стажем выбор очевиден – настройка протокола TLS идентична SSL, при этом безопасность шифрования на несколько порядков выше. Более того, специалисты по безопасности Google настоятельно рекомендуют не использовать SSL-протокол, отдавая предпочтение TLS.

Тем не менее, огромное количество пользователей ошибочно называют TLS «SSL-шифрованием». Откуда пошла путаница: поставщики сертификатов и веб-браузеры «застряли» в термине, который давно и плотно укоренился.

Знайте: когда вам предлагают «SSL-шифрование» — подразумевают TLS.

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

Прекращение поддержки TLS 1.0 и 1.1

В настоящее время используются три версии протокола TLS: TLS 1.0, 1.1 и 1.2.

TLS 1.0 был выпущен в 1999 году, поэтому ему уже почти два десятилетия. В течение многих лет было известно, что он уязвим для атак, таких как BEAST и POODLE, помимо поддержки слабой криптографии, которая не обеспечивает достаточную безопасность современных соединений.

TLS 1.1 — забытый «средний ребенок». У него нет известных уязвимостей протокола, хотя он поддерживает плохую криптографию, как и его младший брат.В большинстве программ он обошел TLS 1.2, и редко можно встретить использование TLS 1.1.

Эти версии редко используются клиентами, составляя однозначные проценты от всех HTTPS-соединений, установленных для многих сайтов. Тем не менее, из 150 000 сайтов с поддержкой HTTPS, отслеживаемых с помощью SSL Pulse, 88% поддерживают TLS 1.0 и 85% поддерживают TLS 1.1.

Может показаться очевидным, что пора прекратить использовать эти устаревшие версии протокола, поддерживающие HTTPS, но в Интернете есть большая разница между почти мертвыми и мертвыми.В этом году большое количество веб-сайтов и сервисов наконец прекращают поддержку TLS 1.0 и 1.1 (включая DigiCert).

Насколько широко используются старые версии TLS?

Почти каждый, кто читает этот пост — а фактически, большая часть Интернета — использует TLS 1.2, последнюю версию протокола (хотя TLS 1.3 не за горами, подробнее об этом позже). Это единственная версия протокола, рекомендованная криптографами и считающаяся «современной».

Однако небольшая часть пользователей может быть не готова к переходу из-за устаревшего программного обеспечения.Несмотря на то, что он был выпущен в 2008 году, поддержка TLS 1.2 некоторое время отсутствовала на некоторых основных платформах и браузерах. Internet Explorer не поддерживал TLS 1.2 до выпуска версии 11 в 2013 году; и версии Android до 5.0 (выпущенные в 2014 году) поддерживали только TLS 1.0, что составляет почти 18% устройств Android, которые все еще используются сегодня.

Измерить использование протокола TLS в Интернете очень сложно. Одним из хороших индикаторов являются данные Cloudflare, которая, как одна из крупнейших в мире сетей CDN, хорошо отслеживает события, происходящие в масштабе Интернета.Недавно они разделили около 11% трафика в своей сети с использованием TLS 1.0 (и лишь небольшая часть (0,38%) использует TLS 1.1).

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

Старые протоколы представляют угрозу безопасности

Существование TLS 1.0 и 1.1 в Интернете в первую очередь действует как угроза безопасности — эти протоколы почти повсеместно поддерживаются серверами, но их использование клиентами ближе к противоположному.Клиенты, которым необходимо использовать эти версии, страдают от своих недостатков. Остальная часть Интернета уязвима для атак на более раннюю версию (которые вынуждают пользователей использовать более слабые версии TLS для использования известных уязвимостей) практически без практической пользы. Для большинства этих серверов старые версии TLS, вероятно, оставлены включенными «на всякий случай», или кто-то забыл их выключить при включении более новых версий.

Главное изменение, которое, наконец, привело к прекращению поддержки TLS 1.0, — это приближающийся крайний срок в стандартах PCI (индустрии платежных карт).Эти стандарты охватывают методы обеспечения безопасности при работе с кредитными картами и применяются ко многим предприятиям. С 30 июня 2018 г. веб-сайтам необходимо прекратить поддержку TLS 1.0, чтобы они оставались совместимыми с PCI.

Следующая версия (TLS 1.1) рассматривается как незначительное инкрементное обновление. Хотя стандарты PCI по-прежнему разрешают использование TLS 1.1 после июня, многие веб-сайты предпочитают отказаться от обоих одновременно из-за исторически низкого уровня принятия этой версии.

Что это означает для среднего пользователя браузера? Это изменение будет для них в основном незаметно.Подавляющее большинство веб-сайтов уже поддерживают TLS 1.2, и любой достаточно современный браузер (почти любой выпуск за последние пять лет) также поддерживает TLS 1.2 и предпочитает использовать новейшую поддерживаемую версию.

DigiCert среди основных веб-сайтов, отключающих TLS 1.0 и 1.1

Это прекращение поддержки в первую очередь коснется программного обеспечения, не связанного с браузером, API-интерфейсов и другой интернет-инфраструктуры. Старые версии инструментов разработки, не поддерживающие TLS 1.2, такие как curl, , по-прежнему широко используются — либо непосредственно разработчиками, либо в виде зависимостей, связанных с другим программным обеспечением.Github — один из первых крупных сервисов, отключивших TLS 1.0 и 1.1. Они внесли изменения в феврале, которые выявили ряд поломок в инструментах разработчика.

DigiCert отключит TLS 1.0 и 1.1 для всех наших служб, включая наш веб-сайт и API, 1 апреля st . (Мы обещаем, что это не первоапрельская шутка.)

Многие крупные веб-сайты и службы объявили о прекращении поддержки в конце этого года. KeyCDN прекратит поддержку TLS 1.0 и 1.1 30 марта -го , как и Cloud.gov. Fastly прекратит поддержку TLS 1.0 и 1.1 8 мая -го . Cloudflare отключит поддержку TLS 1.0 и 1.1 для своего API 4 июня года . Microsoft Office 365 будет поддерживать только TLS 1.2 с 31 октября st . Это лишь несколько основных примеров.

По мере того, как Интернет окончательно прекращает поддержку TLS 1.0, скоро будет завершено создание следующего поколения безопасного протокола. TLS 1.3 уже довольно давно находится в процессе разработки в Инженерной группе Интернета и недавно был одобрен на собрании IETF 101 в Лондоне.Процесс окончательной редакционной проверки, вероятно, займет несколько месяцев, а затем развертывание будет происходить медленно по мере добавления поддержки клиентского и серверного программного обеспечения.

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

Черновые версии TLS 1.3 уже довольно давно поддерживаются некоторыми крупными поставщиками, такими как браузер Chrome и Cloudflare.Недавно Cloudflare сообщил, что 2% подключений в их сети уже используют TLS 1.3. Когда TLS 1.3 станет официальным RFC, мы увидим скачок внедрения этой новой версии протокола, поскольку основные программные пакеты, такие как OpenSSL, добавят поддержку.

В чем разница? Какой из них использовать?

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

В этой статье вы узнаете о ключевых различиях между TLS и SSL, а также о том, как оба протокола подключаются к HTTPS.Вы также узнаете, почему вам, как конечному пользователю, , вероятно, не нужно слишком беспокоиться о TLS и SSL или о том, используете ли вы «сертификат SSL» или «сертификат TLS».

Вы можете нажать ниже, чтобы перейти к определенному разделу или прочитать всю статью:

В чем разница между TLS и SSL?

TLS, сокращение от Transport Layer Security, и SSL, сокращение от Secure Socket Layers, являются криптографическими протоколами, которые шифруют данные и аутентифицируют соединение при перемещении данных в Интернете.

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

Так в чем разница между TLS и SSL?

Ну, TLS на самом деле является более поздней версией SSL . Он устраняет некоторые уязвимости безопасности в более ранних протоколах SSL.

Прежде чем вы узнаете больше об особенностях, важно понять базовую историю SSL и TLS.

SSL 2.0 был впервые выпущен в феврале 1995 года (SSL 1.0 никогда не выпускался публично из-за недостатков безопасности). Хотя SSL 2.0 был выпущен публично, он также содержал недостатки безопасности и был быстро заменен SSL 3.0 в 1996 году.

Затем, в 1999 году, была выпущена первая версия TLS (1.0) как обновление до SSL 3.0. С тех пор было выпущено еще три версии TLS, последняя из которых — TLS 1.3 в августе 2018 года.

На данный момент оба общедоступных выпуска SSL устарели и имеют известные уязвимости безопасности (подробнее об этом позже).

Вот полная история выпусков SSL и TLS:

  • SSL 1.0 — никогда не выпускался публично из-за проблем с безопасностью.
  • SSL 2.0 — выпущен в 1995 году. Не рекомендуется в 2011 году. Известны проблемы безопасности.
  • SSL 3.0 — выпущен в 1996 году. Не рекомендуется в 2015 году. Известны проблемы безопасности.
  • TLS 1.0 — выпущен в 1999 году как обновление до SSL 3.0. Планируемое прекращение поддержки в 2020 году.
  • TLS 1.1 — выпущен в 2006 году. Прекращение поддержки планируется в 2020 году.
  • TLS 1.2 — выпущен в 2008 году.
  • TLS 1.3 — выпущена в 2018 году.

Как TLS и SSL работают для защиты данных?

Вот общий процесс работы SSL и TLS.

Когда вы устанавливаете сертификат SSL / TLS на свой веб-сервер ( часто просто называют «сертификатом SSL») , он включает открытый ключ и закрытый ключ, которые аутентифицируют ваш сервер и позволяют вашему серверу шифровать и дешифровать данные.

Когда посетитель заходит на ваш сайт, его веб-браузер ищет сертификат SSL / TLS вашего сайта.Затем браузер выполнит «рукопожатие», чтобы проверить действительность вашего сертификата и аутентифицировать ваш сервер. Если сертификат SSL недействителен, ваши пользователи могут столкнуться с ошибкой «ваше соединение не защищено», из-за чего они могут покинуть ваш веб-сайт.

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

Здесь также появляется HTTPS (HTTPS означает «HTTP через SSL / TLS»).

HTTP и более поздний HTTP / 2 — это протоколы приложений, которые играют важную роль в передаче информации через Интернет.

При использовании обычного HTTP эта информация уязвима для атак. Но когда вы используете HTTP через SSL или TLS (HTTPS), вы шифруете и аутентифицируете эти данные во время транспортировки, что делает их безопасными.

Вот почему вы можете безопасно обрабатывать данные кредитной карты через HTTPS, но не , а через HTTP, а также почему Google Chrome так настойчиво продвигает HTTPS.

Почему он называется сертификатом SSL, если SSL устарел?

Выше вы узнали, что TLS — это более новая версия SSL, и что обе общедоступные версии SSL устарели в течение нескольких лет и содержат известные уязвимости безопасности.

Это может вызвать у вас вопрос: почему он называется сертификатом SSL, а не сертификатом TLS? В конце концов, TLS — это современный протокол безопасности.

Например, если вы посмотрите на страницу функций Kinsta, вы увидите, что Kinsta рекламирует бесплатный сертификат SSL, а не бесплатный сертификат TLS.

Не волнуйтесь: Kinsta не использует устаревшие технологии!

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

На самом деле, все «SSL-сертификаты», которые вы видите в рекламе, на самом деле SSL / TLS-сертификаты (включая бесплатные SSL-сертификаты, которые мы предлагаем как часть нашей интеграции с Cloudflare).

То есть с вашим сертификатом можно использовать как протоколы SSL, так и TLS.

Не существует просто сертификата SSL или сертификата TLS, и вам не нужно беспокоиться о замене сертификата SSL на сертификат TLS.

Что следует использовать: TLS или SSL? Заменяет ли TLS SSL?

Да, TLS заменяет SSL. И да, вы должны использовать TLS вместо SSL.

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

TLS, более современная версия SSL, безопасна. Более того, последние версии TLS также предлагают преимущества в производительности и другие улучшения.

Подпишитесь на информационный бюллетень

Хотите узнать, как мы увеличили наш трафик более чем на 1000%?

Присоединяйтесь к 20 000+ других, которые получают нашу еженедельную рассылку с инсайдерскими советами по WordPress!

Подпишитесь сейчас

TLS не только стал более безопасным и производительным, но и большинство современных веб-браузеров больше не поддерживают SSL 2.0 и SSL 3.0. Например, Google Chrome прекратил поддержку SSL 3.0 еще в 2014 году, а большинство основных браузеров планируют прекратить поддержку TLS 1.0 и TLS 1.1 в 2020 году.

Фактически, Google начал показывать предупреждения ERR_SSL_OBSOLETE_VERSION в Chrome.

Так как же убедиться, что вы используете самые последние версии TLS, а не старые небезопасные протоколы SSL?

Во-первых, помните, что ваш сертификат не совпадает с протоколом, который использует ваш сервер.Вам , а не , нужно изменить свой сертификат, чтобы использовать TLS. Несмотря на то, что он может быть обозначен как «сертификат SSL», ваш сертификат уже поддерживает протоколы SSL и TLS.

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

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

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

Например, если вы тестируете веб-сайт, размещенный в Kinsta, вы можете увидеть, как Kinsta включает TLS 1.2 и TLS 1.3, но отключает старые небезопасные версии SSL:

Как проверить, какие протоколы SSL / TLS использует ваш сервер.

Если вы обнаружите, что ваш сервер по-прежнему поддерживает устаревшие протоколы SSL, вы можете обратиться в службу поддержки своего хоста за помощью или выполнить следующие инструкции, чтобы отключить SSL на двух самых популярных веб-серверах (Apache и Nginx):

Почему Kinsta поддерживает несколько протоколов TLS?

Если TLS 1.3 — самый современный и производительный протокол, почему Kinsta также пытается включить немного более старый протокол TLS 1.2?

Другими словами: в чем преимущество включения нескольких протоколов?

Как вы узнали выше, квитирование SSL / TLS состоит из двух частей:

  1. Ваш веб-сервер
  2. Клиент (обычно веб-браузер посетителя)

Для того, чтобы квитирование работало, и должны поддерживать один и тот же протокол.

Итак, основным преимуществом наличия нескольких протоколов является совместимость.

Например, в то время как Chrome и Firefox добавили поддержку TLS 1.3 почти сразу после его выпуска в 2018 году, Apple и Microsoft потребовалось немного больше времени, чтобы добавить поддержку TLS 1.3.

Даже в 2019 году следующие браузеры все еще не поддерживают TLS 1.3:

  • Internet Explorer
  • Opera Mini
  • Браузер Android
  • Opera Mobile
  • UC Browser для Android
  • Интернет Samsung
  • Браузер Baidu

TLS 1.3 поддержка веб-браузера

Но хотя TLS 1.3 еще не получил полного внедрения, все основные браузеры поддерживают TLS 1.2 в 2019 г .:

Поддержка веб-браузера TLS 1.2

Включив на сервере и TLS 1.3, и TLS 1.2, вы можете гарантировать совместимость, несмотря ни на что, при этом получая преимущества TLS 1.3 для браузеров, которые его поддерживают, таких как Chrome и Firefox.

Если вы хотите проверить, какую версию SSL / TLS использует ваш веб-браузер, вы можете использовать инструмент How’s My SSL:

Как проверить, какие протоколы SSL / TLS использует ваш браузер

Что касается безопасности, вы везде видите SSL, TLS, HTTPS… и ты можешь заблудиться. Что вообще означают все эти аббревиатуры? Вот все ответы, которые вам нужны! 🔐😀Нажмите, чтобы написать твит

Сводка

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

Они тесно связаны, и TLS на самом деле является более современной и безопасной версией SSL.

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

Чтобы использовать протоколы SSL и TLS, вам необходимо установить сертификат на свой сервер (вот как установить сертификат SSL на WooCommerce). Опять же, хотя большинство людей называют их «сертификатами SSL», эти сертификаты поддерживают протоколы и SSL и TLS.

Вам нужно , а не , нужно беспокоиться об «замене» вашего SSL-сертификата на TLS-сертификат. Если вы уже установили «SSL-сертификат», можете быть уверены, что он также поддерживает TLS.

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

Если вы размещаете на Kinsta, Kinsta в настоящее время поддерживает TLS 1.2 и TLS 1.3, которые безопасны и поддерживаются всеми основными браузерами.

Экономьте время, деньги и повышайте производительность сайта с помощью:

  • Мгновенная помощь от экспертов по хостингу WordPress, 24/7.
  • Интеграция Cloudflare Enterprise.
  • Глобальный охват аудитории с 28 центрами обработки данных по всему миру.
  • Оптимизация с помощью нашего встроенного мониторинга производительности приложений.

Все это и многое другое в одном плане без долгосрочных контрактов, поддержки миграции и 30-дневной гарантии возврата денег. Ознакомьтесь с нашими планами или поговорите с отделом продаж, чтобы найти план, который подходит именно вам.

TLS версии 1.3: что нужно знать о последней версии TLS

TLS 1.По данным IETF, 3 используется 30% подключений в Chrome и 27% в Firefox. Вот что нужно знать о TLS 1.3 и о том, что эта последняя версия TLS для обеспечения безопасности веб-сайтов означает для вашего бизнеса.

Одна из вещей, которые мне больше всего нравятся в индустрии SSL, — это то, что она постоянно меняется. Всегда есть что-то новое, о чем можно поговорить, обсудить, обсудить и узнать. Сегодня мы поговорим о том, что является относительно новым в мире SSL. Мы собираемся проникнуть под капот TLS 1.3, последняя версия криптографического протокола TLS, которая должна поднять безопасность и производительность SSL на новый уровень.

Прежде чем я перейду к TLS 1.3, у меня к вам вопрос. Можете ли вы переключить свой автомобиль прямо на пятую передачу? Ну нет, нельзя, да? Точно так же важно понять, что означает TLS, прежде чем мы перейдем к TLS 1.3. Итак, приступим!

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

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

SSL, впервые разработанный Netscape, был выпущен в 1995 году как SSL 2.0. SSL 1.0 так и не был выпущен. Впоследствии TLS стал преемником SSL. На данный момент выпущено три версии TLS, а также TLS 1.3 — самый последний.

TLS обеспечивает безопасное соединение между клиентом (обычно веб-браузером конечного пользователя) и веб-сервером. Это безопасное соединение устанавливается путем шифрования передаваемых данных. Шифрование данных TLS поддерживается многими интернет-протоколами на основе IP, включая HTTPS, POP3, SMTP и FTP.

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

Как появился TLS 1.3

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

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

Путь к выпуску TLS 1.3 отнюдь не был легким — для его определения потребовалось 28 черновиков для Internet Engineering Task Force (IETF). Было много препятствий, таких как мидлбоксы и попытки подрыва со стороны коммерческих элементов.Но наконец, после десяти лет усилий, в 2018 году был выпущен TLS 1.3.

Как TLS версии 1.3 является значительным обновлением по сравнению с TLS 1.2

Во-первых, позвольте нам еще раз заявить, что не нужно паниковать, поскольку TLS 1.2 по-прежнему является безопасным протоколом для использования. Фактически, по состоянию на май 2020 года более 67% веб-сайтов, опрошенных SSL Labs, поддерживают TLS 1.2, тогда как только 29,7% сайтов поддерживают TLS 1.3. При этом TLS 1.2 был выпущен в 2008 году, и поэтому у него есть некоторые проблемы, которые необходимо решить, имея в виду будущее.

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

  1. Повышенная скорость
  2. Повышенная безопасность
  3. Наборы упрощенных шифров

Давайте подробнее рассмотрим каждое из этих преимуществ.

TLS 1.3: повышение производительности за счет сокращенного процесса установления связи

В основе всех протоколов SSL / TLS лежит процесс, известный как «процесс установления связи».Этот процесс установления связи происходит, когда клиент и сервер соединяются для безопасной передачи данных с помощью процессов аутентификации и шифрования. Это серия обменов данными между обеими сторонами.

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

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

Не только это, TLS 1.3 также представляет еще одну функцию, которая будет иметь значительное влияние на производительность.Эта функция известна как «Возобновление нулевого времени приема-передачи» (0-RTT). Как следует из названия, функция 0-RTT открывает путь для установления связи SSL / TLS с нулевым циклом обхода.

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

TLS 1.3: преимущество безопасности

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

  • RSA Key Transport
  • Различные группы Диффи-Хеллмана
  • CBC Mode Cipher
  • RC4 Steam Cipher
  • DES
  • 3DES
  • MD5 Algorithm
  • EXPORT-Strength Ciphers

TLS 1.3. Упрощенные наборы шифров

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

TLS 1.3, однако, упрощает этот процесс выбора правильной комбинации шифров, поскольку он имеет только пять шифров на выбор.Эти комплекты шифров приведены ниже:

.
  • TLS_AES_256_GCM_SHA384
  • TLS_CHACHA20_POLY1305_SHA256
  • TLS_AES_128_GCM_SHA256
  • TLS_AES_128_CCM_DO_8 TLS_AES_128_CCM_DO_8

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

    .

    Последнее слово: начните использовать TLS 1.3

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

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

    Что такое TLS 1.2 и почему вам (по-прежнему) должно быть не все равно?

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

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

    SSL давно не функционирует — его заменили TLS и его последующие версии. А поскольку TLS 1.0 и 1.1 устарели с конца 2020 года, организациям и веб-хостам, которые хотят обеспечить безопасность данных, необходимо перейти на поддержку TLS 1.2 во всех своих развертываниях. Но что такое TLS 1.2 и как он работает? Чтобы ответить на этот вопрос, давайте сначала кратко рассмотрим историю криптографических протоколов.

    SSL 1.0, 2.0 и 3.0

    Еще в 1995 году, когда Интернет еще только разрабатывался, Netscape решила решить растущую озабоченность по поводу интернет-безопасности, создав форму шифрования, которая позволила бы данным безопасно перемещаться без риска быть перехваченным. SSL 1.0 был небезупречен и так и не вышел в общий выпуск, но вскоре за ним последовал SSL 2.0, который затем был заменен значительно улучшенным SSL 3.0.

    Эта последняя версия SSL стала стандартом для интернет-шифрования на протяжении почти двух десятилетий.К сожалению, по мере совершенствования технологий росли и возможности различных онлайн-злоумышленников. В конце 2014 года группа безопасности Google обнаружила серьезную брешь в безопасности в SSL 3.0, что потребовало нового подхода к шифрованию связи. TLS был решением.

    TLS

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

    За

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

    Что такое TLS 1.2?

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

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

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

    В 2018 году Инженерная группа Интернета (IETF) завершила и опубликовала TLS 1.3, что делает его наиболее продвинутым и безопасным протоколом криптографии. TLS 1.3 улучшил веб-производительность и безопасность за счет увеличения скорости подтверждения TLS, улучшения времени загрузки и удаления устаревших и небезопасных наборов шифров TLS 1.2, таких как алгоритм обмена ключами RSA, потоковый шифр RC4, шифр режима CBC и другие. Проще говоря, TLS 1.3 предназначен для защиты от всех известных уязвимостей TLS 1.2 и упрощает процесс настройки.

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

    Срок сдачи TLS 1.2

    Как упоминалось ранее, по состоянию на конец 2020 года версии TLS 1.0 и 1.1 больше не поддерживаются. Это означает, что веб-сайты, не поддерживающие TLS 1.2 или выше, теперь не могут создавать безопасные соединения. Попытка получить доступ к этим сайтам с помощью основного веб-браузера (такого как Google Chrome, Apple Safari, Mozilla Firefox и Microsoft Edge) вернет сообщение об ошибке «Ошибка безопасного подключения». Точно так же сайты электронной коммерции, которые хотят иметь возможность принимать платежи по кредитным картам и оставаться совместимыми с PCI, должны использовать TLS 1.2 или выше.

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

    Опасности отказа от обновления до TLS 1.2

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

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

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

    Как перейти на TLS 1.2

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

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

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

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

    Gigamon имеет ряд инструментов, которые помогут вам защитить вашу информацию, особенно когда речь идет о расшифровке SSL / TLS.Узнайте, как наши прилагаемые приложения для расшифровки SSL / TLS GigaSMART ® помогут вам эффективно расшифровать и повторно зашифровать трафик, а также обеспечить соблюдение требований конфиденциальности и соответствия требованиям, что означает не только большую безопасность, но и меньшую головную боль для вас.

    Избранные вебинары

    Узнайте от наших экспертов о последних тенденциях и передовых методах оптимизации видимости и анализа вашей сети.

    Различия между версиями протокола SSL и TLS

    Вы слышали разговоры о SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2 и TLS 1.3, но никогда не знали различий между разными версиями? Secure Socket Layer (SSL) и Transport Security Layer (TLS) являются криптографическими протоколами, которые обеспечивают безопасную связь по сети. Все эти различные версии сегодня широко используются в таких приложениях, как просмотр веб-страниц, электронная почта, обмен мгновенными сообщениями и VoIP, и каждая из них немного отличается от других.

    Встроенная библиотека SSL / TLS

    wolfSSL поддерживает все эти протоколы в соответствии с вашими потребностями и требованиями.Ниже вы найдете списки, сравнивающие каждую версию протоколов SSL / TLS, с подробным описанием основных изменений и обновлений от версии к версии.

    SSL 3.0

    Этот протокол был выпущен в 1996 году, но впервые начался с создания SSL 1.0, разработанного Netscape. Версия 1.0 не была выпущена, а версия 2.0 имела ряд недостатков безопасности, что привело к выпуску SSL 3.0. Некоторые важные улучшения SSL 3.0 по сравнению с SSL 2.0:

    • Отделение передачи данных от уровня сообщений
    • Использование полных 128 бит ключевого материала даже при использовании шифра экспорта
    • Способность клиента и сервера отправлять цепочки сертификатов, что позволяет организациям использовать иерархию сертификатов, состоящую более чем из двух сертификатов.
    • Реализация универсального протокола обмена ключами, позволяющего обмен ключами Диффи-Хеллмана и Fortezza, а также сертификаты, не относящиеся к RSA.
    • Разрешение на сжатие и распаковку записей
    • Возможность возврата к SSL 2.0 при обнаружении клиента 2.0

    TLS 1.0

    Этот протокол был впервые определен в RFC 2246 в январе 1999 года. Это было обновление SSL 3.0, и различия не были существенными, но они достаточно значительны, чем SSL 3.0 и TLS 1.0 не взаимодействуют. Некоторые из основных различий между SSL 3.0 и TLS 1.0:

    • Ключевые функции деривации разные
      • MAC-адреса
    • отличаются — SSL 3.0 использует модификацию раннего HMAC, а TLS 1.0 использует HMAC.
    • Сообщения Finished разные
    • TLS имеет больше предупреждений
    • TLS требует поддержки DSS / DH

    TLS 1.1

    Этот протокол был определен в RFC 4346 в апреле 2006 года и является обновлением TLS 1.0. Основные изменения:

    • Неявный вектор инициализации (IV) заменен явным IV для защиты от атак с цепочкой блоков шифра (CBC).
    • Обработка дополненных ошибок изменена для использования предупреждения bad_record_mac вместо предупреждения decryption_failed для защиты от атак CBC.
    • Реестры IANA определены для параметров протокола
    • Преждевременное закрытие больше не приводит к невозможности возобновления сеанса.

    TLS 1.2

    Этот протокол был определен в RFC 5246 в августе 2008 года. TLS 1.2, основанный на TLS 1.1, обладает повышенной гибкостью. Основные отличия включают:

    • Комбинация MD5 / SHA-1 в псевдослучайной функции (PRF) была заменена PRF, заданной набором шифров.
    • Комбинация MD5 / SHA-1 в элементе с цифровой подписью заменена одним хешем. Подписанные элементы включают поле, в котором явно указывается используемый алгоритм хеширования.
    • Произведена существенная очистка возможности клиента и сервера указывать, какие алгоритмы хеширования и подписи они будут принимать.
    • Добавлена ​​поддержка аутентифицированного шифрования с дополнительными режимами данных.
    • Определение расширений TLS и наборы шифров AES были объединены.
    • Более строгая проверка номеров версий EncryptedPreMasterSecret.
    • Многие требования ужесточены
    • Длина Verify_data зависит от набора шифров
    • Описание защиты от атак Bleichenbacher / Dlima очищено.

    TLS 1.3

    Этот протокол в настоящее время пересматривается и находится на стадии 28-го проекта.Основные отличия от TLS 1.2:

    • Список поддерживаемых симметричных алгоритмов был сокращен от всех устаревших алгоритмов. Все остальные алгоритмы используют алгоритмы аутентифицированного шифрования со связанными данными (AEAD).
    • Был добавлен режим нулевого RTT (0-RTT), позволяющий сэкономить время приема-передачи при настройке соединения для некоторых данных приложения за счет определенных свойств безопасности.
    • Статический набор шифров RSA и Diffie-Hellman был удален; все механизмы обмена ключами на основе открытых ключей теперь обеспечивают прямую секретность.
    • Все сообщения рукопожатия после ServerHello теперь зашифрованы.
    • Функции получения ключей были переработаны, при этом в качестве примитива используется основанная на HMAC функция извлечения и расширения ключа (HKDF).
    • Конечный автомат рукопожатия был реструктурирован, чтобы сделать его более согласованным и удалить лишние сообщения.
    • ECC теперь входит в базовую спецификацию и включает новые алгоритмы подписи. Согласование формата точки было удалено в пользу формата одной точки для каждой кривой.
    • Сжатие, настраиваемые группы DHE и DSA были удалены, для заполнения RSA теперь используется PSS.
    • Механизм проверки согласования версии TLS 1.2 устарел и заменен списком версий в расширении.
    • Возобновление сеанса с состоянием на стороне сервера и без него, а также наборы шифров на основе PSK в более ранних версиях TLS были заменены одним новым обменом PSK.

    Ресурсы:

    Если вы хотите узнать больше о SSL или TLS, вот несколько ресурсов, которые могут быть полезны:
    TLS Статья в Википедии: http: // en.wikipedia.org/wiki/Transport_Layer_Security
    Обзор TLS 1.3: https://www.wolfssl.com/docs/tls13/

    Как всегда, если у вас есть какие-либо вопросы или вы хотите поговорить с командой wolfSSL для получения дополнительной информации, пожалуйста, свяжитесь с нами по адресу[email protected].

    Пришло время отключить TLS 1.0 (и все версии SSL), если у вас его еще нет

    Примечание редактора: этот пост был первоначально опубликован в мае 2018 года и был обновлен менеджером по продукту GlobalSign Калли Фритч, чтобы предоставить новые сведения о браузерах ‘планирую прекратить поддержку TLS 1.0 и 1.1 в марте 2020 года.

    Как мы объясняли ранее, SSL и TLS — это криптографические протоколы, которые обеспечивают аутентификацию и шифрование данных между различными конечными точками (например, клиент, подключающийся к веб-серверу), причем SSL является предшественником TLS. Со времени первой итерации SSL в 1995 году были выпущены новые версии каждого протокола для устранения уязвимостей и поддержки самых надежных и безопасных наборов шифров и алгоритмов. В настоящее время мы используем TLS 1.3, который был одобрен IETF (Internet Engineering Task Force) в марте 2018 года.

    Рекомендуется настроить серверы для поддержки последних версий протокола, чтобы гарантировать, что вы используете только самые надежные алгоритмы и шифры, но не менее важно отключить более старые версии. Продолжение поддержки старых версий протоколов может сделать вас уязвимыми для атак перехода на более раннюю версию, когда хакеры заставляют соединения с вашим сервером использовать старые версии протоколов, которые имеют известные эксплойты. Это может оставить ваши зашифрованные соединения (будь то между посетителем сайта и вашим веб-сервером, машиной с машиной и т. Д.) открыт для атак типа «злоумышленник посередине» и других типов атак.

    Возможно, вы также видели недавние новости о том, что браузеры официально прекращают поддержку TLS версий 1.0 и 1.1. Еще одна причина перейти на TLS 1.2 или 1.3, если вы еще этого не сделали. По данным Реестра:

    «Apple заявила:« Полная поддержка будет удалена из Safari в обновлениях для Apple iOS и macOS, начиная с марта 2020 года ». Google заявила, что откажется от поддержки TLS 1.0 и 1.1 в Chrome 81 (ожидается 17 марта).Microsoft заявила, что сделает то же самое «в первой половине 2020 года».

    По теме: нужно напомнить о разнице между SSL и TLS? Ознакомьтесь с нашим объяснением здесь .

    Что стоит за изменениями?

    За последние несколько лет для различных уязвимостей (например, BEAST, POODLE, DROWN… мы любим хорошие аббревиатуры, не так ли?) Отраслевые эксперты рекомендовали на некоторое время отключить все версии SSL и TLS 1.0. Соответствие PCI было еще одним движущим фактором.30 июня 2018 года стандарт безопасности данных PCI (DSS) требовал, чтобы все веб-сайты были на TLS 1.1 или выше, чтобы соответствовать.

    Проверьте, поддерживает ли ваш сайт протоколы SSL и TLS 1.0

    Если вы не уверены, какие протоколы поддерживает ваш сайт, вы можете воспользоваться нашим бесплатным тестом SSL-сервера. Перейдите в раздел «Протоколы» на странице результатов; вы увидите список всех протоколов с указанием того, включены ли они в данный момент. Приведенный ниже пример является «хорошим» плохим примером того, как должен быть настроен ваш сайт, поскольку он по-прежнему поддерживает SSL 2.0, SSL 3.0 и TLS 1.0 и не поддерживает TLS 1.2.

    Пример результатов поддержки протокола из теста GlobalSign SSL Server

    Вы можете найти дополнительную информацию о том, какие версии серверов и клиентов поддерживают каждый протокол, а также инструкции по отключению старых протоколов на нашем сайте поддержки.

    Напоминание: сертификаты не зависят от протоколов

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

    Вкратце

    • Воспользуйтесь нашим бесплатным тестом конфигурации сервера, если вы не уверены, какие протоколы в настоящее время поддерживаются.
    • Вы должны отключить поддержку SSLv2, SSLv3 и TLS 1.0, потому что они устарели и уязвимы (а также для обеспечения соответствия PCI DSS)
    • Вы должны отключить TLS 1.1, если можете, потому что есть известные уязвимости безопасности
    • Вы должны включить TLS 1.2 и 1.3
    • Прочтите нашу статью поддержки, чтобы узнать, как изменить конфигурацию сервера и включить / отключить соответствующие протоколы.

    Что касается планов GlobalSign, мы давно отключили протоколы SSL и прекратили поддержку TLS 1.0 и 1.1 для наших веб-ресурсов, чтобы обеспечить соответствие PCI DSS. Мы продолжим поддерживать версию 1.2 и работаем над поддержкой версии 1.3 сейчас.

    SSL против TLS — в чем разница?

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

    Если вы не работаете с ним регулярно, есть большая вероятность, что вы не знаете разницы между SSL (Secure Sockets Layers) и TLS (Transport Layer Security). И эта отрасль не окажет вам особого внимания, если в разговорной речи называть TLS SSL.Всего было четыре версии протокола TLS. SSL был (или должен быть) полностью устаревшим. Итак, в чем разница между SSL и TLS?

    Вы скоро узнаете.

    Краткая история SSL и TLS

    SSL и TLS являются криптографическими протоколами, которые обеспечивают аутентификацию и шифрование данных между серверами, машинами и приложениями, работающими в сети (например, клиент подключается к веб-серверу). На самом деле SSL всего около 25 лет.Но в годы Интернета это уже давно. Первая итерация SSL, версия 1.0, была впервые разработана в 1995 году компанией Netscape, но так и не была выпущена из-за серьезных недостатков безопасности. SSL 2.0 был ненамного лучше, поэтому всего год спустя был выпущен SSL 3.0. Опять же, у него были серьезные недостатки в безопасности.

    Тогда ребята из Consensus Development взяли курс на это и разработали TLS 1.0. TLS 1.0 был невероятно похож на SSL 3.0 — на самом деле он был основан на нем — но все же достаточно отличался, чтобы потребовать перехода на более раннюю версию до SSL 3.0 можно использовать. Как писали создатели протокола TLS:

    «Различия между этим протоколом и SSL 3.0 несущественны, но они достаточно значительны, чтобы TLS 1.0 и SSL 3.0 не взаимодействовали».


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

    TLS 1.1 вышел семь лет спустя, в 2006 году, на смену TLS 1.2 в 2008 году. Это повредило принятию TLS 1.1, поскольку многие веб-сайты просто обновились с 1.0 до TLS 1.2. Сейчас мы находимся на TLS 1.3, который был завершен в 2018 году после 11 лет и почти 30 проектов IETF.

    TLS 1.3 значительно лучше своих предшественников, и сейчас основные игроки в Интернете настаивают на его распространении. Microsoft, Apple, Google, Mozilla и Cloudflare объявили о планах отказаться от обоих TLS 1.0 и TLS 1.1 в январе 2020 года, что сделало TLS 1.2 и TLS 1.3 единственной игрой в городе.

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

    Что следует использовать: SSL или TLS?

    Протоколы SSL 2.0 и 3.0 были объявлены устаревшими Инженерной группой Интернета, также известной как IETF, в 2011 и 2015 годах соответственно.На протяжении многих лет уязвимости обнаруживались и продолжают обнаруживаться в устаревших протоколах SSL (например, POODLE, DROWN). Большинство современных браузеров будут показывать ухудшенное взаимодействие с пользователем (например, линия через замок или https в строке URL-адреса или другие предупреждения безопасности), когда они сталкиваются с веб-сервером, использующим старые протоколы. По этим причинам вам следует отключить SSL 2.0 и 3.0 в конфигурации вашего сервера, а пока вы это сделаете, продолжайте и откажитесь от поддержки TLS 1.0 и TLS 1.1.
    Согласно недавнему опросу WatchGuard, почти 7% из 100 000 Alexa все еще поддерживают SSL 2.0 и / или SSL 3.0. Так что этих сайтов по-прежнему много.

    Сертификаты

    не совпадают с протоколами

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

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

    Исторически сложилось так, что в наборе шифров было четыре алгоритма:

    • Обмен ключами
    • Цифровая подпись
    • Аутентификация сообщений
    • Алгоритм хеширования

    (Если это покажется маловажным, это не пройдет через секунду, когда мы обсудим различия между SSL и TLS.)

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

    Отличаются ли SSL и TLS криптографически?

    Да. Разница между каждой версией протокола может быть невелика, но если вы сравнивали SSL 2.0 до TLS 1.3 между ними будет каньон. По сути, концепция одинакова во всех версиях. Это просто способ, которым разные протоколы решают задачу шифрования расходящихся соединений.

    Каждая недавно выпущенная версия протокола поставляется со своими собственными улучшениями и / или новыми / устаревшими функциями. Первая версия SSL так и не была выпущена, вторая версия была выпущена, но с некоторыми серьезными недостатками, SSL версия 3 была переработкой второй версии (для исправления этих недостатков — с ограниченным успехом), а TLS версии 1 — улучшением SSL версии 3.Между TLS 1.0 и 1.1 изменения были незначительными. TLS 1.2 внес некоторые существенные изменения, а TLS 1.3 усовершенствовал и упростил весь процесс.

    Здесь стоит отметить, что SSL и TLS просто относятся к рукопожатию, которое происходит между клиентом и сервером. Само по себе рукопожатие не выполняет никакого шифрования, оно просто согласовывает общий секрет и тип шифрования, который будет использоваться. Подтверждение связи SSL использует порт для установления соединения. Это называется явным подключением.Порт 443 является стандартным портом для HTTPS, но всего имеется 65 535 портов, и лишь некоторые из них предназначены для определенной функции.

    TLS, наоборот, начинает свои соединения по протоколу. Это называется неявным подключением. Самый первый шаг рукопожатия — действие, которое его начинает — называется приветствием клиента. При использовании TLS это отправляется по незащищенному каналу, и соединение переключается на порт 443 (или порт, который вы указали), как только начинается рукопожатие.

    Традиционно рукопожатие включает несколько циклов обмена, когда происходит аутентификация и обмен ключами.При использовании SSL это увеличивало задержку соединений. Отсюда и зародился миф о том, что SSL / HTTPS замедляет работу вашего сайта. Каждая новая итерация протокола работала над уменьшением задержки, добавляемой рукопожатием. С помощью TLS 1.2 было доказано, что HTTPS на самом деле БЫСТРЕЕ, чем HTTP, благодаря его совместимости с HTTP / 2.

    TLS 1.3 еще больше усовершенствовал рукопожатие. Теперь это можно выполнить за один проход и включить нулевое возобновление приема-передачи (0-RTT). Частично это было сделано за счет уменьшения количества поддерживаемых наборов шифров с четырех алгоритмов до двух.

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

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

    Отключение SSL 2.0 и 3.0 и TLS 1.0

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

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *