Протокол не поддерживается клиент и сервер используют разные версии протокола SSL или разные наборы шифров

Первоначально разработанный для браузеров, SSL/TLS-протокол позже стал стандартом де-факто вообще для всех защищенных интернет-коммуникаций. Сейчас он используется для удаленного администрирования виртуальной инфра­структуры, развернутой в облаке, для передачи платежных реквизитов покупателя от серверов электронной коммерции к платежным процессорам, таким как PayPal и Amazon, для пересылки локальных данных в облачное хранилище, сохранения переписки в мессенджерах и аутентификации серверов в мобильных приложениях iOS и Android. Как видишь, список ситуаций, когда обмен весьма чувствительной информацией требует максимальной безопасности, довольно внушителен. В этой статье мы рассмотрим, как безопасность этих коммуникаций обеспечивается на практике.

Хотели как лучше

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

Безопасность коммуникаций в таких суровых условиях, как известно, целиком зависит от адекватности проверки криптографического сертификата, предоставленного сервером при установке соединения. В том числе от адекватности реализации набора шифров (cipher suite), которыми клиент и сервер пользуются при обмене данными. Для того чтобы SSL/TLS-соединение было полностью безопасным, клиентский софт в числе прочего должен тщательно удостовериться в том, что:

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

 Загрузка …

Получилось как всегда: проверка провалена

Однако во многих приложениях и библиотеках, для которых безопасность коммуникаций очень критична, процедура проверки SSL/TLS-сертификата, и даже EV-SSL, сертификата с расширенной проверкой, полностью провальна, причем это справедливо для всех популярных операционных систем: Linux, Windows, Android и iOS. Среди уязвимого софта, библиотек и middleware-сервисов можно выделить следующие:

• Amazon’овская Java-библиотека EC2 и все облачные фронтенд-клиенты, построенные на ее основе;
• Amazon’овский и PayPal’овский торговый SDK, ответственный за доставку платежных реквизитов от сайтов (на которых развернута инфраструктура онлайн-коммерции) к платежным шлюзам;
• интегрированные «корзины», такие как osCommerce, ZenCart, Ubercart и PrestaShop, которые не проверяют сертификаты вообще;
• AdMob-код, используемый мобильным софтом для показа контекстной рекламы;
• интерфейсные фронтенд-компоненты ElephantDrive и FilesAnywhere, ответственные за взаимодействие с облачным хранилищем;
• Android’ная библиотека Pusher и весь софт, который использует Pusher API для управления обменом мгновенными сообщениями (например, GitHub’овский Gaug.es);
• Apache HttpClient (версия 3.x), Apache Libcloud и все клиентские подключения к серверам Apache ActiveMQ и подобным;
• SOAP middleware-сервисы Java, в том числе Apache Axis, Axis 2, Codehaus XFire; а также весь софт, который на базе этих middleware-сервисов построен;
• API-инструменты Elastic Load Balancing;
• Weberknecht-реализация WebSockets’ов;
• а также весь мобильный софт, построенный на базе перечисленных выше библиотек и middleware-сервисов (чтобы понять, что такое middleware-сервисы, смотри слайды); в том числе iOS-клиент хостинг-провайдера Rackspace.

Например, здесь перечислено еще больше сотни уязвимых мобильных приложений. В их числе: Android’s Google Cloud Messaging, Angie’s List Business Center Passwords, AT&T Global Network Client, CapitalOne Spark Pay, Cisco OnPlus (remote access), Cisco Technical Support, Cisco WebEx, Cisco WebEx Passwords, Dominos Pizza, E-Trade, Freelancer, Google Earth, Huntington Mobile (Bank), Intuit Tax Online Accountant, iTunes Connect, Microsoft Skype, Oracle Now, Pinterest, SafeNet (VPN client), SouthWest Airlines, Uber, US Bank — Access Online, Western Union, WordPress, Yahoo! Finance, Yahoo! Mail.

 Загрузка …

Логические уязвимости SSL/TLS-протокола

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

Поставщики мобильного софта, которые берут за основу семпл-код AdMob для связи своих приложений с AdMob-аккаунтом, тоже уязвимы — они позволяют атакующему захватывать учетные данные и получать доступ ко всем его Google-сервисам. К примеру, из-за некорректной проверки сертификатов в таких мессенджерах, как Trillian и AIM, MitM-злоумышленник может похитить учетные данные для входа ко всем сервисам Google (включая Gmail), Yahoo и также к сервисам Windows Live (в том числе SkyDrive). Среди других уязвимостей, которыми страдает современный небраузерный веб-софт: использование неправильных регулярных выражений при сравнении имени хоста; игнорирование результатов проверки корректности сертификата; случайное или преднамеренное отключение проверки.

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

Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее

Вариант 2. Открой один материал

Заинтересовала статья, но нет возможности стать членом клуба «Xakep.ru»? Тогда этот вариант для тебя! Обрати внимание: этот способ подходит только для статей, опубликованных более двух месяцев назад.

Я уже участник «Xakep.ru» ← Ранее Опубликованы утилиты для DDoS-атак с применением Memcached, но эксперты нашли средство защиты Далее → Критическая уязвимость в Exim угрожает как минимум 400 000 почтовых серверов

При посещении веб-сайта, если вы столкнулись с ошибкой в первую очередь это не ваша вина ошибки. Это может случиться с любым браузером, включая браузер Chrome, Яндекс, Firefox, Internet Explorer или Edge. При попытке подключения к веб-сайту вы можете получить еще одно сообщение об ошибке. и отображает следующий код ошибки ERR_SSL_PROTOCOL_ERROR. В большинстве случаев эта ошибка возникает из-за проблемы с сервером или проблемы с сертификатом SSL, который отклоняется браузером, поскольку у сертификата есть проблема. Также возможно, что загруженный сертификат на вашем ПК поврежден или конфигурация вашего ПК для TSL/SSL неверно сконфигурирована. В этом руководстве мы разберем некоторые советы по исправлению этой ошибки.

Сообщение об ошибке: Этот сайт не может обеспечить безопасное соединение . Код ошибки: или ERR_SSL_PROTOCOL_ERROR.

Быстрым решением этих ошибок могут быть – это не правильная дата на компьютере и антивирус. Что делать?

• Проверить и выставить правильную дату, число и пояс.
• Отключить на время антивирусный продукт или добавить сертификат в исключения сканирования. Отключение антивируса в такой ситуации может быть опасным решением, если вам есть что терять (данные карты, личные данные, пароли). Нужно быть уверенным в том веб-сайте, что он не зловредный.

Прежде чем приступить, советую Вам ознакомится, что такое SSL 3/TLS в википедии или в поиске Yandex или Google. Так как SSL и TLS протоколы не безопасны. Это может быть временным решением.

1. Можете ли вы получить доступ к веб-сайту с помощью HTTP?

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

• Не совпадает ли ваше имя сертификата SSL? Убедитесь, что имя и псевдоним сайтов совпадают с фактическим URL-адресом веб-сайта, где установлен сертификат.
• Ваш сервер использует RC4 Cipher? Если да, вам нужно это исправить.

Как владелец веб-сайта, вам также необходимо проверить, поддерживает ли ваш CDN протокол SSL. Большая часть CDN теперь поддерживает SSL, и все, что вам нужно, это правильно настроить. В противном случае обратитесь к техподдержке вашего хостинга, они вам помогут.

2. Включить SSL 3/TLS и отключить протокол QUIC

Chrome и Yandex браузер:

Отключение метода QUIC Protocol в Chrome или Yandex является одним из проверенных методов исправления ошибки SSL. Поэтому, если вы хотите отключить протокол QUIC в браузере, то скопируйте следующий адрес и вставьте его в адресную строку браузера chrome://flags/#enable-quic , далее найдите Experimental QUIC protocol и отключите его, Disabled . Перезапустите браузер.

Если не помогло, то открываем браузер Chrome или Yandex и вводим в адресную строку chrome://flags . Далее в поле поиска пишем TLS и включаем . Также, в этом же поле поиска, пишем SSL и включаем его тоже. Enabled переводится, как включен.

Edge и Internet Explorer:

Нажмите сочетание кнопок Win + R и введите inetcpl.cpl,

Перейдите во вкладку “Дополнительно” и включите “Использовать TLS 1.1 ” и “Использовать TLS 1.2 “. Есть момент, если не сработало, то вернитесь обратно в эти параметры и включите еще SSL 3.0 .

Firefox:

Введите about:config в адресной строке и нажмите Enter. Далее в поиске наберите tls и найдите security.tls.version.min. Щелкните по этому параметру два раза и задайте значение 3 , чтобы заставить работать протокол TLS 1.3 . Нажмите “ОК” и перезапустите браузер Firefox.

3. Удалить состояние SSL

Нажмите сочетание кнопок Win + R и введите inetcpl.cpl, чтобы открыть свойства интернета.

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

Протокол 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 помогает защитить ваше соединение. Конечно, при условии, что удаленный веб-сервер, который вы пытаетесь использовать поддерживает этот протокол.

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

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

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

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

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

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

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

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

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

Внимание!

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

КриптоПро TLS SSL

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

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

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

Авторизация на Портале возможна с действующим сертификатом открытого ключа, полученным в инфраструктурах открытых ключей удостоверяющего центра РУП “Информационно-издательский центр по налогам и сборам” (далее – РУП ИИЦ) или в Республиканском удостоверяющем центре Государственной системе управления открытыми ключами проверки электронной цифровой подписи Республики Беларусь (далее – РУЦ ГосСУОК).

Убедитесь, что у вас на руках имеется диск c актуальным программным обеспечением и носитель ключевой информации, т.н. ключ (например, AvPass, AvToken, AvBign).

Для работы с порталом подачи электронных счетов-фактур Вам необходимо:

Откройте просмотр свойств системы: Правой клавишей по ярлыку Компьютер (Мой компьютер) – Свойства.

Посмотрите на то, как выглядят свойства операционной системы:

Год сборки должен соответствовать реальному году выхода операционной системы, например:

• для Windows XP – 2002
• для Windows 7 – 2009 и т.п.

Не должно быть никаких посторонних картинок, кроме логотипа Windows (на предустановленных системах от известных производителей компьютеров также могут присутствовать логотипы производителей и/или информация об активации).

Распространённые сборки, с которыми могут возникать проблемы: ZverCD, ZverDVD, PiterPen, Goletsa и.т.п.

Работа криптографических компонентов на таких рода сборках не гарантируется.

В комплект абонента входит:

• Криптопровайдер Avest CSP 6.3.0.791;
• Криптопровайдер Avest CSP Bel 6.3.0.791;
• Персональный менеджер сертификатов 4.0.6;
• Плагин AvCMXWebP 1.1.8;
• AvJCEProv 1.3.1;

ВНИМАНИЕ! Если данное криптографическое ПО не установлено на ПК пользователя, то работа всего функционала портала и веб-сервиса не гарантируется!

Программное обеспечение, в которое входит комплект абонента с соответствующими настройками для инфраструктуры РУП ИИЦ или РУЦ ГосСУОК и личный сертификат организации распространяется на компакт-диске. Сертификат обычно выдаётся на несколько лет, поэтому программы, передаваемые на диске, могут со временем устаревать. На данный момент актуальная версия криптопровайдера для пользователей с сертификатами из инфраструктуры РУП ИИЦ или РУЦ ГосСУОК:

Avest CSP (Проверьте версию, открыв Пуск – Все программы – Авест – Avest CSP – вкладка «Версия»).

Avest CSP bel (Проверьте версию, открыв Пуск – Все программы – Авест – Avest CSP bel – вкладка «Версия»).

Если у вас на компьютере установлена более старая версия криптопровайдера Avest CSP или Avest CSP bel, то лучше всего воспользоваться обновлением всего комплекта абонента. Для этого:

1. Скачайте и сохраните на компьютер архив с актуальным комплектом абонента для носителей AvToken или AvPass.
2. Программы находятся в архиве. Обязательно распакуйте архив перед установкой программ.
3. Зайдите в распакованный каталог с файлами..AvPKISetup(4.0.6.bign).
4. Если у вас нет сертификта в личном справочнике Найдите папку..data и скопируйте в неё цепочку сертификатов в формате *.p7b с вашим актуальным сертификатом из РУП ИИЦ. Инсталлятор не только обновит вам программы, но и запустит импорт этого сертификата в личный справочник.
5. Если у вас есть актуальный сертификат в личном справочнике , то установку можно запустить просто в режиме обновления ПО: Найдите файл AvPKISetup2.exe и запустите его двойным щелчком мыши. Запустится мастер обновления ПО. Следуйте указаниям мастера установки. Будьте внимательны, возможно в процессе установки потребуется перезагрузка компьютера.
6. Подробная инструкция по использованию автоматического инсталлятора AvPKISetup находится в этом же ахиве в папке..AvPKISetup(4.0.6.bign)DocsИнструкция по установке ПО с помощью AvPKISetup на рабочее место NCES 2.0.pdf.

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

Истёк СОС. Воспользуйтесь кнопкой автоматического обновления актуальных Списков отозванных сертификатов.

Импорт СОС

Импорт СОС

Если вы используете Windows Server 2008R2, Windows Server 2012R1 или Windows Server 2012R2, то у вас могут возникнуть проблемы с авторизацией по защищённому соединению. Рекомендуем вам следующее решение:

1. Сохраните этот файл на компьютер в такое место, где вы точно сможете его потом найти (например, выберите «Мой компьютер» – диск С: или папку «Загрузки»).
2. Распакуйте архив.
3. Запустите файл двойным щелчком мыши (изменения нужно вносить с правами администратора).
4. Разрешите внесение изменений в реестр.
5. Выполните перезагрузку компьютера после внесения всех изменений.

Запустите Internet Explorer. В строке меню необходимо выбрать иконку с настройками и в ней пункт .

Откроется окно свойств обозревателя/браузера. Выбрать вкладку «Безопасность» .

На вкладке безопасность нажать на зеленую галочку , а затем на кнопку «Узлы/сайты» .

Откроется окно . В поле «Добавить в зону следующий узел» вписать адрес, по которому происходит вход в личный кабинет (*.сайт) . Убрать галочку напротив фразы: «Для всех узлов этой зоны требуется проверка серверов (https:)» и нажать кнопку «Добавить» .

После чего адрес появится в списке Веб-узлов. Нажать кнопку «Закрыть» .

Вновь откроется вкладка «Безопасность» . Нажать кнопку «Другой» .

Откроется окно с названием «Параметры безопасности – зона надежных узлов» . Пролистать список вниз до заголовка «Элементы ActiveX и модули подключения» . ВСЁ , что находится ниже этого заголовка до конца списка, должно быть ВКЛЮЧЕНО . Пролистать этот список до конца вниз и включить ВСЕ элементы параметров безопасности, после чего нажать кнопку «ОК».

После нажатия кнопки «ОК» появится окно с предупреждением: «Вы действительно хотите изменить настройку для этой зоны?» . Нажать кнопку «Да» .

Transport Layer Security ( TLS ), преемник уже устаревшего Secure Sockets Layer ( SSL ), представляет собой криптографический протокол, предназначенный для обеспечения безопасности связи в компьютерной сети. Протокол широко используется в таких приложениях, как электронная почта , обмен мгновенными сообщениями и передача голоса по IP , но его использование в качестве уровня безопасности в HTTPS остается наиболее заметным для общественности.

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

TLS – это предлагаемый стандарт Internet Engineering Task Force (IETF), впервые определенный в 1999 году, а текущая версия – TLS 1.3, определенная в августе 2018 года. TLS основан на более ранних спецификациях SSL (1994, 1995, 1996), разработанных Netscape Communications для добавления протокол HTTPS в свой веб-браузер Navigator .

Описание

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

Поскольку приложения могут взаимодействовать с TLS (или SSL) или без него, клиенту необходимо запросить у сервера установку TLS-соединения. Один из основных способов добиться этого – использовать другой номер порта для TLS-соединений. Например, порт 80 обычно используется для незашифрованного HTTP- трафика, а порт 443 – для зашифрованного HTTPS- трафика. Другой механизм заключается в том, что клиент делает запрос к серверу для переключения соединения на TLS; например, отправив запрос

STARTTLS

при использовании почтовых и новостных протоколов.

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

• Рукопожатие начинается, когда клиент подключается к серверу с поддержкой TLS, запрашивая безопасное соединение, и клиент представляет список поддерживаемых наборов шифров (

  шифров

  и хэш-функций ).

• Из этого списка сервер выбирает шифр и хэш-функцию, которые он также поддерживает, и уведомляет клиента о решении.
• Затем сервер обычно обеспечивает идентификацию в виде цифрового сертификата . Сертификат содержит имя сервера , доверенный центр сертификации (CA), который гарантирует подлинность сертификата, и открытый ключ шифрования сервера.
• Перед тем, как продолжить, клиент подтверждает действительность сертификата.
• Чтобы сгенерировать ключи сеанса, используемые для безопасного соединения, клиент либо:
  • шифрует случайное число ( PreMasterSecret ) с помощью открытого ключа сервера и отправляет результат на сервер (который только сервер может расшифровать своим закрытым ключом); обе стороны затем используют случайное число для генерации уникального сеансового ключа для последующего шифрования и дешифрования данных во время сеанса.
  • использует обмен ключами Диффи-Хеллмана для безопасного создания случайного уникального сеансового ключа для шифрования и дешифрования, который имеет дополнительное свойство прямой секретности: если закрытый ключ сервера будет раскрыт в будущем, его нельзя будет использовать для расшифровки текущего сеанса, даже если сеанс перехватывается и записывается третьей стороной.

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

TLS и SSL не подходят ни на один уровень модели OSI или

модели

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

При защите с помощью TLS соединения между клиентом (например, веб-браузером) и сервером (например, wikipedia.org) должны иметь одно или несколько из следующих свойств:

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

  симметричным ключом

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

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

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

TLS поддерживает множество различных методов обмена ключами, шифрования данных и проверки целостности сообщений. В результате безопасная конфигурация TLS включает в себя множество настраиваемых параметров, и не все варианты обеспечивают все свойства, связанные с конфиденциальностью, описанные в списке выше (см. Таблицы ниже: § Обмен ключами , § Безопасность шифрования и § Целостность данных ).

Были предприняты попытки подорвать аспекты безопасности связи, которую стремится обеспечить TLS, и протокол несколько раз пересматривался для устранения этих угроз безопасности. Разработчики веб-браузеров неоднократно пересматривали свои продукты для защиты от потенциальных слабых мест в системе безопасности после того, как они были обнаружены (см. Историю поддержки TLS / SSL веб-браузерами).

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

Протоколы SSL и TLS

Протокол	Опубликовано	Положение дел
SSL 1.0	Не опубликовано	Не опубликовано
SSL 2.0	1995 г.	Не рекомендуется в 2011 г. ( RFC  6176 )
SSL 3.0	1996 г.	Не рекомендуется в 2015 г. (RFC  7568 )
TLS 1.0	1999 г.	Не рекомендуется в 2020 г. (RFC  8996 )
TLS 1.1	2006 г.	Не рекомендуется в 2020 г. (RFC  8996 )
TLS 1.2	2008 г.
TLS 1.3	2018 г.

Система защищенных сетей передачи данных

Ранние исследовательские усилия по обеспечению безопасности транспортного уровня включали в себя

интерфейс прикладного программирования

(API) безопасного сетевого программирования (SNP) , который в 1993 году исследовал подход к созданию безопасного API транспортного уровня, очень похожего на

сокеты Беркли

SSL 1.0, 2.0 и 3.0

Netscape разработала оригинальные протоколы SSL, а Тахер Эльгамал , главный научный сотрудник Netscape Communications с 1995 по 1998 год, был назван «отцом SSL». Версия 1.0 SSL никогда не выпускалась публично из-за серьезных недостатков безопасности в протоколе. Версия 2.0, выпущенная в феврале 1995 года, была быстро обнаружена как содержащая ряд недостатков, связанных с безопасностью и удобством использования. Он использовал одни и те же криптографические ключи для аутентификации и шифрования сообщений. У него была слабая конструкция MAC, в которой использовалась хеш-функция MD5 с секретным префиксом, что делало его уязвимым для атак на увеличение длины. И он не обеспечивал защиты ни для открытия рукопожатия, ни для явного закрытия сообщения, что означало, что атаки «злоумышленник посередине» могли остаться незамеченными. Более того, SSL 2.0 предполагал наличие единой службы и фиксированного сертификата домена, что противоречило широко используемой функции виртуального хостинга на веб-серверах, поэтому использование SSL для большинства веб-сайтов было фактически затруднено.

Эти недостатки потребовали полной модернизации протокола до версии SSL 3.0. Выпущенный в 1996 году, он был разработан Полом Кохером в сотрудничестве с инженерами Netscape Филом Карлтоном и Аланом Фрейером, а эталонная реализация была реализована Кристофером Алленом и Тимом Дирксом из Consensus Development. Новые версии SSL / TLS основаны на SSL 3.0. Проект SSL 3.0 1996 г. был опубликован IETF как исторический документ в RFC  6101 .

SSL 2.0 был объявлен устаревшим в 2011 году в соответствии с RFC  6176 . В 2014 году было обнаружено, что SSL 3.0 уязвим для атаки POODLE, которая затрагивает все блочные шифры в SSL; RC4 , единственный неблочный шифр, поддерживаемый SSL 3.0, также может быть взломан, как и в SSL 3.0. SSL 3.0 был объявлен устаревшим в июне 2015 года согласно RFC  7568 .

TLS 1.0

TLS 1.0 был впервые определен в RFC  2246 в январе 1999 года как обновление SSL версии 3.0 и написан Кристофером Алленом и Тимом Дирксом из Consensus Development. Как указано в RFC, «различия между этим протоколом и SSL 3.0 несущественны, но они достаточно значительны, чтобы исключить возможность взаимодействия между TLS 1.0 и SSL 3.0». Тим Диркс позже писал, что эти изменения и переименование с «SSL» в «TLS» были жестом сохранения лица Microsoft, «так что это не будет выглядеть [так, как будто] IETF просто штампует протокол Netscape».

Совет PCI предложил организациям перейти с TLS 1.0 на TLS 1.1 или выше до 30 июня 2018 года. В октябре 2018 года Apple , Google , Microsoft и Mozilla совместно объявили о прекращении поддержки TLS 1.0 и 1.1 в марте 2020 года.

TLS 1.1

TLS 1.1 был определен в RFC  4346 в апреле 2006 года. Это обновление TLS версии 1.0. Существенные отличия этой версии:

• Добавлена ​​защита от атак cipher-block chaining (CBC).
  • Неявная вектор инициализации (IV) была заменена с явными IV.
  • Изменения в обработке ошибок заполнения .
• Поддержка регистрации параметров IANA .

Поддержка TLS версий 1.0 и 1.1 была объявлена ​​устаревшей на веб-сайтах примерно в 2020 году, что привело к отключению доступа к версиям Firefox до 24 и Google Chrome до 29.

TLS 1.2

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

использованная литература

дальнейшее чтение

Викискладе есть медиафайлы, связанные с SSL и TLS .

• Вагнер, Давид; Шнайер, Брюс (ноябрь 1996 г.). «Анализ протокола SSL 3.0» (PDF) . Второй семинар USENIX по электронной коммерции . USENIX Press. С. 29–40.
• Эрик Рескорла (2001). SSL и TLS: проектирование и создание безопасных систем . США: ISBN Addison-Wesley Pub Co.  978-0-201-61598-2.
• Стивен А. Томас (2000). Основы SSL и TLS для защиты Интернета . Нью-Йорк: Вили. ISBN 978-0-471-38354-3.
• Бард, Грегори (2006). «Сложная, но выполнимая блочно-адаптивная атака по выбранному открытому тексту на SSL» . Международная ассоциация криптологических исследований (136) . Проверено 23сентября 2011 .
• Канвел, Брайс. «Перехват пароля в канале SSL / TLS» . Проверено 20 апреля 2007 .

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

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

Технология SSL/TLS и ее роль в безопасности сайта

SSL (Secure Sockets Layer) и TLS (Transport Layer Security) — стандартизированная технология шифрования, которая защищает передаваемые сайтом и сайту данные. Она напрямую связана с HTTPS (Hypertext Transfer Protocol Secure): если сайт использует HTTPS-подключение, это значит, что данные передаются по протоколу SSL или TLS.

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

Как SSL/TLS влияет на продвижение

Для Google безопасность всегда среди главных приоритетов: поисковик учитывает наличие HTTPS при ранжировании с 2014 года и постоянно обновляет требования к SSL-/TLS-сертификатам. Яндекс тоже делает акцент на безопасности, признавая HTTPS знаком качества сайта и предупреждая пользователей о некорректном сертификате. 

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

Хоть преимущества технологии SSL/TLS довольно очевидны, многие сайты до сих пор не перешли на HTTPS или же используют недостаточно надежные версии протоколов. Статистика 2019 года говорит о том, что 20% крупнейших сайтов в мире не используют безопасный протокол, а по данным на начало 2020 года, только 18% доменных имен в зоне .ru используют узлы HTTPS.

Многие владельцы сайтов не хотят заморачиваться с покупкой и обновлением SSL-/TLS-сертификата или считают, что он им не нужен, если ресурс не собирает пользовательские данные. Но в современных реалиях ваш сайт будет попросту терять клиентов и позиции в поиске, если вы не перейдете на HTTPS и не будете следить за актуальностью шифрования. Для вашего удобства существует множество инструментов для настройки и мониторинга SSL-/TLS-сертификатов, в том числе бесплатные, как Let’s Encrypt.

Как исправлять типичные ошибки SSL/TLS

Если у вас уже есть SSL-/TLS-сертификат, он требует регулярного обновления и мониторинга. Чтобы избежать ошибок, проверяйте свой сайт на наличие проблем с SSL/TLS. Вы можете быстро обнаружить возможные ошибки с помощью «Аудита сайта» SE Ranking — для этого перейдите в раздел «Отчет об ошибках» и секцию «Безопасность сайта»:

Давайте рассмотрим 4 частые ошибки SSL-/TLS-сертификатов и объясним, как их исправить.

1. Недействительный сертификат

У сертификата безопасности есть определенный срок действия. Он постоянно уменьшался: до 5 лет в 2011-м, до 3 лет в 2015-м, до 2 лет в 2018-м. Сейчас сертификаты действительны только 398 дней (13 месяцев) — с 2020 года Safari, Chrome и Mozilla прекратили поддержку сертификатов с большим сроком действия.

Информация о дате истечения действия сертификата доступна в браузере:

Что же происходит, если SSL-/TLS-сертификат устаревает? Сайт становится недоступен — пользователи увидят сообщение о небезопасности в браузере. Результат — существенные потери трафика и, соответственно, прибыли.

Поэтому стоит знать дату истечения действия сертификата и вовремя его обновлять. Помогут вам в этом автоматизированные решения типа Let’s Encrypt, AWS Certificate Manager, Yandex Certificate Manager. Также существуют инструменты, которые несколько раз оповещают вас перед окончанием срока действия сертификата. Иногда и вовсе ничего делать не нужно, ведь многие центры сертификации предлагают автоматическое обновление. 

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

• Выбрать тип сертификата. Большинство центров сертификации предлагает несколько вариантов, покрывающих потребности сайтов разного масштаба. Если вы только обновляете существующий сертификат и не хотите поменять его тип, этот шаг у вас уже выполнен (иногда логично переключиться на более мощный тип сертификата — например, приобрести Wildcard-сертификат, если у вашего сайта появились поддомены). Покупая новый сертификат, внимательно проверяйте авторитетность производителя. Вы можете настроить CAA-запись, чтобы ограничить круг удостоверяющих центров, имеющих право выпускать сертификаты для вашего домена. Среди самых популярных центров сертификации — GlobalSign, Digicert, Sectigo, Thawte.
• Сгенерировать запрос на получение сертификата. После покупки нужно сгенерировать CSR (certificate signing request) у хостинг-провайдера. В результате вы получите файл ключа и сам запрос для загрузки в настройках сертификата.
• Активировать и валидировать сертификат. Далее нужно подтвердить свои права на домен через email, CNAME-запись или подтверждающий файл. Как и в предыдущем процессе, особенности настройки зависят от выбранного провайдера.
• Проверить корректность работы сертификата. После установки сертификата проверьте его с помощью онлайн-инструмента. Например:

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

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

2. Устаревшая версия протокола безопасности

Технологии шифрования совершенствуются, но и хакерские атаки становятся все изощреннее. Постоянно растущие риски — одна из причин сокращения срока действия SSL-/TLS-сертификатов и обновления протокола.

Протокол TLS был представлен как апгрейд SSL (версии 3.0 на тот момент), поэтому любая версия TLS более безопасна чем SSL. Самый актуальный протокол — TLS 1.3, выпущенный в 2018 году, — имеет усовершенствованный криптографический алгоритм и позволяет браузеру быстрее подсоединиться к серверу сайта. С 2020 года все основные браузеры не поддерживают устаревшие версии TLS (1.0 и 1.1), а значит не пускают пользователей на сайты, использующие эти версии.

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

• Во вкладке Security в Chrome DevTools:

• В онлайн-инструментах, проверяющих, какие версии TLS и SSL включены на сайте. Например:

Чтобы включить последнюю версию TLS, прежде всего убедитесь, что ваш сайт поддерживает ее. Запустите серверную проверку — например, в SSL Labs — и просмотрите результаты конфигурации:

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

Скажем, ваш сайт размещен на сервере Nginx. Вам нужно отредактировать файл nginx.conf, указав в нем установленную версию TLS. Также удалите из файла все ранее используемые версии, которые признаны устаревшими. Строка конфигурации будет выглядеть так:

ssl_protocols TLSv1.2 TLSv1.3;

Если же окажется, что ваш сайт не поддерживает TLS 1.2 или 1.3, стоит обратиться к провайдеру и по возможности сменить тариф (или провайдера). 

3. Несоответствие имени сертификата

Ошибка неверного имени сертификата вызвана тем, что доменное имя, указанное в SSL-/TLS-сертификате, не соответствует введенному в адресной строке. Пользователи в таком случае не смогут зайти на сайт.

Причины несоответствия имени SSL-/TLS-сертификата:

• На сайт заходят через внутреннее доменное имя, не указанное в сертификате. Например, вы вводите в адресную строку vashsajt.localhost, тогда как ваш сертификат содержит только vashsajt.com. Вы можете решить эту проблему с помощью сертификата с альтернативным именем субъекта SAN — такой тип позволяет включать целый ряд имен хостов. Проверяйте наличие сертификатов SAN у разных удостоверяющих центров.
• Сайт доступен и с префиксом www, и без, тогда как в сертификате указана только одна версия. Вам нужно решить, хотите ли вы использовать www в доменном имени, перенаправить весь трафик сайта на соответствующую версию и указать ее в SSL-/TLS-сертификате. Мы детальнее разбираем этот вопрос в статье о префиксе www и его влиянии на SEO.
• Сайт делит IP-адрес с другими и не имеет отдельного протокола. Для большинства сайтов необязателен отдельный IP-адрес, а использование совместного экономит бюджет. Если у вашего сайта общий IP, укажите доменное имя в расширении протокола SNI. С помощью SNI сервер будет выбирать уникальный для вашего имени хоста TLS-сертификат и соответствующий ключ. Без такого расширения сервер будет использовать шаблонный сертификат, общий для нескольких сайтов, и он может быть слабее установленного вами протокола.
• Хостинг-провайдер сайта использует шаблонные настройки, которые предопределяют SSL/TLS для доменного имени. Чтобы решить эту проблему, нужно связаться с провайдером и узнать, как заменить их сертификат на ваш, или же поменять провайдера.

В онлайн-инструментах можно проверить, какие доменные имена включены в ваш SSL-/TLS-сертификат:

4. Устаревший алгоритм шифрования

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

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

• Алгоритм для обмена ключами между сервером и браузером (ECDHE)
• Цифровая подпись, удостоверяющая сертификат (ECDSA)
• Шифр для обмена данными (AES-256-GCM)
• Алгоритм для аутентификации сообщений (SHA384)

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

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

Если вы не знаете, какие шифры поддерживаются вашим сертификатом, стоит проверить их актуальность. Можно запустить онлайн-тест:

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

Обеспечьте сайту бескомпромиссную защиту

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