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

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

В 1995 году был внедрён SSL (англ. Secure Sockets Layer) — криптографический протокол, обеспечивающий безопасную связь между пользователем и сервером. Благодаря его работе можно было безопасно передавать информацию или обмениваться данными. Однако в 2014 году в его работе обнаружили уязвимости. И на основе SSL 3.0 был разработан новый стандарт — TLS.

Протокол TLS (англ. Transport Layer Security) — криптографический протокол, который обеспечивает защищённый обмен данными между сервером и клиентом. Протокол работает на трёх уровнях защиты:

• отвечает за конфиденциальность передаваемых от компьютера к компьютеру данных,
• проводит аутентификацию,
• следит за целостностью передаваемой информации.

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

Защита данных c SSL

Установите SSL-сертификат, и ваш сайт будет работать по протоколу безопасного соединения HTTPS.

Заказать

TLS-протокол лежит в основе безопасного обмена информацией, но не обеспечивает его сам по себе. Чтобы защищённое соединение состоялось, нужно настроить одно из безопасных интернет-соединений, например — FTP (для передачи и загрузки файлов), IMAP/POP3/SMTP (для почтовых протоколов) и HTTPS (для интернет-страниц).

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

Однако, чтобы сайт заработал по безопасному соединению HTTPS, нужно выбрать и установить для сайта SSL-сертификат. Подробнее об этом читайте в статье Что такое протокол https и принципы его работы и Что такое secure sockets layer и как работает SSL.

Параметры безопасности протокола TLS

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

Протокол TLS обеспечивает защиту в три этапа:

• Handshake,
• False Start,
• Chain of trust.

На этапе TLS Handshake (рукопожатие) происходит согласование параметров соединения (версии протокола, способа шифрования и соединения) между клиентом и сервером. Для этого используется обмен ключами по алгоритму RSA:

Для каждой такой проверки требуется большое количество вычислительных ресурсов. Чтобы не устанавливать новое соединение и не проверять сертификат повторно каждую транзакцию, была разработана процедура TLS False Start.

TLS False Start (фальстарт) — процедура возобновления сессии. Если транзакции выполняются в пределах одной запущенной сессии, данный этап позволяет пропустить процедуру Handshake. Протокол повторно использует те данные, которые уже были обработаны и подтверждены в начале сессии. При этом каждая сессия имеет свой срок жизни. Как только срок сессии истекает, с помощью TLS Handshake запускается новая сессия.

Также обязательная процедура TLS-соединения — TLS Chain of trust (цепочка доверия). Она отвечает за аутентификацию между клиентом и сервером. «Цепочка доверия» работает на основе регулярной проверки подлинности — соответствия сертификатов стандартам Сертификационных центров, которые их выдают. Подлинность сертификата регулярно проверяется в течение сессии. Если обнаружится, что сертификат скомпрометирован (то есть данные под его защитой были перехвачены), данные будут отозваны, транзакция не состоится и сессия будет прервана.

Таким образом, при передаче данных сначала вызывается процедура Handshake или False Start, которая согласовывает параметры, а затем Chain of trust, которая обеспечивает аутентификацию (проверку авторства передаваемой информации). Подробнее о принципах работы TLS читайте в официальной документации Datatracker.

Влияние SSL/TLS на SEO

SEO (Search Engine Optimization, поисковая оптимизация) – это всестороннее развитие и продвижение сайта для его выхода на первые позиции в результатах выдачи поисковых систем (SERPs). Поисковая оптимизация способствует увеличению посещаемости сайта.

Использование SSL-сертификата влияет на SEO-показатели, однако это влияние является скорее косвенным. С 2015 года Google отдаёт приоритет ранжирования (то есть назначения сайту места в поисковой выдаче) тем сайтам, которые работают по протоколу HTTPS. Такой же политики придерживается компании Яндекс и Mozilla.

Браузер Google Chrome — один из самых популярных браузеров в рунете. С недавнего времени Chrome отмечает HTTP-сайты как небезопасные:

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

Установка SSL/TLS

В компании REG.RU вы можете приобрести SSL-сертификат, который работает по TLS версии 1.2. Для этого выберите подходящий сертификат и выполните три шага — закажите, активируйте и установите его на сайт.

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

Проверка сайта на SSL/TLS

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

Рассмотрим вариант проверки сайта с помощью сервиса SSL Server Test. Для этого:

1. org/HowToStep»> 1.

   В браузере перейдите на страницу SSL Server Test.

2. 2.

   В поле «Hostname» введите домен и нажмите Submit:
   

3. 3.

   Дождитесь окончания проверки. В блоке «Configuration» вы увидите протоколы, которые поддерживает сайт:

Такой результат показывает, что сайт работает по безопасному подключению TLS версии 1.2. Если в результатах выдачи вы увидите «Yes» напротив пунктов SSL 2 или 3 — значит сайту нельзя доверять.

Помогла ли вам статья?

Да

раз уже
помогла

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

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

Содержание:

Подробнее о протоколе TLS

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

TLS применяется сегодня практически во всех приложениях, связанных с передачей данных: интернет-браузер, мессенджер (VoIP), электронная почта. Первая версия протокола (SSL) была разработана компанией Netscape Communication. На данным момент более новой версией и её развитием занимается инженерный совет Интернета (IETF).

Причины сбоя в протоколе TLS

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

Есть и некоторые другие причины такого сообщения:

• Блокировка антивирусом интернет-ресурса, из-за чего и возникает подобное сообщение;
• Пользователь использует старую версию «КриптоПро» — программы для создания отчетов и др.;
• В базовой системе ввода-вывода (BIOS) активирован параметр «SecureBoot»;
• У пользователя установлено VPN-приложение или расширение для браузера, из-за чего появляется ошибка;
• На компьютере есть вирусы, которые блокируют безопасное соединение;
• В том случае, если неполадки наблюдаются только при подключении к одному ресурсу, возможно у самого сайта какие-то проблемы с серверами или с настройками TLS;
• Не исключено, что сайт является небезопасным, поэтому лучше его не посещать.

В базовой системе ввода-вывода (BIOS) активирован параметр «SecureBoot»

Как решить проблему с параметрами безопасности TLS

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

• Для антивируса Avast — откройте настройки, выберите раздел «Активная защита», нужный пункт должен быть возле пиктограммы щитка. Уберите с него галочку и включите HTTP сканирование. Сохраните настройки;
• Для антивируса Kaspersky — найдите раздел «не проверять защищенное соединение». Его можно найти во вкладке «Сканирование». Или в дополнительных настройках найдите «Установить сертификат». Сохраните настройки и перезагрузите ПК.

В антивирусе Avast включаем сканирование HTTPSВ антивирусе Kaspersky устанавливаем сертификат

Необходимо также убедиться, что в вашей версии Windows установлены последние обновления.

1. Для этого нажмите WIN+R и введите команду «services.msc»;
2. Нажмите ENTER;
3. Найдите в списке служб Windows «Центр обновления»;
4. Нажмите правой кнопкой мыши на этой строке и выберите «Свойства»;
5. В открывшемся окошке убедитесь, что установлено значение в блоке «Тип запуска» — «Автоматически»;
6. Далее выберите кнопку «Пуск», «Панель управления»;
7. Выберите «Система и безопасность»;
8. Затем «Центр обновления» и нажмите кнопку «Проверить обновления».

Проверяем последние обновления в Windows

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

Рекомендуем: Igfxtray в автозагрузке что это за процесс и как удалить?

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

Теперь рассмотрим, что делать, если в вашем компьютере поселился вирус, который блокирует безопасное соединение. Для начала попробуйте открыть установленный на вашем компьютере антивирус и запустите разные типы сканирования: «Полное сканирование», «Быстрое», «Интеллектуальное» и др. Попробуйте сканировать не только весь жесткий диск, но и отдельные тома и папки. Проверьте папки, в которых находятся файлы вашего браузера.

Утилита Dr.Web-CureIt для сканирования ПК на вирусы

Если это не дало результатов, воспользуйтесь специальными утилитами, которые предназначены для разового сканирования и поиска вредоносного программного обеспечения. Практически каждый разработчик полноценного антивирусного ПО (Dr.WEB, Kaspersky, ESET и др.) имеет специальную утилиту, которую можно взять на официальном сайте. Это по размеру небольшие программы, которые не нужно устанавливать на диск. Их достаточно запустить и указать путь для сканирования. Обязательно воспользуйтесь этим эффективным инструментом.

Другие методы устранения ошибки безопасного соединения TLS

Если вы получили сообщение о сбое в протоколе TLS, работая с программой «КриптоПро», попробуйте загрузить более новую версию. Её можно взять на официальном сайте https://www.cryptopro.ru/downloads. Возможно проблема в самом браузере. Воспользуйтесь другим браузером, хотя-бы для того, чтобы определить, что проблема кроется в нём. Попробуйте также настроить свой браузер.

• Если вы пользуетесь Internet Explorer — откройте «Сервис». Нажмите «Свойства обозревателя», выберите «Дополнительно», затем нажмите вкладку «Безопасность». Здесь нужно найти пункты SSL и TLS. Если галочка установлена на пункте SSL, уберите её и поставьте на более новую версию протокола. Сохраните настройки и попытайтесь войти на сайт;
• В Opera — нажмите «Инструменты», далее выберите «Общие настройки». Перейдите в «Расширенные», и в разделе безопасности найдите пункт «Протоколы безопасности». Здесь нужно убрать галочки со строк с версиями TLS и оставить те, которые установлены на пунктах, вроде «256 bit…». Обязательно уберите галочку с пункта «Anonymous DH/SHA-256;
• Для Mozilla Firefox — откройте настройки, выберите пункт «Дополнительно» и «Шифрование». Как в IE, нам нужно оставить галочки на TLS и убрать со старого протокола SSL. Другие браузеры (Google Chrome, Safari и т.д.) настроек безопасного соединения не имеют. Поэтому нам приходится либо сменить браузер, либо искать причины в другом месте.

Настройка браузера Internet Explorer (SSL, TLS)

Встречается проблема со сбоем протокола TLS еще в том случае, если в системе время настроено неправильно. Чтобы это исправить:

1. Выберите внизу рабочего стола Windows справа время правой кнопкой мыши;
2. Нажмите пункт «Настройка даты и времени»;
3. Установите правильное значение времени;
4. Выберите вкладку «Время по интернету», выберите «Изменить параметры», поставьте галочку на «Синхронизировать с временем по интернету». Выберите сервер «windows.com» и сохраните настройки.

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

Summary

Параметры реестра безопасности транспортного уровня (TLS)

• Статья
• 11.04.2023

Применяется к: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows 11, Windows 10 и более ранним версиям, как указано

.

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

Предостережение

Эта информация предоставляется в качестве справочной информации при устранении неполадок или проверке применения требуемых параметров. Мы рекомендуем вам не редактировать реестр напрямую, если нет другой альтернативы. Изменения в реестре не проверяются редактором реестра или операционной системой Windows до их применения. В результате могут сохраняться неверные значения, что может привести к неисправимым ошибкам в системе. По возможности вместо непосредственного редактирования реестра используйте групповую политику или другие инструменты Windows, такие как консоль управления Microsoft (MMC). Если вам необходимо отредактировать реестр, будьте предельно осторожны.

Существует восемь уровней регистрации событий SChannel, сохраняемых в системном журнале событий и доступных для просмотра с помощью средства просмотра событий. Этот путь реестра хранится в HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL в разделе EventLogging со значением DWORD, равным 1 .

Десятичный или шестнадцатеричный	События регистрации SChannel
0	Нет событий
1	События ошибок
2	Предупреждающие события
3	События ошибок и предупреждений
4	Информационные и успешные события
5	Error, Information и Success Events
6	Предупреждения, информационные события и события успеха
7	Error, Warning, Information и Success Events

Примечание

После изменения уровня ведения журнала SChannel необходимо перезагрузить устройство.

CertificateMappingMethods

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

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

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

• Один сертификат сопоставляется с одной учетной записью пользователя (сопоставление один к одному).
• Несколько сертификатов сопоставлены с одной учетной записью пользователя (сопоставление «многие к одному»).

Поставщик SChannel использует четыре (4) метода сопоставления сертификатов:

1. Сопоставление службы Kerberos для пользователя (S4U) ( включено по умолчанию )
2. Сопоставление основного имени пользователя
3. Сопоставление один к одному (также известное как сопоставление субъекта/эмитента)
4. Преобразование «многие к одному»

Путь реестра: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

Имя записи	двойное слово	Включено по умолчанию
Субъект/эмитент	0x000000001	№
Эмитент	0x000000002	№
УПН	0x000000004	№
S4U2Self	0x000000008	Да
S4U2Явный	0x000000010	Да

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

Шифры

Шифры TLS/SSL должны управляться путем настройки порядка набора шифров. Дополнительные сведения см. в разделе Настройка порядка наборов шифров TLS.

Сведения о порядках наборов шифров по умолчанию, которые используются поставщиком общих служб SChannel, см. в разделе Наборы шифров в TLS/SSL (SChannel SSP).

CipherSuites

Настройка наборов шифров TLS/SSL должна выполняться с помощью групповой политики, MDM или PowerShell. Дополнительные сведения см. в разделе Настройка порядка наборов шифров TLS.

Сведения о порядках наборов шифров по умолчанию, которые используются поставщиком общих служб SChannel, см. в разделе Наборы шифров в TLS/SSL (SChannel SSP).

ClientCacheTime

Эта запись указывает время жизни элемента кэша сеанса TLS клиента в миллисекундах. Начиная с Windows Server 2008 и Windows Vista, значение по умолчанию составляет 10 часов. Значение 0 отключает кэширование сеанса TLS на клиенте.

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

Путь в реестре: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

EnableOcspStaplingForSni

Сшивание протокола статуса онлайн-сертификата (OCSP) позволяет веб-серверу, такому как IIS, предоставлять текущий статус отзыва сертификата сервера, когда он отправляет сертификат сервера клиенту во время рукопожатия TLS. Эта функция снижает нагрузку на серверы OCSP, поскольку веб-сервер может кэшировать текущий статус OCSP сертификата сервера и отправлять его нескольким веб-клиентам. Без этой функции каждый веб-клиент пытался бы получить текущий статус OCSP сертификата сервера с сервера OCSP. Это приведет к высокой нагрузке на этот сервер OCSP.

Помимо IIS, этот параметр также может использовать веб-службы через http. sys, включая службы федерации Active Directory (AD FS) и прокси-сервер веб-приложения (WAP).

По умолчанию поддержка OCSP включена для веб-сайтов IIS с простой безопасной привязкой (SSL/TLS). Однако эта поддержка не включена по умолчанию, если веб-сайт IIS использует один или оба из следующих типов привязок SSL/TLS:

• Требуется указание имени сервера
• Использовать централизованное хранилище сертификатов

В этом случае ответ приветствия сервера во время рукопожатия TLS по умолчанию не будет включать статус сшивания OCSP. Такое поведение повышает производительность: реализация сшивания Windows OCSP масштабируется до сотен сертификатов сервера. Однако индикация имени сервера (SNI) и центральное хранилище сертификатов (CCS) позволяют масштабировать IIS до тысяч веб-сайтов, которые потенциально имеют тысячи сертификатов сервера, поэтому включение сшивания OCSP для привязок CCS может вызвать проблемы с производительностью.

Применимые версии: все версии, начиная с Windows Server 2012 и Windows 8.

Путь реестра: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

Добавьте следующий ключ:

9001 3 «EnableOcspStaplingForSni»=dword:00000001

Чтобы отключить, установите для параметра DWORD значение 0:

«EnableOcspStaplingForSni»=dword:00000000

Примечание

Включение этого раздела реестра может повлиять на производительность.

Хэши

Хэш-алгоритмы TLS/SSL должны управляться путем настройки порядка набора шифров. Дополнительные сведения см. в разделе Настройка порядка наборов шифров TLS.

IssuerCacheSize

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

Чтобы предотвратить это, сервер имеет отрицательный кеш, поэтому, если имя издателя не сопоставляется с учетной записью, оно добавляется в кеш, и поставщик общих служб SChannel не будет пытаться снова сопоставить имя издателя, пока не истечет срок действия записи в кеше. . Эта запись реестра указывает размер кэша. Эта запись , а не существует в реестре по умолчанию. Значение по умолчанию: 100 .

Применимые версии: Все версии, начиная с Windows Server 2008 и Windows Vista.

Путь реестра: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

IssuerCacheTime

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

Чтобы предотвратить это, сервер имеет отрицательный кеш, поэтому, если имя издателя не сопоставляется с учетной записью, оно добавляется в кеш, и поставщик общих служб SChannel не будет пытаться снова сопоставить имя издателя, пока не истечет срок действия записи в кеше. . Этот кеш сохраняется из соображений производительности, чтобы система не пыталась сопоставить одни и те же эмитенты. Эта запись не существует в реестре по умолчанию. Значение по умолчанию — 10 минут.

Применимые версии: Все версии, начиная с Windows Server 2008 и Windows Vista.

Путь в реестре: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

Размеры ключей KeyExchangeAlgorithm

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

• Диффи-Хеллман
• ЮАР

Добавлено в Windows 10 версии 1507 и Windows Server 2016.

Путь реестра: HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\Diffie-Hellman

Чтобы указать минимальный поддерживаемый диапазон битовой длины ключа Диффи-Хеллмана для клиента TLS, создайте запись ClientMinKeyBitLength . После того, как вы создали запись, измените значение DWORD на желаемую длину в битах. Если не настроено, минимум 1024 бита.

Чтобы указать максимальный поддерживаемый диапазон битовой длины ключа Диффи-Хеллмана для клиента TLS, создайте Запись ClientMaxKeyBitLength . После того, как вы создали запись, измените значение DWORD на желаемую длину в битах.

Чтобы указать битовую длину ключа Диффи-Хеллмана для сервера TLS по умолчанию, создайте запись ServerMinKeyBitLength . После того, как вы создали запись, измените значение DWORD на желаемую длину в битах. Если не настроено, по умолчанию используется 2048 бит.

Примечание

Сконфигурированные эллиптические кривые определяют криптографическую стойкость обмена ключами ECDHE. Дополнительные сведения см. в разделе Управление безопасностью транспортного уровня (TLS).

Чтобы узнать больше о криптографических алгоритмах наборов шифров TLS/SSL, см.:

• Наборы шифров в TLS/SSL (SChannel SSP)
• Демистификация SChannel (блог)

MaximumCacheSize

Эта запись определяет максимальное количество сеансов TLS для кэширования. Установка для параметра MaximumCacheSize значения 0 отключает кеш сеанса на стороне сервера для предотвращения возобновления сеанса. Увеличение MaximumCacheSize выше значения по умолчанию заставляют Lsass.exe потреблять дополнительную память. Каждый элемент кэша сеанса обычно требуется от 2 КБ до 4 КБ памяти. Эта запись не существует в реестре по умолчанию. По умолчанию значение составляет 20 000 элементов.

Применимые версии: Все версии, начиная с Windows Server 2008 и Windows Vista.

Путь в реестре: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

Обмен сообщениями — анализ фрагментов

Эта запись определяет максимально допустимый размер сообщения подтверждения TLS, которое будет принято. Сообщения, размер которых превышает допустимый, не будут приняты, и рукопожатие TLS завершится ошибкой. Эти записи не существуют в реестре по умолчанию. 916 байт. Разрешение клиенту или серверу читать и хранить большие объемы непроверенных данных из сети — не очень хорошая идея, поскольку для каждого контекста безопасности потребуется дополнительная память.

Добавлено в Windows 7 и Windows Server 2008 R2: Доступно обновление, позволяющее Internet Explorer в Windows XP, Windows Vista или Windows Server 2008 анализировать фрагментированные сообщения рукопожатия TLS/SSL.

Путь реестра: HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Messaging

Чтобы указать максимально допустимый размер фрагментированных сообщений подтверждения TLS, которые будет принимать клиент TLS, создайте запись MessageLimitClient . После того, как вы создали запись, измените значение DWORD на желаемую длину в битах. Если он не настроен, значение по умолчанию — 0x8000 байта.

Чтобы указать максимально допустимый размер фрагментированных сообщений рукопожатия TLS, которые сервер TLS будет принимать при отсутствии аутентификации клиента, создайте MessageLimitServer запись. После того, как вы создали запись, измените значение DWORD на желаемую длину в битах. Если он не настроен, значение по умолчанию — 0x4000 байта.

Чтобы указать максимально допустимый размер фрагментированных сообщений подтверждения TLS, которые сервер TLS будет принимать при проверке подлинности клиента, создайте запись MessageLimitServerClientAuth . После того, как вы создали запись, измените значение DWORD на желаемую длину в битах. Если не настроено, значение по умолчанию — 0x8000 9.0024 байт.

SendTrustedIssuerList

Серверы TLS могут отправлять список различающихся имен допустимых центров сертификации при запросе проверки подлинности клиента. Это может помочь клиентам TLS выбрать подходящий сертификат клиента TLS. TLS-серверы на основе SChannel по умолчанию не отправляют этот список доверенных издателей, потому что он раскрывает центры сертификации, которым доверяет сервер, пассивным наблюдателям, а также увеличивает объем данных, которыми обмениваются в ходе рукопожатия TLS. Установка этого значения на 1 заставляет серверы на основе SChannel отправлять свои списки доверенных эмитентов.

Отсутствие отправки списка доверенных издателей может повлиять на то, что клиент отправляет при запросе сертификата клиента. Например, когда Internet Explorer получает запрос на проверку подлинности клиента, он отображает только те клиентские сертификаты, которые связаны с одним из центров сертификации, отправленным сервером. Если сервер не отправил список, Internet Explorer отобразит все клиентские сертификаты, установленные на клиенте.

Такое поведение может быть желательным. Например, когда среды PKI включают перекрестные сертификаты, сертификаты клиента и сервера не будут иметь один и тот же корневой ЦС; поэтому Internet Explorer не может выбрать сертификат, связанный с одним из ЦС сервера. Клиенты TLS могут предлагать любой доступный клиентский сертификат, если сервер не отправляет список доверенных издателей. Эта запись не существует в реестре по умолчанию.

Поведение по умолчанию «Отправить список доверенных эмитентов»

Версия Windows	Поведение по умолчанию
Windows Server 2012, Windows 8 и более поздние версии	ЛОЖЬ
Windows Server 2008 R2, Windows 7 и более ранние версии	ИСТИНА

Применимые версии: Все версии, начиная с Windows Server 2008 и Windows Vista.

Путь реестра: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

ServerCacheTime

Эта запись указывает время жизни элемента кэша сеанса TLS сервера в миллисекундах. По умолчанию 10 часов. Значение 0 отключает кэширование сеанса TLS на сервере и предотвращает возобновление сеанса. Увеличение ServerCacheTime выше значений по умолчанию приводит к тому, что Lsass.exe потребляет дополнительную память. Для каждого элемента кэша сеанса обычно требуется от 2 до 4 КБ памяти. Эта запись не существует в реестре по умолчанию.

Применимые версии: Все версии, начиная с Windows Server 2008 и Windows Vista.

Путь реестра: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

Время кэширования сервера по умолчанию: 10 часов , DTLS и SSL-протоколы. Различные выпуски Windows поддерживают разные версии протокола. Набор версий (D)TLS и SSL, доступных для всей системы, может быть ограничен (но не расширен) вызывающими объектами SSPI, указывающими структуру SCH_CREDENTIALS в вызове AcquireCredentialsHandle. Вызывающим сторонам SSPI рекомендуется использовать системные значения по умолчанию, а не накладывать ограничения версии протокола.

Поддерживаемая версия протокола (D)TLS или SSL может существовать в одном из следующих состояний:

• Включено : Если вызывающая сторона SSPI явно не отключит эту версию протокола с помощью структуры SCH_CREDENTIALS, поставщик общих служб SChannel может согласовать эту версию протокола с поддерживающий сверстник.
• Отключено : SChannel SSP не будет согласовывать эту версию протокола независимо от настроек, которые может указать вызывающая сторона SSPI.

Эти значения реестра настраиваются отдельно для ролей клиента протокола и сервера в подразделах реестра, названных в следующем формате:

<основной номер версии>.<дополнительный номер версии>

Эти зависимые от версии подразделы можно создать по следующему пути реестра:

HKLM SYSTEM\CurrentControlSet\Control \ SecurityProviders \ Schannel \ Protocols

Например, вот некоторые достоверные пути реестра с специфичными для версией подказков:

• HKLM System \ CuranceControlset \ Controlspiders \ Schannel \ Protocols \ SSL 3.0 \ Client

• HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server

• HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\DTLS 1. 2\Client

Чтобы переопределить системное значение по умолчанию и установить поддерживаемую версию протокола (D)TLS или SSL в состояние Включено , создайте значение реестра DWORD с именем «Включено» со значением записи « 1 » под соответствующим подразделом для конкретной версии.

В следующем примере показан клиент TLS 1.0, установленный в состояние Enabled :

Чтобы переопределить системное значение по умолчанию и установить поддерживаемую версию протокола (D)TLS или SSL в состояние Disabled , измените значение реестра DWORD с «Enabled» на « 0 » в соответствующем подразделе для конкретной версии.

В следующем примере показано, что DTLS 1.2 отключен в реестре:0013

Переключение версии протокола (D)TLS или SSL на состояние Disabled может привести к сбою вызовов AcquireCredentialsHandle из-за отсутствия версий протокола, включенных для всей системы и в то же время разрешенных для определенных вызывающих абонентов SSPI. Кроме того, сокращение набора версий Enabled (D)TLS и SSL может привести к нарушению взаимодействия с удаленными одноранговыми узлами.

После изменения настроек версии протокола (D)TLS или SSL они вступают в силу для соединений, установленных с использованием дескрипторов учетных данных, открытых последующими вызовами AcquireCredentialsHandle. (D) Клиентские и серверные приложения и службы TLS и SSL, как правило, повторно используют дескрипторы учетных данных для нескольких подключений из соображений производительности. Чтобы эти приложения повторно получили свои дескрипторы учетных данных, может потребоваться перезапуск приложения или службы.

Эти параметры реестра применяются только к SChannel SSP и не влияют на сторонние реализации (D)TLS и SSL, которые могут быть установлены в системе.

Что такое TLS и как он работает?

Transport Layer Security (TLS) шифрует данные, отправляемые через Интернет, чтобы гарантировать, что перехватчики и хакеры не смогут увидеть, что вы передаете, что особенно полезно для частной и конфиденциальной информации, такой как пароли, номера кредитных карт и личная переписка. На этой странице объясняется, что такое TLS, как он работает и почему его следует развертывать.

Что такое TLS?

TLS – это криптографический протокол, который обеспечивает сквозную защиту данных, пересылаемых между приложениями через Интернет. Он в основном знаком пользователям благодаря его использованию в безопасном просмотре веб-страниц и, в частности, значку замка, который появляется в веб-браузерах при установлении безопасного сеанса. Однако его можно и даже нужно использовать для других приложений, таких как электронная почта, передача файлов, видео/аудиоконференции, обмен мгновенными сообщениями и передача голоса по IP, а также интернет-службы, такие как DNS и NTP.

TLS произошел от Secure Socket Layers (SSL), который был первоначально разработан Netscape Communications Corporation в 1994 году для защиты веб-сеансов. SSL 1.0 никогда не выпускался публично, в то время как SSL 2.0 был быстро заменен SSL 3.0, на котором основан TLS.

TLS был впервые указан в RFC 2246 в 1999 году как протокол, независимый от приложений, и, хотя он не имел прямого взаимодействия с SSL 3. 0, при необходимости предлагал резервный режим. Однако в настоящее время SSL 3.0 считается небезопасным и объявлен устаревшим в соответствии с RFC 7568 в июне 2015 г. с рекомендацией использовать TLS 1.2. TLS 1.3 также в настоящее время (по состоянию на декабрь 2015 г.) находится в разработке и прекратит поддержку менее безопасных алгоритмов.

Следует отметить, что TLS не защищает данные на конечных системах. Он просто обеспечивает безопасную доставку данных через Интернет, избегая возможного прослушивания и/или изменения содержимого.

TLS обычно реализуется поверх TCP для шифрования протоколов прикладного уровня, таких как HTTP, FTP, SMTP и IMAP, хотя он также может быть реализован на UDP, DCCP и SCTP (например, для приложений на основе VPN и SIP). использует). Это известно как защита транспортного уровня дейтаграмм (DTLS) и описано в RFC 6347, 5238 и 6083.

Зачем мне TLS?

Исторически данные передавались через Интернет в незашифрованном виде, а там, где использовалось шифрование, оно обычно применялось по частям для конфиденциальной информации, такой как пароли или платежные реквизиты. Хотя еще в 1996 году (RFC 1984) было признано, что рост Интернета потребует защиты личных данных, за прошедший период стало все более очевидным, что возможности перехватчиков и злоумышленников больше и более распространены, чем считалось ранее. . Поэтому в ноябре 2014 года IAB опубликовал заявление, призывающее проектировщиков, разработчиков и операторов протоколов сделать шифрование нормой для интернет-трафика, что, по сути, означает сделать его конфиденциальным по умолчанию.

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

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

Поэтому рекомендуется, чтобы все клиенты и серверы настаивали на обязательном использовании TLS в своих коммуникациях и, желательно, самой последней версии TLS 1.2. Для полной безопасности необходимо использовать его в сочетании с общедоступной инфраструктурой открытых ключей X.509 (PKI) и, желательно, с DNSSEC, чтобы аутентифицировать, что система, к которой устанавливается соединение, действительно является тем, на что она претендует. быть.

Как работает TLS?

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

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

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

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

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

Можно использовать множество различных методов генерации ключей и обмена, включая RSA, алгоритм Диффи-Хеллмана (DH), эфемерный алгоритм Диффи-Хеллмана (DHE), алгоритм Диффи-Хеллмана на эллиптических кривых (ECDH) и алгоритм Диффи-Хеллмана на эфемерных эллиптических кривых (ECDHE). ). DHE и ECDHE также обеспечивают прямую секретность, благодаря чему сеансовый ключ не будет скомпрометирован, если один из закрытых ключей будет получен в будущем, хотя постулируется слабая генерация случайных чисел и/или использование ограниченного диапазона простых чисел для обеспечения возможности взлома даже 1024-битные ключи DH дают вычислительные ресурсы на уровне состояния. Однако их можно считать проблемами реализации, а не протокола, и существуют инструменты для тестирования более слабых наборов шифров.

При использовании TLS также желательно, чтобы клиент, подключающийся к серверу, мог подтвердить право собственности на открытый ключ сервера. Обычно это выполняется с использованием цифрового сертификата X.509, выданного доверенной третьей стороной, известной как центр сертификации (ЦС), который подтверждает подлинность открытого ключа. В некоторых случаях сервер может использовать самозаверяющий сертификат, которому клиент должен явно доверять (браузеры должны отображать предупреждение при обнаружении ненадежного сертификата), но это может быть приемлемо в частных сетях и/или там, где защищенный сертификат возможна раздача. Однако настоятельно рекомендуется использовать сертификаты, выпущенные общедоступными доверенными центрами сертификации.

Что такое ЦС?

Центр сертификации (ЦС) — это организация, выдающая цифровые сертификаты, соответствующие стандарту ITU-T X. 509 для инфраструктур открытых ключей (PKI). Цифровые сертификаты удостоверяют открытый ключ владельца сертификата (известный как субъект) и то, что владелец контролирует домен, защищаемый сертификатом. Таким образом, ЦС действует как доверенная третья сторона, которая дает клиентам (известным как проверяющие стороны) уверенность в том, что они подключаются к серверу, управляемому проверенной организацией.

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

Доверие к корневым сертификатам обычно устанавливается путем физического распространения корневых сертификатов в операционных системах или браузерах. Основные программы сертификации проводятся Microsoft (Windows и Windows Phone), Apple (OSX и iOS) и Mozilla (Firefox и Linux) и требуют, чтобы центры сертификации соответствовали строгим техническим требованиям и заполняли WebTrust, ETSI EN 319 411-3 (ранее TS 102 042) или аудит ISO 21188:2006   для включения в их дистрибутивы. WebTrust — это программа, разработанная Американским институтом сертифицированных бухгалтеров и Канадским институтом дипломированных бухгалтеров, ETSI — Европейским институтом стандартов в области телекоммуникаций, а ISO — Международной организацией по стандартизации.

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

Однако также возможно создать частные центры сертификации и установить доверие посредством безопасного распространения и установки корневых сертификатов в клиентских системах. Примеры включают центры сертификации RPKI, управляемые региональными интернет-регистратурами (AfriNIC, APNIC, ARIN, LACNIC и RIPE NCC), которые выдают сертификаты локальным интернет-реестрам, подтверждающие IP-адреса и номера AS, которыми они владеют; а также Международная федерация доверия к сети (IGTF), которая обеспечивает якорь доверия для выдачи серверных и клиентских сертификатов, используемых машинами в распределенных научных вычислениях. В этих случаях корневые сертификаты можно безопасно загрузить и установить с сайтов с помощью сертификата, выданного общедоступным доверенным центром сертификации.

Одним из недостатков системы PKI X.509 является то, что третьи лица (ЦС) могут выдавать сертификаты для любого домена, независимо от того, действительно ли запрашивающий объект владеет им или иным образом контролирует его. Проверка обычно выполняется посредством проверки домена, а именно отправки электронного письма со ссылкой для проверки подлинности на адрес, который, как известно, несет административную ответственность за домен. Обычно это один из стандартных контактных адресов, таких как «[email protected]», или технический контакт, указанный в базе данных WHOIS, но это оставляет себя открытым для атак «человек посередине» на протоколы DNS или BGP или, проще говоря, , пользователи, регистрирующие административные адреса в доменах, которые не были зарезервированы. Возможно, что еще более важно, сертификаты с проверкой домена (DV) не утверждают, что домен имеет какие-либо отношения с юридическим лицом, даже если может показаться, что домен таковым является.

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

Конечно, это по-прежнему не предотвращает случайную или мошенническую выдачу центрами сертификации неверных сертификатов, а также были случаи нарушения безопасности, когда центры сертификации были обманом выданы поддельные сертификаты. Несмотря на существенное ужесточение процедур безопасности после нескольких громких инцидентов, система по-прежнему зависит от доверия третьих сторон, что привело к разработке протокола аутентификации именованных объектов (DANE) на основе DNS, как указано в RFC 6698, 7671, 7672 и 7673.

С помощью DANE администратор домена может сертифицировать свои открытые ключи, сохраняя их в DNS или альтернативно указывая, какие сертификаты должен принимать клиент.