LINUX.ORG.RU

В новой версии Google Chrome будут помечаться небезопасными SSL-сертификаты, использующие алгоритм SHA-1

 , , ,


2

1

Для Google Chrome 42 cтало реальностью заявление, сделанное еще осенью 2014 года о пометке небезопасными браузером сертификатов, использующих алгоритм SHA-1.

Однако, затронуты будут не все сертификаты. Результат отображения статуса сертификата зависит от его даты выдачи.

>>> Подробности



Проверено: Shaman007 ()

MD-5 не тру, SHA-1 выкидывают. Чем предлагают хеши считать?

anonymous ()
Ответ на: комментарий от anonymous

MD-5 не тру, SHA-1 выкидывают. Чем предлагают хеши считать?

Whirlpool

dnf83 ()

Chrome это одна большая дыра в безопасности.

anonymous ()

Когда там http запишут в дыру?

mandala ★★★★ ()

Страшно жить! Я в своём быдлокоде sha384 использовать боюсь, а в SSL sha1 оказывается.

fero ★★★★ ()

Ну и нормально. Благо у продавцов сертификатов их можно пересоздавать сколько душе угодно при условии неизменности даты конца валидности.

jekader ★★★★★ ()

Блин, да когда ж закопают уже этого хромого инвалида?! Не броузер а УГ сплошное!

Lord_Dewl ()
Ответ на: комментарий от Lord_Dewl

Ха, разбежался. Гугл задает моду, вот сейчас закапывает http и пиарит шифрование.

mandala ★★★★ ()

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

Централизованнные центры сертификации - адское зло. И защищает только от скрипт-кидди, просто по своему дизайну.

kir2yar ()
Ответ на: комментарий от kir2yar

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

Только через сторонние каналы получить 100500 сертификатов для всех сайтов, куда когда либо ходишь + всех платежных систем просто замучаешься. А уж обновлять и актуализировать это еще 100500 раз нужно через «левый» канал получить сертификат.

Собственно, публичный ключ + имя сервиса удобнее самоподписанного сертификата. Но это не решает проблему 100500 сертификатов.

Централизованные CA решают, но создают новую проблему - нет стандарта кто может генерить ключ для определенного сервиса.

По нормальному через DNSSEC нужно раздавать не только IP серверов, но и для каждого URL хранить сертификат CA, который может подтвердить сертификат сервера.

Это защитит от возможности любого CA сформировать валидный, но поддельный сертификат.

Останется только проблема доверия корневому серверу и сертификату корневого сервера.

VoDA ★★ ()
Ответ на: комментарий от Lord_Dewl

Блин, да когда ж закопают уже этого хромого инвалида?! Не броузер а УГ сплошное!

Когда в мозиле табы будут в разных потоках работать

userd ()
Ответ на: комментарий от VoDA

Только через сторонние каналы получить 100500 сертификатов для всех сайтов, куда когда либо ходишь + всех платежных систем просто замучаешься. А уж обновлять и актуализировать это еще 100500 раз нужно через «левый» канал получить сертификат.

Собственно, публичный ключ + имя сервиса удобнее самоподписанного сертификата. Но это не решает проблему 100500 сертификатов.

Да, ты прав.

Централизованные CA решают, но создают новую проблему
Останется только проблема доверия корневому серверу и сертификату корневого сервера.

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

ИМХО - каждый сайт должен генерировать себе сертификат сам, а публичные ключи следует раздавать через распределенную и децинтрализованную сеть по типу freenet/i2p. Ключи весят копейки, трафика особого не будет, соответственно работать все будет достаточно быстро.

kir2yar ()

Плевать мы хотели на Google Chrome. Эта бяка даже не запускается на процессарах не умеющих SSE2.

zenden ()
Ответ на: комментарий от kir2yar

ИМХО - каждый сайт должен генерировать себе сертификат сам, а публичные ключи следует раздавать через распределенную и децинтрализованную сеть по типу freenet/i2p.

А как удостовериться, что этот сертификат положил именно владелец сайта, а не кулхацкер Вася? И как удостовериться, что обновленный ключ тоже выложил владелец?

Распределенная сеть решает проблему доставки сертификатов, но не решает проблему доверия.

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

Вопрос не в том, что нужны или не нужны CA. Вопрос в том, «кто будет охранять охранников»? Как ограничить CA, чтобы сами центры не стали рассадниками поддельных сертификатов, или не продавали промежуточные сертификаты (что еще хуже).

VoDA ★★ ()
Ответ на: комментарий от anonymous

SHA-2 же. Железо, способное создавать коллизии SHA-1 появится уже в ближайшие лет 5.

anonymous ()

Эка невидаль, будет сайты какашками называть.

Суровые мужики (читай firefox) на сайты, использующие RC4, тупо не пускают с 36 версии.

Dao_Dezi ()
Ответ на: комментарий от zenden

Ты ещё забыл про ядра, младше 3.17, с которыми Хромой будет неполноценно работать скоро.

sluggard ★★★★★ ()
Ответ на: комментарий от VoDA

А как удостовериться, что этот сертификат положил именно владелец сайта, а не кулхацкер Вася? И как удостовериться, что обновленный ключ тоже выложил владелец?

Я так полагаю, что левый ключ не будет соответвовать правильному сертификату, которым подписан/защифрован контент сайта.
Ключи будут привязанны к доменному имени. Доверие будет организованно большинством. Если большинство пиров в распределенной среде доверяют ключу А, то он считается верным.
Если сайт хостится так, что большинству приходит контент, который защищен не верным сертификатом (скажем, произошла подмена сертификата на шлюзе хостера) - то это не проблемма системы.

kir2yar ()
Ответ на: комментарий от kir2yar

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

Если сторонний канал не скомпрометирован.

Централизованнные центры сертификации - адское зло.

Почему это?

И защищает только от скрипт-кидди, просто по своему дизайну.

Нет.

Legioner ★★★★★ ()

Дык у меня хром 41, но он уже ругается на SHA-1 сертификаты

pmedved ()
Ответ на: комментарий от VoDA

По нормальному через DNSSEC нужно раздавать не только IP серверов, но и для каждого URL хранить сертификат CA, который может подтвердить сертификат сервера.

По-нормальному сделано в TOR-е. Когда публичный ключ закодирован в доменном имени.

Legioner ★★★★★ ()
Ответ на: комментарий от userd

Эм.. В разных процессах?

Включить e10s и выставить dom.ipc.processCount побольше?
Правда, все это в nightly

Kuzz ★★★ ()
Ответ на: комментарий от fero

Страшно жить! Я в своём быдлокоде sha384 использовать боюсь, а в SSL sha1 оказывается.

при чём это sha1 было там в OpenSSL в конфиге *поумолчанию* (прям совсем недавно, несколько месяцев назад такое было!).. то есть при генерации сертификата если не указывать название функции.

а в некоторых дистрибутивах наверное и до сих пор в OpenSSL в конфиге поумолчанию используется sha1 :-)

user_id_68054 ★★★★★ ()
Ответ на: комментарий от mandala

Гугл задает моду, вот сейчас закапывает http

а как Google Chrome решил — Alt-Svc-для-http поддерживать или не поддерживать?

или как раз чтобы НЕ делать Alt-Svc-для-http — они хотят просто избавиться от http ? :-)

user_id_68054 ★★★★★ ()
Последнее исправление: user_id_68054 (всего исправлений: 2)
Ответ на: комментарий от Legioner

И защищает только от скрипт-кидди, просто по своему дизайну.

Нет.

https://www.google.ru/search?q=перехват https

До жопы рецептов. Если у тебя есть доступ хоть к одному из удостоверяющих центров, которым доверяет клиент - ты можешь выпустить валидный сертификат для любого домена и устроить MITM.

А такого доступа нет только у юных кулхацкеров да скрипт-кидди.

kir2yar ()
Ответ на: комментарий от kir2yar

Если у тебя есть доступ хоть к одному из удостоверяющих центров...

отлично! достаточно получить этот доступ ;)

[sarcasm]делов-то.. каждый день это делаю как разминку перед завтраком![/sarcasm]

user_id_68054 ★★★★★ ()
Последнее исправление: user_id_68054 (всего исправлений: 1)
Ответ на: комментарий от kir2yar

ты можешь выпустить валидный сертификат для любого домена

Не любого, почитай про certificate pinning.

Vovka-Korovka ★★★★★ ()
Ответ на: комментарий от kir2yar

До жопы рецептов. Если у тебя есть доступ хоть к одному из удостоверяющих центров, которым доверяет клиент - ты можешь выпустить валидный сертификат для любого домена и устроить MITM.

Не можешь. man hsts, hpkp

А такого доступа нет только у юных кулхацкеров да скрипт-кидди.

Такого доступа на практике ни у кого. Что случается с тупыми УЦ, забывающими про это — можешь погуглить, недавно все браузеры выкинули китайский национальный удостоверяющий центр за тупость.

Legioner ★★★★★ ()
Ответ на: комментарий от Legioner

man hsts, hpkp

hsts перекидывает на https при входе на http. hpkp не решает проблему доверия. никак.

HPKP is a Trust on First Use (TOFU) technique.

Если первым будет поддельный сертификат от MITM, то hpkp не сработает. не очевидно как отработает hpkp на валидную смену ключей из за компрометации старых.

недавно все браузеры выкинули китайский национальный удостоверяющий центр за тупость.

Только начали гнобить. Забанят еще не скоро.

VoDA ★★ ()
Ответ на: комментарий от Vovka-Korovka

ты можешь выпустить валидный сертификат для любого домена

Не любого, почитай про certificate pinning.

Любого-любого. Только редкие программы таскают с собой прибинненые сертификаты. Известно, что гугл в chrome внес сертификаты для *.google.com

Но тот же Chrome легко пропустит мошеннический сертификат для сайта рога-и-копыта.ру

До ПО нужно донести не только сертификат, который подтверждает, что сервер обслуживает конкретное доменное имя, но и информацию о том, какой CA удостоверяет это доменное имя.

Пока действует практика, что любой CA может выдать сертификат на любой домен. Даже если на этот домен выдавал сертификат другой CA и совсем другим лицам.

VoDA ★★ ()
Ответ на: комментарий от VoDA

hsts перекидывает на https при входе на http

Без него у активного атакующего слишком большие шансы перекинуть браузер на HTTP.

hpkp не решает проблему доверия. никак.

Если ты не под колпаком, твой сертификат будет у многих юзеров в кеше и любая попытка использования MITM будет моментально сдетектирована браузерами и сертификат беспредельщика улетит из твоего браузера на юг со следующим обновлением.

Если первым будет поддельный сертификат от MITM, то hpkp не сработает.

Во-первых certificate preloading. Во-вторых рисковать многомиллиардным бизнесом не зная, был ли браузер на этом сайте или нет? Ну только если ты путина MITM-ишь. Но у него, я думаю, есть свои методы борьбы с MITM.

не очевидно как отработает hpkp на валидную смену ключей из за компрометации старых.

Никаких проблем. В HPKP-заголовке указываются два ключа. Один используется, второй в бэкапе как раз для случая компрометации. Меняешь сертификат на бэкапный ключ, генеришь новый бэкапный ключ, старый убираешь и всё.

Только начали гнобить. Забанят еще не скоро.

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

Legioner ★★★★★ ()
Ответ на: комментарий от VoDA

До ПО нужно донести не только сертификат, который подтверждает, что сервер обслуживает конкретное доменное имя, но и информацию о том, какой CA удостоверяет это доменное имя.

При чём тут CA? До ПО нужно донести хеш публичного ключа. А кто там сертификат подписал это уже глубоко пофиг.

Пока действует практика, что любой CA может выдать сертификат на любой домен. Даже если на этот домен выдавал сертификат другой CA и совсем другим лицам.

И это правильно, а как иначе-то? Привязывать юзера к CA? За отзыв сертификата они бабки просят вообще то.

Legioner ★★★★★ ()
Последнее исправление: Legioner (всего исправлений: 1)
Ответ на: комментарий от Legioner

Что случается с тупыми УЦ, забывающими про это — можешь погуглить, недавно все браузеры выкинули китайский национальный удостоверяющий центр за тупость.

К слову этот CA пинают не за то, что они выпустили мошеннический сертификат, а за то, что продали налево промежуточный сертификат, который можно использовать для подписания всего-чего-угодно.

И запалились на том, что этим промежуточным генерили сертификаты на *.google.com

VoDA ★★ ()
Ответ на: комментарий от Legioner

При чём тут CA? До ПО нужно донести хеш публичного ключа. А кто там сертификат подписал это уже глубоко пофиг.

Нужен публичный ключ + имя сервиса. Причем и то и другой из доверенного источника. Для одного сайта это сделать можно, для 100500 - нет. Тогда и нужно сделать CA, которому доверяют и который посредством сертификатов и доносит информацию о публичном ключе + имени сервиса.

VoDA ★★ ()
Ответ на: комментарий от VoDA

К слову этот CA пинают не за то, что они выпустили мошеннический сертификат, а за то, что продали налево промежуточный сертификат, который можно использовать для подписания всего-чего-угодно.

А точнее за то, что нормально не проверили тех, кому продали. Так то продают все.

Legioner ★★★★★ ()
Ответ на: комментарий от Legioner

И это правильно, а как иначе-то? Привязывать юзера к CA? За отзыв сертификата они бабки просят вообще то.

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

Примерно как сейчас с регистрацией доменов - регистрировать можешь в любом (относительно), но только в одном. Не нравится регистратор - переноси к другому.

VoDA ★★ ()

Сверните в мини-новость

Кому какое дело, что там делают в закрытом, зондированном ПО?

Да, специалисты Гугл выявили недостатки sha-1, молодцы. А на их зонд откровенно пофиг.

gh0stwizard ★★★★★ ()
Ответ на: комментарий от user_id_68054

Alt-Svc - фича из HTTP/2. К обычному http она отношения не имеет. HTTP/2 же, на данный момент, у всех, у кого реализован - реализован с шифрованием. Даже хотели в стандарте прописать обязательность шифрования, но в последний момент уступили эмбедщикам, которые упирали на то, что шифрование в некоторых случаях не нужно, зато жрет драгоценные ресурсы. Впрочем, разработчики из Mozilla и Google решили из принципа не реализовывать в своих продуктах HTTP/2 без шифрования.

anonymous ()
Ответ на: комментарий от Vovka-Korovka

Ну, выпустить-то можно для любого домена. Именно выпустить. А вот заюзать - тут ты прав, во всех нормальных браузерах (в лисе и хромиуме точно) прямо в коде жестко прописаны допустимые сертификаты для самых популярных сервисов (а-ля gmail). Собственно, именно так и стало известно, что китайский удостоверяющий центр недавно выпустил сертификат, который один из его клиентов стал использовать для генерации поддельных сертификатов направо и налево. Все экземпляры Chrome, обнаружив несовпадение полученного сертификата со вшитым, немедленно отстучали в гугл.

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.