Устранение неполадок SSL_ERROR_NO_CYPHER_OVERLAP в Firefox
Я пытаюсь получить некоторую помощь на Network Engineering Stack Exchange , но они действительно хотят обвинить браузер (см. Комментарии там). Я ищу исправление, которое не изменяет настройки браузера (хотя я готов изменить их, чтобы определить проблему) и которое по-прежнему позволяет использовать самозаверяющий сертификат. Я использую много самозаверяющих сертификатов с Firefox на других серверах и хорошо знаю, как Firefox обрабатывает ошибки самозаверяющих сертификатов, это не одно и то же, происходит что-то еще, что маршрутизатору Cisco не нравится в TLS-соединении. варианты, предложенные Firefox.
В любом случае ... У меня есть Cisco ISR4331 / K9 под управлением IOS XE версии 16.09.04, который я настроил с именем хоста, доменным именем и сгенерировал 2048-битные ключи RSA, я также проверил, что часы установлены правильно.
После настройки ip http secure-server я пытаюсь получить доступ к маршрутизатору с ПК под управлением Firefox 83.0
Пока работает HTTP-доступ, HTTPS зависает с ошибкой «SSL_ERROR_NO_CYPHER_OVERLAP» в Firefox. Однако sh ip http server secure status возвращает:
HTTP secure server status: Enabled
HTTP secure server port: 443
HTTP secure server ciphersuite: 3des-ede-cbc-sha aes-128-cbc-sha
aes-256-cbc-sha dhe-aes-128-cbc-sha ecdhe-rsa-3des-ede-cbc-sha
rsa-aes-cbc-sha2 rsa-aes-gcm-sha2 dhe-aes-cbc-sha2 dhe-aes-gcm-sha2
ecdhe-rsa-aes-cbc-sha2 ecdhe-rsa-aes-gcm-sha2 ecdhe-ecdsa-aes-gcm-sha2
HTTP secure server TLS version: TLSv1.2 TLSv1.1
HTTP secure server client authentication: Disabled
HTTP secure server PIV authentication: Disabled
HTTP secure server trustpoint:
HTTP secure server peer validation trustpoint:
HTTP secure server ECDHE curve: secp256r1
HTTP secure server active session modules: ALL
Это может показаться вполне приемлемым списком наборов шифров для Firefox.
При просмотре в Wireshak выяснилось, что маршрутизатор немедленно возвращает в браузер сообщение о фатальной ошибке установления связи TLSv1.2 сразу после сообщения Hello TLSv1.2 от клиента.
Я вообще не получаю никаких сообщений на маршрутизаторе, использующем debug ip http all во время этого рукопожатия.
Есть идеи, что мне здесь не хватает?
Обратите внимание, что это лабораторный маршрутизатор, который я использую для репликации / отладки этой проблемы, поэтому у него отсутствует большая часть конфигурации. Конфигурация маршрутизатора:
routertest#sh run
Building configuration...
Current configuration : 1787 bytes
!
! Last configuration change at 18:22:01 UTC Fri Jan 29 2021
!
version 16.9
service timestamps debug datetime msec
service timestamps log datetime msec
platform qfp utilization monitor load 80
no platform punt-keepalive disable-kernel-core
!
hostname routertest
!
boot-start-marker
boot-end-marker
!
!
vrf definition Mgmt-intf
!
address-family ipv4
exit-address-family
!
address-family ipv6
exit-address-family
!
!
no aaa new-model
!
no ip domain lookup
ip domain name test.com
!
!
!
login on-success log
!
!
!
!
!
!
!
subscriber templating
!
!
!
!
!
multilink bundle-name authenticated
!
!
!
crypto pki trustpoint TP-self-signed-886488406
enrollment selfsigned
subject-name cn=IOS-Self-Signed-Certificate-886488406
revocation-check none
rsakeypair TP-self-signed-886488406
!
!
crypto pki certificate chain TP-self-signed-886488406
!
license udi pid ISR4331/K9 sn FDO19370HXL
license boot level securityk9
no license smart enable
diagnostic bootup level minimal
!
spanning-tree extend system-id
!
!
!
!
redundancy
mode none
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
interface GigabitEthernet0/0/0
no ip address
shutdown
negotiation auto
!
interface GigabitEthernet0/0/1
ip address 10.30.0.1 255.255.255.0
negotiation auto
!
interface GigabitEthernet0/0/2
no ip address
shutdown
negotiation auto
!
interface Serial0/1/0
no ip address
!
interface Serial0/1/1
no ip address
!
interface GigabitEthernet0
vrf forwarding Mgmt-intf
no ip address
shutdown
negotiation auto
!
ip forward-protocol nd
ip http server
ip http authentication local
ip http secure-server
ip tftp source-interface GigabitEthernet0
!
!
!
!
!
!
control-plane
!
!
line con 0
logging synchronous
transport input none
stopbits 1
line aux 0
stopbits 1
line vty 0 4
login
!
!
!
!
!
!
end
После длительного тестирования я смог разобраться в этом. Насколько я могу судить, это официально не документировано компанией Cisco, например, в их Руководстве по конфигурации служб HTTP некоторые из этих шагов все еще перечислены как необязательные, но похоже, что на более новом оборудовании или программном обеспечении один из необязательных шагов стал обязательным.
В частности, старые устройства Cisco автоматически связывали HTTPS сервер с самоподписанной точкой доверия, когда HTTPS был включен. Хотя включение HTTPS по-прежнему генерирует ключи, сертификат и доверительную точку для вас, HTTPS сервер больше не использует эту доверительную точку автоматически для соединений, поэтому вы должны вручную указать HTTPS серверу использовать правильную доверительную точку с помощью команды ip http secure-trustpoint.
Я подозреваю, что это непреднамеренная ошибка, введенная где-то на линии, потому что все остальное, включая создание доверительной точки, все равно автоматически делается за вас, HTTPS сервер просто не выбирает автоматически созданную им доверительную точку в качестве используемой.
Итак, если вы внимательно посмотрите журнал терминала после выполнения команды ip http secure-server на маршрутизаторе, вы увидите примерно следующее:
r2(config)#ip http secure-server
CRYPTO_PKI: setting trustpoint policy TP-self-signed-3189949043 to use keypair TP-self-signed-3189949043% Generating 2048 bit RSA keys, keys will be non-exportable...
[OK] (elapsed time was 5 seconds)
*Jan 30 09:50:16.152: %CRYPTO_ENGINE-5-KEY_ADDITION: A key named TP-self-signed-3189949043 has been generated or imported by crypto-engine
*Jan 30 09:50:16.243: %PKI-4-NOCONFIGAUTOSAVE: Configuration was modified. Issue "write memory" to save new IOS PKI configuration
Это даст вам имя созданной точки доверия, в моем случае "TP-self-signed-3189949043".
Обратите внимание, что если вы пропустите это сообщение во время включения HTTPS-сервера, вы можете найти доверительную точку в конфигурации маршрутизатора после этого.
Затем необходимо указать серверу HTTPS использовать эту точку доверия с помощью команды ip http secure-trustpoint TP-self-signed-3189949043 (заменив имя точки доверия на свое).
После этого браузеры смогут подключаться к HTTPS-серверу, используя обычный процесс доверия самоподписанным сертификатам.
Обратите внимание, что это вряд ли произойдет в производственной среде, поскольку вы должны настроить доверительные точки, если вы используете сертификаты, подписанные CA (в отличие от самоподписанных сертификатов).