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

хорошо. спасиб за справку (очень интересно, правда, не сарказм).

ну тыг и всё-таки как там — поддерживает ли Google Chrome Alt-Svc-для-http ? (или будут ли? если щаз нет поддержки)

Известно, что гугл в chrome внес сертификаты для *.google.com

В лисе тоже есть список сертификатов.

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

Не знаю насчет хрома, но для лисы есть CertPatrol, который при изменении сертификата сервера выдает алерт со списком изменений в сертификате. Если вдруг ВНЕЗАПНО у рога-и-копыта.ру резко изменился сертификат (например, стал выдан другим центром), то это сигнал, что пока лучше через сайт конфиденциальную инфу не передавать и связаться с админом.

Только редкие программы таскают с собой прибинненые сертификаты.

А вот тут непаханное поле для разработчиков стороннего софта. Нужно что-то вроде виндового EMET, который позволяет юзеру самому пиннить сертификаты для любых сайтов. Но пока это работает лишь для IE (надеюсь, допилят до поддержки любой выбранной юзером софтины). Для Linux никто подобного не встречал?

Не интересуюсь развитием хрома, если честно. Вот в лисе пока отключили поддержку Alt-Svc из-за уязвимости. В следующей версии включат обратно + пофиксят дырку. Судя по всему, уязвимость не в самом протоколе, а в конкретной реализации.

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

Когда самоподписанный сертификат не будет считаться дырой. Какого хрена мне платить бабки сторонним сервисам?

Судя по всему, уязвимость не в самом протоколе, а в конкретной реализации.

bug-report закрыт от чтения (не знаю что внутри), но когда я смотрел как работает Alt-Svc в Firefox (в изначальной версии v37) — я заметил следущую странность:

если http-версия (которая может быть и подменённой злоумышленником, если MitM) имеет Alt-Svc, и если на неё был хотябы один раз заход..

..то через несколько милисекунд после открытия — можно сделать Javascript-редирект на https-версию (location.assign('https://'+location.host)) .

в этом случае — если https-версия имеет даже хоть невалидный протокол — Firefox всё равно покажет будто бы всё нормально и безопасно, якобы сертификат нормальный! (и Firefox даже инфу о сертификате покажет, по клику на иконку замочка, лол)

вообщем можно было подменить https в случае если подменить тоже и http .

разумеется это ошибка реализации :) ..

правильно реализованная версия — должна чётко ОТЛИЧАТЬ https-показываемый-как-http от настоящего https !

то есть — имея правильно-реальзованный Alt-Svc — мы получае аж целых ТРИ протокола (вместо двух):

• http-показываемый-как-http
• https-показываемый-как-https
• https-показываемый-как-http

а Firefox думал (с точки зрения безопасности) будто https он якобы и есть https.

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

пиарит

Ты сделал несколько ошибок в слове «пидорит».

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

Как указал? Где? Если он может юзеру что-то надёжно указать, то CA в принципе не нужен, т.к. сервису достаточно юзеру указать, какой публичный ключ он использует.

Когда самоподписанный сертификат не будет считаться дырой.

Но ведь это дыра. Потому что MITM легко может притвориться тобой. Самоподписанный сертификат лучше, чем HTTP, потому что защищает от пассивного наблюдателя, но HTTPS подразумевает полную безопасность.

Какого хрена мне платить бабки сторонним сервисам?

Не плати, есть сторонние сервисы, которые выдают бесплатные сертификаты.

В лисе тоже есть список сертификатов.

Только там всего несколько сайтов и все. Ни банков, ни платежных шлюзов нет.

Если вдруг ВНЕЗАПНО у рога-и-копыта.ру резко изменился сертификат (например, стал выдан другим центром), то это сигнал, что пока лучше через сайт конфиденциальную инфу не передавать и связаться с админом.

Это поймем ты, я и адекватные ИТ-шники. А что делать с обычными пользователями? Хомячкам тоже нужно оплачивать покупки через Инет.

К тому же должна быть возможность миграции от одного CA к другому без ошибок со стороны браузера/ПО.

ИМХО корректный CA для сайта нужно распространять как одну из записей DNSSEC. Единственно тут затыкается на доверии корневому домену.

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

Как указал? Где? Если он может юзеру что-то надёжно указать, то CA в принципе не нужен, т.к. сервису достаточно юзеру указать, какой публичный ключ он использует.

ИМХО указать в одной из записей DNSSEC. Тогда все, что нужно знать - сертификат корневого домена. Дальше по иерархии DNS получаем подтвержденный CA. Берем сертификат сервера - если CA тот же, то доверяем. Если CA указанный для сайта в DNS и CA реального сертификата разные, то выявляем обман.

Когда самоподписанный сертификат не будет считаться дырой. Какого хрена мне платить бабки сторонним сервисам?

Было бы смешно, если б не было так грусно.

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

Это не риторический вопрос. Меня интересует конкретная дата, принципиальное решение корпорация бобра уже приняла.

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

А что, Trustwave уже разорился?

ИМХО указать в одной из записей DNSSEC. Тогда все, что нужно знать - сертификат корневого домена. Дальше по иерархии DNS получаем подтвержденный CA. Берем сертификат сервера - если CA тот же, то доверяем. Если CA указанный для сайта в DNS и CA реального сертификата разные, то выявляем обман.

Про DNSSEC я много не знаю, но, имхо, тут ровно та же проблема доверия центральному сертификату. Да и сегодня эта технология мало распространена.

На основе DNSSEC есть DANE — там публичный ключ сервера указывается в DNS-записи и никакого дополнительного CA не нужно. Самоподписанный сертификат прекрасно подойдёт. Но, опять же, нужна поддержка всего этого добра в браузерах и поддержка DNSSEC. Пока этого не будет, от SSL с доверием никуда не деться.

А что с ним?

Не плати.

https://www.startssl.com/?app=1

Не плати

Гут, пощупаю. Хотя при платных wildcards и сроке в 1 год придётся дофига часто обновлять сертификаты. У меня доменов/поддоменов в совокупности — десятки.

Гы.

Ошибка при установлении защищённого соединения

An error occurred during a connection to auth.startssl.com. SSL peer was unable to negotiate an acceptable set of security parameters. (Error code: ssl_error_handshake_failure_alert) 

решение - несколько сертификатов параллельно

от разных CA

А что с ним?

Да ничего, они просто продавали сертификат для mitm, их поймали за руку, поругали, они извинились и сказали что больше не будут. Живут спокойно, продолжают работать.

https://en.wikipedia.org/wiki/Trustwave_Holdings#Unrestricted_sub-CA_Incident

Когда самоподписанный сертификат не будет считаться дырой. Какого хрена мне платить бабки сторонним сервисам?

Осталось всего несколько месяцев до бесплатной раздачи сертификатов всем желающим

Уроды, что скажешь. Сейчас бы это им с рук не сошло.

Сейчас бы это им с рук не сошло.

Я вот боюсь, что если поймают какой-нибудь Thawte или Comodo, то им тоже всё сойдёт с рук. Потому что Мозилла не рискнёт удалять сертификат от таких крупных контор, это миллионы пользователей и куча серьёзных сайтов, работающих с огромными деньгами.

Будет много шума, CA скажет, что этого точно никогда не повторится, а браузерам придётся поверить на слово.