| 1.1, pavlinux (ok), 00:47, 04/01/2013 [ответить] [﹢﹢﹢] [ · · · ]
| –4 +/– |
 Поднимите руку, кто доверяет TurkTrust, а так же Machachkala Security Center, корневым центрам Тегерана и Кабула? :)
| | |
| |
| |
| 3.24, ъ (?), 10:15, 04/01/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
Я в турецком отеле хотел парнушку посмотреть по местному ви-фи. Обломись. Не дало. Написало, что контент нехороший.
| | |
|
| 2.59, robux (ok), 00:03, 05/01/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > Поднимите руку, кто доверяет TurkTrust
Ты доверяюешь Гуглю. Гугль доверяет туркишу. Туркиш доверяет хулиганам.
Итак: ты довряешь хулиганам.
Как это работает:
1) ты лезешь на сайт https://money.google.com
2) хулиган посередине подсовывает самопальный ключ туркиша
3) твой браузер спокоен, ибо цепочка доверия работает
4) твои явки и пароли уходят хулигану
5) ?????
6) PROFIT!!11
| | |
| |
| |
| 4.81, ЬТЛ (?), 12:04, 09/01/2013 [^] [^^] [^^^] [ответить]
| +/– |
Это в идеале, в жизни в борьбе лень vs паранойа побеждает лень... (в большинстве случаев)
| | |
|
|
|
| 1.2, Anonim (??), 00:57, 04/01/2013 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Как они собираются обновить базу ключей в моем браузере? Просто интересен механизм.
Или надо обновления фокса ждать?
| | |
| |
| 2.3, Аноним (-), 01:07, 04/01/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
Обычно оформляется как новая версия браузера и там этот серт добавлен в недоверяемые.
| | |
| |
| 3.14, Аноним (-), 03:02, 04/01/2013 [^] [^^] [^^^] [ответить]
| +/– |
не далее как пару-тройку версий назад база ключей приходит молча, был же анонс
| | |
| |
| 4.15, Аноним (-), 03:19, 04/01/2013 [^] [^^] [^^^] [ответить]
| +/– |
Молча для юзера, но не для митм у которого пользовательский ключ изначально в наличии) Вот вам и весь SSL
| | |
| |
| 5.46, Xasd (ok), 19:34, 04/01/2013 [^] [^^] [^^^] [ответить]
| +/– |
 > Вот вам и весь SSL
когда ты самолично (или например твой друг/знакомый) сможешь достать/сгенерировать сертификат который будет компрометировать SSL -- вот после этого и рассказывай о том какой SSL якобы совершенно не надёжный :D ..
да, никто не спорит: все понимают что SSL (с его цепочкой доверия) не является совершенно идеальным.
но даже в такой вот реализации -- SSL это очень хорошая защита от MitM.
любой даже самый квалифицированный мега-хакер -- не сможет сделать MitM над SSL, до тех пор пока не сможет раздобыть компрометирующий сертификат.
| | |
| |
| 6.54, Аноним (-), 22:19, 04/01/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> но даже в такой вот реализации -- SSL это очень хорошая защита от MitM.
Только если вы выпилите все ауторити и оставите только свою. Иначе любой козел может подписать что вон тот сервак - типа, ваш.
| | |
| 6.61, Аноним (-), 01:44, 05/01/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> любой даже самый квалифицированный мега-хакер -- не сможет сделать MitM над SSL, до тех пор пока не сможет раздобыть компрометирующий сертификат.
Ну и сколько вам еще нужно новостей о выявлении таких сертификатов? И это мы в сторонке стоим, а если реально квалифицированный взломщик, который в теме, да для него это вообще не проблема. Мальчики в этих конторках что сертификаты выдают зп 15 руб имеют, не договорятся так подломят рабочее место, и т.д. и т.п. варианты, было бы достаточно времени, и оно есть.
> SSL это очень хорошая защита от MitM
Это защита от дурака со снифером, но не от профессионала
| | |
| |
| 7.63, arisu (ok), 01:56, 05/01/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > Ну и сколько вам еще нужно новостей о выявлении таких сертификатов?
сколько угодно: тушканчики всё равно уверены в том, что неоднократно скомпрометированая система безопасности по-прежнему безопасна.
| | |
|
| 6.62, arisu (ok), 01:54, 05/01/2013 [^] [^^] [^^^] [ответить]
| +/– |
> когда ты самолично (или например твой друг/знакомый) сможешь достать/сгенерировать сертификат
> который будет компрометировать SSL -- вот после этого и рассказывай о
> том какой SSL якобы совершенно не надёжный :D ..
я тебе уже много раз говорил, попробуй хоть в этот раз понять: однажды скомпрометированая система безопасности больше никогда не будет являться надёжной. ssl скомпрометирован намного больше, чем один раз.
> SSL это очень хорошая защита от MitM
trustwave с тобой согласны.
| | |
|
|
|
|
| 2.4, wesnoth (?), 01:07, 04/01/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
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.
| | |
| 2.5, user (??), 01:08, 04/01/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
В Firefox база сертификатов находится в библиотеке NSS. Разумеется она будет изменена с обновлением Firefox.
| | |
| |
| |
| 4.9, user (??), 01:26, 04/01/2013 [^] [^^] [^^^] [ответить]
| +/– |
Да. Там, где собрана отдельно, но на некоторых платформах её носят с собой :)
| | |
|
|
| 2.7, iZEN (ok), 01:14, 04/01/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
 % 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/
| | |
| |
| 3.11, user (??), 01:37, 04/01/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Required by:
> firefox-i18n-17.0.1
> thunderbird-i18n-17.0
Я не знаю что у вас за дистр, но либо в нём не очевидные названия пакетов, либо лишние зависимости у пакетов :)
| | |
| |
| 4.12, iZEN (ok), 01:49, 04/01/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
>> Required by:
>> firefox-i18n-17.0.1
>> thunderbird-i18n-17.0
> Я не знаю что у вас за дистр,
FreeBSD
> но либо в нём не очевидные названия пакетов, либо лишние зависимости у пакетов :)
pkg_info перечислила все узлы в ветвях зависимостей (список пакетов) от одного узла (пакета nss).
| | |
| |
| 5.20, Аноним (-), 06:42, 04/01/2013 [^] [^^] [^^^] [ответить]
| –7 +/– | |
> FreeBSD
Я только одно не понял: что твой долбаный листинг должен доказывать? По нему не видно заблочен ли конкретный сертификат. Прикинь?
| | |
| |
| 6.36, user (??), 15:40, 04/01/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
Этот листинг показывает, что базой из библитеки мозиллы пользуются не только браузеры. В fedora этот показатель еще больше.
p.s. ваш комментарий груб и неинформативен.
| | |
| |
| 7.55, Аноним (-), 22:37, 04/01/2013 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> ты прикинь братан - там думать надо, а тебе хотелось только на кнопки жать ?
Вот я и интересуюсь: какой глобальный вывод сделал мыслитель? То что либой оказывается пользуется куча программ? Вай, спасибо, без изена мы этого не знали. Он что, пытается титул Кэпа отбить? :)
| | |
|
| 6.42, iZEN (ok), 17:23, 04/01/2013 [^] [^^] [^^^] [ответить]
| +/– |
>> FreeBSD
> Я только одно не понял: что твой долбаный листинг должен доказывать?
Что база данных о сертификатах находится не в браузерах, а в отдельном пакете — nss-3.14. Пока он не обновится, все зависящие от него приложения будут использовать устаревший список сертификатов для аутентификации.
> По нему не видно заблочен ли конкретный сертификат. Прикинь?
Заблочен ли конкретный сертификат можно посмотреть в Firefox, открыв "Настройки"->"Дополнительно"->"Шифрование"->"Просмотр сертификатов".
Также рекомендуется включить в "Настройках OCSP" "проверять статус сертификата, если в нём указан адрес сервера OCSP", и "при ошибке соединения с сервером OCSP рассматривать сертификат как недействительный".
| | |
|
| 5.48, ананим (?), 20:31, 04/01/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
да-да, вот и интересно что понадобилось пакетам вида *i18n с переводами вида
/usr/share/locale/ru/LC_MESSAGES/*mo от базы сертификатов.
| | |
|
|
|
|
| 1.10, Аноним (-), 01:32, 04/01/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– | |
Интересно, почему сразу же автоматом не убрали TÜRKTRUST из списка корневых, а возились с отзывом сертификатов?
IMHO другого метода держать остальных в узде не существует. Только если будут знать, что один прокол - и всё, лавочку закрывают навсегда.
| | |
| |
| 2.64, arisu (ok), 01:58, 05/01/2013 [^] [^^] [^^^] [ответить]
| +/– |
> IMHO другого метода держать остальных в узде не существует. Только если будут
> знать, что один прокол — и всё, лавочку закрывают навсегда.
и этот метод тоже не сработает. потому что централизованая система обречена на фэйл by design.
| | |
|
| 1.16, дон педро (?), 05:12, 04/01/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– | |
Конечно-же это была ошибка, и может быть, даже, бес попутал.
Вся эта система с SSL сертификатами настолько ненадёжная, что доверять ей, конечно, может только субъект неразбирающийся ни на йоту в деталях и принцыпах работы оной. Как ей можно доверять, когда сертификаты могут выдавать такие компании как verisign, аоl time warner Inc. и упомянутая в новости. И самое главное: ведь всем плевать.
| | |
| |
| 2.19, Аноним (-), 06:41, 04/01/2013 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> Конечно-же это была ошибка, и может быть, даже, бес попутал.
Ну да, и вовсе то они и не пытались срубить бабла на доверии. Как вы могли такое подумать?!
| | |
| |
| 3.27, Аноним (-), 11:45, 04/01/2013 [^] [^^] [^^^] [ответить]
| +/– |
>> Конечно-же это была ошибка, и может быть, даже, бес попутал.
> Ну да, и вовсе то они и не пытались срубить бабла на
> доверии. Как вы могли такое подумать?!
А на чем они пытались срубить бабла? На заявлении в CPS - "Мамой клянемся, все будет хорошо"?
Брюс английским по белому предупреждал, что эта концепция доверия НЕХ не стоит выеденного яйца. У него что, неясно написано? Доверять можно тому, кого ты ЛИЧНО знаешь. И то не всякому. И ВСЕ.
А концепция деревьев доверия порочна по своей сути. Достаточно быть скомпрометированному ОДНОМУ из узловых CA/RA - и песец, коллапс всего дерева доверия. Что непонятного?
| | |
|
|
| 1.18, дядя (?), 05:46, 04/01/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Единственное в чем польза ssl - это шифрование. "Доверие" вообще яйца выеденного не стоит. Делают деньги из воздуха.
| | |
| |
| 2.26, Евгений (??), 11:39, 04/01/2013 [^] [^^] [^^^] [ответить] | –4 +/– | Объясню, почему вас минусуют и раскрою вашу некомпетентность в данном вопросе Ш... большой текст свёрнут, показать | | |
| |
| 3.33, Аноним (-), 15:22, 04/01/2013 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> в датацентрах находится специальное оборудование для снифинга не только внешнего трафика, но и внутреннего, который не зашифрован
Делись.
| | |
| 3.37, Аноним (-), 16:14, 04/01/2013 [^] [^^] [^^^] [ответить] | –1 +/– | Спасибо за разъяснения Прочитал Ваш комментарий с интересом А если у меня свой... большой текст свёрнут, показать | | |
| |
| 4.40, дон педро (?), 16:44, 04/01/2013 [^] [^^] [^^^] [ответить]
| +/– | |
>А если у меня свой днс (например прописаны жестко 8.8.8.8)?
И кто помешает провайдеру перенаправлять пакеты куда нужно? Ещё проще попросить держателя корневого сертификата выдать им на Х дней сертификат. Шах и мат.
| | |
| |
| 5.45, Аноним (-), 18:00, 04/01/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
>>А если у меня свой днс (например прописаны жестко 8.8.8.8)?
> И кто помешает провайдеру перенаправлять пакеты куда нужно? Ещё проще попросить держателя
> корневого сертификата выдать им на Х дней сертификат. Шах и мат.
Можно как-то противостоять перенаправлению пакетов в этом случае?
Но вообще печалька конечно. Остается только поднимать свой туннель, но и там возможно от другого провайдера перенаправление. В общем нужно для безопасного общения два своих сервера с туннелями, представляющие собой одновременно и клиент и сервер.
| | |
| |
| 6.56, Аноним (-), 22:41, 04/01/2013 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Можно как-то противостоять перенаправлению пакетов в этом случае?
Туннель до своего серванта. Хоть тот же опенвпн, где из доверяемых ауторити оставлена только лично ваша. В таком варианте подделать пакеты будет проблематично. Но это ж надо понимать как все это работает. А типовой хомячок - ну вы поняли.
| | |
| |
| 7.70, an0num0z (?), 18:00, 05/01/2013 [^] [^^] [^^^] [ответить]
| +/– |
>> Можно как-то противостоять перенаправлению пакетов в этом случае?
> Туннель до своего серванта. Хоть тот же опенвпн, где из доверяемых ауторити
> оставлена только лично ваша. В таком варианте подделать пакеты будет проблематично.
> Но это ж надо понимать как все это работает. А типовой
> хомячок - ну вы поняли.
при проведении разъяснительной работы и хомячок заинтересуется - но вряд ли сможет что-либо сделать. Без соответствующих знаний и дополнительных усилий заведомо жертва - вы абсолютно правы
| | |
|
|
|
| 4.57, Аноним (-), 22:48, 04/01/2013 [^] [^^] [^^^] [ответить] | +/– | Есть такая штука - прозрачный прокси Ну или попросту говоря, технически тот к... большой текст свёрнут, показать | | |
| |
| 5.69, an0num0z (?), 17:57, 05/01/2013 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
> вам может и соврать насчет ответа днс, отредиректить пакеты независимо от
> того что вам сообщил DNS и прочая. Собственно, SSL/TLS пытаелся бороться
> в том числе и с этим. Но из-за того что trusted
> authority легион и любая из них может выписать кому угодно серт
> на что угодно, хоть на тот же гугл.ком - достаточно одному
> из списка пролошиться или оказаться не совсем честным и вся схема
> разваливается. В отдельных применениях типа openvpn это лечится - указанием единственной
> доверяемой ауторити, вашей. На которую у недругов нет ключа, а остальные
> - попросту никто и не могут заверить что либо :). Но
> вот в вебе - оно так не лечится, увы.
где-то видел статью - разъясняющую как легко обнаружить подмену пакетов и как этому противостоять. Вывод один будущее безопасной сети за персональными серверами. Сейчас народ дурят облаками. Но это легкая нажива. Только свои машинки - не являюсь большим поклонником облаков, но думаю что для защищенности там придется изрядно повозиться. Надо чтобы сервера стали дешевыми как пока еще спички и маленькими таких же размеров а интернет стал бесплатен и РМС высылал как диски с убунтой флэшки с токенами ))
И все-же что простым пользователям и разработчикам прикладного софта и админам делать с этим безобразием в SSL. Ведь раньше эти случаи были редки. Надо что-то предпринимать или хотя бы пересмотреть традиционные подходы.
Спасибо за развернутый ответ.
Может SSL тут не причем в общем. Кроме подделки сертификатов как выясняется слабое звено в первичных не-секурных запросах. Вобщем туннелирование днс запросов через свою доверенную сеть рулит. Может кроме туннелей есть секурный днс?
| | |
|
| 4.65, arisu (ok), 02:01, 05/01/2013 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> Вопрос: Как по Вашему мнению можно улучшить надежность SSL
выкинуть его нафиг. оно починке не поддаётся в принципе: как «запорожец» не тюнь, а «lamborgini» всё равно не получится.
| | |
| |
| 5.68, an0num0z (?), 17:42, 05/01/2013 [^] [^^] [^^^] [ответить]
| +/– |
>> Вопрос: Как по Вашему мнению можно улучшить надежность SSL
> выкинуть его нафиг. оно починке не поддаётся в принципе: как «запорожец» не
> тюнь, а «lamborgini» всё равно не получится.
Простите, а Вы как на гмейл и им подобные ходите и проверяете свои акаунты в онлайне и почту? Только откровенно: вы любите сайты почту, в которых авторизация идет без SSL, а пароли не солятся быстрорастворимой солью? Или может быть это просто старая теплая ненависть к SSL?
<--...-->
выкинуть всегда успеется, если есть достойная замена. Для меня весь драмматизм с SSL в том, что ему альтернативы нет на фоне браузерных технологий (и не только: все ведь крутится вокруг библиотеки openssl... не так-ли? (хотя эта либа особо тут не причем и не решает "социально-инженерных" проблем) ). Именно это напрягает. Неужели так сложны применяемые технологии? Хотя по-ходу данный монополизм выгоден (вопрос кому) и что подтверждает на практике мы имеем дело с выделяющимися крайностями. С одной стороны монополизм (возможно ошибаюсь но что-то не попадалось альтернатив), с другой жесткая конкуренция и фрагментация + мутная водчика. Хотя man openssl отвечает практически на все вопросы.
| | |
| |
| 6.75, arisu (ok), 00:57, 06/01/2013 [^] [^^] [^^^] [ответить]
| –2 +/– |
> Простите, а Вы как на гмейл и им подобные ходите и проверяете
> свои акаунты в онлайне и почту?
никак: зачем мне эти зонды? у меня свой сервер, с пингвинами и поэзией. о какой вообще безопасности может идти речь, когда *личная* информация хранится незнамо у кого?
ах, да: *свой* сервер. вот он, железный, рядом со мной, можно пощупать. а не загадочное нечто в далёком датацентре.
впрочем, если СИЛЬНО хочется обмениваться информацией через гугель, то шифрование никто ещё не отменял. а уж как обменяться ключами — это другой вопрос.
> выкинуть всегда успеется, если есть достойная замена.
которая не появится, пока «да ладно, оно же даёт иллюзию безопасности. значит — работает. да и бизнес на сертификатах тоже вкусный.»
| | |
|
|
|
| 3.43, Аноним (-), 17:47, 04/01/2013 [^] [^^] [^^^] [ответить]
| –2 +/– |
>> Единственное в чем польза ssl - это шифрование. "Доверие" вообще яйца выеденного не стоит.
> Объясню, почему вас минусуют и раскрою вашу некомпетентность в данном вопросе.
Я так и не понял в каком месте там была некомпетентность. Шифрование в ssl работает, просто взять и расшифровать пакет нельзя. Гарантии сторонних организаций - фейл, они с тем же успехом, что и провайдер, могут отдать ключь фсб.
| | |
| |
| 4.44, filosofem (ok), 17:58, 04/01/2013 [^] [^^] [^^^] [ответить]
| +2 +/– |
 >>> Единственное в чем польза ssl - это шифрование. "Доверие" вообще яйца выеденного не стоит.
>> Объясню, почему вас минусуют и раскрою вашу некомпетентность в данном вопросе.
> Я так и не понял в каком месте там была некомпетентность. Шифрование
> в ssl работает, просто взять и расшифровать пакет нельзя. Гарантии сторонних
> организаций - фейл, они с тем же успехом, что и провайдер,
> могут отдать ключь фсб.
В слове "ключь". Правильно "ключъ". В остальном всё верно, ваш оппонент бредит.
| | |
| 4.51, Евгений (??), 21:10, 04/01/2013 [^] [^^] [^^^] [ответить]
| +/– |
> Я так и не понял в каком месте там была некомпетентность. Шифрование
> в ssl работает, просто взять и расшифровать пакет нельзя. Гарантии сторонних
> организаций - фейл, они с тем же успехом, что и провайдер,
> могут отдать ключь фсб.
Сорри, я так и думал, что неправильно понял вас изначально. Речь шла именно об этом фейковым доверии, который я счел непониманием простых принципов SSL.
| | |
|
| 3.47, Xasd (ok), 19:47, 04/01/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> в датацентрах находится специальное оборудование для снифинга не только внешнего трафика, но и внутреннего, который не зашифрован.
и как же они этот внутренний трафик получают? неужто это оборудование расшифровывает SSL? а откуда взялся private-ключ у этого оборудования?
| | |
| |
| 4.49, Евгений (??), 21:06, 04/01/2013 [^] [^^] [^^^] [ответить]
| –1 +/– | |
Никто ничего не расшифровывает. Впереди стоит балансировщик. Обычно он же SSL-фронтенд. Траф от фронтенда до бэкендов идет не зашифрованным (внутренний трафик датацентра). Оборудование типа Carnivore/СОРМ-2 слушает оба трафика: и внешний, и внутренний.
| | |
| 4.50, KT315 (ok), 21:10, 04/01/2013 [^] [^^] [^^^] [ответить]
| +/– |
 SSL это протокол, а не шифр или система шифрования. Синхронизация ключей шифрования происходит благодаря системе открытого ключа шифрования. Сертификат применяется для аутентификации и обмена ключами.
Сертификат как раз и говорит, что я "тот кто я есть" и вот тебе мой открытый ключ, который ты можешь использовать для синхронизации со мной ключа шифрованния данных, а у меня есть закрытый ключ, которым я расшифрую этот трафик, но я его не скажу. Потом ты отправляешь зашифрованный открытым ключем - ключ шифрования (к примеру ключ блочного алгоритма шифрования - aes). Сервак его получил и расшифровал закрытым ключем. Дальше ты шифруешь отправляемые данные ключем шифрования блочного (или потокового) шифра свои персональные данные и пересылаешь по "открытому" каналу. Сервак уже может расшифровать данные ключем блочного (или потокового) шифра - ибо ты его передал с помощью открытого ключа. Блочный или потоковый шифр используется, т.к. для системы открытого ключа требуется существенно больше вычислительных мощностей, при достижении такой же надежности, как у блочного или потокового алгоритма шифрования.
Понятно от куда у сервера расшифрованные данные? Иначе не обработать данные не расшифровав их. Данные в основном в сетях должны шифроваться только для защиты их от извлечения по "открытому" каналу связи и в местах длительного хранения (ПЗУ).
А теперь, кто осилил то, что я написал, то что будет, если кто-то получит фиктивный сертификат с открытым ключем?
| | |
| |
| 5.78, Xasd (ok), 06:03, 07/01/2013 [^] [^^] [^^^] [ответить]
| +/– | |
"датацентрах находится специальное оборудование для снифинга" -- вот как ИМЕННО ЭТО ОБОРУДОВАНИЕ подучает доступ к зашифрованному трафику?
а про сервера объснять не надо
> А теперь, кто осилил то, что я написал, то что будет, если кто-то получит фиктивный сертификат с открытым ключем?
если я хозяин сервера и решил подключитсья к своему серверу из дома -- то для меня не составит проблемы посмотреть на отпечаток ключа (совпадёт ли он или нет?). таким образом хозяин сервера может ОДНОЗНАЧНО определить была ли подстановка или не было. [в случае если в датацентре стоит "специальное оборудование для снифинга SSL"].
сразу вопрос: каким образом можно сделать MitM над SSL и при этом НЕ поменять отпечаток ключа? ни каким? значит невозможно сделать MitM над SSL совершенно незаметным. хозяен сервера узнает об MitM и сразуже разгорится скандал => очередной доверенный центр SSL пойдёт в вечный бан от Mozilla и Chromium.
| | |
| |
| 6.79, KT315 (ok), 12:11, 07/01/2013 [^] [^^] [^^^] [ответить]
| +/– |
> "датацентрах находится специальное оборудование для снифинга" -- вот как ИМЕННО ЭТО ОБОРУДОВАНИЕ
> подучает доступ к зашифрованному трафику?
> а про сервера объснять не надо
это оборудование стоит уже за сервером, который расшифровывает трафик. Далее трафик, уже будучи расшифрованным, заворачивается в маршрут для прослушки спец оборудованием (незачем ему шифрованный трафик).
> если я хозяин сервера и решил подключитсья к своему серверу из дома
> -- то для меня не составит проблемы посмотреть на отпечаток ключа
> (совпадёт ли он или нет?). таким образом хозяин сервера может ОДНОЗНАЧНО
> определить была ли подстановка или не было. [в случае если в
> датацентре стоит "специальное оборудование для снифинга SSL"].
> сразу вопрос: каким образом можно сделать MitM над SSL и при этом
> НЕ поменять отпечаток ключа? ни каким? значит невозможно сделать MitM над
> SSL совершенно незаметным. хозяен сервера узнает об MitM и сразуже разгорится
> скандал => очередной доверенный центр SSL пойдёт в вечный бан от
> Mozilla и Chromium.
Часто вы смотрите на отпечаток?
А если серверов сотня, для балансировки нагрузки, вы ведете учет по каждому из них?
А если закончился срок сертификата, то все, подмена? Ведь злоумышленнику тоже ничего не мешает, применить свой фиктивный сертификат в день замены сертификата, и какой из 2х будут действительный - вы знать не будете.
| | |
|
|
|
| 3.53, Аноним (-), 22:01, 04/01/2013 [^] [^^] [^^^] [ответить]
| +/– |
> В действительности, все несколько иначе. Предположим, вам необходимо соединиться с account.google.com.
> Местный DNS-резолвер вам возвращает ip-адрес хоста и вы соединяетесь с ним.
Перенаправив клиента на левый хост, вы не сможете подделать сертификат, который выписан на _домен_. В ответ на левый незаверенный сертификат, который вы попытайтесь вручить клиенту, его браузер начнёт кричать что хост не тот за кого себя выдаёт. Не зная закрытого ключа невозможно создать поддельный SSL-канал к клиенту с промежуточного хоста, вы можете тольно попытаться впарить самоподписанный сертификат.
| | |
| |
| 4.66, arisu (ok), 02:05, 05/01/2013 [^] [^^] [^^^] [ответить]
| +/– |
> В ответ на левый незаверенный сертификат, который вы попытайтесь
> вручить клиенту, его браузер начнёт кричать что хост не тот за
> кого себя выдаёт.
после чего юзер бездумно тыкнет в кнопку «принять и заткнуться», матеря про себя тупоголовых создателей софта, которые только и умеют, что доставлять проблемы.
| | |
| 4.71, an0num0z (?), 18:24, 05/01/2013 [^] [^^] [^^^] [ответить] | +/– | Это действительно так, только например гугл часто отдает разные сертификаты и оч... большой текст свёрнут, показать | | |
|
| 3.58, Ytch (ok), 23:15, 04/01/2013 [^] [^^] [^^^] [ответить]
| +/– |
 >...в датацентрах находится специальное оборудование для снифинга не только внешнего трафика, но и внутреннего, который не зашифрован.
Да. Если уж кто-то читает секретные донесения вслух, а у вас есть возможность поставить рядом микрофон, то нет никакого смысла заморачиваться с перехватами, расшифровками и т. п.
| | |
| 3.80, дядя (?), 22:38, 07/01/2013 [^] [^^] [^^^] [ответить]
| +/– |
Объясню почему вас минусуют - 99.99% сайтов в интернете с SSL. Никакого доверия к ним нет. То что им выдали сертификат с закрытыми глазами - тоже абсолютно ничего не значит, т.к. они сами по себе могут быть man-in-the-middle. Например, изменить 1 букву в имени домена и выписать себе сертификат. Все. А у пользователя возникнет ложное чувство доверенности из-за зеленого замка.
| | |
|
|
| 1.21, Z (??), 07:53, 04/01/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
> в августе 2011 года по ошибке двум организациям вместо обычных SSL-сертификатов были выписаны вторичные корневые сертификаты
Сколько? Удивительно, что в такой новости нет ни одного символа $, только бред про "по ошибке". Еще интересно, сам владелец бизнеса был в курсе, когда совершал такую "ошибку", которая уничтожит бизнес (вход в который стоит не дешево, а прибыль дает не сильно большую) или это кто-то из наемников за спиной работодателя так "ошибся"?
| | |
| |
| 2.23, Аноним (-), 09:41, 04/01/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Сколько? Удивительно, что в такой новости нет ни одного символа $, только
> бред про "по ошибке".
Более-менее понятно, что эти сертификаты были тихо выданы под системы выявления утечек данных или для местных спецслужб. Ни они первые, Trustwave CA за руку в прошлом году на этом поймали (http://www.opennet.dev/opennews/art.shtml?num=33034).
| | |
|
| 1.25, Аноним (-), 10:19, 04/01/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
ИМХО: Доверие не должно происходить автоматически, а до тех пор пока это так — будут такие инциденты. Я не призываю отказываться от этой системы и проверять лично каждый сертификат сайта, просто надо быть готовым …
Кстати, гугл могли бы присылать для аутентификации по SMS хеш своего публичного ключа (fingerprint или как там его), что-бы убедится что нету "посредника" ?
| | |
| |
| 2.29, Аноним (-), 11:48, 04/01/2013 [^] [^^] [^^^] [ответить]
| +/– |
> ИМХО: Доверие не должно происходить автоматически, а до тех пор пока это
> так — будут такие инциденты. Я не призываю отказываться от этой
> системы и проверять лично каждый сертификат сайта, просто надо быть готовым
> …
Готовым к чему? Конкретно можно?
> Кстати, гугл могли бы присылать для аутентификации по SMS хеш своего публичного
> ключа (fingerprint или как там его), что-бы убедится что нету "посредника"
> ?
Чушь собачья. Костыль костылей. Рекомендую вначале почитать-таки Брюса - он как-никак ведущий криптограф а не хрен собачий с опеннета. И знает толк в криптографии.
| | |
| |
| 3.32, VoDA (ok), 15:15, 04/01/2013 [^] [^^] [^^^] [ответить]
| +/– |
 > Рекомендую вначале почитать-таки Брюса - он как-никак ведущий
> криптограф а не хрен собачий с опеннета. И знает толк в
> криптографии.
и какое у него решение текущей проблемы для сертификатов?
| | |
| |
| 4.35, clown (?), 15:39, 04/01/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
1 послать всех на
2 покупать сертификаты у него, ему доверять можно
Криптографов в мире хватает, да и не нужно им быть чтобы придумать ИДЕЮ. хотели по простому - всё испортил человеческий фактор. Теперь будет по-сложному.
| | |
| |
| 5.39, Аноним (-), 16:23, 04/01/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
> 1 послать всех на
> 2 покупать сертификаты у него, ему доверять можно
> Криптографов в мире хватает, да и не нужно им быть чтобы придумать
> ИДЕЮ. хотели по простому - всё испортил человеческий фактор. Теперь будет
> по-сложному.
Рабинович, не надо перепевать Карузо. Ты тоже не читал Шнайера.
Тащемта - да, додуматься до идеи нетрудно. Но статью Брюса-таки прочти. Все же не ты ее написал, а он - и когда написал! На дату посмотри!
| | |
| 5.52, Аноним (-), 21:54, 04/01/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> всё испортил человеческий фактор.
не испортил, а показал несостоятельность. доверие, оберегаемое угрозой санкций, цена репутации - цена услуг пласт. хирурга плюс новая история жизни, подтвержденная документарно. а то мало-ли что по защищенному SSL передадут, человека там транспондируют по частям, или, боже мой, зачатие по электронной почте (понятие доверия ведь перенесли в Сеть из жизни).
| | |
|
| 4.38, Аноним (-), 16:22, 04/01/2013 [^] [^^] [^^^] [ответить]
| +/– |
>> Рекомендую вначале почитать-таки Брюса - он как-никак ведущий
>> криптограф а не хрен собачий с опеннета. И знает толк в
>> криптографии.
> и какое у него решение текущей проблемы для сертификатов?
И не только текущей. Пойди на его сайт и почитай. Может, просветление наступит.
| | |
|
|
|
| |
| 2.72, Аноним (-), 18:40, 05/01/2013 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> SSL — это надёжно!
(лениво) Толсто же, Арису. Толстенный наброс, аж жыр из монитора потек.
| | |
| |
| 3.74, arisu (ok), 00:28, 06/01/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> SSK + TLS v1.2 + DNSSEC
лучше, чем «голый» ssl, но не намного. к тому же — подписывать весь сайт? если он, например, динамически генерируется? не лучший вариант.
остаётся, опять же, вопрос доверия ключу. решаемый, но тем не менее.
p.s. ах, да. DNS. с ключевым словом «централизация».
| | |
|
|
|
