На рассмотрение в комитет IETF (Internet Engineering Task Force) внесен черновой вариант (http://tack.io/draft.html) стандарта, определяющего дополнение к протоколу TLS, предназначенное для защиты пользователей от атак MITM (Man-in-the-middle), основанных на использовании поддельных сертификатов, выданных корневыми удостоверяющими центрами. Стандарт появился в ответ на случаи взлома серверов корневых удостоверяющих центров (CA) Comodo (https://www.opennet.ru/opennews/art.shtml?num=30013) и DigiNotar (https://www.opennet.ru/opennews/art.shtml?num=31635) в прошлом году.Стандарт определяет легковесное расширение TLS-протокола TACK (Trust Assertions for Certificate Keys), суть которого состоит в том, чтобы позволить браузеру "запомнить" информацию о сертификатах веб-сайта и использовать ее для блокирования соединения или информирования пользователя об угрозе в том случае если против него будет осуществлена MITM-атака с использованием поддельных сертификатов, выданных другими корневыми удостоверяющими центрами.
Благодаря TACK веб-сайты смогут подписывать свои сертификаты с помощью приватного TACK-ключа, отправляя публичный ключ браузеру при установке TLS-сессии. После того, как пользователь несколько раз зайдет на сайт, браузер установит привязку (pin) открытого ключа к доменному имени на определенный промежуток времени (до 30 дней). Если в будущем против пользователя будет осуществлена MITM-атака с использованием поддельных сертификатов, браузер сможет легко проверить подлинность сертификата с помощью TACK-ключа.
TACK позволяет организовать еще один слой защиты SSL, который гарантирует, что осуществление атаки против пользователя будет возможно только в том случае, если будут скомпрометированы и веб-сайт и центр сертификации. В целом такая схема напоминает подход, используемый в браузере Google Chrome, который имеет белый список центров сертификации, которые могут подписывать сертификаты для домена google.com, а также ряда других доменов, но обладает большей гибкостью, позволяя создавать привязки сертификатов к доменам динамически.
Поддержка TACK должна быть реализована как на стороне клиента, так и сервера, однако она не является необходимой. Клиенты, без поддержки TACK будут продолжать работать с серверами полагаясь на полное доверие к CA.
URL: http://arstechnica.com/security/2012/05/ssl-fix-flags-forged.../
Новость: https://www.opennet.ru/opennews/art.shtml?num=33937
Загадочно как-то. Можно просто давать сайту генерировать свой сертификат, подписанный авторизованным центром, а дальше полагаться доверять или этому сертификату сайта или сертификату, им подписанному. Ну и напрашиваются перекрёстные подписи тогда.А уж почему 30 дней - вообще непонятно.
какие-то костыли
> какие-то костылиКостыли. Но довольно логичные. Вообще, я не понимаю почему запоминание параметров серта + алерт при их изменении не сделали сразу. Так вообще любой rogue CA будет обнаружен и юзер словит аларм.
> какие-то костылихуже: это костыли для костылей вообще.
а что помешает подменить целевой сайт пока браухер ещё не совсем запомнил его?
> а что помешает подменить целевой сайт пока браухер ещё не совсем запомнил
> его?Потому и костыль. Надпиленный.
Позвонить в банк/магазин/вебмастеру и попросить продиктовать фингерпринт оригинального сертификата. Или получить его распечатку при оформлении счета.
//KOТо что здесь предлагают, это что-то вроде .ssh/known_hosts, судя по описанию. Не больше и не меньше. Странно, что изначально не доперли это сделать.
Этот набор костылей пропихивать как стандарт? IT деградирует.
Можете предложить что-то лучшее? Понятной альтернативы SSl/TLS пока нет и не предвидится. Когда появится тогда (возможно) и произойдёт переход, а работать надо сейчас. Причем новое решение надо не просто придумать - оно должно стать общепринятым, то есть поддерживаться всеми основными браузерами, быть понятным и приемлемым для бизнеса (что неприемлемо для сетей доверия) и т.п.
> Можете предложить что-то лучшее?конечно. а кто внедрять будет?
> быть понятным и приемлемым для бизнеса (что неприемлемо для сетей доверия) и т.п.
а вот мне положить на «бизнес». совершенно положить. это их личные проблемы. и вот нечто похожее на «сети доверия» как раз будет работать, и работать надёжней (для меня). как с этим будет работать «бизнес» — мне неинтересно. а пока что я просто заблокировал весь https по несамоподписаным сертификатам: не люблю угрюмые централизованые костыли.
Если Вы имеете в виду систему, которая применялась в pgp. То «сеть доверия» накроется при наличии пары дятлов. На самом деле их будет намного больше. ИМХО
> Если Вы имеете в виду систему, которая применялась в pgp. То «сеть
> доверия» накроется при наличии пары дятлов. На самом деле их будет
> намного больше. ИМХОиз принципа читаем выборочно? слова «нечто похожее» незаметны? нет, я не собираюсь сейчас разрабатывать подробную структуру — потому что это время и труд, которые уйдут в помойку. примерно я себе представляю, что и как — мне этого достаточно.
Ну в общих чертах опишите - во-первых интересно, а во-вторых - если получится прикрутить эту штуку параллельно существующему SSL то может и получится хотя бы среди гиков завести. А там смотря как дело пойдёт.
что значит «параллельно»? это в любом случае новый протокол и новые методы (чинить то, что defective by design смысла нет), их надо реализовывать и в серверах, и в браузерах. потому не вижу смысла.
В идеале "параллельно" - значит: оставляем старые серификаты, но по-другому проверяем их подлинность. Если сервер этого не умеет - используем обычный SSL - всяко лучше, чем вообще открытый канал.
это называется «делаем подпорки для костылей». как я уже говорил, то, что defective by design, не надо чинить, его надо аннигилировать. во-вторых, если оставить костыли, то ними и будут пользоваться: в силу инерции.тут главное портерингом не стать.
А чем вам сами сертификаты не угодили? Алгоритмы там можно любые использовать, поля добавлять - тоже сколько угодно, формат стандартный... Что не так? Вот инфрастуктура - дело другое.
> А чем вам сами сертификаты не угодили?а зачем оно? нееееет, сжигать — так сжигать. чтобы и духу не было.
Заблокировать https недолго - но клиент-банк как-то работать должен, нужен доступ к закрытой зоне корпоративного сайта (своего или клиентского) и крутящимися там веб-приложениями, к гуглосервисам, без которых сейчас мало кто обходится... Так что без https полностью лично у меня жить не выйдет - хотя бы потому что рабочий trac доступен только через него.А то, что не подходит для бизнеса, просто-напросто не окажется в браузерах и серверах. По причине отсутствия достаточного количества ресурсов на внедрение. Сеть доверия здесь точно не гдится - там принимать решение приходится массовому неквалифицированному пользователю, что, понятно дело, неприемлемо - он там надоверяет...
> клиент-банк как-то работать долженя не использую.
> нужен доступ к закрытой зоне корпоративного сайта
самоподписаные сертификаты.
> к гуглосервисам, без которых сейчас мало кто обходится
я обхожусь. точнее, иногда использую гугломыло, smpt которого у меня и разбанен единственный. и то я его использую только когда надо где-то зарегистрироваться и не берёт mailcatch в основном.
> потому что рабочий trac доступен только через него.
самоподписаные сертификаты.
> А то, что не подходит для бизнеса, просто-напросто не окажется в браузерах
> и серверах.поэтому я и не вижу смысла напрягаться и «доводить до ума» свои идеи.
> Сеть доверия здесь точно не гдится — там принимать решение приходится массовому
> неквалифицированному пользователю, что, понятно дело, неприемлемо — он там надоверяет…тут не только сеть доверия, но ещё и как минимум распределённая сеть ключей, как в pgp. и ещё кое-что. неа, уточнять не хочу: будем считать, что я или балабол, или очень жадный.
Как одна из альтернатив - DANE, уже почти стандарт.
draft-ietf-dane-protocol-21.txt
Угу, и те, кто контролирует домен второго уровня, будут монополистами для всех его поддоменов. Сейчас хоть конкуренция есть. В общем, по виду - опять же костыль, да еще и с возможностью вырастить монополистов.
Попытка стандартизировать защиту от дурака :)Запасаемся попкорном и ждем нового расширения для раширения для SSL/TLS, для борьбы с новыми угрозами, возникающими по причине тупости менеджеров и криворукости админов.
ребятки упорно чинят то, что defective by design. ну, их право, конечно. выкинуть-то систему нельзя: на ней Большие Люди бабки стригут.
> ребятки упорно чинят то, что defective by design. ну, их право, конечно.
> выкинуть-то систему нельзя: на ней Большие Люди бабки стригут.РеволюЧионеры - в следующей палате!
Вот SMTP - уж его только ленивый не пинал ... но при этом _никто_ не соскочил!
Так что лай собачка, лай ... :)
> Вот SMTP - уж его только ленивый не пинал ... но при этом _никто_ не соскочил!Как это не соскочил? Соскочил и уже давно. Года четыре как, если не пять...
Костыли одни нет готового компатного кода решения...
На самом деле ничего нового. Боян чудовищный - распределение ключей. Точнее доверенная передача закрытого ключа. Корневые CA доверие утратили.В итоге имеем все то же окошко для самоподписанных ключей: доверять? Y/N
> В итоге имеем все то же окошко для самоподписанных ключей: доверять? Y/Nа также «круги доверия» и ещё много чего. построить распределённую систему можно, только тогда у CA не выйдет стричь бабло за воздух (а они стригут за воздух, потому что доверия им нет никакого).
Это расширение не помогает в случае, когда человек заходит на сайт в первый раз, и уже через mitm.
Например, недобросовестный провайдер может настроить ssl сниффер на какой-то банк клиент.
Те, кто будут заходить на сайт в первый раз, никак не защищены этим расширением.Хотя ничего лучше предложить не могу.
Разве только - усугубление ответственности для CA-компаний.Кстати, про компанию DigiNotar.
Она обанкротилась.
http://diginotar.nl/Мне кажется, разработчикам браузеров и дистрибутивов просто нужно оперативно реагировать.
Всплыло что-то про CA-компанию - выкинуть её сертификат нафиг (добавить в crl).
Если что, сертификат можно вернуть.
В следующем обновлении.
В конце концов, CA-компании делают деньги из воздуха, за счет доверия к себе.
Пусть работают над этим доверием.
Пару компаний так наказать, остальные сразу возьмутся за ум.
> Это расширение не помогает в случае, когда человек заходит на сайт в
> первый раз, и уже через mitm.
> Например, недобросовестный провайдер может настроить ssl сниффер
> на какой-то банк клиент.Сейчас почти все банки используют двойную авторизацию, пароль/логин, плюс
таблица разовых ключей или сертификат, который выдают на руки, у кого-то ещё
и SMS есть.В общем из-за этой всей мудожопии, Вебмани особо не прижилось.
> В общем из-за этой всей мудожопии, Вебмани особо не прижилось.Зато qiwi очень даже прижилось. Из-за широкого распространения терминалов.
>> В общем из-за этой всей мудожопии, Вебмани особо не прижилось.
> Зато qiwi очень даже прижилось. Из-за широкого распространения терминалов.Они просто откатывают не по-детски.