Во-первых, это очевидно, что сами корневые сертификаты крупных Certification Authorities будут распространяться в открытом виде, так как это решает проблему курицы и яйца (нелогично отдать новый Root CA по HTTPS с тем же новым chain of trust, так как эта цепочка еще не является доверенной).
Во-вторых, вся эта информация всё-таки лежит на сайте доступном через HTTPS (https://sectigo.com) вместе с инструкциями как проверить эти сертификаты. Нужно учитывать, что эта информация предназначается для крупных игроков (Application Providers), и никакие конечные пользователи оттуда сертфикаты сами устанавливать не будут. (Не зря страница по ссылке называется Sectigo Legal Repository). То есть спецы из Mozilla или Google прежде чем взять и добавить оттуда что-то в trust store, получат это по юридическим каналам с подписями и десять раз перепроверят.
В третьих, habr.com подписан не корневым сертификатом Comodo, а Intermediate CA (COMODO RSA Domain Validation Secure Server CA), что является общеприянтой практикой, так как корневой сертификат такого уровня и его ключ хранятся в сейфе на выключенном из сети HSM. А это очень важно, так как если Intermediate CA будет взломан, его всё-таки можно быстро отозвать с помощью корневого сертификата через CRL или аналогичные механизмы.
Теперь попробуйте это сравнить с ситуацией когда а) конечных пользователей без опыта в IT вообще просят скачать и установить в систему корневой сертификат с сайта по HTTP и b) Этот сертификат стопроцентно находится на включенных в интернет прокси вместе со своим приватным ключом, так как он используется для того, чтобы на лету генерировать и подписывать сертификаты для всех доменов которые вы посещаете (любой MITM так устроен). Надеюсь разница в подходах к безопасности очевидна. Достаточно один раз персонально поучаствовать в физической разлочке Root CA чтобы понять насколько серьезно к этому должны относиться.
Тут самоподписанный корневой сертификат через HTTP раздают, мне кажется их прокси будет сильно хуже, чем разработанная спецами в Касперском. И согласен, MITM прокси в этом плане ужасна, там скорее всего не будет многих проверок, которые делают современные браузеры (например certificate pinning), будут пропускать старые версии TLS с непонятно какими ciphersuites. А вишенкой на торте будут уязвимости самой прокси, которую в итоге или хакнут или сольют приватный ключ от этого корневого сертификата (30 лет валидности хехе)
Немного оптимизма внушает только то, что внедрение root CA поддерживается далеко не везде, особенно в мире нативных приложений (не бразуеров), а с внедрением TLS1.3 может вообще сойти на нет, хотя подозреваю что корпоративные политики будут до последнего использовать фильтрующие прокси с TLS MITM.
Что и требовалось доказать. После того как атака будет проведена (пароли перехвачены и сменены, а деньги например переведены куда надо), атакующего будет мало волновать что вы поймёте что сертификат не тот. Да и сколько людей в процентном соотношении способны проверить/сравнить сертификат?
Это очень частое явление в не-браузерном мире, когда клиент и сервер контролируется одной организацией. Мы, например, делаем то же самое для VPN клиента, что гарантирует то, что никто кроме нас не сможет подписать наши сертификаты (а историй про факапы с доверенными certificate authority было уже предостаточно). Так что это даже секьюрнее.
Разверните пожалуйста ответ, при подмене трафика с этого сайта, как именно это заметить или проверить? Если страницу (с возможными инструкциями по проверке) и сам сертификат можно подменить, а после расшифровать любой трафик этого юзера если он идёт через мой раутер (например в офисе)?
Сам сертификат просто песня:
Самоподписанный, безотзывной, валиден 30 лет, имеет право подписывать сертификаты. (У тех кто владеет приватными ключами огромный оптимизм и вера в то что ключ не утечёт)
...
Issuer: C = KZ, CN = Qaznet Trust Network
Validity
Not Before: Feb 2 05:41:00 2016 GMT
Not After : Feb 2 05:41:00 2046 GMT
Subject: C = KZ, CN = Qaznet Trust Network
...
X509v3 Key Usage: critical
Non Repudiation, Certificate Sign, CRL Sign
...
PS: интересно кому сказать «спасибо» за карму и комментарии в пять минут. На хабре стало опасно выражать своё мнение…
Сам переехал из Казахстана давно, как сетевому спецу было давно понятно, что там делать нечего. Но в данном разрезе меня сильно веселит то, что корневой сертификат безопасности надо скачать с HTTP(!!!)//qca.kz Уровень гос спецов, внезапно, не изменился. Кому надо, делайти MITM на сайт и распространяйте свой корневой сертификат.
Риэлтеры с продажи в Калифорнии, например, имеют около 6%, что даже с цены в миллион будет 60 тысяч. Они и дороже «подарки» делают если кто-то готов через них продать :)
Каждый год проходят Prime Days, распродажи вполне реальные с настоящими скидками. Настолько популярным стал, что магазины помельче тоже писали о скидках в амазоновский prime day.
Такие случаи же тоже должны как-то разрешаться, по серийнику, фото платы при продаже или еще как? Ведь похоже это типичный сценарий для запчастей тогда будет.
Думаю что с использование локального софта так или иначе проблем не должно быть, всё решаемо, даже если потребуется какое-то время на улучшение существующего, опыт со своим линуксом у них уже был, тем более что научный софт исторически под никсами. А вот с сервисами точно, SaaS затем и создавался, чтобы тянуть деньги по подписке постоянно. Офис не зря переехал в 365. Тут нужна вторая итерация опенсорса, уже не только с софтом, но и с общими сервисами, не привязанными ни к какому бизнес-владельцу, который вправе менять условия в любой момент так, что содрать 10x больше денег, как сейчас случилось с CERN.
«присутствует определённый рекламный баннер, который поставляется через рекламную сеть Google AdSense» <-> «Сам по себе он не позволит увязать ваше мобильное устройство и десктопный комп.»
Во-первых, это очевидно, что сами корневые сертификаты крупных Certification Authorities будут распространяться в открытом виде, так как это решает проблему курицы и яйца (нелогично отдать новый Root CA по HTTPS с тем же новым chain of trust, так как эта цепочка еще не является доверенной).
Во-вторых, вся эта информация всё-таки лежит на сайте доступном через HTTPS (https://sectigo.com) вместе с инструкциями как проверить эти сертификаты. Нужно учитывать, что эта информация предназначается для крупных игроков (Application Providers), и никакие конечные пользователи оттуда сертфикаты сами устанавливать не будут. (Не зря страница по ссылке называется Sectigo Legal Repository). То есть спецы из Mozilla или Google прежде чем взять и добавить оттуда что-то в trust store, получат это по юридическим каналам с подписями и десять раз перепроверят.
В третьих, habr.com подписан не корневым сертификатом Comodo, а Intermediate CA (COMODO RSA Domain Validation Secure Server CA), что является общеприянтой практикой, так как корневой сертификат такого уровня и его ключ хранятся в сейфе на выключенном из сети HSM. А это очень важно, так как если Intermediate CA будет взломан, его всё-таки можно быстро отозвать с помощью корневого сертификата через CRL или аналогичные механизмы.
Теперь попробуйте это сравнить с ситуацией когда а) конечных пользователей без опыта в IT вообще просят скачать и установить в систему корневой сертификат с сайта по HTTP и b) Этот сертификат стопроцентно находится на включенных в интернет прокси вместе со своим приватным ключом, так как он используется для того, чтобы на лету генерировать и подписывать сертификаты для всех доменов которые вы посещаете (любой MITM так устроен). Надеюсь разница в подходах к безопасности очевидна. Достаточно один раз персонально поучаствовать в физической разлочке Root CA чтобы понять насколько серьезно к этому должны относиться.
Немного оптимизма внушает только то, что внедрение root CA поддерживается далеко не везде, особенно в мире нативных приложений (не бразуеров), а с внедрением TLS1.3 может вообще сойти на нет, хотя подозреваю что корпоративные политики будут до последнего использовать фильтрующие прокси с TLS MITM.
Сам сертификат просто песня:
Самоподписанный, безотзывной, валиден 30 лет, имеет право подписывать сертификаты. (У тех кто владеет приватными ключами огромный оптимизм и вера в то что ключ не утечёт)
...
Issuer: C = KZ, CN = Qaznet Trust Network
Validity
Not Before: Feb 2 05:41:00 2016 GMT
Not After : Feb 2 05:41:00 2046 GMT
Subject: C = KZ, CN = Qaznet Trust Network
...
X509v3 Key Usage: critical
Non Repudiation, Certificate Sign, CRL Sign
...
PS: интересно кому сказать «спасибо» за карму и комментарии в пять минут. На хабре стало опасно выражать своё мнение…
Кому как, гугл точно свяжет)