Компании Mozilla и Google одновременно (https://blog.mozilla.org/security/2013/01/03/revoking-trust-.../) объявили (http://googleonlinesecurity.blogspot.ru/2013/01/enhancing-di...) о прекращении доверия двум корневым сертификатам удостоверяющего центра TurkTrust и отзыве данных сертификатов из базы, поставляемой в составе браузеров Firefox и Chrome. Причиной удаления сертификатов, являются вскрывшиеся факты использования выписанных от лица сервиса TurkTrust SSL-сертификатов для совершения MITM-атак (man-in-the-middle), направленных на транзитный перехват и расшифровку SSL-трафика на промежуточном узле.
24 декабря компанией Google был выявлен обманный сертификат, выписанный для доменов *.google.com, который был задействован для совершения атаки на пользователей сервисов Google. Не исключено, что подобные обманные сертификаты могли быть использованы для атаки на другие компании и службы. Удостоверяющий центр TurkTrust, который присутствовал в цепочке доверия у обманного сертификата, провёл внутреннее расследование, которое показало, что в августе 2011 года по ошибке двум организациям вместо обычных SSL-сертификатов были выписаны вторичные корневые сертификаты, которые можно было использовать для генерации SSL-сертификатов для любого сайта в сети, при этом подобные обманные сертификаты будут восприняты клиентским ПО, как заслуживающие доверия.
В настоящее время рассматривается вопрос о применении санкций против удостоверяющего центра TurkTrust, допустившего столь непростительную халатность в своей работе, приведшей к нарушению цепочки доверия. Напомним, что компрометация любого из существующих удостоверяющих центров может привести к возможности сгенерировать рабочий сертификат для любого сайта в сети, независимо от того каким центром сертификации выдан оригинальный SSL-сертификат. При каждом HTTPS/TLS-сеансе пользователь изначально доверяет всем имеющимся центрам сертификации, поэтому утечка корневого сертификата у одного из центров сертификации может привести к коллапсу всей системы.Средства защиты от подобных манипуляций, например методы перекрёстной сертификации, только разрабатываются.
URL: https://blog.mozilla.org/security/2013/01/03/revoking-trust-.../
Новость: http://www.opennet.me/opennews/art.shtml?num=35754
Поднимите руку, кто доверяет TurkTrust, а так же Machachkala Security Center, корневым центрам Тегерана и Кабула? :)
Клоуны в треде, скорее в машину.
Турецкие провайдеры снифят трафик юзеров ?
Я в турецком отеле хотел парнушку посмотреть по местному ви-фи. Обломись. Не дало. Написало, что контент нехороший.
Вы хотели сказать "не дала". :)
Вы таки доверяете другим удостоверяющим центрам?
> Поднимите руку, кто доверяет TurkTrustТы доверяюешь Гуглю. Гугль доверяет туркишу. Туркиш доверяет хулиганам.
Итак: ты довряешь хулиганам.Как это работает:
1) ты лезешь на сайт https://money.google.com
2) хулиган посередине подсовывает самопальный ключ туркиша
3) твой браузер спокоен, ибо цепочка доверия работает
4) твои явки и пароли уходят хулигану
5) ?????
6) PROFIT!!11
Во-первых, работает это не совсем так: твой браузер доверяет Туркишу. Туркиш доверяет хулиганам. Хулиганы генерируют собственный сертификат для *.google.com и подсовывают его в сессию. Итак: твой браузер доверяет "поддельному Гуглю", то есть, хулиганам.Во-вторых, у сертификата можно поменять степень доверия. Например, пометить в своей личной базе корневых сертификатов любой корневой сертификат как недоверенный. Или вообще его грохнуть.
Тогда это будет работать так:
1) ты лезешь на сайт https://money.google.com
2) хулиган посередине подсовывает самопальный ключ *.google.com, подписанный сертификатом, степень доверия которому ты отредактировал.
3) браузер начинает жутко орать, дескать царь ненастоящ^W^Wсертификат невалидный, так как подписан недоверенным/неизвестным CA (в зависимости от того, что именно было сделано из перечисленного выше).
4) ты начинаешь подозревать, что тебя пытаются нае^Wобмануть.
5) ??????
6) PROFIT!!11 -- но не у хулиганов. У тебя. :)Как-то так.
Это в идеале, в жизни в борьбе лень vs паранойа побеждает лень... (в большинстве случаев)
Как они собираются обновить базу ключей в моем браузере? Просто интересен механизм.
Или надо обновления фокса ждать?
Обычно оформляется как новая версия браузера и там этот серт добавлен в недоверяемые.
не далее как пару-тройку версий назад база ключей приходит молча, был же анонс
Молча для юзера, но не для митм у которого пользовательский ключ изначально в наличии) Вот вам и весь SSL
> Вот вам и весь SSLкогда ты самолично (или например твой друг/знакомый) сможешь достать/сгенерировать сертификат который будет компрометировать SSL -- вот после этого и рассказывай о том какой SSL якобы совершенно не надёжный :D ..
да, никто не спорит: все понимают что SSL (с его цепочкой доверия) не является совершенно идеальным.
но даже в такой вот реализации -- SSL это очень хорошая защита от MitM.любой даже самый квалифицированный мега-хакер -- не сможет сделать MitM над SSL, до тех пор пока не сможет раздобыть компрометирующий сертификат.
> но даже в такой вот реализации -- SSL это очень хорошая защита от MitM.Только если вы выпилите все ауторити и оставите только свою. Иначе любой козел может подписать что вон тот сервак - типа, ваш.
> любой даже самый квалифицированный мега-хакер -- не сможет сделать MitM над SSL, до тех пор пока не сможет раздобыть компрометирующий сертификат.Ну и сколько вам еще нужно новостей о выявлении таких сертификатов? И это мы в сторонке стоим, а если реально квалифицированный взломщик, который в теме, да для него это вообще не проблема. Мальчики в этих конторках что сертификаты выдают зп 15 руб имеют, не договорятся так подломят рабочее место, и т.д. и т.п. варианты, было бы достаточно времени, и оно есть.
> SSL это очень хорошая защита от MitM
Это защита от дурака со снифером, но не от профессионала
> Ну и сколько вам еще нужно новостей о выявлении таких сертификатов?сколько угодно: тушканчики всё равно уверены в том, что неоднократно скомпрометированая система безопасности по-прежнему безопасна.
> когда ты самолично (или например твой друг/знакомый) сможешь достать/сгенерировать сертификат
> который будет компрометировать SSL -- вот после этого и рассказывай о
> том какой SSL якобы совершенно не надёжный :D ..я тебе уже много раз говорил, попробуй хоть в этот раз понять: однажды скомпрометированая система безопасности больше никогда не будет являться надёжной. ssl скомпрометирован намного больше, чем один раз.
> SSL это очень хорошая защита от MitM
trustwave с тобой согласны.
Mozilla is actively revoking trust for the two mis-issued certificates which will be released to all supported versions of Firefox in the next update on Tuesday 8th January.
В Firefox база сертификатов находится в библиотеке NSS. Разумеется она будет изменена с обновлением Firefox.
тихо она даже отдельно обновляется.
Да. Там, где собрана отдельно, но на некоторых платформах её носят с собой :)
% pkg_info nss-3.14
Information for nss-3.14:Comment:
Libraries to support development of security-enabled applications
Required by:
chromium-23.0.1271.97
eclipse-3.7.1_3
eclipse-emf-2.7.2
firefox-17.0.1,1
firefox-i18n-17.0.1
gnash-0.8.10_3
icedtea-web-1.3.1
libxul-10.0.11
thunderbird-17.0
thunderbird-i18n-17.0
Description:
Network Security Services (NSS) is a set of libraries designed to support
cross-platform development of security-enabled server applications.
Applications built with NSS can support SSL v2 and v3, TLS, PKCS #5, PKCS #7,
PKCS #11, PKCS #12, S/MIME, X.509 v3 certificates, and other security
standards.WWW: http://www.mozilla.org/projects/security/pki/nss/
> Required by:
> firefox-i18n-17.0.1
> thunderbird-i18n-17.0Я не знаю что у вас за дистр, но либо в нём не очевидные названия пакетов, либо лишние зависимости у пакетов :)
>> Required by:
>> firefox-i18n-17.0.1
>> thunderbird-i18n-17.0
> Я не знаю что у вас за дистр,FreeBSD
> но либо в нём не очевидные названия пакетов, либо лишние зависимости у пакетов :)
pkg_info перечислила все узлы в ветвях зависимостей (список пакетов) от одного узла (пакета nss).
> FreeBSDЯ только одно не понял: что твой долбаный листинг должен доказывать? По нему не видно заблочен ли конкретный сертификат. Прикинь?
Этот листинг показывает, что базой из библитеки мозиллы пользуются не только браузеры. В fedora этот показатель еще больше.
p.s. ваш комментарий груб и неинформативен.
ты прикинь братан - там думать надо, а тебе хотелось только на кнопки жать ?
> ты прикинь братан - там думать надо, а тебе хотелось только на кнопки жать ?Вот я и интересуюсь: какой глобальный вывод сделал мыслитель? То что либой оказывается пользуется куча программ? Вай, спасибо, без изена мы этого не знали. Он что, пытается титул Кэпа отбить? :)
>> FreeBSD
> Я только одно не понял: что твой долбаный листинг должен доказывать?Что база данных о сертификатах находится не в браузерах, а в отдельном пакете — nss-3.14. Пока он не обновится, все зависящие от него приложения будут использовать устаревший список сертификатов для аутентификации.
> По нему не видно заблочен ли конкретный сертификат. Прикинь?
Заблочен ли конкретный сертификат можно посмотреть в Firefox, открыв "Настройки"->"Дополнительно"->"Шифрование"->"Просмотр сертификатов".
Также рекомендуется включить в "Настройках OCSP" "проверять статус сертификата, если в нём указан адрес сервера OCSP", и "при ошибке соединения с сервером OCSP рассматривать сертификат как недействительный".
да-да, вот и интересно что понадобилось пакетам вида *i18n с переводами вида
/usr/share/locale/ru/LC_MESSAGES/*mo от базы сертификатов.
Интересно, почему сразу же автоматом не убрали TÜRKTRUST из списка корневых, а возились с отзывом сертификатов?IMHO другого метода держать остальных в узде не существует. Только если будут знать, что один прокол - и всё, лавочку закрывают навсегда.
> IMHO другого метода держать остальных в узде не существует. Только если будут
> знать, что один прокол — и всё, лавочку закрывают навсегда.и этот метод тоже не сработает. потому что централизованая система обречена на фэйл by design.
Конечно-же это была ошибка, и может быть, даже, бес попутал.Вся эта система с SSL сертификатами настолько ненадёжная, что доверять ей, конечно, может только субъект неразбирающийся ни на йоту в деталях и принцыпах работы оной. Как ей можно доверять, когда сертификаты могут выдавать такие компании как verisign, аоl time warner Inc. и упомянутая в новости. И самое главное: ведь всем плевать.
> Конечно-же это была ошибка, и может быть, даже, бес попутал.Ну да, и вовсе то они и не пытались срубить бабла на доверии. Как вы могли такое подумать?!
>> Конечно-же это была ошибка, и может быть, даже, бес попутал.
> Ну да, и вовсе то они и не пытались срубить бабла на
> доверии. Как вы могли такое подумать?!А на чем они пытались срубить бабла? На заявлении в CPS - "Мамой клянемся, все будет хорошо"?
Брюс английским по белому предупреждал, что эта концепция доверия НЕХ не стоит выеденного яйца. У него что, неясно написано? Доверять можно тому, кого ты ЛИЧНО знаешь. И то не всякому. И ВСЕ.
А концепция деревьев доверия порочна по своей сути. Достаточно быть скомпрометированному ОДНОМУ из узловых CA/RA - и песец, коллапс всего дерева доверия. Что непонятного?
Единственное в чем польза ssl - это шифрование. "Доверие" вообще яйца выеденного не стоит. Делают деньги из воздуха.
Объясню, почему вас минусуют и раскрою вашу некомпетентность в данном вопросе. Шифрование это хорошо: соединяется узел А с узлом Б и шифруют передаваемые данные - видимо, такого ваше представление об SSL.
В действительности, все несколько иначе. Предположим, вам необходимо соединиться с account.google.com. Местный DNS-резолвер вам возвращает ip-адрес хоста и вы соединяетесь с ним. Хост отправляет вам свой публичный ключ и вы, шифруя этим ключом, отправляете свои данные на сервер. Бесспорно, расшифровать ваши данные сможет только сервер, выдавший вам публичный ключ.Но что если этот сервер не настоящий account.google.com? Что если ваш провайдер резолвит данное доменное имя гугла на фсб-ную тачку? В этом и заключается вся соль SSL - подписывание ключей сторонней независимой организацией, иными словами доказательство, что данный ключ действительно гугловский, а не чей-либо.
Сам факт шифрования канала это еще пол дела, главная задача: гарантировать, что связь происходит именно с оригинальным сервисом.
_______
Уповать на защиту SSL бессмысленно: в большинстве случаев, все ваши данные все равно расшифрованы, т.к. в датацентрах находится специальное оборудование для снифинга не только внешнего трафика, но и внутреннего, который не зашифрован.
> в датацентрах находится специальное оборудование для снифинга не только внешнего трафика, но и внутреннего, который не зашифрованДелись.
Читать до посинения: http://ru.wikipedia.org/wiki/SSL
Спасибо за разъяснения. Прочитал Ваш комментарий с интересом.А если у меня свой днс (например прописаны жестко 8.8.8.8)? По идее это должно снизить вероятность атаки.
Кроме SSL пока ничего более надежного для браузеров не наблюдается. Исключая различные альтернативы: свой аля впн-сервер или туннель или какой-то апплет на джаве.
Вопрос: Как по Вашему мнению можно улучшить надежность SSL в контексте mitm-атак (включая случаи подмен со стороны провайдеров и не исключая фактор ненадежности удо-центров)?
Можно рассмотреть для начала крайности: идеальная схема и реально осуществимая в настоящее время подручными средствами.
Вспомнилось: вроде идея подтверждения достоверности сертификата как раз вытекает из голосования несколькими удо-центрами независимыми друг от друга. Чем их больше - тем выше вероятность "правильного подтверждения".
>А если у меня свой днс (например прописаны жестко 8.8.8.8)?И кто помешает провайдеру перенаправлять пакеты куда нужно? Ещё проще попросить держателя корневого сертификата выдать им на Х дней сертификат. Шах и мат.
>>А если у меня свой днс (например прописаны жестко 8.8.8.8)?
> И кто помешает провайдеру перенаправлять пакеты куда нужно? Ещё проще попросить держателя
> корневого сертификата выдать им на Х дней сертификат. Шах и мат.Можно как-то противостоять перенаправлению пакетов в этом случае?
Но вообще печалька конечно. Остается только поднимать свой туннель, но и там возможно от другого провайдера перенаправление. В общем нужно для безопасного общения два своих сервера с туннелями, представляющие собой одновременно и клиент и сервер.
> Можно как-то противостоять перенаправлению пакетов в этом случае?Туннель до своего серванта. Хоть тот же опенвпн, где из доверяемых ауторити оставлена только лично ваша. В таком варианте подделать пакеты будет проблематично. Но это ж надо понимать как все это работает. А типовой хомячок - ну вы поняли.
>> Можно как-то противостоять перенаправлению пакетов в этом случае?
> Туннель до своего серванта. Хоть тот же опенвпн, где из доверяемых ауторити
> оставлена только лично ваша. В таком варианте подделать пакеты будет проблематично.
> Но это ж надо понимать как все это работает. А типовой
> хомячок - ну вы поняли.при проведении разъяснительной работы и хомячок заинтересуется - но вряд ли сможет что-либо сделать. Без соответствующих знаний и дополнительных усилий заведомо жертва - вы абсолютно правы
> А если у меня свой днс (например прописаны жестко 8.8.8.8)?Есть такая штука - "прозрачный прокси". Ну или попросту говоря, технически тот кто передает ваши пакеты может их пропатчить в обе стороны. Он вам может и соврать насчет ответа днс, отредиректить пакеты независимо от того что вам сообщил DNS и прочая. Собственно, SSL/TLS пытаелся бороться в том числе и с этим. Но из-за того что trusted authority легион и любая из них может выписать кому угодно серт на что угодно, хоть на тот же гугл.ком - достаточно одному из списка пролошиться или оказаться не совсем честным и вся схема разваливается. В отдельных применениях типа openvpn это лечится - указанием единственной доверяемой ауторити, вашей. На которую у недругов нет ключа, а остальные - попросту никто и не могут заверить что либо :). Но вот в вебе - оно так не лечится, увы.
>[оверквотинг удален]
> вам может и соврать насчет ответа днс, отредиректить пакеты независимо от
> того что вам сообщил DNS и прочая. Собственно, SSL/TLS пытаелся бороться
> в том числе и с этим. Но из-за того что trusted
> authority легион и любая из них может выписать кому угодно серт
> на что угодно, хоть на тот же гугл.ком - достаточно одному
> из списка пролошиться или оказаться не совсем честным и вся схема
> разваливается. В отдельных применениях типа openvpn это лечится - указанием единственной
> доверяемой ауторити, вашей. На которую у недругов нет ключа, а остальные
> - попросту никто и не могут заверить что либо :). Но
> вот в вебе - оно так не лечится, увы.где-то видел статью - разъясняющую как легко обнаружить подмену пакетов и как этому противостоять. Вывод один будущее безопасной сети за персональными серверами. Сейчас народ дурят облаками. Но это легкая нажива. Только свои машинки - не являюсь большим поклонником облаков, но думаю что для защищенности там придется изрядно повозиться. Надо чтобы сервера стали дешевыми как пока еще спички и маленькими таких же размеров а интернет стал бесплатен и РМС высылал как диски с убунтой флэшки с токенами ))
И все-же что простым пользователям и разработчикам прикладного софта и админам делать с этим безобразием в SSL. Ведь раньше эти случаи были редки. Надо что-то предпринимать или хотя бы пересмотреть традиционные подходы.
Спасибо за развернутый ответ.
Может SSL тут не причем в общем. Кроме подделки сертификатов как выясняется слабое звено в первичных не-секурных запросах. Вобщем туннелирование днс запросов через свою доверенную сеть рулит. Может кроме туннелей есть секурный днс?
> Вопрос: Как по Вашему мнению можно улучшить надежность SSLвыкинуть его нафиг. оно починке не поддаётся в принципе: как «запорожец» не тюнь, а «lamborgini» всё равно не получится.
>> Вопрос: Как по Вашему мнению можно улучшить надежность SSL
> выкинуть его нафиг. оно починке не поддаётся в принципе: как «запорожец» не
> тюнь, а «lamborgini» всё равно не получится.Простите, а Вы как на гмейл и им подобные ходите и проверяете свои акаунты в онлайне и почту? Только откровенно: вы любите сайты почту, в которых авторизация идет без SSL, а пароли не солятся быстрорастворимой солью? Или может быть это просто старая теплая ненависть к SSL?
<--...-->
выкинуть всегда успеется, если есть достойная замена. Для меня весь драмматизм с SSL в том, что ему альтернативы нет на фоне браузерных технологий (и не только: все ведь крутится вокруг библиотеки openssl... не так-ли? (хотя эта либа особо тут не причем и не решает "социально-инженерных" проблем) ). Именно это напрягает. Неужели так сложны применяемые технологии? Хотя по-ходу данный монополизм выгоден (вопрос кому) и что подтверждает на практике мы имеем дело с выделяющимися крайностями. С одной стороны монополизм (возможно ошибаюсь но что-то не попадалось альтернатив), с другой жесткая конкуренция и фрагментация + мутная водчика. Хотя man openssl отвечает практически на все вопросы.
> Простите, а Вы как на гмейл и им подобные ходите и проверяете
> свои акаунты в онлайне и почту?никак: зачем мне эти зонды? у меня свой сервер, с пингвинами и поэзией. о какой вообще безопасности может идти речь, когда *личная* информация хранится незнамо у кого?
ах, да: *свой* сервер. вот он, железный, рядом со мной, можно пощупать. а не загадочное нечто в далёком датацентре.
впрочем, если СИЛЬНО хочется обмениваться информацией через гугель, то шифрование никто ещё не отменял. а уж как обменяться ключами — это другой вопрос.
> выкинуть всегда успеется, если есть достойная замена.
которая не появится, пока «да ладно, оно же даёт иллюзию безопасности. значит — работает. да и бизнес на сертификатах тоже вкусный.»
>> Единственное в чем польза ssl - это шифрование. "Доверие" вообще яйца выеденного не стоит.
> Объясню, почему вас минусуют и раскрою вашу некомпетентность в данном вопросе.Я так и не понял в каком месте там была некомпетентность. Шифрование в ssl работает, просто взять и расшифровать пакет нельзя. Гарантии сторонних организаций - фейл, они с тем же успехом, что и провайдер, могут отдать ключь фсб.
>>> Единственное в чем польза ssl - это шифрование. "Доверие" вообще яйца выеденного не стоит.
>> Объясню, почему вас минусуют и раскрою вашу некомпетентность в данном вопросе.
> Я так и не понял в каком месте там была некомпетентность. Шифрование
> в ssl работает, просто взять и расшифровать пакет нельзя. Гарантии сторонних
> организаций - фейл, они с тем же успехом, что и провайдер,
> могут отдать ключь фсб.В слове "ключь". Правильно "ключъ". В остальном всё верно, ваш оппонент бредит.
> Я так и не понял в каком месте там была некомпетентность. Шифрование
> в ssl работает, просто взять и расшифровать пакет нельзя. Гарантии сторонних
> организаций - фейл, они с тем же успехом, что и провайдер,
> могут отдать ключь фсб.Сорри, я так и думал, что неправильно понял вас изначально. Речь шла именно об этом фейковым доверии, который я счел непониманием простых принципов SSL.
> в датацентрах находится специальное оборудование для снифинга не только внешнего трафика, но и внутреннего, который не зашифрован.и как же они этот внутренний трафик получают? неужто это оборудование расшифровывает SSL? а откуда взялся private-ключ у этого оборудования?
Никто ничего не расшифровывает. Впереди стоит балансировщик. Обычно он же SSL-фронтенд. Траф от фронтенда до бэкендов идет не зашифрованным (внутренний трафик датацентра). Оборудование типа Carnivore/СОРМ-2 слушает оба трафика: и внешний, и внутренний.
SSL это протокол, а не шифр или система шифрования. Синхронизация ключей шифрования происходит благодаря системе открытого ключа шифрования. Сертификат применяется для аутентификации и обмена ключами.
Сертификат как раз и говорит, что я "тот кто я есть" и вот тебе мой открытый ключ, который ты можешь использовать для синхронизации со мной ключа шифрованния данных, а у меня есть закрытый ключ, которым я расшифрую этот трафик, но я его не скажу. Потом ты отправляешь зашифрованный открытым ключем - ключ шифрования (к примеру ключ блочного алгоритма шифрования - aes). Сервак его получил и расшифровал закрытым ключем. Дальше ты шифруешь отправляемые данные ключем шифрования блочного (или потокового) шифра свои персональные данные и пересылаешь по "открытому" каналу. Сервак уже может расшифровать данные ключем блочного (или потокового) шифра - ибо ты его передал с помощью открытого ключа. Блочный или потоковый шифр используется, т.к. для системы открытого ключа требуется существенно больше вычислительных мощностей, при достижении такой же надежности, как у блочного или потокового алгоритма шифрования.Понятно от куда у сервера расшифрованные данные? Иначе не обработать данные не расшифровав их. Данные в основном в сетях должны шифроваться только для защиты их от извлечения по "открытому" каналу связи и в местах длительного хранения (ПЗУ).
А теперь, кто осилил то, что я написал, то что будет, если кто-то получит фиктивный сертификат с открытым ключем?
"датацентрах находится специальное оборудование для снифинга" -- вот как ИМЕННО ЭТО ОБОРУДОВАНИЕ подучает доступ к зашифрованному трафику?а про сервера объснять не надо
> А теперь, кто осилил то, что я написал, то что будет, если кто-то получит фиктивный сертификат с открытым ключем?
если я хозяин сервера и решил подключитсья к своему серверу из дома -- то для меня не составит проблемы посмотреть на отпечаток ключа (совпадёт ли он или нет?). таким образом хозяин сервера может ОДНОЗНАЧНО определить была ли подстановка или не было. [в случае если в датацентре стоит "специальное оборудование для снифинга SSL"].
сразу вопрос: каким образом можно сделать MitM над SSL и при этом НЕ поменять отпечаток ключа? ни каким? значит невозможно сделать MitM над SSL совершенно незаметным. хозяен сервера узнает об MitM и сразуже разгорится скандал => очередной доверенный центр SSL пойдёт в вечный бан от Mozilla и Chromium.
> "датацентрах находится специальное оборудование для снифинга" -- вот как ИМЕННО ЭТО ОБОРУДОВАНИЕ
> подучает доступ к зашифрованному трафику?
> а про сервера объснять не надоэто оборудование стоит уже за сервером, который расшифровывает трафик. Далее трафик, уже будучи расшифрованным, заворачивается в маршрут для прослушки спец оборудованием (незачем ему шифрованный трафик).
> если я хозяин сервера и решил подключитсья к своему серверу из дома
> -- то для меня не составит проблемы посмотреть на отпечаток ключа
> (совпадёт ли он или нет?). таким образом хозяин сервера может ОДНОЗНАЧНО
> определить была ли подстановка или не было. [в случае если в
> датацентре стоит "специальное оборудование для снифинга SSL"].
> сразу вопрос: каким образом можно сделать MitM над SSL и при этом
> НЕ поменять отпечаток ключа? ни каким? значит невозможно сделать MitM над
> SSL совершенно незаметным. хозяен сервера узнает об MitM и сразуже разгорится
> скандал => очередной доверенный центр SSL пойдёт в вечный бан от
> Mozilla и Chromium.Часто вы смотрите на отпечаток?
А если серверов сотня, для балансировки нагрузки, вы ведете учет по каждому из них?
А если закончился срок сертификата, то все, подмена? Ведь злоумышленнику тоже ничего не мешает, применить свой фиктивный сертификат в день замены сертификата, и какой из 2х будут действительный - вы знать не будете.
> В действительности, все несколько иначе. Предположим, вам необходимо соединиться с account.google.com.
> Местный DNS-резолвер вам возвращает ip-адрес хоста и вы соединяетесь с ним.Перенаправив клиента на левый хост, вы не сможете подделать сертификат, который выписан на _домен_. В ответ на левый незаверенный сертификат, который вы попытайтесь вручить клиенту, его браузер начнёт кричать что хост не тот за кого себя выдаёт. Не зная закрытого ключа невозможно создать поддельный SSL-канал к клиенту с промежуточного хоста, вы можете тольно попытаться впарить самоподписанный сертификат.
> В ответ на левый незаверенный сертификат, который вы попытайтесь
> вручить клиенту, его браузер начнёт кричать что хост не тот за
> кого себя выдаёт.после чего юзер бездумно тыкнет в кнопку «принять и заткнуться», матеря про себя тупоголовых создателей софта, которые только и умеют, что доставлять проблемы.
>> В действительности, все несколько иначе. Предположим, вам необходимо соединиться с account.google.com.
>> Местный DNS-резолвер вам возвращает ip-адрес хоста и вы соединяетесь с ним.
> Перенаправив клиента на левый хост, вы не сможете подделать сертификат, который выписан
> на _домен_. В ответ на левый незаверенный сертификат, который вы попытайтесь
> вручить клиенту, его браузер начнёт кричать что хост не тот за
> кого себя выдаёт. Не зная закрытого ключа невозможно создать поддельный SSL-канал
> к клиенту с промежуточного хоста, вы можете тольно попытаться впарить самоподписанный
> сертификат.Это действительно так, только например гугл часто отдает разные сертификаты и очень сложно понять валидный он или нет, на фоне постоянных усовершенствований со стороны разработчиков браузеров. То зеленый то серый (например в лисе) - обращаю на это периодически внимание но дальше изучения подписей дело не заходит. Потом сам гугл не очень внушает доверия после запросов whois google.com
============
Server Name: GOOGLE.COM.ZZZZZZZZZZZZZZZZZZZZZZZZZZZ.LOVE.AND.TOLERANCE.THE-WONDERBOLTS.COM
IP Address: 50.62.130.9
Registrar: GODADDY.COM, LLC
Whois Server: whois.godaddy.com
Referral URL: http://registrar.godaddy.comServer Name: GOOGLE.COM.ZZZZZZZZZZZZZZZZZZZZZZZZZZ.HAVENDATA.COM
IP Address: 50.23.75.44
Registrar: PDR LTD. D/B/A PUBLICDOMAINREGISTRY.COM
Whois Server: whois.PublicDomainRegistry.com
Referral URL: http://www.PublicDomainRegistry.comServer Name: GOOGLE.COM.ZZZZZZZZZZZZZ.GET.ONE.MILLION.DOLLARS.AT.WWW.UNIMUNDI.COM
IP Address: 209.126.190.70
Registrar: PDR LTD. D/B/A PUBLICDOMAINREGISTRY.COM
Whois Server: whois.PublicDomainRegistry.com
Referral URL: http://www.PublicDomainRegistry.comServer Name: GOOGLE.COM.ZZZZZ.GET.LAID.AT.WWW.SWINGINGCOMMUNITY.COM
IP Address: 69.41.185.195
Registrar: TUCOWS.COM CO.
Whois Server: whois.tucows.com
Referral URL: http://domainhelp.opensrs.netServer Name: GOOGLE.COM.ZOMBIED.AND.HACKED.BY.WWW.WEB-HACK.COM
IP Address: 217.107.217.167
Registrar: DOMAINCONTEXT, INC.
Whois Server: whois.domaincontext.com
Referral URL: http://www.domaincontext.comServer Name: GOOGLE.COM.ZNAET.PRODOMEN.COM
IP Address: 62.149.23.126
Registrar: PDR LTD. D/B/A PUBLICDOMAINREGISTRY.COM
Whois Server: whois.PublicDomainRegistry.com
Referral URL: http://www.PublicDomainRegistry.comServer Name: GOOGLE.COM.Z.LOVE.AND.TOLERANCE.THE-WONDERBOLTS.COM
IP Address: 50.62.130.9
Registrar: GODADDY.COM, LLC
Whois Server: whois.godaddy.com
Referral URL: http://registrar.godaddy.comServer Name: GOOGLE.COM.YUCEKIRBAC.COM
IP Address: 88.246.115.134
Registrar: PDR LTD. D/B/A PUBLICDOMAINREGISTRY.COM
Whois Server: whois.PublicDomainRegistry.com
Referral URL: http://www.PublicDomainRegistry.comServer Name: GOOGLE.COM.YUCEHOCA.COM
IP Address: 88.246.115.134
Registrar: PDR LTD. D/B/A PUBLICDOMAINREGISTRY.COM
Whois Server: whois.PublicDomainRegistry.com
Referral URL: http://www.PublicDomainRegistry.comServer Name: GOOGLE.COM.WORDT.DOOR.VEEL.WHTERS.GEBRUIKT.SERVERTJE.NET
IP Address: 62.41.27.144
Registrar: KEY-SYSTEMS GMBH
Whois Server: whois.rrpproxy.net
Referral URL: http://www.key-systems.net============
Да и вообще гугл стал все редиректить на домен google.ru а его сертификат "серый" :(
только у мзиллы нормуль цвет
>...в датацентрах находится специальное оборудование для снифинга не только внешнего трафика, но и внутреннего, который не зашифрован.Да. Если уж кто-то читает секретные донесения вслух, а у вас есть возможность поставить рядом микрофон, то нет никакого смысла заморачиваться с перехватами, расшифровками и т. п.
Объясню почему вас минусуют - 99.99% сайтов в интернете с SSL. Никакого доверия к ним нет. То что им выдали сертификат с закрытыми глазами - тоже абсолютно ничего не значит, т.к. они сами по себе могут быть man-in-the-middle. Например, изменить 1 букву в имени домена и выписать себе сертификат. Все. А у пользователя возникнет ложное чувство доверенности из-за зеленого замка.
> в августе 2011 года по ошибке двум организациям вместо обычных SSL-сертификатов были выписаны вторичные корневые сертификатыСколько? Удивительно, что в такой новости нет ни одного символа $, только бред про "по ошибке". Еще интересно, сам владелец бизнеса был в курсе, когда совершал такую "ошибку", которая уничтожит бизнес (вход в который стоит не дешево, а прибыль дает не сильно большую) или это кто-то из наемников за спиной работодателя так "ошибся"?
> Сколько? Удивительно, что в такой новости нет ни одного символа $, только
> бред про "по ошибке".Более-менее понятно, что эти сертификаты были тихо выданы под системы выявления утечек данных или для местных спецслужб. Ни они первые, Trustwave CA за руку в прошлом году на этом поймали (http://www.opennet.me/opennews/art.shtml?num=33034).
diginotar2 aka turktrust - "давай, до свиданья" :-)
ИМХО: Доверие не должно происходить автоматически, а до тех пор пока это так — будут такие инциденты. Я не призываю отказываться от этой системы и проверять лично каждый сертификат сайта, просто надо быть готовым …Кстати, гугл могли бы присылать для аутентификации по SMS хеш своего публичного ключа (fingerprint или как там его), что-бы убедится что нету "посредника" ?
> ИМХО: Доверие не должно происходить автоматически, а до тех пор пока это
> так — будут такие инциденты. Я не призываю отказываться от этой
> системы и проверять лично каждый сертификат сайта, просто надо быть готовым
> …Готовым к чему? Конкретно можно?
> Кстати, гугл могли бы присылать для аутентификации по SMS хеш своего публичного
> ключа (fingerprint или как там его), что-бы убедится что нету "посредника"
> ?Чушь собачья. Костыль костылей. Рекомендую вначале почитать-таки Брюса - он как-никак ведущий криптограф а не хрен собачий с опеннета. И знает толк в криптографии.
> Рекомендую вначале почитать-таки Брюса - он как-никак ведущий
> криптограф а не хрен собачий с опеннета. И знает толк в
> криптографии.и какое у него решение текущей проблемы для сертификатов?
1 послать всех на
2 покупать сертификаты у него, ему доверять можноКриптографов в мире хватает, да и не нужно им быть чтобы придумать ИДЕЮ. хотели по простому - всё испортил человеческий фактор. Теперь будет по-сложному.
> 1 послать всех на
> 2 покупать сертификаты у него, ему доверять можно
> Криптографов в мире хватает, да и не нужно им быть чтобы придумать
> ИДЕЮ. хотели по простому - всё испортил человеческий фактор. Теперь будет
> по-сложному.Рабинович, не надо перепевать Карузо. Ты тоже не читал Шнайера.
Тащемта - да, додуматься до идеи нетрудно. Но статью Брюса-таки прочти. Все же не ты ее написал, а он - и когда написал! На дату посмотри!
> всё испортил человеческий фактор.не испортил, а показал несостоятельность. доверие, оберегаемое угрозой санкций, цена репутации - цена услуг пласт. хирурга плюс новая история жизни, подтвержденная документарно. а то мало-ли что по защищенному SSL передадут, человека там транспондируют по частям, или, боже мой, зачатие по электронной почте (понятие доверия ведь перенесли в Сеть из жизни).
>> Рекомендую вначале почитать-таки Брюса - он как-никак ведущий
>> криптограф а не хрен собачий с опеннета. И знает толк в
>> криптографии.
> и какое у него решение текущей проблемы для сертификатов?И не только текущей. Пойди на его сайт и почитай. Может, просветление наступит.
SSL — это надёжно!
> SSL — это надёжно!(лениво) Толсто же, Арису. Толстенный наброс, аж жыр из монитора потек.
SSK + TLS v1.2 + DNSSEC
> SSK + TLS v1.2 + DNSSECлучше, чем «голый» ssl, но не намного. к тому же — подписывать весь сайт? если он, например, динамически генерируется? не лучший вариант.
остаётся, опять же, вопрос доверия ключу. решаемый, но тем не менее.
p.s. ах, да. DNS. с ключевым словом «централизация».
MITM-атаки. Охохо, MIT - это турецкая гэбня.
Порт библиотеки nss на FreeBSD обновили: http://www.freshports.org/security/nss/