Протокол TLS в Internet Explorer. TLS и SSL: Необходимый минимум знаний Протокола tls не установлены

Описание

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

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

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

Процедура подтверждения связи в TLS в деталях

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

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

Простое подтверждение связи в TLS

1. Фаза переговоров:
   • Клиент посылает сообщение ClientHello
   • Сервер отвечает сообщением ServerHello
   • Сервер посылает сообщение Certificate
   • Сервер отсылает сообщение ServerHelloDone
   • Клиент отвечает сообщением ClientKeyExchange , которое содержит открытый ключ PreMasterSecret(Этот PreMasterSecret шифруется с помощью открытого ключа сертификата сервера.) или ничего (опять же зависит от алгоритма шифрования);
   • PreMasterSecret
2. Клиент посылает сообщение ChangeCipherSpec
   • Клиент посылает сообщение Finished
3. Сервер посылает ChangeCipherSpec

Подтверждение связи с аутентификацией клиента

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

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

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

Возобновление TLS-соединения

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

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

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

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

Алгоритмы, использующиеся в TLS

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

• Для обмена ключами и проверки их подлинности применяются комбинации алгоритмов: RSA (асимметричный шифр), Diffie-Hellman (безопасный обмен ключами), DSA (алгоритм цифровой подписи) и алгоритмы технологии Fortezza;
• Для симметричного шифрования: RC2 , RC4 , IDEA , DES , Triple DES или AES ;

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

Сравнение с аналогами

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

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

См. также

Ссылки

1. T. Dierks, E. Rescorla The Transport Layer Security (TLS) Protocol, Version 1.2 (August 2008). Архивировано из первоисточника 9 февраля 2012.
2. The SSL Protocol: Version 3.0 Netscape’s final SSL 3.0 draft (November 18, 1996)
3. «SSL/TLS in Detail ». Microsoft TechNet . Updated July 31, 2003.
4. Dan Goodin . The Register (19 сентября 2011). Архивировано
5. Eric Rescorla Understanding the TLS Renegotiation Attack . Educated Guesswork (5 ноября 2009). Архивировано из первоисточника 9 февраля 2012. Проверено 7 декабря 2011.
6. McMillan, Robert . Security Pro Says New SSL Attack Can Hit Many Sites , PC World (20 ноября 2009). Проверено 7 декабря 2011.
7. SSL_CTX_set_options SECURE_RENEGOTIATION . OpenSSL Docs (25 февраля 2010). Архивировано из первоисточника 9 февраля 2012. Проверено 7 декабря 2010.
8. GnuTLS 2.10.0 released . GnuTLS release notes (25 июня 2010). Архивировано из первоисточника 9 февраля 2012. Проверено 7 декабря 2011.
9. NSS 3.12.6 release notes . NSS release notes (3 марта 2010). Проверено 24 июля 2011.
10. Various IE SSL Vulnerability . Educated Guesswork (10 августа 2002).

Сетевые протоколы SSL и TLS являются криптографическими протоколами, обеспечивающими аутентификацию и защиту от несанкционированного доступа, нарушения целостности передаваемых данных. Протоколы SSL/TLS предназначены для исключения подмены идентификатора на клиентской или серверной стороне, раскрытия или искажения данных. Для этих целей используется надежный метод аутентификации, применяются шифрование канала связи и коды целостности сообщений. Стандартным портом, устанавливаемым по умолчанию для SSL/TLS, является порт 443 для HTTPS, 465 для SMTPS (электронная почта), 636 для LDAPS, 563 для NNTPS, 994 для IRCS (чат), 995 для POP3S.

Протокол SSL

Протокол SSL разработан компанией Netscape для защиты данных между сервисными и транспортными протоколами. Первая обнародованная версия была выпущена в 1995 году. Широко используется для VoIP-приложений, сервисов обмена мгновенными сообщениями. SSL представляет собой безопасный канал, имеющий следующие свойства:

• Частный канал. Обеспечивается шифрование всех сообщений после диалога, необходимого для определения ключа шифрования.
• Канал является аутентифицированным. Для клиентской стороны аутентификация выполняется опционально, а с серверной — обязательна.
• Надежность канала. При транспортировке сообщений осуществляется проверка целостности с использованием MAC.

Протокол SSL использует как симметричный, так и асимметричный ключи.

Особенности и назначение протокола SSL

Протокола SSL обеспечивает решение двух задач — шифрование передаваемой информации и передача информации именно туда, куда требуется (аутентификация). Основное назначение протокола — предоставление надежного способа обмена данными между приложениями. Реализация SSL выполнена в виде многослойной среды, которая используется для безопасной передачи информации посредством незащищенных каналов связи.

Многослойная структура представлена слоем протокола подтверждения подключения и слоем протокола записи. Первым слоем выступает транспортный протокол, например, TCP — вместе с SSL Record Protocol данные слои образуют ядро SSL, которое впоследствии участвует в формировании сложных инфраструктур.

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

Протокол TLS

Протокол TLS представляет собой криптографический протокол, который применяется для защищенной передачи данных между различными узлами в сети интернет. Данный протокол нашел применение в VoIP-приложениях, веб-браузерах, приложениях для мгновенного обмена сообщениями. TLS реализован на спецификации SSL 3.0. Разработкой и развитием протокола занимается компания IETF.

К основным мерам безопасности, которые обеспечивает протокол TLS, относятся:

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

Особенности и назначение протокола TLS

В протоколе TLS используются следующие алгоритмы:

• RC4, Triple DES, SEED, IDEA и др. для симметричного шифрования.
• RSA, DSA, Diffie-Hellman и ECDSA для проверки подлинности ключей.
• MD5, SHA и SHA-256/384 для хэш-функций.

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

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

Если вы столкнулись с проблемой, при которой возникает ошибка доступа к определенному сайту, при этом в браузере появляется сообщение , этому есть разумное объяснение. Причины и способы устранения проблемы приведем в этой статье.

Протокол SSL TLS

Пользователи бюджетных организаций, да и не только бюджетных, чья деятельность напрямую связана с финансами, во взаимодействии с финансовыми организациями, например, Минфином, казначейством и т.д., все свои операции проводят исключительно по защищенному протоколу SSL. В основном, в своей работе они используют браузер Internet Explorer. В некоторых случаях — Mozilla Firefox.

Ошибка SSL

Основное внимание, при проведении данных операций, да и работе в целом, уделено системе защиты: сертификаты, электронные подписи. Для работы используется программное обеспечение КриптоПро актуальной версии. Что касается проблемы с протоколами SSL и TLS , если ошибка SSL появилась, вероятнее всего отсутствует поддержка данного протокола.

Ошибка TLS

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

Поддержка протоколов SSL и TLS

Итак, при использовании Microsoft Internet Explorer, чтобы посетить веб-сайт по защищенному протоколу SSL, в строке заголовка отображается Убедитесь что протоколы ssl и tls включены . В первую очередь, необходимо включить поддержку протокола TLS 1.0 в Internet Explorer.

Если вы посещаете веб-сайт, на котором работает Internet Information Services 4.0 или выше, настройка Internet Explorer для поддержки TLS 1.0 помогает защитить ваше соединение. Конечно, при условии, что удаленный веб-сервер, который вы пытаетесь использовать поддерживает этот протокол.

Для этого в меню Сервис выберите команду Свойства обозревателя .

На вкладке Дополнительно в разделе Безопасность , убедитесь, что следующие флажки выбраны:

• Использовать SSL 2.0
• Использовать SSL 3.0
• Использовать SSL 1.0

Нажмите кнопку Применить , а затем ОК . Перезагрузите браузер .

После включения TLS 1.0, попытайтесь еще раз посетить веб-сайт.

Системная политика безопасности

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

Чтобы это сделать, в Панели управления выберите Администрирование , а затем дважды щелкните значок Локальная политика безопасности .

В локальных параметрах безопасности, разверните узел Локальные политики , а затем нажмите кнопку Параметры безопасности .

В соответствии с политикой в ​​правой части окна, дважды щелкните Системная криптография: использовать FIPS-совместимые алгоритмы для шифрования, хеширования и подписывания , а затем нажмите кнопку Отключено .

Внимание!

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

КриптоПро TLS SSL

Обновить КриптоПро

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

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

По требованиям российского законодательства признается только использование TLS-соединений, установленных по российским криптографическим алгоритмам ГОСТ 28147-89, ГОСТ Р 34.10-94, ГОСТ Р 34.11-94 и ГОСТ Р 34.10-2001. Поэтому, если вам требуется использование сайтов, использующих шифрование по ГОСТ алгоритмам, необходимо установить программу «КриптоПро CSP» .

В операционных системах Windows используется программа КриптоПро CSP - набор криптографических утилит для генерации электронной подписи, работы с сертификатами

Для установки КриптоПро CSP воспользуйтесь материалами с официального сайта:

После установки КриптоПро CSP браузер проверяет наличие и работоспособность этой программы.

Сайты, запрашивающие шифрование ГОСТ TLS

Если сайт запрашивает шифрование ГОСТ TLS, браузер проверяет, установлено ли программа КриптоПро CSP. Если программа установлена, ей передается управление.

Примеры сайтов, запрашивающих шифрование: www.gosuslugi.ru , сайты на домене .gov.ru , .kamgov.ru , .nalog.ru .

Если сайта нет в списке, то запрашивается дополнительное подтверждение. Если вы доверяете сайту и соединение должно быть произведено с использованием шифрования ГОСТ TLS, нажмите кнопку Продолжить .

Протокол 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траница покажет в реальном времени используемую версию протокола, и подвержен ли браузер каким-то уязвимостям.

Источники : перевод