Чем читал? Они не блокируются.

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

SHA-256? SHA-512?

Одобренный NSA Keccak

Тонко

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

Whirlpool

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

Чем предлагают хеши считать?

ГОСТ Р 34.11-2012.

CRC-32, lol

А мне ripemd160 больше нравится.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Да, ты прав.

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

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

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

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

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

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

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

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

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

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

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

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

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

100% гуглам очень выгодно эту дыру эксплуатировать

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

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

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

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

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

Почему это?

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

Нет.

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

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

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

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

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

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

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

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

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

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

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

Да. Когда будет в релизе, вернусь на Firefox.

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

Нет.

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

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

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

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

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

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

спасибо, не надо.

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

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

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

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

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

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

man hsts, hpkp

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

и пиарит шифрование.

И правильно делает.

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

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

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

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

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