Chrome позбавляє довіри Chunghwa Telecom та Netlock
Google Chrome оголосив, що з 31 липня його браузер більше не буде довіряти TLS-сертифікатам, виданим двома відомими центрами сертифікації (ЦС): тайванською Chunghwa Telecom та угорською Netlock. Це рішення стало наслідком річного періоду порушень норм, помилкових видань та загального невиконання суворих вимог, встановлених у Chrome Root Store Policy та CAB Forum’s Baseline Requirements. Для підприємств, розробників і кінцевих користувачів цей крок підкреслює важливість надійного управління життєвим циклом сертифікатів та прозорого управління ЦС.
У практичному сенсі, вебсайти, які використовують сертифікати від цих ЦС, отримуватимуть повноекранне попередження про безпеку в Chrome, закликаючи відвідувачів бути обережними або взагалі відмовитися від з’єднання. Організаціям, які все ще покладаються на ці постачальники, слід переходити до альтернативних ЦС, що відповідають політиці, інакше вони ризикують зазнати перерв у сервісі, зниження SEO-рейтингу та втрати довіри користувачів.
Огляд скасування довіри
Chunghwa Telecom та Netlock протягом багатьох років були надійними учасниками кореневих пакетів браузера, отримуючи довіру на видачу X.509 сертифікатів, підписаних кореневими ключами, визнаними в магазинах Chrome та інших провідних браузерів. Сертифікати, що базуються на цих коренях, забезпечують HTTPS з’єднання, дозволяють OCSP стаплінг і реєструють кожне видання в публічних журналах сертифікаційної прозорості (CT) — механізми, розроблені для запобігання невиявленим помилковим виданням і атакам «людина посередині».
Попри це, команда безпеки Chrome зазначила «тривожні патерни поведінки», що охоплюють кілька політичних сфер: невиконання вимог щодо розкриття сертифікатів проміжних ЦС у Загальній базі даних ЦС (CCADB), затримка скасування помилково виданих сертифікатів та ігнорування термінів звітності під час критичних інцидентів безпеки. З огляду на нульову толерантність програми Chrome Root до повторних або серйозних порушень, ризик, який ці ЦС становили, більше не можна було виправдати.
Тривожні патерни поведінки та технічні недоліки
- Netlock не включив сертифікат проміжного ЦС до CCADB протягом більше 12 місяців, порушуючи вимоги прозорості Політики сертифікатів Mozilla.
- Netlock не скасував помилково виданий сертифікат, незважаючи на 72-годинний термін повідомлення, передбачений вимогами CAB Forum Baseline Requirements v1.8.1.
- Chunghwa Telecom помилково видала 247 сертифікатів з неправильно сформованими записами
subjectAltName, що порушує синтаксис іменування RFC 5280. - Повторні затримки в оновленнях OCSP-респондерів залишили клієнтів без дійсних даних про статус скасування на критичних етапах.
- Обидва ЦС пропустили кілька термінів звітності після публічного розкриття інцидентів безпеки, що підривало перевірку виправлень.
Вимоги програми Chrome Root
Політика Chrome Root Store визначає багаторівневу структуру аудиту та реагування на інциденти. Основні вимоги включають:
- Щоквартальні аудити WebTrust або ETSI, що підтверджують відповідність політикам та операційній безпеці.
- Обов’язкове ведення журналу всіх виданих сертифікатів принаймні в двох незалежних журналах CT із доказами узгодженості між журналами.
- Автоматизовані точки розподілу OCSP або CRL, оновлювані протягом 24 годин після будь-якої події скасування.
- Негайне повідомлення основних браузерів та CCADB про виявлення будь-якого помилкового видання або компрометації ключів.
“Коли ці фактори розглядаються в сукупності та оцінюються щодо вродженого ризику, який кожен публічно визнаний ЦС несе, подальша публічна довіра вже не виправдана,” попередила команда Google у своєму червневому бюлетені безпеки.
Вплив на підприємства та розробників
Організаціям, які використовують сертифікати Chunghwa Telecom або Netlock, слід терміново почати міграцію. Вікно можливостей закривається 31 липня, коли Chrome 122 (або пізніші версії) почне застосовувати недовіру. Автоматизовані платформи управління сертифікатами — що використовують протокол ACME або інтеграції корпоративного PKI — можуть спростити перехід до альтернативних ЦС, таких як Let’s Encrypt, DigiCert або Sectigo, які мають бездоганні записи в журналах CT і історії аудитів.
Розробники також повинні оновити CI/CD конвеєри для перевірки кореневих пакетів ЦС, впровадити моніторинг журналів CT і додати перевірки резервного OCSP-стаплінгу. Команди, що покладаються на проміжні сертифікати, повинні перевірити їх включення до CCADB та протестувати відповіді на скасування в умовах симульованих помилкових видань, щоб забезпечити відповідність політикам і вимогам реальних інцидентів.
Технічний аналіз аудитів відповідності ЦС
Аудити WebTrust та ETSI досліджують управління криптографічними ключами ЦС, фізичний захист апаратних модулів безпеки (HSM), контроль змін програмного забезпечення та зрілість реагування на інциденти. Аудитори перевіряють, що:
- Кореневі та проміжні приватні ключі розподілені між багатопартійними HSM з політиками підписання за порогами.
- Системи видачі сертифікатів забезпечують сувору перевірку контролю домену відповідно до RFC 8555 (ACME) або еквівалентних протоколів.
- Інструменти ведення журналів та моніторингу фіксують кожен запит на сертифікат, етап схвалення та подію видачі в незмінних журналах.
Недоліки в будь-якій з цих областей вказують на прогалини, які зловмисники можуть використати для видачі підроблених сертифікатів, перехоплення зашифрованого трафіку або проведення масштабних фішингових кампаній без виявлення.
Перспективи та тенденції в галузі
Рішучі дії Google сигналізують про ширшу зміну в індустрії в бік суворішого управління кореневими програмами та перевірки відповідності в реальному часі. Майбутні випуски браузерів, ймовірно, посилять контроль за журналами CT, зменшать використання SHA-1 і навіть SHA-2, де це необхідно, та вимагатимуть підтримки DNS-автентифікації іменованих сутностей (DANE) для додаткових рівнів валідації.
Експерти галузі прогнозують частіші випадки недовіри, оскільки цикли аудитів виявляють застарілі ЦС, які не можуть або не бажають відповідати зростаючим стандартам безпеки. Підприємствам і постачальникам хмарних послуг слід стежити за оновленнями кореневих програм у Chrome, Firefox та Microsoft Edge, щоб передбачити та підготуватися до подальших змін у екосистемі цифрових сертифікатів.