Кешируют ли веб-браузеры сертификаты SSL?

26

Кешируют ли веб-браузеры сертификаты сервера SSL? Например, если я изменю SSL-сертификат на веб-сервере, все ли веб-браузеры подберут новый сертификат при подключении через SSL или возможно, что у них может быть устаревший сертификат?

Я имею в виду сценарий, когда срок действия сертификата SSL истекает и заменяется новым на веб-сервере.

— Лорин Хохштайн
источник

Я бы предположил, что браузер проверяет дату на сертификате, чтобы узнать, нужно ли ему получать более новую, как это делается для всего остального, но я не уверен.

— soandos

Посмотрите здесь imperialviolet.org/2011/05/04/pinning.html о «свидетельство пиннинга» и по инициативе HSTS whis связана с бывшим dev.chromium.org/sts

— Shadok

1

Начиная с 2019 года мой Chrome 75 кэширует SSL-сертификаты

— Фабиан Томмен,

10

Что ж, ответ RedGrittyBrick правильный, но на самом деле не отвечает на вопрос. Вопрос заключался в том, если браузеры делают это, а не в том, должны ли они или должны это делать.

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

— tuexss
источник

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

— Ramhound

3

Это снижает его, потому что вы не можете заменить старый ключ SHA-1 на новый, потому что старый все еще действует, и Chrome игнорирует новый, если я все правильно понял. Таким образом, нет никакого способа принудительно перейти на более высокий стандарт безопасности - поэтому он «понижается» в относительном смысле, не давая возможности повысить его. Точно так же, как инфляция не понижает назначенную вами стоимость денег, но ее фактическую рыночную стоимость.

— вторник,

5

+1 После фиаско смешанной цепочки SHA1 / SHA2 в StartSSL стало ясно, что Chrome в Windows действительно кэширует промежуточные сертификаты, возможно, неограниченное время. Chrome будет игнорировать любые новые промежуточные сертификаты, отправленные сервером. Неясно, однако, является ли кэширование ключом идентификации сертификата сервера или промежуточного сертификата и что именно представляет собой эту идентичность.

— Роберт Важан

3

Хит и сегодня Firefox показывает разные сертификаты в обычном окне (старый сертификат) и режиме инкогнито (правильный). Утилиты командной строки, такие как curl или openssl, сообщают, конечно, правильный сертификат. Исправлено путем очистки кэша браузера (ctrl + shift + del) - «куки и другие данные сайта» для chrome и «данные офлайн-сайта» для firefox.

— anilech

1

По крайней мере, текущая версия Firefox (66.0) для OSX, похоже, довольно сильно удерживает свой кеш. Вчера я обновил сертификат TLS для своего сайта, и CLI opensslи Chromium показывают мне новый сертификат. Firefox показывает мне старый, несмотря на перезагрузку с отключенным кешем, очищает весь кеш и офлайн данные и перезагружает браузер

— Тэд Лиспи

20

Нет. Смотрите IBM SSL обзор

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

Сервер SSL отвечает сообщением «hello server», которое содержит CipherSuite, выбранный сервером из списка, предоставленного клиентом SSL, идентификатор сеанса и другую строку случайного байта. Сервер SSL также отправляет свой цифровой сертификат . Если серверу требуется цифровой сертификат для проверки подлинности клиента, сервер отправляет «запрос сертификата клиента», который включает список поддерживаемых типов сертификатов и выделенные имена приемлемых центров сертификации (CA).

Клиент SSL проверяет цифровую подпись на цифровом сертификате сервера SSL и проверяет, является ли выбранный сервером CipherSuite приемлемым.

...

Резюме Microsoft аналогично. Рукопожатие TLS также похоже в этом отношении.

На шаге 2 клиент, похоже, не может сказать: «Не беспокойтесь об отправке сертификата сервера, я буду использовать свой кэш».

Обратите внимание, что существует несколько типов сертификатов, клиент, сервер и CA. Некоторые из них кэшируются.

— RedGrittyBrick
источник

Изменен оригинальный вопрос, чтобы уточнить, что это сертификат сервера.

— Лорин Хохштайн

Это не так, и если предположить, что кеша нет, так как обзор работы SSL исключает кеширование, это довольно плохое оправдание. youtube.com/watch?v=wMFPe-DwULM

— Эван Кэрролл

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

— Даниэль Б

0

Я не уверен, поможет ли мой вклад каким-либо образом, но вот что я только что испытал: у меня есть веб-сайт в лазури с пользовательским доменом. Я попытался получить доступ к нему с помощью https в цветах перед настройкой привязки SSL для моего доменного имени. Chrome говорил мне, что сайт не защищен, что вполне логично (ERR_CERT_COMMON_NAME_INVALID) Но после того, как я загрузил свой сертификат и настроил привязку SSL в Azure, я все еще получал ту же ошибку. На этом этапе при открытии нового частного окна браузера (или с помощью другого браузера) https работал нормально.

Но я никогда не мог заставить его работать в моей открытой сессии Chrome. Я попытался очистить состояние SSL, тот же результат. Сработало после перезапуска хрома вообще.

Я, вероятно, был обманут чем-то, но это почти выглядело, как будто сертификат был кэширован

— Etienne
источник

Эта ошибка будет означать, что вы получили доступ к сайту с URI, который отличается от того, что было в CN. Вы действительно изменили URI для доступа к сайту в Chrome после настройки привязки?

— Сет

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

— Этьен

Как вы сказали, вы настроили привязку SSL к своему домену, означает ли это, что вы получили доступ к серверу, используя свой домен с самого начала, или нет? Ошибка может указывать на разницу между URL-адресом, который вы использовали, и URL-адресом сертификата. Это то, что я имел в виду. Кроме того, ваша фактическая конфигурация сервера может иметь большое значение, если вы думаете о HSTS и тому подобном.

— Сет

1

Шаг 1: опубликовал веб-сайт на лазурь. На этом этапе он имеет как URL-адрес Azure по умолчанию, так и сертификат по умолчанию. Шаг 2: настройте собственный домен для веб-приложения, теперь mysite.com правильно указывает на сайт. Сертификат SSL для mysite.com на этом этапе не настроен. Шаг 3: На этом этапе, когда я пытаюсь зайти на сайт https, я получаю сообщение об ошибке безопасности, в котором говорится, что сертификат не совпадает (и это имеет смысл). Шаг 4: Я устанавливаю сертификат SSL для Mysite.com в Azure и STILL. предупреждение о безопасности выскакивает из Chrome. Это не происходит в любом другом браузере или если я открываю приватную навигацию.

— Этьен

1

Шаг 5. Я перезагружаю Chrome и теперь (и только сейчас) мой веб-сайт обслуживается с использованием правильного SSL-сертификата. Отсюда мой вывод, что действительно была проблема с кешированием сертификата

— Этьен

-1

Некоторые разработчики браузеров планируют внедрить такую систему для обнаружения атак, таких как атака на Diginotar в 2011 году.

Но на данный момент AFAIK ни одна такая система не работает в современных браузерах. Поэтому вам не нужно думать об этой ситуации при обновлении сертификата сервера.

— Роберт
источник