Поскольку я обновил Firefox до версии 38, у меня возникла проблема при отправке определенной формы на веб-сайте https://usercenter.checkpoint.com/. Большинство веб-сайтов работают нормально, но отправляют форму при открытии заявки в службу поддержки (URL-адрес в журнале ниже. ) приводит к сбою Firefox при согласовании TLS. Страница ошибок Firefox почти ничего не объясняет:
Сбой безопасного соединения
Соединение с сервером было сброшено во время загрузки страницы.
- Невозможно отобразить страницу, которую вы пытаетесь просмотреть, поскольку не удалось проверить подлинность полученных данных.
- Пожалуйста, свяжитесь с владельцами сайта, чтобы сообщить им об этой проблеме.
Сообщить об этой ошибке
Сообщение адреса и информации о сертификате для usercenter.checkpoint.com поможет нам идентифицировать и блокировать вредоносные сайты. Спасибо за помощь в создании более безопасной сети!
Автоматически сообщать об ошибках в будущем Подробнее ...
В консоли веб-разработчика я вижу только это:
19:58:44.470 This site makes use of a SHA-1 Certificate; it's recommended you use certificates with signature algorithms that use hash functions stronger than SHA-1.1 AjaxCall
19:58:44.589 POST https://usercenter.checkpoint.com/usercenter/portal/js_pane/supportId,CreateServiceRequestId [178ms]
Первая строка - это просто предупреждение о том, что в будущем SHA-1 не будет поддерживаться. Нужно ли что-то включать, чтобы увидеть причину сбоя TLS? Информация о TLS и сертификате с консоли приведена ниже:
Я не вижу в этом ничего плохого. В отчаянии я безуспешно пытался поиграть с параметрами TLS about:config:
security.tls.insecure_fallback_hosts
security.tls.unrestricted_rc4_fallback
security.tls.version.fallback-limit
security.tls.version.max
security.tls.version.min
Тест Qualy SSL не показывает ничего абсолютно неправильного: https://www.ssllabs.com/ssltest/analyze.html?d=usercenter.checkpoint.com
В базе знаний Red Hat есть многообещающая статья: серверы Firefox 38 и SSL / TLS, которые не переносят версию TLS, но решение доступно только для платящих клиентов.
Я также проверил совместимость сайта для Firefox 38 .
Вопросов
- Как я могу выяснить причину сбоя TLS?
- В Firefox есть ли другие настраиваемые пользователем белые списки, где я могу попытаться добавить адрес неисправного веб-сайта?
- Каковы могут быть причины появления ошибки только после отправки определенной формы, когда консоль показывает, что запрос POST отправляется на тот же хост,
usercenter.checkpoint.comчто и предыдущий успешный обмен данными?
{Distinguished Name, Serial Number}делает сертификат уникальным, чтобы его можно было однозначно выбрать; см. RFC 4158 . Но посмотрите на предостережения ниже при выборе, потому что это не легко сделать. Кроме того, Checkpoint не должен отправлять старый сертификат G5 как часть цепочки.Ответы:
Использование
openssl s_client. Это швейцарский армейский нож для таких вещей. И использоватьopenssl x509для сброса сертификатов.Обычно вас интересуют
{Issuer, Subject}пары в цепочке:Обратите внимание, как издатель на сервере становится субъектом для следующего более высокого сертификата. Гутман предлагает следующую диаграмму для описания в своей книге « Инженерная безопасность» :
Вверху корень ЦС самоподписан, а проблема и тема совпадают. Если бы был уровень 3, это было бы:
Но вы обычно не видите это в цепи, потому что вы должны доверять этому. И часть требований к доверительному якору заключается в том, что он у вас уже есть, чтобы гарантировать, что он не подделан.
Использование имен субъекта и эмитента - это то, что называется выделенными именами . Другой способ сформировать цепь - с
KEYIDs. Иногда вы можете увидеть его через Идентификатор ключа субъекта (SKI) и Идентификатор ключа авторизации (AKI). Идентификаторы ключа - это просто отпечатки открытого переваренного ключа.Вы можете найти информацию о выдающихся именах в таких стандартах, как RFC 4514 ; и использование KEYID в стандартах, таких как RFC 4518 , что касается построения пути.
Похоже, проблема в браузере (но см. Ниже). Похоже, что отсутствует
Class 3 Public Primary Certification Authorityс отпечаткомa1 db 63 93 91 6f 17 e4 18 55 09 40 04 15 c7 02 40 b0 ae 6b.Когда я захожу на Symantec Root Certifcates и загружаю Публичный первичный центр сертификации класса 3 , я могу создать путь для проверки (обратите внимание на
Verify return code: 0 (ok)ниже).Вы должны скачать и установить
Class 3 Public Primary Certification Authorityв надежном корневом хранилище вашего браузера. Или определите, почему он не используется браузером для построения пути (см. Далее).В
Class 3 Public Primary Certification Authorityблоге Mozilla и Firefox рассказывают о постепенной отмене сертификатов с помощью 1024-битных ключей RSA . Согласно сообщению, они не одобряют этот сертификат CA со времен Firefox 32. Я на самом деле их не виню, поскольку эти ключи используются в течение длительного времени для операций подписания CA, и им нужны «более сильные» параметры, потому что они должны жить от 10 до 30 лет (буквально).Контрольная точка должна получить новый сертификат сервера, выданный в соответствии с сертификатом (цепочкой) с современными параметрами, например, CA с 4096-битными модулями RSA и SHA-256. Или подчиненный ЦС с 2048-битными модулями RSA и SHA-256 ...
(Также посмотрите, что не работает для меня ниже).
Вот пример проверки сертификата сервера с помощью публичного первичного центра сертификации класса 3 с использованием OpenSSL
s_client:Ранее я говорил: «На верхнем уровне корень ЦС самоподписан, а проблема и тема совпадают» . Вот дамп этого самозаверяющего корня CA, где субъект и издатель совпадают. Он также показывает 1024-битные модули и sha1WithRSAEncryption.
Ранее я говорил: «Контрольной точке необходимо получить новый сертификат сервера, выданный в соответствии с сертификатом (цепочкой) с современными параметрами, такими как ЦС с 4096-битными модулями RSA и SHA-256. Или Подчиненный ЦС с 2048-битными модулями RSA и SHA-256 ... " .
Вот что не сделал работу для меня: укоренения или якорь доверия к сильному Подчиненный ЦС
VeriSign Class 3 Public Primary Certification Authority - G5, а не слабее 1024-битовую Root CA.РЕДАКТИРОВАТЬ : это связано с ошибкой в OpenSSL 1.0.2a и ниже. Это было исправлено в OpenSSL 1.0.2b. См. Ожидаемое поведение для проверки, когда подчиненный в цепочке переводится в самозаверяющий корень?
Практическая проблема заключается в том, что Symantec повторно выпускает сертификат с тем же именем и тем же открытым ключом, поэтому отличительное имя , идентификатор ключа субъекта и идентификатор ключа авторизации не изменились; но только меняя серийный номер .
Я смог определить его ниже из-за разных серийных номеров сертификата, отправленного в цепочке, и сертификата, загруженного с сайта Symantec. Затем стало очевидно, что переизданный сертификат был заменен с подчиненного ЦС на корневой ЦС.
Вы можете использовать
-showcertsOpenSSLs_clientдля просмотра сертификатов в цепочке:Далее я обычно копирую сертификат PEM в цепочке в буфер обмена, а затем использую его
pbpasteдля вставки в терминал и передачи его в OpenSSLx509. Например, вот уровень 2,VeriSign Class 3 Public Primary Certification Authority - G5отправленный как часть цепочки:источник
Это можно исправить, набрав about: config в адресной строке, затем выбрав «Я буду осторожен, обещаю!» кнопка. В этот момент дважды щелкните параметр security.tls.insecure_fallback_hosts, а затем добавьте адрес, к которому вы пытаетесь получить доступ.
Мне пришлось удалить «https: \» (поставить обе обратные косые черты, суперпользователь удалил мою вторую) с моего адреса, чтобы заставить его работать, но ваши результаты могут отличаться, поэтому, возможно, попробуйте оба.
Это точно с версии Firefox 43.0.1.
источник
security.tls.insecure_fallback_hostsне было дела. Позже в комментарии написал, что проблема была на стороне сервера. Сервер закрывал соединения.Если вы посмотрите на Публичный первичный центр сертификации VeriSign Class 3 - G5, предоставленный в цепочке,
openssl s_client ... -showcertsи на Публичный первичный центр сертификации VeriSign Class 3 - G5, доступный для загрузки, вы увидите, что это разные сертификаты. Поэтому Verisign переоформил сертификат с тем же отличительным именем и открытым ключом субъекта .Цепная версия публичного первичного центра сертификации VeriSign Class 3 - G5 имеет следующий серийный номер и не является самоподписанным (обратите внимание, что субъект и эмитент различаются):
Загруженный версия от Symantec корневых сертификатов от VeriSign Class 3 Public Primary Certification Authority - G5 имеет следующий серийный номер, и он является самозаверяющим (уведомление Субъекта и Эмитент одинаковы):
Здесь действительно есть только одно исправление.
Контрольная точка должна прекратить отправку старой версии публичного первичного центра сертификации VeriSign класса 3 - подчиненного G5 в цепочке.
Это потому, что на практике эти пути проверки и выбора сертификатов будут сбиты с толку, потому что старый сертификат G5 и новый сертификат G5 слишком похожи. Они слишком похожи, потому что используют одно и то же различающееся имя и один и тот же идентификатор ключа субъекта / идентификатор ключа авторизации .
Теоретически вы можете извлечь старый сертификат G5 из цепочки, отправленной сервером, и поместить его в хранилище доверия Mozilla. Но я сильно подозреваю, что это запутает пользовательских агентов, пытающихся построить путь, потому что единственное, что изменилось, это серийный номер.
Чтобы понять путаницу, посмотрите на RFC 4158 и как выбрать сертификат. Одним из способов является
{Distinguished Name, Serial Number}кортеж. Но проверяемый сертификат не включает серийный номер эмитента. Он включает в себя только идентификатор отличительного имени и ключ авторизации .Раздел 3.5.12 Соответствие идентификаторам ключей (KID), определяет:
Но это не требуется, и его не хватает в Warez, предоставленном Symantec. Чтобы увидеть это из первых рук, выбросьте промежуточное звено уровня 1, отправленное в цепочку Он называется VeriSign Class 3 Secure Server CA - G3 . Обратите внимание, что у него есть идентификатор ключа авторизации , но нет серийного номера :
источник