tls файл чем открыть
Расширение файла TLS
Оглавление
Мы надеемся, что вы найдете на этой странице полезный и ценный ресурс!
1 расширений и 0 псевдонимы, найденных в базе данных
✅ TuneUp Utilities Logon Screen
Другие типы файлов могут также использовать расширение файла .tls.
По данным Поиск на нашем сайте эти опечатки были наиболее распространенными в прошлом году:
Это возможно, что расширение имени файла указано неправильно?
Мы нашли следующие аналогичные расширений файлов в нашей базе данных:
Если дважды щелкнуть файл, чтобы открыть его, Windows проверяет расширение имени файла. Если Windows распознает расширение имени файла, файл открывается в программе, которая связана с этим расширением имени файла. Когда Windows не распознает расширение имени файла, появляется следующее сообщение:
Windows не удается открыть этот файл:
Чтобы открыть этот файл, Windows необходимо знать, какую программу вы хотите использовать для его открытия.
Если вы не знаете как настроить сопоставления файлов .tls, проверьте FAQ.
🔴 Можно ли изменить расширение файлов?
Изменение имени файла расширение файла не является хорошей идеей. Когда вы меняете расширение файла, вы изменить способ программы на вашем компьютере чтения файла. Проблема заключается в том, что изменение расширения файла не изменяет формат файла.
Если у вас есть полезная информация о расширение файла .tls, напишите нам!
Расширение файла TLS
TuneUp Utilities Logon Screen
Что такое файл TLS?
Программы, которые поддерживают TLS расширение файла
Программы, обслуживающие файл TLS
Как открыть файл TLS?
Причин, по которым у вас возникают проблемы с открытием файлов TLS в данной системе, может быть несколько. К счастью, наиболее распространенные проблемы с файлами TLS могут быть решены без глубоких знаний в области ИТ, а главное, за считанные минуты. Приведенный ниже список проведет вас через процесс решения возникшей проблемы.
Шаг 1. Установите TuneUp программное обеспечение
Проблемы с открытием и работой с файлами TLS, скорее всего, связаны с отсутствием надлежащего программного обеспечения, совместимого с файлами TLS на вашем компьютере. Решение простое, просто скачайте и установите TuneUp. Полный список программ, сгруппированных по операционным системам, можно найти выше. Если вы хотите загрузить установщик TuneUp наиболее безопасным способом, мы рекомендуем вам посетить сайт TuneUp Corporation и загрузить его из официальных репозиториев.
Шаг 2. Убедитесь, что у вас установлена последняя версия TuneUp
Если проблемы с открытием файлов TLS по-прежнему возникают даже после установки TuneUp, возможно, у вас устаревшая версия программного обеспечения. Проверьте веб-сайт разработчика, доступна ли более новая версия TuneUp. Иногда разработчики программного обеспечения вводят новые форматы вместо уже поддерживаемых вместе с новыми версиями своих приложений. Это может быть одной из причин, по которой TLS файлы не совместимы с TuneUp. Самая последняя версия TuneUp обратно совместима и может работать с форматами файлов, поддерживаемыми более старыми версиями программного обеспечения.
Шаг 3. Назначьте TuneUp для TLS файлов
После установки TuneUp (самой последней версии) убедитесь, что он установлен в качестве приложения по умолчанию для открытия TLS файлов. Следующий шаг не должен создавать проблем. Процедура проста и в значительной степени не зависит от системы
Изменить приложение по умолчанию в Windows
Изменить приложение по умолчанию в Mac OS
Шаг 4. Проверьте TLS на наличие ошибок
Если вы выполнили инструкции из предыдущих шагов, но проблема все еще не решена, вам следует проверить файл TLS, о котором идет речь. Отсутствие доступа к файлу может быть связано с различными проблемами.
Если TLS действительно заражен, возможно, вредоносное ПО блокирует его открытие. Сканируйте файл TLS и ваш компьютер на наличие вредоносных программ или вирусов. TLS файл инфицирован вредоносным ПО? Следуйте инструкциям антивирусного программного обеспечения.
2. Проверьте, не поврежден ли файл
Если файл TLS был отправлен вам кем-то другим, попросите этого человека отправить вам файл. В процессе копирования файла могут возникнуть ошибки, делающие файл неполным или поврежденным. Это может быть источником проблем с файлом. Это может произойти, если процесс загрузки файла с расширением TLS был прерван и данные файла повреждены. Загрузите файл снова из того же источника.
3. Проверьте, есть ли у вашей учетной записи административные права
Некоторые файлы требуют повышенных прав доступа для их открытия. Переключитесь на учетную запись с необходимыми привилегиями и попробуйте снова открыть файл TuneUp Utilities Logon Screen.
4. Убедитесь, что в системе достаточно ресурсов для запуска TuneUp
Если система перегружена, она может не справиться с программой, которую вы используете для открытия файлов с расширением TLS. В этом случае закройте другие приложения.
5. Убедитесь, что ваша операционная система и драйверы обновлены
Современная система и драйверы не только делают ваш компьютер более безопасным, но также могут решить проблемы с файлом TuneUp Utilities Logon Screen. Возможно, что одно из доступных обновлений системы или драйверов может решить проблемы с файлами TLS, влияющими на более старые версии данного программного обеспечения.
Вы хотите помочь?
Если у Вас есть дополнительная информация о расширение файла TLS мы будем признательны, если Вы поделитесь ею с пользователями нашего сайта. Воспользуйтесь формуляром, находящимся здесь и отправьте нам свою информацию о файле TLS.
Что такое TLS
Данный текст является вольным переводом вот этой главы замечательной книги «High Performance Browser Networking» авторства Ильи Григорика. Перевод выполнялся в рамках написания курсовой работы, потому очень вольный, но тем не менее будет полезен тем, кто слабо представляет что такое TLS, и с чем его едят.
Общие сведения о TLS
Протокол TLS (transport layer security) основан на протоколе SSL (Secure Sockets Layer), изначально разработанном в Netscape для повышения безопасности электронной коммерции в Интернете. Протокол SSL был реализован на application-уровне, непосредственно над TCP (Transmission Control Protocol), что позволяет более высокоуровневым протоколам (таким как HTTP или протоколу электронной почты) работать без изменений. Если SSL сконфигурирован корректно, то сторонний наблюдатель может узнать лишь параметры соединения (например, тип используемого шифрования), а также частоту пересылки и примерное количество данных, но не может читать и изменять их.
Конкретное место TLS (SSL) в стеке протоколов Интернета показано на схеме:
После того, как протокол SSL был стандартизирован IETF (Internet Engineering Task Force), он был переименован в TLS. Поэтому хотя имена SSL и TLS взаимозаменяемы, они всё-таки отличаются, так как каждое описывает другую версию протокола.
Первая выпущенная версия протокола имела название SSL 2.0, но была довольно быстра заменена на SSL 3.0 из-за обнаруженных уязвимостей. Как уже упоминалось, SSL был разработан компанией Netscape, так что в январе 1999 года IETF открыто стандартизирует его под именем TLS 1.0. Затем в апреле 2006 года была опубликована версия TLS 1.1, которая расширяла первоначальные возможности протокола и закрывала известные уязвимости. Актуальная версия протокола на данный момент – TLS 1.2, выпущенная в августе 2008 года.
Как уже говорилось, TLS был разработан для работы над TCP, однако для работы с протоколами дейтаграмм, такими как UDP (User Datagram Protocol), была разработана специальная версия TLS, получившая название DTLS (Datagram Transport Layer Security).
Шифрование, аутентификация и целостность
Также в рамках процедуры TLS Handshake имеется возможность установить подлинность личности и клиента, и сервера. Например, клиент может быть уверен, что сервер, которые предоставляет ему информацию о банковском счёте, действительно банковский сервер. И наоборот: сервер компании может быть уверен, что клиент, подключившийся к нему – именно сотрудник компании, а не стороннее лицо (данный механизм называется Chain of Trust и будет рассмотрен в соответствующем разделе).
Наконец, TLS обеспечивает отправку каждого сообщения с кодом MAC (Message Authentication Code), алгоритм создания которого – односторонняя криптографическая функция хеширования (фактически – контрольная сумма), ключи которой известны обоим участникам связи. Всякий раз при отправке сообщения, генерируется его MAC-значение, которое может сгенерировать и приёмник, это обеспечивает целостность информации и защиту от её подмены.
Таким образом, кратко рассмотрены все три механизма, лежащие в основе криптобезопасности протокола TLS.
TLS Handshake
Перед тем, как начать обмен данными через TLS, клиент и сервер должны согласовать параметры соединения, а именно: версия используемого протокола, способ шифрования данных, а также проверить сертификаты, если это необходимо. Схема начала соединения называется TLS Handshake и показана на рисунке:
Также имеется дополнительное расширение процедуры Handshake, которое имеет название TLS False Start. Это расширение позволяет клиенту и серверу начать обмен зашифрованными данными сразу после установления метода шифрования, что сокращает установление соединения на одну итерацию сообщений. Об этом подробнее рассказано в пункте “TLS False Start”.
Обмен ключами в протоколе TLS
По различным историческим и коммерческим причинам чаще всего в TLS используется обмен ключами по алгоритму RSA: клиент генерирует симметричный ключ, подписывает его с помощью открытого ключа сервера и отправляет его на сервер. В свою очередь, на сервере ключ клиента расшифровывается с помощью закрытого ключа. После этого обмен ключами объявляется завершённым. Данный алгоритм имеет один недостаток: эта же пара отрытого и закрытого ключей используется и для аутентификации сервера. Соответственно, если злоумышленник получает доступ к закрытому ключу сервера, он может расшифровать весь сеанс связи. Более того, злоумышленник может попросту записать весь сеанс связи в зашифрованном варианте и занять расшифровкой потом, когда удастся получить закрытый ключ сервера. В то же время, обмен ключами Диффи-Хеллмана представляется более защищённым, так как установленный симметричный ключ никогда не покидает клиента или сервера и, соответственно, не может быть перехвачен злоумышленником, даже если тот знает закрытый ключ сервера. На этом основана служба снижения риска компрометации прошлых сеансов связи: для каждого нового сеанса связи создаётся новый, так называемый «временный» симметричный ключ. Соответственно, даже в худшем случае (если злоумышленнику известен закрытый ключ сервера), злоумышленник может лишь получить ключи от будущих сессий, но не расшифровать ранее записанные.
На текущий момент, все браузеры при установке соединения TLS отдают предпочтение именно сочетанию алгоритма Диффи-Хеллмана и использованию временных ключей для повышения безопасности соединения.
Следует ещё раз отметить, что шифрование с открытым ключом используется только в процедуре TLS Handshake во время первоначальной настройки соединения. После настройки туннеля в дело вступает симметричная криптография, и общение в пределах текущей сессии зашифровано именно установленными симметричными ключами. Это необходимо для увеличения быстродействия, так как криптография с открытым ключом требует значительно больше вычислительной мощности.
Возобновление сессии TLS
Как уже отмечалось ранее, полная процедура TLS Handshake является довольно длительной и дорогой с точки зрения вычислительных затрат. Поэтому была разработана процедура, которая позволяет возобновить ранее прерванное соединение на основе уже сконфигурированных данных.
Начиная с первой публичной версии протокола (SSL 2.0) сервер в рамках TLS Handshake (а именно первоначального сообщения ServerHello) может сгенерировать и отправить 32-байтный идентификатор сессии. Естественно, в таком случае у сервера хранится кэш сгенерированных идентификаторов и параметров сеанса для каждого клиента. В свою очередь клиент хранит у себя присланный идентификатор и включает его (конечно, если он есть) в первоначальное сообщение ClientHello. Если и клиент, и сервер имеют идентичные идентификаторы сессии, то установка общего соединения происходит по упрощённому алгоритму, показанному на рисунке. Если нет, то требуется полная версия TLS Handshake.
Процедура возобновления сессии позволяет пропустить этап генерации симметричного ключа, что существенно повышает время установки соединения, но не влияет на его безопасность, так как используются ранее нескомпрометированные данные предыдущей сессии.
Однако здесь имеется практическое ограничение: так как сервер должен хранить данные обо всех открытых сессиях, это приводит к проблеме с популярными ресурсами, которые одновременно запрашиваются тысячами и миллионами клиентов.
Для обхода данной проблемы был разработан механизм «Session Ticket», который устраняет необходимость сохранять данные каждого клиента на сервере. Если клиент при первоначальной установке соединения указал, что он поддерживает эту технологию, то в сервер в ходе TLS Handshake отправляет клиенту так называемый Session Ticket – параметры сессии, зашифрованные закрытым ключом сервера. При следующем возобновлении сессии, клиент вместе с ClientHello отправляет имеющийся у него Session Ticket. Таким образом, сервер избавлен от необходимости хранить данные о каждом соединении, но соединение по-прежнему безопасно, так как Session Ticket зашифрован ключом, известным только на сервере.
TLS False Start
Технология возобновления сессии бесспорно повышает производительность протокола и снижает вычислительные затраты, однако она не применима в первоначальном соединении с сервером, или в случае, когда предыдущая сессия уже истекла.
Для получения ещё большего быстродействия была разработана технология TLS False Start, являющаяся опциональным расширением протокола и позволяющая отправлять данные, когда TLS Handshake завершён лишь частично. Подробная схема TLS False Start представлена на рисунке:
Важно отметить, что TLS False Start никак не изменяет процедуру TLS Handshake. Он основан на предположении, что в тот момент, когда клиент и сервер уже знают о параметрах соединения и симметричных ключах, данные приложений уже могут быть отправлены, а все необходимые проверки можно провести параллельно. В результате соединение готово к использованию на одну итерацию обмена сообщениями раньше.
TLS Chain of trust
Пусть теперь Алиса получает сообщение от Чарли, с которым она не знакома, но который утверждает, что дружит с Бобом. Чтобы это доказать, Чарли заранее попросил подписать собственный открытый ключ закрытым ключом Боба, и прикрепляет эту подпись к сообщению Алисе. Алиса же сначала проверяет подпись Боба на ключе Чарли (это она в состоянии сделать, ведь открытый ключ Боба ей уже известен), убеждается, что Чарли действительно друг Боба, принимает его сообщение и выполняет уже известную проверку целостности, убеждаясь, что сообщение действительно от Чарли:
Описанное в предыдущем абзаце и есть создание «цепочки доверия» (или «Chain of trust», если по-английски).
В протоколе TLS данные цепи доверия основаны на сертификатах подлинности, предоставляемых специальными органами, называемыми центрами сертификации (CA – certificate authorities). Центры сертификации производят проверки и, если выданный сертификат скомпрометирован, то данный сертификат отзывается.
Из выданных сертификатов складывается уже рассмотренная цепочка доверия. Корнем её является так называемый “Root CA certificate” – сертификат, подписанный крупным центром, доверие к которому неоспоримо. В общем виде цепочка доверия выглядит примерно таким образом:
Естественно, возникают случаи, когда уже выданный сертификат необходимо отозвать или аннулировать (например, был скомпрометирован закрытый ключ сертификата, или была скомпрометирована вся процедура сертификации). Для этого сертификаты подлинности содержат специальные инструкции о проверке их актуальности. Следовательно, при построении цепочки доверия, необходимо проверять актуальность каждого доверительного узла.
Механизм этой проверки прост и в его основе лежит т.н. «Список отозванных сертификатов» (CRL – «Certificate Revocation List»). У каждого из центров сертификации имеется данный список, представляющий простой перечень серийных номеров отозванных сертификатов. Соответственно любой, кто хочет проверить подлинность сертификата, попросту загружает данный список и ищет в нём номер проверяемого сертификата. Если номер обнаружится – это значит, что сертификат отозван.
Таким образом, в данной статье рассмотрены все ключевые средства, предоставляемые протоколом TLS для защиты информации. За некоторую отсебятину в статье прошу прощения, это издержки изначальной цели выполнения перевода.
Обновление для того, чтобы включить протоколы TLS 1.1 и TLS 1.2 в качестве безопасных протоколов по умолчанию в WinHTTP в Windows
Это обновление поддерживает TLS 1.1 и TLS 1.2 в Windows Server 2012, Windows 7 Пакет обновления 1 (SP1) и Windows Server 2008 R2 SP1.
Об этом обновлении
Приложения и службы, написанные с помощью подключений WinHTTP для SSL, которые используют флаг WINHTTP_OPTION_SECURE_PROTOCOLS, не могут использовать протоколы TLS 1.1 или TLS 1.2. Это значит, что определение этого флага не включает эти приложения и службы.
Это обновление добавляет поддержку записи реестра DefaultSecureProtocols, с которой системный администратор может указать, какие протоколы SSL следует использовать WINHTTP_OPTION_SECURE_PROTOCOLS флажком.
Это позволяет некоторым приложениям, которые были встроены для использования флага WinHTTP по умолчанию, использовать новые протоколы TLS 1.2 или TLS 1.1 без необходимости обновления приложения.
Это касается некоторых Microsoft Office приложений, которые открывают документы из библиотеки SharePoint или веб-папки, туннель IP-HTTPS для подключения DirectAccess и другие приложения с помощью таких технологий, как WebClient, с помощью WebDav, WinRM и других приложений.
Для этого обновления необходимо настроить компонент Secure Channel (Schannel) в Windows 7 для поддержки TLS 1.1 и 1.2. Так как эти версии протоколов не включены по умолчанию в Windows 7, необходимо настроить параметры реестра, чтобы приложения Office могли работать с TLS 1.1 и 1.2.
Это обновление не изменит поведение приложений, которые вручную настраивают безопасные протоколы, вместо того чтобы помечать их по умолчанию.
Как получить это обновление
Важно!Если после установки обновления вы установили языковой пакет, необходимо переустановить это обновление. Поэтому мы рекомендуем установить все необходимые языковые пакеты перед установкой обновления. Дополнительные сведения см. в теме «Добавление языковых пакетов в Windows».
Способ 1. Обновление Windows
Это обновление предоставляется в качестве рекомендуемых обновлений для Windows. Дополнительные сведения о запуске Обновления Windows см. в сведениях о том, как получить обновление через Windows Update.
Способ 2. Каталог обновлений Майкрософт
Чтобы получить автономный пакет для этого обновления, перейдите на веб-сайт каталога обновлений Майкрософт.
Обновление подробных сведений
Предварительные условия
Чтобы применить это обновление, необходимо установить Пакет обновления 1 для Windows 7 или Windows Server 2008 R2.
Нет предварительных условий для применения этого обновления в Windows Server 2012.
Сведения о внесении изменений в реестр
Чтобы применить это обновление, необходимо добавить подкод DefaultSecureProtocols реестра.
Примечание Для этого можно добавить подкайку реестра вручную или установить «Простое исправление», чтобы заполнить его.
Требование перезагрузки
После установки этого обновления может потребоваться перезагрузить компьютер.
Сведения о замене обновлений
Это обновление не заменяет ранее выпущенное обновление.
Дополнительная информация
Для соответствия требованиям в отрасли платежных карт требуется TLS 1.1 или TLS 1.2.
Дополнительные сведения о флаге WINHTTP_OPTION_SECURE_PROTOCOLS см. в параметрах флажков.
Как работает запись реестра DefaultSecureProtocols
Внимание! В этом разделе, описании метода или задачи содержатся сведения о внесении изменений в реестр. Однако неправильное изменение параметров реестра может привести к возникновению серьезных проблем. Поэтому следует точно выполнять приведенные инструкции. В качестве дополнительной защитной меры перед изменением реестра необходимо создать его резервную копию. Это позволит восстановить реестр в случае возникновения проблем. Дополнительные сведения о том, как создать и восстановить реестр, см. в сведениях о том, как создать его и восстановить в Windows.
Когда приложение указывает WINHTTP_OPTION_SECURE_PROTOCOLS, система проверяет запись defaultSecureProtocols и, если есть, переопределяет протоколы по умолчанию, указанные приложением WINHTTP_OPTION_SECURE_PROTOCOLS, с протоколами, указанными в записи реестра. Если запись реестра не существует, winHTTP будет использовать существующие значения по умолчанию для Win WINHTTP_OPTION_SECURE_PROTOCOLS HTTP. Эти значения WinHTTP по умолчанию следуют за существующими правилами приоритета и имеют приоритет, за которые SCHANNEL отключил протоколы и протоколы, установленные для каждого приложения winHttpSetOption.
Примечание.Установщик hotfix не добавляет значение DefaultSecureProtocols. Администратор должен вручную добавить запись после определения протоколов переопределения. Вы также можете установить легкое исправление, чтобы автоматически добавить запись.
Запись реестра DefaultSecureProtocols можно добавить следующим образом:
На компьютерах с оси x64 к пути Wow6432Node также необходимо добавить defaultSecureProtocols:
Значением реестра является точная карта DWORD. Используемая величина определяется добавлением значений, соответствующих нужным протоколам.
Введение в TLS для п̶р̶а̶к̶т̶и̶к̶о̶в̶ Патриков (часть 2)
Сегодня мы продолжаем разбираться, как устроен TLS и чем он может быть полезен Патрику и его друзьям. Первую часть истории можно прочитать тут.
Мы остановились на том, что сервер отправил свою часть TLS-handshake клиенту. Теперь клиент должен прежде всего проверить сертификаты – и это самая тяжелая из вещей, которые ему обязательно надо сделать.
Certificate verification: chain
Возможно, вы обратили внимание на формулировку: посылается не сертификат, а сертификаты – сейчас станет понятно, почему (в общем-то, догадаться нетрудно).
Сертификат подписывается ишьюером – тем человеком, который этот сертификат выписал. Для того, чтобы считать этот сертификат правильным и все данные в нем верными, мы должны доверять этому ишьюеру – то есть верить, что он всякую фигню не подписывает. Чтобы вся эта система работала, придумали такую концепцию как корневой сертификат (root certificate).
Root certificate
В принципе, это даже не обязательно должен был быть сертификат – вполне хватило бы просто пары ключей. Потому что единственное, что нам от него надо – это знать, что такому-то центру сертификации (Certificate Authority, CA) соответствует такой-то публичный ключ. Тогда мы можем проверить все сертификаты, которые он выписал, и если мы считаем, что CA не врет, значит, и в сертификатах всё верно. Так что на самом деле Root CA Certificate это такой же сертификат, как и все, просто самоподписанный.
Откуда появляется вера в центры сертификации как в «хороших парней»? Все просто договорились, что вот таким-то организациям можно доверять. У каждого клиента есть список соответствия CA и публичного ключа. Таким образом, каждый клиент знает, что есть вот такой чувак и ключ для него такой. И так это всё и проверяется. То есть – просто записано, просто договорились, что верим.
Intermediate certificate
Следующий в цепочке – Intermediate Certificate. Зачем он нужен? Дело в том, что в случае, если с Root CA Certificate что-то пошло не так, очень сложно его поменять. Центру сертификации нужно сделать новый приватный ключ, новый публичный ключ, всем это всё нужно обновить и так далее, это утомительно и это ломает всю секьюрити. И вообще, чем меньше мы работаем с машиной, на которой находится этот CA, тем меньше шансов, что этот приватный ключ украдут. Поэтому CA выписывают промежуточные сертификаты и уже с их помощью подписывают конечные (end-entity) сертификаты для вашего домена. Такая цепочка происходит очень часто и сертификат для нашего Патрика может быть подписан Губкой Бобом, а сертификат Губки Боба – Мистером Крабсом (а Губка Боб работает на мистера Крабса, как мы знаем из мультика). То есть это, в принципе, может быть вообще одна организация. Для того, чтобы всё это провалидировать, клиенту нужно всю эту цепочку составить и проверить: взять ключик рутового сертификата, проверить, что промежуточный правильный и подпись валидна, потом взять ключик промежуточного сертификата и проверить конечный сертификат.
Цепочка должна присутствовать в списке сертификатов, которые сервер отсылает. По факту бывает всякое. Бывает, что не посылаются. Symantec, например, очень любил в бесплатные сертификаты не вставлять промежуточный. И поэтому в браузерах ничего не работало.
На самом деле, для большей производительности, поиск производится не по ишьюеру и субъекту, а с помощью расширений (extensions) – там вся эта информация лежит в виде хэшей, поэтому всё происходит быстрее. Но иногда хэшей нет, тогда происходит поиск по текстовым полям субъекта и ишьюера, и вот здесь могут случаться атаки.
Поэтому если вы видите сертификат, в котором этих полей нет, можно возбудиться и что-нибудь покопать – возможно, там всё не очень хорошо.
Basic Constraints
Еще одна штука, которая улучшает секьюрити (и с этим были серьезные баги до 2003 года в Internet Explorer): в промежуточных сертификатах в поле Basic Constraints должно быть написано CA: true, что означает, что этим сертификатам разрешено подписывать конечные сертификаты. Если этой штуки нет, то клиент при проверке цепочки должен сказать: «я не могу принять этот промежуточный сертификат» – несмотря на то, что все подписи совпадают, в субъекте всё совпадает и т.д. Этой штуки нет – до свидания. Internet Explorer не делал этой проверки и люди страдали из-за этого. Казалось бы, мелочь! Но тем не менее.
Еще раз, если кто не понял: если эту штуку не проверять, я могу получить сертификат от Let’s Encrypt и потом этим сертификатом подписывать что угодно. И цепочка будет валидная.
CAPI и SCVP
Еще про верификацию и про цепочку. Есть маленькая особенность – похвалим здесь Windows. Если сервер не отдал сертификат, в обычном (традиционном) подходе сертификат нам взять неоткуда, цепочки нет, всё сломалось. Так вот, в Windows есть такая штука как Certificate API, и она может достроить цепочку, взяв промежуточные сертификаты из своего хранилища. То есть, даже если сервер не передал, но у тебя в хранилище они есть, то цепочка построится и всё будет работать. Достаточно удобная штука, можно пересылать меньше информации, не уменьшая секьюрити.
Как эти сертификаты туда попадают? Либо залиты в хранилище, либо из сертификата, установленного на сервере. Например, в Plesk, если получить сертификат от Comodo и поставить его на домен – в хранилище попадет промежуточный сертификат от Comodo.
Ну и еще люди, которым Windows нравится, придумали SCVP (Server-based Certificate Validation Protocol). В действительности не работает почти ни у кого и нигде – в смысле глобально и массово, — но как концепция есть. Более того, есть продукты, которые это делают, и даже в каких-то сетях это может быть настроено. Это сервис, который за тебя эту цепочку строит и частично даже проверяет, что удобно. Если там заявлена поддержка DPV (Delegated Path Validation), то он цепочку еще и провалидирует. То есть, клиенту надо этому сервису отправить сертификат и получить ответ – продолжать сессию или рвать.
Предположительно это могло бы всё ускорить, но из-за того, что сервису тоже надо как-то доверять, идея глохнет. И всё-таки она была.
Итак, вот у нас получается такая вот цепочка.
Прежде всего мы проверяем, что с подписями у нас всё нормально: выстраиваем цепочку, проверяем подписи – и считаем, что содержимое сертификатов верно. Дальше нам надо проверить конечный сертификат. Промежуточный нам проверять не надо, потому что мы идем к Патрику и проверить нам надо только самый последний сертификат.
Certificate verification
Подпись
Про подпись уже упоминалось. Это вот пример, как это может выглядеть структурно: вот есть подпись, вот алгоритм этой подписи, мы берем какую-нибудь библиотечку, которая умеет с этим работать и проверяем, что тело сертификата подписано вот этой подписью и что всё действительно хорошо.
Дальше мы из этого сертификата достаем следующие поля и начинаем проверять их. Вы видите, что ишьюер у нас – Global Sign, мы взяли его ключик и проверили, что подпись работает.
Не протух ли сертификат?
После этого нам надо проверить, что сертификат не протух – это логично, ведь сертификаты выдаются на какое-то время.
Сейчас все certificate Authority договорились, что максимальный срок – 2 года (раньше было 3). Еще дальше они хотят сделать 1 год, а некоторые радикалы хотят, чтобы был месяц. Let’s Encrypt сейчас на 3 месяца выдает. А совсем радикальные радикалы хотят на каждое соединение новый сертификат выписывать. Почему некоторые люди так этим озабочены, станет понятно попозже, когда дойдем до пункта «Не отозван ли сертификат?». Еще из интересного – сертификат может быть выписан на будущее, так что надо проверять дату старта (по-хорошему).
Тот ли домен?
Тут всё понятно: если домен Wikipedia, а сертификат выписан на домен Plesk, то что происходит вообще? Кажется очевидным и капитанистым, но было несколько багов, когда клиенты это не проверяли. Сейчас, по счастью, такого бардака уже нет и стараются проверять все. Но опять-таки есть нюанс. Это SAN – Subject Alternative Name.
Subject Alternative Name
В subject у нас может быть только один домен — в нашем случае там, кстати, есть звездочка, про это попозже, это так называемый wildcard-сертификат. Итак, в субъекте доменное имя одно, но если хочется много (например, у нас есть сабдомены и/или разные имена типа plesk.ru, plesk.com и т.д., и хочется один сертификат на это всё иметь) – тогда есть возможность всё это запихать в это поле SAN. Но нужно, чтобы это работало, во-первых, на сервере, во-вторых, на клиенте. Потому что, чтобы сервер отдал правильный сертификат, клиент должен ему как-то передать, куда конкретно он пришел. Это важно. И когда сервер выбирает сертификат, он должен знать Subject Alternative Name, потому что, может быть, имя домена – там. За всё это отвечает такое расширение TLS, как SNI (Server Name Indication), на эту тему есть 4 RFC, – короче, возможность есть, но не все это поддерживают. Например, у продуктов на GNU TLS с поддержкой SNI всё неплохо, а вот на OpenSSL многие не поддерживают. Кажется, это потому, что в GNU TLS это проще.
Ладно, мы, допустим, всё это умеем. Всё хорошо, всё проверили, пришли сюда.
Как мы должны проверять wild-card? Отдельный момент. Можно просто запомнить: звёздочка это не вообще звёздочка, а только один сегмент.
Еще интересный момент, что www.domain.com – это отдельное имя, и если мы хотим по нему ходить, его надо защитить отдельно. Не у всех это в голове есть.
Ну и да, как уже говорилось, серверу надо найти сертификат для домена. Как работает SNI – клиент в определенном заголовке передает, какой домен нужен. Поэтому это доступно даже на уровне TCP, где доменных имен нет – в TLS есть, а в TCP (и в FTP) нет. Поэтому если мы делаем TLS, мы можем передать имя, но мало передать имя – надо же серверу найти этот сертификат, и здесь есть разные нюансы с разными продуктами. Продукты на Windows нередко находят этот сертификат в хранилище сертификатов, а для продуктов на Linux нужно указывать конфиги, где брать эти сертификаты. И здесь тоже есть разные проблемы. Мы недавно чинили SAN в Postfix – там может быть очень простая вещь — мы, например, указываем, что для domain.com сертификат такой, а человек приходит c mail.domain.com. А mail.domain.com – это не domain.com. Всё, сервер не может найти сертификат, всё развалилось. То есть кому-то надо указывать, кто-то сам находит. Для тестирования и разработки это важная вещь в аспекте SAN.
Тот ли тип использования?
Кроме проверки, тот ли это домен, не истёк ли срок годности и валидна ли подпись, из таких вещей, которые достаточно просто делаются, у нас еще есть пункт «тот ли тип использования».
Сертификаты бывают разные. То есть, если в Key Usage не указаны вот эти вот два параметра, то это – по идее! – должно влиять на то, как клиент с этим работает.
Key agreement – это как раз когда мы выписываем сеансовые ключи и договариваемся о них. Обычно вся эта коммуникация подписывается или шифруется вот этим вот публичным ключом, который чуть выше. Но если в key usage не прописан key agreement, то это означает, что ишьюер этого сертификата запрещает использовать этот сертификат для вот этого назначения. Сейчас на практике это почти не встречается, то есть эти вещи у большинства сертификатов одинаковые, но тем не менее — в принципе могут быть и другие. И бывает, что сертификат НЕ подходит для чего-то. Для чего он подходит – написано здесь. Клиент должен это проверять. Кстати, нередко бывает, что в extended key usage вот это вот ‘TLS Web Server Authentication’ у промежуточных сертификатов отсутствует.
Не отозван ли сертификат?
Самая интересная вещь – мы дошли до нее, ура! Самая прикольная, самая неработающая 🙂
Если говорить кратко, то сейчас здесь во всей инфраструктуре TLS очень большие проблемы, потому что: не работает ничего. И эту проблему как раз и хотят решать тем, чтобы срок действия сертификата сделать очень маленьким. Когда нужно отзывать сертификат? Чаще всего – когда ваш приватный ключ утек. Ваш приватный ключ утек – вы попали. Надо сертификат отозвать, потому что если не отозвать, тот кто украл ваш ключ, сможет подсовывать клиентам ваш сертификат и представляться вами. Надо сказать: чуваки, я поменял свой ключ – тот сертификат не действителен!
Если сделать время действия сертификата очень маленьким, то в принципе можно не отзывать, а подождать, когда он кончится. Отсюда все эти экстремальные предложения с минутами и часами. Ну, а если у тебя сертификат на 3 года, а ключ украли на второй день – то три года кто-то сможет представляться тобой.
Как же проверить, отозван сертификат или нет?
Certificate Revocation List
Изначально сделали что (и это до сих пор работает, и это до сих пор по-хорошему надо проверять): Certificate Revocation List. То есть тупо список сертификатов (их серийные номера с ишьюерами), которые отозваны. Ну, вы представляете, сколько за время существования SSL и TLS было отозвано сертификатов… очевидный минус в том, что список здоровый. Для того, чтобы понять, отозван сертификат или нет, тебе этот список надо откуда-то скачать, а значит, надо доверять тому, у кого качаешь, ведь там могут подменить, — потом себе вгрузить, распарсить и проверить, что вот этого сертификата, который ты проверяешь, там нет – то есть посмотреть тебе надо всё. Поэтому это всё медленно, а еще это единая точка отказа. Есть специальные атаки, когда вот этот URL, по которому надо проверять CRL, просто DDOS-ят, клиенты не могут скачать список и расценивают ошибки скачивания как «всё хорошо» («нет списка – значит, всё хорошо»).
Поэтому этот механизм считается устаревшим, но в стандартах всё еще есть и по-хорошему надо бы его использовать. Google Chrome на него забил уже давно, Mozilla тоже.
Есть другая штука – OCSP. Это примерно то же самое, только вместо того, чтобы качать файлик, делается специальный запрос на то, чтобы та сторона сказала тебе – отозван сертификат или нет. То есть, клиенту стало проще, а вот чуваку на той стороне проще не стало, потому что вместо того, чтобы просто отдавать список, надо по этому списку проверять запрос и говорить «да» или «нет». Если основываться на CRL, другого варианта, кроме этого, особо-то и нет – и это действительно лучше, чем чистый CRL. Тем не менее, Chrome забил и на это, остальные пока используют.
OCSP stapling
Это примерно в ту же степь, но тут мы уже начинаем уходить от структуры Certificate Authority. То есть возлагаем эту проверку на сервер. Как это работает: сервер периодически ходит по этому OSCP URL-у и говорит: «OCSP-resolver, посмотри-ка, вот этот мой сертификат – в отозванных или нет?». OCSP-resolver отвечает подписанным ответом, наш сервер его запоминает, и когда клиент приходит, ему отдаётся этот ответ. То есть у клиента есть подписанный ответ и в нём написано, что всё хорошо. Из-за того, что серверов меньше, чем клиентов и сервер может на какое-то время это кэшировать, нагрузка на всех становится меньше.
Тут есть тоже некоторые проблемы: текущий механизм — это только на один сертификат, а у нас цепочка (и это важно). А еще, из-за того, что мой сервер отвечать на это не обязан, клиент не может рассчитывать на то, что OSCP-stapling точно будет. И поэтому отказаться ни от CRL, ни от OCSP не получается – просто потому, что серверы не обязаны опрашивать и отвечать. Ну и еще один аспект: если в вебе с этим нормально, то в почте всё плохо, а в FTP даже слов таких не знают.
Проблема того, что сервер не обязан отвечать, может решиться добавлением в сертификат еще одного поля – так как оно еще не утряслось, у него просто номер, — в котором мы говорим клиенту, что сервер таки обязан ответить, и если он не ответил, считать этот сертификат невалидным.
Вот это всё вместе теоретически может начать работать, но пока еще мало распространено.
Google и Mozilla, так как им всё это не нравится, сделали свой CRL. И зашили его в браузер. Огонь вообще! Это работает быстро, ну и на этом все плюсы заканчиваются. Для того чтобы не помереть, они не запихивают в него DV-сертификаты. То есть если DV-сертификат отозван, они считают – ну и ладно. Так что если DV-сертификат отозван и при этом нет OSCP-степлинга, Chrome об этом не скажет – он посчитает этот сертификат нормальным. На самом деле, правильно пользоваться OSCP-степлингом и OCSP Must Staple флагом в сертификате. С ним тоже не всё просто — большинство генераторов CSR сейчас не умеют его указывать, а большинство Сertificate Authority не умеют его выписывать.
Сertificate Transparency
Итак, всё хорошо, но Google не был бы Google, если бы не придумал еще одну технологию конкретно для себя. Она называется Сertificate Transparency. Откуда что идет: Google очень беспокоится о том, чтобы кто-нибудь не выписал плохой сертификат на него самого – чтобы именно Google не пострадал от того, что кто-то там выписывает какие-то нехорошие сертификаты. И вот с помощью Сertificate Transparency каждый владелец домена (и вообще кто угодно) может посмотреть, какие сертификаты на этот домен были выписаны. Дальше он может этот сертификат взять и с ним что-нибудь сделать. Например, проверить, хороший он или нет. Ну и возбудиться (или не возбудиться).
Это не только технология, но и набор процессов. То есть Google говорит: ребята, вот у нас есть Сertificate Transparency, мы в него записываем только нормальные сертификаты – такие, где цепочка есть, цепочка правильная и всё нормально. Мы можем время записи Сertificate Transparency Log запихать в сертификат, чтобы клиент мог четче посмотреть, что вот этот сертификат в Transparency Log должен быть тогда-то. Мы гарантируем, что это вот эта штука не редактируема обратно (из-за того, что блокчейн) – ну то есть нельзя взять и подменить старые записи, можно только добавлять новые. И давайте, ребята, кто-нибудь из вас будет периодически ходить по этому логу, и проверять, что там всё нормально, а если что-то не так, говорить нам и мы будем это править. А другие ребята пусть держат у себя всё это, потому что надо, чтобы было много мощностей на вот эту вот штуку.
Сейчас Сertificate Transparency поддерживает DigiCert, недавно начал поддерживать Let’s Encrypt, а вот из валидаторов практически никого нет, Google сам всё это делает. Когда всё это заработает в полную силу и валидаторов станет больше, то плохих сертификатов должно стать меньше, потому что кто-нибудь будет возбуждаться. На картинке показан HTTP-заголовок Excpect-CT, его можно отдать и клиент будет обязан сходить в Сertificate Transparency и проверить, что вот этот сертификат в нем указан. А из-за того, что там еще есть timestamp, сложнее становится запихать плохую запись в Сertificate Transparency. Но, опять-таки — это не очень помогает с Revocation, можно сказать, вообще не помогает. Это только про то, что все сертификаты, выписанные на домен, владелец домена может посмотреть и возбудиться.
Вот такая вот штука. По большому счету – хайпа много, но ничего она не решает. А что решает (каким-то образом), но не используется – это DANE.
Дополнительная защита
Вся структура TLS является уязвимой в одной точке – точке доверия, то есть вот эти вот сертификационные центры, рутовые сертификаты — если с ними что-то не то, всё разлетелось. Есть по сути две попытки с этим как-то бороться.
Первая попытка, собственно, DANE – хранить информацию о сертификатах в DNS.
Почему это должно работать – потому что DNSSEC. Certificate Authority здесь могут вообще в принципе отсутствовать, можно даже без них. Сейчас DANE используется примерно для того же, для чего HPKP (следующий пункт рассказа) – для того, чтобы в базе данных DNS держать информацию о том, какой публичный ключ должен быть у сертификата. То есть это, по существу, еще одна связочка. Можно указать: «мой публичный ключ – такой-то», и когда клиент получит сертификат и там посмотрит ключ, он сможет из DNS посчитать хэш и если не совпадет, заорать – меня хакнули. Так что, чтобы в случае с DANE украсть сертификат, надо еще и на стороне DNS что-то сломать. В этом плане эффект есть. В Голландии, например, DANE обязателен для сервисов, которые предоставляют почту и связаны с госструктурами.
Давайте посмотрим на запись детальнее. Здесь есть разные поля: можно указать, что сертификат должен быть выписан именно этим Authority – это уже немного помогает. Принцип тот же, что и у САА, только уже после выписки. Это не зависит от того, смотрит ли ишьюер в САА запись или нет. В DANE написано: клиент обязан посмотреть, что сертификат, который он получил, выписан определенным Certificate Authority, и если это не так – ничего не выйдет. Всё зависит только от клиента и не зависит от CA. Это плюс.
Из остального остановимся на Domain issued certificate. В принципе, если бы всё хорошо работало (здесь ключевая проблема с DNSSEC), то мы бы могли указывать в своей DNS-записи свой сертификат и не зависеть ни от кого. То есть, если я владею доменом, сгенерировал хотя бы самоподписанный сертификат, указал его вот сюда, и DNSSEC работает нормально, то клиент доверяет моей DNS-записи и сертификат берет оттуда. Всё, CA не нужны. Бизнес на сертификатах рушится, денег никаких нет 🙂
Однако это всё не работает. Во-первых, есть EV-сертификаты, для которых всё-таки хочется проверить организацию. Во-вторых, проблема доверия уходит с Certificate Authority на инфраструктуру DNSSEC, которая считается недостаточно рабочей, потому что она мало распространена, на нее все забили, а еще там тоже есть уязвимости.
В общем, спорная вещь, одно меняем на другое, из-за этого теряем EV-сертификаты. Возможно, поэтому это не слишком распространилось.
Дальше еще есть одна интересная вещь, называется HPKP.
Идея на картинке: мы в HTTP-заголовке отдаем собственно хэши сертификатов, которые клиент должен проверить, и если публичный ключ сертификата имеет другой хэш (то есть его нет среди перечисленных) — до свидания. Google в HPKP разочаровался и Chrome это не поддерживает. На этом можно закончить, хотя вообще выглядит интересно — если я знаю, какие у меня есть сертификаты, мне очень легко этот заголовок отдать, и это должно повышать секьюрити по идее.
Policy
Как мы уже знаем, если браузер смотрит в это поле и находит там определенные сочетания циферок и буковок, то он должен понять, что это EV-сертификат и, возможно надо сделать дополнительные вещи. Вот тут у нас указан Global Sign Repository – и иногда браузер должен сходить по указанному там адресу и получить ответ, что всё хорошо. Это в основном работает для EV-сертификатов, для OV браузеры это часто просто игнорируют, ну и в DV этих полиси-то и нет собственно. Для чего это надо вам – просто для информации.
Ответ клиента
Итак, Патрик проверил сертификаты и начинает отвечать Губке Бобу.
Если у клиента просили сертификаты, он их отдает. Дальше он отдает информацию для того, чтобы сделать ключики – так же, как сервер, clientKeyExchange. Поле CertificateVerify – неинтересная инфа на тему «как валидировать сертификат», в TLS 1.3 она и выглядит-то уже по-другому, потому что не сильно нужна.
После этого клиент переходит на шифрованный канал и посылает сообщение Finished – «я готов к шифрованному каналу». Сервер проверяет это сообщение – что там всё нормально, как договорились, что оно расшифровывается, что не успели на данном этапе ничего подменить и это всё еще Патрик, — тоже переходит на шифрованный канал и отдает свое Finished-сообщение, которое в свою очередь проверяет клиент. И после этого идет общение уже данными приложений по шифрованному каналу.
TLS-handshake full vs resumed
В этой статье мы не стали подробно останавливаться на том, как выбираются сессионные ключи. Там тоже много работы на процессоре, много вычислительных действий – и следующая проблема после безопасности это производительность. Всё это происходит медленно, особенно, если ходить в CRL списки и делать прочие дополнительные проверки. А если еще цепочка сертификатов огромная, то всё может быть прям совсем медленно, и с этим надо что-то делать.
Session ID
До TLS 1.3 для решения этой проблемы использовались укороченные сессии. Когда сервер отвечает клиенту, он отдает ему Session ID. Если у клиента этот Session ID тоже есть, он отсылает его серверу и вот эта часть, которая в рамочке, пропускается. Потому что сервер запоминает контекст всей этой штуки и продолжает так, как будто это уже произошло. Сессионный ключ выбран, и клиенту не надо проверять сертификат, потому что он есть в этом сессионном ключе. Если окажется, что сертификат там какой-то другой, то выбранный сессионный ключ не будет работать и клиент просто не сможет расшифровать сообщение сервера.
Так это всё работает. Это побыстрее, но тоже есть проблемы, — возрастает нагрузка на сервер, ну и есть атаки с перехватом Session ID. Потому что этот Session ID идет по открытому каналу.
Session ticket
Еще для ускорения можно использовать Session Ticket — это в принципе то же самое, что и Session ID, только передается зашифрованный контекст, а не циферка, которую можно украсть. Бывает, что сессию установить не удалось, тогда придет алерт. С ними тоже связаны атаки на TLS, потому что алерты имеют определенную структуру и определенный размер. Если алерт произошел на этапе, когда уже трафик идет зашифрованным, то из-за того, что алерт понятной структуры и злоумышленник может знать, что ему в этом алерте отвечают – задача расшифровывания становится сильно проще. Поэтому в TLS 1.3 это уже не используется.
Reinit
Что еще бывает в TLS-handshake в принципе? Иногда серверу бывает нужно инициализировать сессию повторно – чаще всего тогда, когда сертификат клиента был не нужен и вдруг стал нужен. Тогда сервер говорит: давай перезапустим. Ну и клиент может сказать еще раз Client Hello. В TLS 1.3 это тоже убрали, потому что тоже были атаки – атаки были везде!
Что в TLS 1.3?
Все упомянутые трудности решаются использованием TLS 1.3. Половины проблем вообще нет, всё проще, красивее, всё прям отличненько. Но TLS 1.3 еще распространен маловато. Самые важные отличия TLS 1.3 (их очень много, они везде, поэтому только самые важные):
В общем, это наше будущее, там всё получше и попроще, самое главное. Но пока оно еще не везде наступило.
Как всё это тестить?
Инструментов для тестирования много, большинство из них не очень, вот эти плюс-минус ничего:
Маленький бонус
На картинку тоже не всё влезло – тема очень большая, но на практике можно фокусироваться таким образом, чтобы на любом уровне понимать идею в целом и смочь разгрести что происходит, понять, что вам нужно доучить, что сейчас конкретно нужно узнать и всё вот это. Эта картинка — про ключевые слова. Из литературы можно рекомендовать очень крутую статью на русском языке «Ключи, шифры, сообщения: как работает TLS» – прочитать целиком вряд ли удастся, но в качестве справочника пригодится. Открыл, нашел что надо, почитал, ключевые слова узнал, пошел в википедию и на английском прочитал (на русском почему-то плохо написано). На английском написано отлично: идея, зачем, почему, ссылочки. Не знаешь, что такое HSTS – иди в википедию, там будет ссылочки на статьи для Патриков, то есть чайников. Еще на RFC, но это читать невозможно. Общий смысл станет понятен даже из самой статьи в Википедии.