Мир движется к TLS 1.3, что очень хорошо! Эта статья предлагает обзор высокого уровня TLS 1.3, и обсуждение эффективности его новых функций.
Transport Layer Security
Безопасность транспортного уровня, или TLSявляется криптографическим протоколом, который защищает данные, передаваемые по компьютерной сети. TLS стал известен как S in HTTPS, Более конкретно, TLS используется для защиты данных пользователя сети от сетевых атак.
TLS был разработан как более безопасная альтернатива своему предшественнику Уровень защищенных гнезд (SSL). За прошедшие годы исследователи безопасности обнаружили множество уязвимостей, влияющих на SSL, что побудило IETF разработать TLS в попытке смягчить их.
Как ни странно, более ранние версии TLS были также затронуты опасными уязвимостями, что в конечном итоге привело к TLS 1.2 (то есть версия по умолчанию, рекомендованная профессионалами отрасли).
Большинство известных уязвимостей протокола были смягчены в TLS 1.2, но этот уровень безопасности все еще был результатом серии патчей поверх некорректного дизайна.
В ответ, TLS 1.3 был разработан с нуля, чтобы создать современный и безопасный дизайн TLS протокол. Спустя пять лет тестирования оно было окончательно одобрено и теперь близко к стандарту безопасности в Интернете по умолчанию.
TLS версии и их соответствующие документы RFC можно найти в списке ниже:
- TLS 1.0 был опубликован как RFC 2246 , в 1996 году
- TLS 1.1 был опубликован как RFC 4346 , в 2006 году
- TLS 1.2 был опубликован как RFC 5246 , в 2008 году
- TLS 1.3 был опубликован в качестве предлагаемого стандарта в RFC 8446 в 2018 году.
Как пожить TLS версии работают?
Чтобы эффективно обсудить преимущества TLS 1.3, мы должны сначала поговорить о том, как старше TLS версии работают (и как они не работают).
TLS - это гибрид криптосистема, что означает, что она использует оба асимметричный (открытый ключ) и симметричный (на основе пароля / фразы) шифрование. Это связано с асимметричная криптография будучи на порядки медленнее, чем его симметричные эквиваленты.
Следовательно, TLS использует только открытые ключи, чтобы клиенты и серверы могли безопасно обмениваться симметричным ключом. Этот ключ затем можно использовать для шифрования всех последующих соединений, избегая снижения производительности, вызванного асимметричным шифрованием.
TLS 1.2 поддерживает несколько алгоритмов обмена ключами (например, RSA, DH и т. Д.), А также несколько алгоритмов (также известных как шифры) используется для шифрования и дешифрования сообщений. Такое большое количество альтернативных вариантов требует от клиентов и серверов согласования, чтобы все стороны использовали одно и то же TLS параметры.
Это согласование стандартизировано в протоколе под названием рукопожатие, Если вы не знакомы с этим, пожалуйста, обратитесь к этой статье чтобы получить больше информации.
Так что не так с TLS 1.2?
Несмотря на то, что TLS Доказано, что 1.2 работает очень хорошо в большинстве случаев, есть опасения по поводу общего уровня безопасности и конфиденциальности, которые он обеспечивает после многих лет исправлений и исправлений.
Помимо соображений безопасности, однако, TLS 1.2 также накладывает ненужную производительность и нагрузку на сеть.
TLS Проблемы безопасности 1.2
За эти годы исследователи (и злоумышленники) обнаружили множество уязвимостей во многих TLS 1.2 компоненты, включая алгоритмы обмена ключами, шифры и цифровые подписи. Некоторые из них были ошибки реализации, о которых вы, возможно, слышали, такие как heartbleed or неистовый. Однако некоторые из них были уязвимостями протокола, то есть они использовали неверные проектные решения ранее TLS версии (т.е. до TLS 1.2).
Хотя большинство реализаций и другие ошибки были исправлены в TLS 1.2, к сожалению, уязвимости в дизайне протокола не могут быть исправлены с помощью программного патча. Как оказалось, для этого IETF пришлось полностью переделать протокол рукопожатия в TLS 1.3.
Было много опасений по поводу TLS безопасность, но одним из самых важных было осознание того, что TLS 1.2 (и все более ранние версии, включая SSL) уязвимы для атак перехода на более раннюю версию из-за недостатка в конструкции протокола подтверждения. В частности, TLS 1.2 не использует цифровые подписи для защиты целостности рукопожатия. Подписи защищают часть рукопожатия, только после согласования набора шифров.
Как следствие, злоумышленники могут манипулировать любым сторонним согласованием набора шифров, которое происходит в той же компьютерной сети (например, wifi в аэропорту), и принудительно использовать небезопасный шифр. Затем они могут взломать этот уязвимый шифр и получить необоснованный доступ ко всему разговору.
TLS 1.2 проблемы с производительностью
Помимо этих соображений безопасности, TLS 1.2 необходимо обсудить многочисленные TLS параметры могут накладывать снижение производительности на HTTPS (или другие TLS защищенные) коммуникации.
TLS Четырехэтапное рукопожатие 1.2 требует двух двусторонних обменов: сначала для выбора набора шифров, а затем для обмена сертификатами и симметричными ключами (или общими ключами).
Это означает, что для каждого TLS соединение должно быть установлено, две дополнительные транзакции с сервером требуются. В следствии, TLS соединения требуют большей пропускной способности и мощности, чем (незашифрованный) HTTP, что может быть особенно дорогостоящим для приложений Интернета вещей (IoT), где низкое энергопотребление и потребление пропускной способности являются жесткими ограничениями.
TLS 1.2 вопросы конфиденциальности
Наконец, TLS 1.2 был подвергнут критике за нарушение конфиденциальности пользователей сети.
Более конкретно, TLS предлагает расширение, известное как Указание имени сервера или SNI. SNI позволяет включить имя хоста сервера в начальное подтверждение SSL. Это расширение используется для виртуального хостинга, где серверы могут обслуживать несколько доменов с одним и тем же IP-адресом и портом, при этом для каждого домена предоставляется отдельный сертификат.
In TLS 1.2, SNI отправлены незашифрованномпоэтому, несмотря на использование HTTPS, сетевой злоумышленник может утечь эту информацию и отследить веб-страницы, которые посещает пользователь.
TLS 1.3 все это исправить?
TLS 1.2 (и более ранние версии) были направлены на поддержание обратной совместимости. Каждая версия построена на предыдущих версиях с незначительными изменениями, пытаясь устранить уязвимости, опубликованные между TLS версий.
К сожалению, это также означало, что неправильные решения по разработке протокола (например, незащищенное рукопожатие) также были унаследованы в более новых версиях.
TLS 1.3 отказывается от обратной совместимости в пользу правильного дизайна безопасности. Он был разработан с нуля для обеспечения функциональности, аналогичной (но не совместимой) TLS 1.2, но со значительно улучшенной производительностью, конфиденциальностью и безопасностью.
TLS 1.3 безопасность
Основной принцип TLS 1.3 это простота. В новой версии все алгоритмы обмена ключами, кроме Диффи-Хеллмана (DH) обмен ключами, были удалены. TLS 1.3 также определил набор проверенных и проверенных параметров DH, исключая необходимость согласования параметров с сервером.
Более того, TLS 1.3 больше не поддерживает ненужные или уязвимые шифры, такие как CBC-режим и шифр RC4. Известно, что эти шифры подвержены атакам, но в большинстве TLS реализации для унаследованной совместимости. К счастью, недавний всплеск атак понижения TLS версии побудили IETF полностью удалить такие шифры из TLS 1.3.
Кроме того, TLS 1.3 требует, чтобы серверы криптографически подписывали весь рукопожатие, включая согласование шифров, что не позволяет злоумышленникам изменять любые параметры рукопожатия. Это означает, что TLS 1.3 архитектурно невосприимчив к атакам понижения, которые затронули ранее TLS версий.
Наконец, сами подписи были также улучшены путем внедрения нового стандарта, названного РСА-ПСС, Подписи RSA-PSS невосприимчивы к криптографическим атакам, влияющим на схемы подписи, использовавшиеся ранее. TLS версий.
TLS НЕТ производительности
Помимо повышения безопасности, сокращенного набора параметров и упрощенного рукопожатия в TLS 1.3 также способствует улучшению общей производительности. Поскольку существует только один алгоритм обмена ключами (со встроенными параметрами) и всего несколько поддерживаемых шифров, абсолютная полоса пропускания, необходимая для настройки TLS 1.3 канал значительно меньше, чем в предыдущих версиях.
Кроме того, TLS 1.3 теперь поддерживает новый протокол рукопожатия, называемый 1-RTT режим, В 1-RTT клиент может отправлять общие ключи DH в первом сообщении о рукопожатии, поскольку он может быть достаточно определенным из параметров, которые будет использовать сервер. В редких случаях, когда сервер их не поддерживает, он может выдать ошибку, чтобы клиент отправил другую конфигурацию.
Вместо того, чтобы сначала согласовывать параметры, а затем обмениваться ключами или общими ключами, TLS 1.3 позволяет клиенту настроить TLS канал только с одной транзакцией туда-обратно (вместо двух, как это было ранее). Это может иметь большой кумулятивный эффект в обработке, мощности и сетевых ресурсах, которые требуются клиенту для связи с сервером через TLS 1.3.
Оптимизация производительности на этом не заканчивается. TLS 1.3 особенность, называемая 0-RTT Режим возобновления, Когда браузер посещает сервер в первый раз и успешно завершает TLS рукопожатие, и клиент, и сервер могут хранить предварительно общий ключ шифрования локально.
Если браузер снова посещает сервер, он может использовать этот ключ возобновления для отправки зашифрованных данных приложения в своем первом сообщении на сервер. Это имеет ту же задержку как незашифрованный HTTP, потому что начальные рукопожатия не требуются.
Следует отметить, что были некоторые меры безопасности проблемы о режиме 0-RTT в прошлом.
TLS Конфиденциальность 1.3
Учиться на прошлых ошибках, TLS 1.3 теперь предлагает расширение который шифрует информацию SNI. При правильном использовании это расширение предотвращает утечку злоумышленникам доменного имени удаленного сервера, поэтому у них нет метода отслеживания истории пользователей HTTPS. Эта функция обеспечивает большую конфиденциальность для пользователей Интернета, чем предыдущие версии TLS.
Заключение
В то время как TLS 1.2 достойно служил все эти годы, TLS 1.3 значительно безопаснее и эффективнее. TLS 1.3 был тщательно протестирован в экспериментальных реализациях браузера, и теперь он готов заменить TLS 1.2 в качестве протокола сетевой безопасности по выбору. Издательский TLS 1.3 - это большой шаг к более быстрому и безопасному Интернету для всех.
Спасибо за выбор SSL.com, где, как мы полагаем, безопаснее Интернет это better Интернет.
