Tls certificate changed ошибка

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

Одной из таких ошибок является «Недопустимый сертификат TLS» в Linux.

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

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

Однако вы также можете столкнуться с этой ошибкой при установке приложения Flatpak или использовании ref-файла Flatpak из стороннего репозитория через терминал.

Некоторые пользователи заметили эту проблему при использовании рекомендованной их организацией службы VPN для работы в Linux.

Итак, как это исправить? Почему это проблема?

Ну, технически это одна из двух вещей:

• Ваша система не принимает сертификат (и сообщает, что он недействителен).
• Сертификат не соответствует домену, к которому подключается пользователь.

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

Но если это первое, у вас есть несколько способов справиться с этим.

1. Исправьте «Недопустимый сертификат TLS» при использовании Flatpak или добавлении онлайн-аккаунтов GNOME.

Если вы пытаетесь добавить пульт Flathub или новое приложение Flatpak и замечаете ошибку в терминале, вы можете просто ввести:

sudo apt install --reinstall ca-certificates

Это должно переустановить доверенные сертификаты ЦС на случай, если какая-то проблема со списком возникла.

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

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

2. Исправьте «Недопустимый сертификат TLS» при использовании Work VPN.

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

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

Далее вам нужно будет пройти свой путь к /usr/local/share/ca-сертификаты каталог.

Вы можете создать в нем каталог и использовать любое имя для идентификации сертификата вашей организации. Затем добавьте файл .CRT в этот каталог.

Например, это usr/local/share/ca-certificates/organization/xyz.crt.

Обратите внимание, что вам нужны привилегии root для добавления сертификатов или создания каталога под CA-сертификаты каталог.

После того, как вы добавили необходимый сертификат, все, что вам нужно сделать, это обновить список поддерживаемых сертификатов, введя:

sudo update-ca-certificates

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

Подводя итог

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

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

Вы когда-нибудь сталкивались с этой ошибкой? Как ты это починил? Известны ли вам другие решения этой проблемы (возможно, что-то, за чем легко следовать)? Дайте мне знать ваши мысли в комментариях ниже.

Оригинал статьи

Ошибки браузера и предупреждения

Слишком часто при доступе к веб-сайтам встречаются такие сообщения об ошибках браузера:

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

• Google Chrome 76.0.3809.100 (macOS 10.14.6)
• Firefox 68.0.1 (macOS 10.14.6)
• Safari 12.1.2 (macOS 10.14.6)
• Edge 44.17763.1.0 (Windows 10 Корпоративная)
• Internet Explorer 11.379.11763.0 (Windows 10 Корпоративная)

Ситуации, которые мы рассмотрим, подробно описаны в содержании ниже.

Сертификат с истекшим сроком действия

В этих случаях на сервере установлен сертификат, который истек срок действия и нуждается в замене:

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

Доменное имя не соответствует сертификату

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

Решение: Убедитесь, что распространенное имя и / или альтернативное имя субъекта указанное в сертификате соответствует доменному имени веб-сайта.

Неполная цепь доверия

Если веб-сервер не имеет полного цепь доверия включая все необходимые промежуточные сертификаты, эти ошибки могут привести к:

Решение: Убедитесь, что на вашем сервере установлена ​​полная цепочка сертификатов. Пожалуйста, смотрите наш статья о диагностике и устранении этой проблемы чтобы получить больше информации.

Аннулированный сертификат

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

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

Мы надеемся, что это руководство было полезно для того, чтобы помочь вам расшифровать (иногда загадочные) сообщения об ошибках, выдаваемые веб-браузерами, когда они сталкиваются с проблемным SSL /TLS монтаж. Если у вас есть какие-либо вопросы, пожалуйста, свяжитесь с нами по электронной почте на Support@SSL.com, вызов 1-877-SSL-SECURE, или просто нажмите ссылку чата в правом нижнем углу этой страницы. Вы также можете найти ответы на многие распространенные вопросы поддержки в нашем база знаний. Спасибо, что выбрали SSL.com!

Windows 10, version 1903, all editions Windows 10, version 1809, all editions Windows Server 2019, all editions Windows 10, version 1803, all editions Windows 10, version 1709, all editions Windows 10, version 1703, all editions Windows 10, version 1607, all editions Windows Server 2016, all editions Windows 10 Windows 8.1 Windows Server 2012 R2 Windows Server 2012 Windows 7 Service Pack 1 Windows Server 2008 R2 Windows Server 2008 Service Pack 2 Windows Embedded 8 Standard Windows Embedded Standard 7 Service Pack 1 Windows Embedded POSReady 7 Еще…Меньше

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

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

SSL/TLS-протокол: хотели как лучше…

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

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

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

…а получилось как всегда: примеры провальной проверки SSL/TLS-сертификата

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

• 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-сервисы, смотри рис. 1); в том числе iOS-клиент хостинг-провайдера Rackspace.

Рисунок 1. Что такое middleware-сервисы

Кроме того, в [2] перечислено ещё больше сотни уязвимых мобильных приложений (см. рис. 2). В том числе: 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, WesternUnion, WordPress, Yahoo! Finance, Yahoo! Mail.

Рисунок 2. Небольшая выборка из списка уязвимых мобильных приложений

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

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

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

Другие распространённые уязвимости реализации SSL/TLS-протокола

Ну и конечно же нельзя забывать о том, что даже если в реализации SSL/TLS-протокола нет логических ошибок (если конечно кто-то в это ещё верит), то защиту можно обойти посредством похищения приватного ключа [12], посредством применения 0day-эксплойтов к таким вещам как клавиатуры, браузеры, операционные системы, утилиты и прошивки [3]; посредством компрометации BGP-маршрутизации [10]; или атаковать SSL/TLS по аппаратным (см. рис. 3) [8] и/или программным [9] обходным каналам.

Рисунок 3. Атака на SSL по аппаратным обходным каналам

Кроме того, злоумышленники могут выполнять практически невидимые MiTM-атаки, злоупотребляя механизмом кэширования SSL/TLS-сеансов, реализованным в классе SSLSessionCache. Этот механизм проверяет достоверность сертификатов только при первоначальном соединении; и при этом не способен должным образом аннулировать сеанс связи после удаления сертификатов с устройства. Кроме того, после перезагрузки Android-устройства (через опции «Перезапуск» или «Отключить питание») можно продолжать видеть зашифрованный трафик некоторых приложений, которые после перезагрузки не запускались, но до перезагрузки работали. Так например с Google Maps происходит. В [2] описано, как благодаря этим недочётам кэширования, злоумышленник может совершенно прозрачно для пользователя устанавливать и удалять «невидимые сертификаты», и затем устанавливать сетевое соединение с любым приложением.

Рисунок 4. Ретроспектива уязвимого шифрования

Среди других распространённых уязвимостей реализации SSL/TLS-протокола можно отметить уязвимое шифрование (см. рис. 4) [5], повторное использования GCM (Galois/Counter Mode; счётчик с аутентификацией Галуа) [6], хитрость с CNG (CryptoAPI-NG) в Schannel (см. рис. 5) [7], некорректную проверку цепочки доверия [2], некорректную проверка имени хоста [11].

Рисунок 5. Хитрость с CNG: вытягиваем секреты из Schannel

Некорректная проверка цепочки доверия представляет собой ситуацию, когда веб-приложение принимает абсолютно любой сертификат, в котором указано корректное имя хоста, не проверяя при этом каким центром сертификации он был подписан. Это позволяет перехватывать и дешифровывать пароли и/или номера кредитных карт. А в некоторых случаях даже делать инъекцию вредоносного кода. В Android-софт данная уязвимость проникает, например когда создаётся кастомизированный X509TrustManger-интерфейс, который игнорирует исключения CertificateException. Или когда разработчик софта вставляет в код WebViews-компонента вызов метода SslErrorHandler.proceed(). [2]

Некорректная проверка имени хоста представляет собой ситуацию, когда веб-приложение принимает сертификат, не удостоверившись в том, что хост, с которого этот сертификат пришёл, присутствует в списке доверенных хостов. В Android-софт данная уязвимость проникает, например когда создаётся HostnameVerifier-интерфейс, который при любых условиях возвращает TRUE. Или когда разработчик софта в вставляет в код WebViews-компонента вызов метода SslErrorHandler.proceed(). [2]

Коренная причина существования уязвимостей в SSL/TLS-протоколе

Коренная причина существования подавляющего большинства перечисленных уязвимостей – ужасный API-дизайн SSL/TLS-библиотек (в том числе JSSE, OpenSSL, и GnuTLS). А также не менее ужасный дизайн библиотек передачи данных (таких как cURL, Apache HttpClient и urllib), каждая из которых представляет собой высокоуровневую обёртку для SSL/TLS-библиотек. Не говоря уже о middleware-сервисах (таких как Apache Axis, Axis 2, или Codehaus XFire), которые ещё более высокоуровневой обёрткой являются, и которые увеличивают «снежный ком» ужасного дизайна ещё больше. Вместо того чтобы вести с прикладным разработчиком (зачастую далёким от системного программирования) диалог на понятном ему языке (в терминах конфиденциальности и аутентификации), абстрагировано от низкоуровневых подробностей реализации SSL/TLS-протокола, эти API вываливают на бедолагу кучу низкоуровневых SSL/TLS-параметров, непонятных ему. Требуют от высокоуровневого софта, чтобы он правильно выставлял низкоуровневые опции; реализовывал функции проверки имени хоста и заботился об интерпретации возвращаемых низкоуровневыми операциями значений.

В результате, прикладные разработчики используют SSL/TLS API неправильно: ошибочно интерпретируют многообразие их параметров, опций, побочных эффектов и возвращаемых значений. Например [1]:

• Amazon’овская PHP-библиотека Flexible Payments Service пытается включить проверку имени хоста – посредством установки параметра CURLOPT_SSL_VERIFYHOST в значение TRUE (в cURL-библиотеке). Однако корректное значение по умолчанию для этого параметра – 2; если же присвоить ему значение TRUE, то этому параметру незаметно для разработчика присваивается значение 1, и т.о. проверка сертификата отключается.
• PHP-библиотека PayPal Payments Standard – приобрела ту же самую ошибку; причём в тот момент, когда предыдущая, уязвимая, реализация обновлялась (т.е. одну ошибку убрали, другую добавили).
• Другой пример – это Lynx, тексто-ориентированный браузер. Он проверяет самоподписанные сертификаты, – но только в том случае, если GnuTLS’ная функция проверки сертификата возвращает отрицательное значение. Однако эта самая функция для некоторых ошибок возвращает 0; в том числе в тех случаях, когда сертификаты подписаны недоверенным органом. Из-за этого цепочка проверки доверия в Lynx – нарушена.

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

Например, в JSSE (Java Secure Socket Extension) расширенный интерфейс SSLSocketFactory API – молча пропускает проверку имени хоста, если поле «algorithm» в SSL-клиенте установлено в NULL или в пустую строку, – а не в HTTPS. Хотя данное обстоятельство упоминается в справочном руководстве JSSE, многие Java-реализации SSL-протоколов используют SSLSocketFactory без выполнения проверки имени хоста…

Ложка мёда в бочку дёгтя

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

Рисунок 6. Классификация актуальных для SSL/TLS уязвимостей

Ну и чтобы добавить ложку мёда в бочку дёгтя, стоит отметить, что в [1] подробно/понятно/популярно/грамотно описано, как SSL реализовываться должен, со ссылкой на RFC. Лучшего описания, которое бы технически точным и одновременно понятным было, мы не встречали. Также в [1] разбираются самые распространённые SSL-библиотеки, с классификацией по уровню абстрагирования (низкоуровневые/высокоуровневые). Всё с диаграммами и лаконичными алгоритмами в псевдокоде. Подробно уязвимости конкретных продуктов описаны, с приведением программного кода некорректного, и указанием ошибок. Так что если вдруг у кого-то в очередной раз возникнет желание создать такую реализацию SSL/TLS-фреймворка, которая станет исключением из поговорки «хотели как лучше, а получилось как всегда», то [1] – идеальное для этого начало.

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

Одной из таких ошибок является «Недопустимый сертификат TLS» в Linux.

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

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

Однако вы также можете столкнуться с этой ошибкой при установке приложения Flatpak или использовании ref-файла Flatpak из стороннего репозитория через терминал.

Некоторые пользователи заметили эту проблему при использовании рекомендованной их организацией службы VPN для работы в Linux.

Итак, как это исправить? Почему это проблема?

Ну, технически это одна из двух вещей:

• Ваша система не принимает сертификат (и сообщает, что он недействителен).
• Сертификат не соответствует домену, к которому подключается пользователь.

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

Но если это первое, у вас есть несколько способов справиться с этим.

1. Исправьте «Недопустимый сертификат TLS» при использовании Flatpak или добавлении онлайн-аккаунтов GNOME.

Если вы пытаетесь добавить пульт Flathub или новое приложение Flatpak и замечаете ошибку в терминале, вы можете просто ввести:

sudo apt install --reinstall ca-certificates

Это должно переустановить доверенные сертификаты ЦС на случай, если какая-то проблема со списком возникла.

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

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

2. Исправьте «Недопустимый сертификат TLS» при использовании Work VPN.

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

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

Далее вам нужно будет пройти свой путь к /usr/local/share/ca-сертификаты каталог.

Вы можете создать в нем каталог и использовать любое имя для идентификации сертификата вашей организации. Затем добавьте файл .CRT в этот каталог.

Например, это usr/local/share/ca-certificates/organization/xyz.crt.

Обратите внимание, что вам нужны привилегии root для добавления сертификатов или создания каталога под CA-сертификаты каталог.

После того, как вы добавили необходимый сертификат, все, что вам нужно сделать, это обновить список поддерживаемых сертификатов, введя:

sudo update-ca-certificates

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

Подводя итог

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

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

Вы когда-нибудь сталкивались с этой ошибкой? Как ты это починил? Известны ли вам другие решения этой проблемы (возможно, что-то, за чем легко следовать)? Дайте мне знать ваши мысли в комментариях ниже.

Оригинал статьи

Ошибки браузера и предупреждения

Слишком часто при доступе к веб-сайтам встречаются такие сообщения об ошибках браузера:

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

• Google Chrome 76.0.3809.100 (macOS 10.14.6)
• Firefox 68.0.1 (macOS 10.14.6)
• Safari 12.1.2 (macOS 10.14.6)
• Edge 44.17763.1.0 (Windows 10 Корпоративная)
• Internet Explorer 11.379.11763.0 (Windows 10 Корпоративная)

Ситуации, которые мы рассмотрим, подробно описаны в содержании ниже.

Сертификат с истекшим сроком действия

В этих случаях на сервере установлен сертификат, который истек срок действия и нуждается в замене:

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

Доменное имя не соответствует сертификату

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

Решение: Убедитесь, что распространенное имя и / или альтернативное имя субъекта указанное в сертификате соответствует доменному имени веб-сайта.

Неполная цепь доверия

Если веб-сервер не имеет полного цепь доверия включая все необходимые промежуточные сертификаты, эти ошибки могут привести к:

Решение: Убедитесь, что на вашем сервере установлена ​​полная цепочка сертификатов. Пожалуйста, смотрите наш статья о диагностике и устранении этой проблемы чтобы получить больше информации.

Аннулированный сертификат

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

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

Мы надеемся, что это руководство было полезно для того, чтобы помочь вам расшифровать (иногда загадочные) сообщения об ошибках, выдаваемые веб-браузерами, когда они сталкиваются с проблемным SSL /TLS монтаж. Если у вас есть какие-либо вопросы, пожалуйста, свяжитесь с нами по электронной почте на Support@SSL.com, вызов 1-877-SSL-SECURE, или просто нажмите ссылку чата в правом нижнем углу этой страницы. Вы также можете найти ответы на многие распространенные вопросы поддержки в нашем база знаний. Спасибо, что выбрали SSL.com!

Windows 10, version 1903, all editions Windows 10, version 1809, all editions Windows Server 2019, all editions Windows 10, version 1803, all editions Windows 10, version 1709, all editions Windows 10, version 1703, all editions Windows 10, version 1607, all editions Windows Server 2016, all editions Windows 10 Windows 8.1 Windows Server 2012 R2 Windows Server 2012 Windows 7 Service Pack 1 Windows Server 2008 R2 Windows Server 2008 Service Pack 2 Windows Embedded 8 Standard Windows Embedded Standard 7 Service Pack 1 Windows Embedded POSReady 7 Еще…Меньше

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

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

SSL/TLS-протокол: хотели как лучше…

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

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

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

…а получилось как всегда: примеры провальной проверки SSL/TLS-сертификата

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

• 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-сервисы, смотри рис. 1); в том числе iOS-клиент хостинг-провайдера Rackspace.

Рисунок 1. Что такое middleware-сервисы

Кроме того, в [2] перечислено ещё больше сотни уязвимых мобильных приложений (см. рис. 2). В том числе: 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, WesternUnion, WordPress, Yahoo! Finance, Yahoo! Mail.

Рисунок 2. Небольшая выборка из списка уязвимых мобильных приложений

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

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

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

Другие распространённые уязвимости реализации SSL/TLS-протокола

Ну и конечно же нельзя забывать о том, что даже если в реализации SSL/TLS-протокола нет логических ошибок (если конечно кто-то в это ещё верит), то защиту можно обойти посредством похищения приватного ключа [12], посредством применения 0day-эксплойтов к таким вещам как клавиатуры, браузеры, операционные системы, утилиты и прошивки [3]; посредством компрометации BGP-маршрутизации [10]; или атаковать SSL/TLS по аппаратным (см. рис. 3) [8] и/или программным [9] обходным каналам.

Рисунок 3. Атака на SSL по аппаратным обходным каналам

Кроме того, злоумышленники могут выполнять практически невидимые MiTM-атаки, злоупотребляя механизмом кэширования SSL/TLS-сеансов, реализованным в классе SSLSessionCache. Этот механизм проверяет достоверность сертификатов только при первоначальном соединении; и при этом не способен должным образом аннулировать сеанс связи после удаления сертификатов с устройства. Кроме того, после перезагрузки Android-устройства (через опции «Перезапуск» или «Отключить питание») можно продолжать видеть зашифрованный трафик некоторых приложений, которые после перезагрузки не запускались, но до перезагрузки работали. Так например с Google Maps происходит. В [2] описано, как благодаря этим недочётам кэширования, злоумышленник может совершенно прозрачно для пользователя устанавливать и удалять «невидимые сертификаты», и затем устанавливать сетевое соединение с любым приложением.

Рисунок 4. Ретроспектива уязвимого шифрования

Среди других распространённых уязвимостей реализации SSL/TLS-протокола можно отметить уязвимое шифрование (см. рис. 4) [5], повторное использования GCM (Galois/Counter Mode; счётчик с аутентификацией Галуа) [6], хитрость с CNG (CryptoAPI-NG) в Schannel (см. рис. 5) [7], некорректную проверку цепочки доверия [2], некорректную проверка имени хоста [11].

Рисунок 5. Хитрость с CNG: вытягиваем секреты из Schannel

Некорректная проверка цепочки доверия представляет собой ситуацию, когда веб-приложение принимает абсолютно любой сертификат, в котором указано корректное имя хоста, не проверяя при этом каким центром сертификации он был подписан. Это позволяет перехватывать и дешифровывать пароли и/или номера кредитных карт. А в некоторых случаях даже делать инъекцию вредоносного кода. В Android-софт данная уязвимость проникает, например когда создаётся кастомизированный X509TrustManger-интерфейс, который игнорирует исключения CertificateException. Или когда разработчик софта вставляет в код WebViews-компонента вызов метода SslErrorHandler.proceed(). [2]

Некорректная проверка имени хоста представляет собой ситуацию, когда веб-приложение принимает сертификат, не удостоверившись в том, что хост, с которого этот сертификат пришёл, присутствует в списке доверенных хостов. В Android-софт данная уязвимость проникает, например когда создаётся HostnameVerifier-интерфейс, который при любых условиях возвращает TRUE. Или когда разработчик софта в вставляет в код WebViews-компонента вызов метода SslErrorHandler.proceed(). [2]

Коренная причина существования уязвимостей в SSL/TLS-протоколе

Коренная причина существования подавляющего большинства перечисленных уязвимостей – ужасный API-дизайн SSL/TLS-библиотек (в том числе JSSE, OpenSSL, и GnuTLS). А также не менее ужасный дизайн библиотек передачи данных (таких как cURL, Apache HttpClient и urllib), каждая из которых представляет собой высокоуровневую обёртку для SSL/TLS-библиотек. Не говоря уже о middleware-сервисах (таких как Apache Axis, Axis 2, или Codehaus XFire), которые ещё более высокоуровневой обёрткой являются, и которые увеличивают «снежный ком» ужасного дизайна ещё больше. Вместо того чтобы вести с прикладным разработчиком (зачастую далёким от системного программирования) диалог на понятном ему языке (в терминах конфиденциальности и аутентификации), абстрагировано от низкоуровневых подробностей реализации SSL/TLS-протокола, эти API вываливают на бедолагу кучу низкоуровневых SSL/TLS-параметров, непонятных ему. Требуют от высокоуровневого софта, чтобы он правильно выставлял низкоуровневые опции; реализовывал функции проверки имени хоста и заботился об интерпретации возвращаемых низкоуровневыми операциями значений.

В результате, прикладные разработчики используют SSL/TLS API неправильно: ошибочно интерпретируют многообразие их параметров, опций, побочных эффектов и возвращаемых значений. Например [1]:

• Amazon’овская PHP-библиотека Flexible Payments Service пытается включить проверку имени хоста – посредством установки параметра CURLOPT_SSL_VERIFYHOST в значение TRUE (в cURL-библиотеке). Однако корректное значение по умолчанию для этого параметра – 2; если же присвоить ему значение TRUE, то этому параметру незаметно для разработчика присваивается значение 1, и т.о. проверка сертификата отключается.
• PHP-библиотека PayPal Payments Standard – приобрела ту же самую ошибку; причём в тот момент, когда предыдущая, уязвимая, реализация обновлялась (т.е. одну ошибку убрали, другую добавили).
• Другой пример – это Lynx, тексто-ориентированный браузер. Он проверяет самоподписанные сертификаты, – но только в том случае, если GnuTLS’ная функция проверки сертификата возвращает отрицательное значение. Однако эта самая функция для некоторых ошибок возвращает 0; в том числе в тех случаях, когда сертификаты подписаны недоверенным органом. Из-за этого цепочка проверки доверия в Lynx – нарушена.

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

Например, в JSSE (Java Secure Socket Extension) расширенный интерфейс SSLSocketFactory API – молча пропускает проверку имени хоста, если поле «algorithm» в SSL-клиенте установлено в NULL или в пустую строку, – а не в HTTPS. Хотя данное обстоятельство упоминается в справочном руководстве JSSE, многие Java-реализации SSL-протоколов используют SSLSocketFactory без выполнения проверки имени хоста…

Ложка мёда в бочку дёгтя

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

Рисунок 6. Классификация актуальных для SSL/TLS уязвимостей

Ну и чтобы добавить ложку мёда в бочку дёгтя, стоит отметить, что в [1] подробно/понятно/популярно/грамотно описано, как SSL реализовываться должен, со ссылкой на RFC. Лучшего описания, которое бы технически точным и одновременно понятным было, мы не встречали. Также в [1] разбираются самые распространённые SSL-библиотеки, с классификацией по уровню абстрагирования (низкоуровневые/высокоуровневые). Всё с диаграммами и лаконичными алгоритмами в псевдокоде. Подробно уязвимости конкретных продуктов описаны, с приведением программного кода некорректного, и указанием ошибок. Так что если вдруг у кого-то в очередной раз возникнет желание создать такую реализацию SSL/TLS-фреймворка, которая станет исключением из поговорки «хотели как лучше, а получилось как всегда», то [1] – идеальное для этого начало.