Чи кешують веб-браузери SSL-сертифікати?

26

Чи будь-які веб-браузери кешують сертифікати сервера SSL? Наприклад, якщо я зміню сертифікат SSL на веб-сервері, чи всі веб-браузери підберуть новий сертифікат, коли вони підключуються через SSL, чи можливо, вони могли мати сертифікат несвіжої?

Я думаю про сценарій, коли термін дії сертифікату SSL закінчується і замінюється новим на веб-сервері.

— Лорін Хохштайн
джерело

Я б припустив, що браузер перевіряє дату на cert, щоб побачити, чи потрібно йому отримати нову, як це робиться для всього іншого, але я не впевнений.

— soandos

Подивіться тут imperialviolet.org/2011/05/04/pinning.html про "закріплення сертифікатів", а за ініціативою HSTS, що стосується колишнього dev.chromium.org/sts

— Шадок

1

Станом на 2019 рік мій Chrome 75

— кешує

10

Ну, відповідь RedGrittyBrick правильна, але насправді не відповідає на питання. Питання полягало в тому, якщо браузери це роблять, а не в тому випадку, якщо їм це потрібно чи потрібно робити.

З того, що я чув, і MSIE, і Chrome насправді роблять кеш-сертифікати, і не замінюють їх, коли вони отримують нову версію, поки стара версія дійсна. Чому вони роблять це, я не розумію, оскільки це знижує безпеку.

— tuexss
джерело

В даний час прийнята відповідь досить зрозуміла. Це спеціально вказує на те, що ні , браузери не кешують сертифікати. Як ви вказуєте, що ландшафт змінився, і причини, які це робить у Chrome, добре задокументовано, вам було б приємно пов’язати ці причини. Оскільки сертифікат все ще дійсний, він не "знижує" безпеку, яка не мала б сенсу.

— Рамхаунд

3

Це знижує його, тому що ви не можете замінити старий ключ SHA-1 на новий, тому що старий все ще діє, а Chrome ігнорує новий, якщо я все зрозумів правильно. Таким чином, немає способу примусити переключитися на більш високий рівень безпеки - тому він "знижується" у відносному сенсі, не даючи можливості висунути його вище. Так само, як інфляція не знижує визначену вами суму грошей, а її фактичну ринкову вартість.

— tuexss

5

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

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

3

сьогодні трапляється проблема, і Chrome, і Firefox показують різні сертифікати у звичайному вікні (старий сертифікат) та режимі інкогніто (правильний). Утиліти командного рядка, такі як curl або openssl, звітують про правильний сертифікат курсу. Виправлено очищенням кешу браузера (ctrl + shift + del) - "файли cookie та інші дані про сайт" для chrome та "offline дані веб-сайту" для firefox.

— анілех

1

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

— Tad Lispy

20

Ні. Див. Огляд IBM SSL

Клієнт SSL надсилає повідомлення "привіт клієнтові", в якому перераховується криптографічна інформація, така як версія SSL, та в порядку уподобань клієнта підтримуються клієнтом CipherSuites. Повідомлення також містить випадковий рядок байтів, який використовується в наступних обчисленнях. Протокол SSL дозволяє "клієнту привіт" включати методи стиснення даних, підтримувані клієнтом, але поточні реалізації SSL зазвичай не включають це положення.

Сервер SSL відповідає на повідомлення "привіт сервера", яке містить вибраний сервером 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 лазурно, я все-таки отримував ту саму помилку. На цьому етапі відкриття нового вікна приватного браузера (або використання іншого браузера) https працювало чудово.

Але я ніколи не міг змусити його працювати у відкритому сеансі Chrome. Я спробував очистити стан SSL, такий же результат. Це спрацювало після перезавантаження хрому взагалі.

Мене, напевно, щось обмануло, але це мало не схоже на керт ...

— Етьєнн
джерело

Ця помилка означатиме, що ви отримали доступ до сайту з URI, який відрізнявся від того, що було в CN. Ви дійсно змінили URI для доступу до сайту в хромі після встановлення прив'язки?

— Сет

ні, єдине, що я змінив у той час, було обов'язковим. Коли я вперше запитував https, його подавали за допомогою типового cert azure ssl cert, але він все ще обслуговував мене після того, як я змінив прив'язку правильним cert на Azure.

— Етьєн

Як ви сказали, що ви налаштували прив'язку SSL домену, чи означає це, що ви зверталися до сервера, використовуючи свій домен із початку роботи чи ні? Помилка вказуватиме на те, що між URL-адресою, яку ви використовували, та URL-адресою, для якої використовувався сертифікат, була різниця. Це я мав на увазі. Крім того, ваша фактична конфігурація сервера може мати велике значення, якщо ви думаєте про HSTS та інше.

— Сет

1

Крок 1: опублікований веб-сайт, щоб бути azure. На цьому етапі він має як URL-адресу блакитного замовчування, так і cert за замовчуванням. Крок 2: налаштування користувацького домену для веб-програми, тепер mysite.com правильно вказує на сайт. На цьому етапі не налаштовано протокол SSL для mysite.com. Крок 3: У цей момент, намагаючись https-сайт, я отримую помилку безпеки, кажучи, що cert не відповідає (і це має ідеальний сенс). Крок 4: Я встановлюю SSL-сертифікат для Mysite.com лазурним та ВСІЛЬНО з Chrome з’являється попередження про безпеку. Він НЕ зустрічається в будь-якому іншому браузері або якщо я відкриваю приватний навичок.

— Етьєн

1

Крок 5: Я перезавантажую Chrome, і тепер (і тільки зараз) мій веб-сайт обслуговується за допомогою правильного сертифіката SSL. Звідси мій висновок, що справді виникла проблема кешування сертифіката

— Етьєн

-1

Є плани деяких розробників браузерів впровадити таку систему чачінгу для виявлення атак, як атака на Diginotar у 2011 році.

Але на даний момент AFAIK жодна така система не активна в поточних браузерах. Тому вам не доведеться думати про цю ситуацію під час оновлення сертифіката сервера.

— Роберт
джерело