Как включить кэш возобновления сессии не сохраняющий состояние позади подсистемы балансировки нагрузки?
Я просканировал конфигурацию SSL/TLS своих серверов с помощью https://www.ssllabs.com/ssltest/, и она сообщила Session resumption (caching) No (IDs assigned but not accepted)
Я использую 2 экземпляра веб-ролей Azure позади циклической подсистемы балансировки нагрузки. Я полагаю, что возобновление сессии было повреждено из-за идентификаторов сессии, кэшируемых на одном сервере, но не на другом.
Как я настраиваю IIS для использования общего кэша (предпочтительно Redis), поскольку это - идентификаторы сессии?
Обновление:
Кажется, нет способа совместно использовать кэш сессии. Однако Windows Server 2012 R2, кажется, поддерживает (основанную на билете) сессию не сохраняющую состояние http://technet.microsoft.com/en-us/library/hh831771.aspx#BKMK_Changes2012R2.
Испытанная установка HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\MaximumCacheSize к 0, как указано в http://technet.microsoft.com/en-us/library/dn786418.aspx#BKMK_SchannelTR_IssuerCacheSize для отключения кэша сессии, но нет никакого эффекта.
Испытанная включающая основанная на билете сессия с Новым-TlsSessionTicketKey и Включает-TlsSessionTicketKey (http://technet.microsoft.com/en-us/library/dn296629.aspx), но нет также никакого эффекта.
Кому-либо удалось заставить те настройки работать?
Обновление 2:
Успешно отключенный кэш сессии путем установки обоих
- HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\MaximumCacheSize к 0
- HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\ServerCacheTime к 0
и перезапуск сервера
Все еще не мог заставить билеты работать несмотря на выполнение команды Enable-TlsSessionTicketKey для IIS AppPool\{app pool GUID} и Network Service
Наконец, найден способ включить билеты сеанса TLS на win2k12 r2 и win2k16. Вам необходимо выполнить следующие действия:
Создайте ключ (
DWORD) в реестре со значением 1HKLM \ SYSTEM \ CurrentControlSet \ Services \ HTTP \ Parameters \ EnableSslSessionTicketСоздайте новый TLS ключ билета сеанса с помощью этой команды powershell:
New-TlsSessionTicketKey -Password <пароль> -Path "C: \ KeyConfig \ TlsSessionTicketKey.config" -ServiceAccountName "System" https://technet.microsoft.com/en-us/itpro/powershell/windows/tls/new-tlssessionticketkeyВключите ключ билета сеанса TLS с помощью этой команды powershell:
Enable-TlsSessionTicketKey -Password- Путь "C: \ KeyConfig \ TlsSessionTicketKey.config" -ServiceAccountName "System" https://technet.microsoft.com/en-us/itpro/powershell/windows/tls/enable-tlssessionticketkey Перезагрузите сервер, чтобы включить создание билета сеанса TLS. Чтобы запись в реестре вступила в силу, требуется перезагрузка.
ВАЖНО: Чтобы повторно использовать одни и те же билеты сеанса TLS на серверах с балансировкой нагрузки, необходимо скопировать файл " C: \ KeyConfig \ TlsSessionTicketKey.config " создается после выполнения команды « New-TlsSessionTicketKey » на одном из серверов, а затем копирования файла конфигурации на все оставшиеся серверы и выполнения команды PowerShell « Enable-TlsSessionTicketKey » для каждого файла. К сожалению, у меня это сработало только на win2k16. Не работало на win2k12r2.
Может возникнуть некоторое недопонимание, о каком сеансе идет речь.
У вас есть сеанс, который используется большинством веб-приложений для создания постоянства между несколькими HTTP-запросами, стереотипным содержимым вашей корзины покупок. SSLLabs тестирует не это.
В любом случае: при использовании балансировщика нагрузки вам обычно следует реплицировать это состояние сеанса, чтобы у вашего посетителя не оставалась пустая корзина для покупок, когда последующие HTTP-запросы распределяются на разные серверы. -end веб-серверы.
Существует также сеанс SSL / TLS, который SSLLabs тестирует.
Короче говоря, когда устанавливается соединение SSL, веб-сервер и браузер сначала используют относительно дорогостоящее в вычислительном отношении установление связи / согласование открытого ключа (Диффи-Хеллмана). Частью этого согласования является установление симметричного ключа, уникального для этого конкретного соединения, который будет использоваться для последующего шифрования / дешифрования данных, передаваемых по этому соединению. Симметричное шифрование по-прежнему безопасно, но относительно дешево в вычислительном отношении, так что снижает нагрузку как на веб-сервер, так и на веб-браузер. В отличие от обычного HTTP, веб-браузер оставит HTTPS-соединение с веб-сервером открытым и будет использовать его для нескольких HTTPS-запросов, но после некоторого времени простоя соединение все равно будет закрыто.
Вот где в игру вступает кеш сеанса SSL. Если этот параметр включен, вместо согласования нового симметричного ключа веб-сервер может разрешить веб-браузеру повторно использовать этот старый симметричный ключ в новом соединении.Преимущество состоит в том, что новое соединение устанавливается быстрее (это экономит несколько циклов TCP / IP и некоторые тяжелые вычисления), вероятно, за счет безопасности, как я подозреваю.
Я не знаю, используются ли IIS (или другие веб-серверы для это важно) имеют функции для репликации кеша сеанса SSL на другие узлы в кластере с балансировкой нагрузки. В этом тоже может быть нет нужды.
Обычно либо завершение SSL выполняется на балансировщике нагрузки, либо липкие сеансы TCP используются для обеспечения того, чтобы последующие HTTPS-соединения обрабатывались одним и тем же веб-сервером, что устраняет необходимость для веб-серверов реплицировать кеш сеанса SSL.
Если это не так, и веб-сервер объявляет о поддержке возобновления SSL, но балансировщик нагрузки распределяет новое соединение на другой веб-сервер, создается несоответствие.