Я просканировал конфигурацию 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 для отключения кеша сеанса, но эффекта нет.
Пытался включить сеанс на основе билетов с помощью New-TlsSessionTicketKey и Enable-TlsSessionTicketKey (http://technet.microsoft.com/en-us/library/dn296629.aspx), но эффекта тоже нет.
Кому-нибудь удалось заставить эти настройки работать?
Обновление 2:
Успешно отключен кеш сеанса, установив оба
и перезапуск сервера
По-прежнему не удается получить билеты на работу, несмотря на выполнение команды Enable-TlsSessionTicketKey для IIS AppPool\{app pool GUID} и Network Service
Может возникнуть непонимание, о каком сеансе идет речь.
У вас есть сеанс, который используется большинством веб-приложений для создания постоянства между несколькими HTTP-запросами, стереотипного содержимого вашей корзины покупок. SSLLabs не это тестирует.
В любом случае: при использовании балансировщика нагрузки вы обычно должны реплицировать это состояние сеанса, чтобы у вашего посетителя не оставалась пустая корзина для покупок, когда последующие HTTP-запросы распределяются на разные внутренние веб-серверы.
Существует также сеанс SSL / TLS, который SSLLabs тестирует.
Короче говоря, когда устанавливается соединение SSL, веб-сервер и браузер сначала используют относительно дорогостоящее в вычислительном отношении рукопожатие / согласование открытого ключа (Диффи-Хеллмана). Частью этого согласования является установление симметричного ключа, уникального для этого конкретного соединения, который будет использоваться для последующего шифрования / дешифрования данных, передаваемых по этому соединению. Симметричное шифрование по-прежнему безопасно, но относительно дешево в вычислительном отношении, так что снижает нагрузку как на веб-сервер, так и на веб-браузер. В отличие от обычного HTTP, веб-браузер оставит HTTPS-соединение с веб-сервером открытым и будет использовать его для нескольких HTTPS-запросов, но после некоторого времени простоя соединение все равно будет закрыто.
Вот где в игру вступает кеш сеанса SSL. Если этот параметр включен, вместо согласования нового симметричного ключа веб-сервер может разрешить веб-браузеру повторно использовать этот старый симметричный ключ в новом соединении. Преимущество заключается в том, что новое соединение устанавливается быстрее (это экономит несколько циклов TCP / IP и некоторые тяжелые вычисления), вероятно, за счет безопасности, как я подозреваю.
Я не знаю, есть ли у IIS (или других веб-серверов, если на то пошло) функции для репликации кеша сеанса SSL на другие узлы в кластере с балансировкой нагрузки. В этом тоже может быть нет нужды. Обычно либо завершение SSL выполняется на балансировщике нагрузки, либо липкие сеансы TCP используются для обеспечения того, чтобы последующие HTTPS-соединения обрабатывались одним и тем же веб-сервером, что устраняет необходимость для веб-серверов реплицировать кеш сеанса SSL.
Если это не так, и веб-сервер объявляет о поддержке возобновления SSL, но балансировщик нагрузки распределяет новое соединение на другой веб-сервер, создается несоответствие.
Наконец, нашел способ включить билеты сеанса TLS на win2k12 r2 и win2k16. Вам необходимо выполнить следующие действия:
Создайте ключ (DWORD) в реестре со значением 1 HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\EnableSslSessionTicket
Создайте новый ключ билета сеанса TLS с помощью этой команды powershell: New-TlsSessionTicketKey -Password <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 <password> -Path "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"команду на одном из серверов, а затем скопируйте файл конфигурации на все оставшиеся серверы и запустите"Enable-TlsSessionTicketKey"Команда powershell для каждого файла. К сожалению, у меня это сработало только на win2k16. Это не сработало на win2k12r2.