The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Выявлены обманные SSL-сертификаты, полученные из-за халатности удостоверяющего центра TurkTrust

03.01.2013 23:43

Компании Mozilla и Google одновременно объявили о прекращении доверия двум корневым сертификатам удостоверяющего центра TurkTrust и отзыве данных сертификатов из базы, поставляемой в составе браузеров Firefox и Chrome. Причиной удаления сертификатов, являются вскрывшиеся факты использования выписанных от лица сервиса TurkTrust SSL-сертификатов для совершения MITM-атак (man-in-the-middle), направленных на транзитный перехват и расшифровку SSL-трафика на промежуточном узле.

24 декабря компанией Google был выявлен обманный сертификат, выписанный для доменов *.google.com, который был задействован для совершения атаки на пользователей сервисов Google. Не исключено, что подобные обманные сертификаты могли быть использованы для атаки на другие компании и службы. Удостоверяющий центр TurkTrust, который присутствовал в цепочке доверия у обманного сертификата, провёл внутреннее расследование. Расследование показало, что в августе 2011 года по ошибке двум организациям вместо обычных SSL-сертификатов были выписаны вторичные корневые сертификаты, которые можно было использовать для генерации SSL-сертификатов для любого сайта в сети, при этом подобные обманные сертификаты будут восприняты клиентским ПО, как заслуживающие доверия.

В настоящее время рассматривается вопрос о применении санкций против удостоверяющего центра TurkTrust, допустившего столь непростительную халатность в своей работе, приведшей к нарушению цепочки доверия. Напомним, что компрометация любого из существующих удостоверяющих центров может привести к возможности сгенерировать рабочий сертификат для любого сайта в сети, независимо от того каким центром сертификации выдан оригинальный SSL-сертификат. При каждом HTTPS/TLS-сеансе пользователь изначально доверяет всем имеющимся центрам сертификации, поэтому утечка корневого сертификата у одного из центров сертификации может привести к коллапсу всей системы. Средства защиты от подобных манипуляций, например методы перекрёстной сертификации или специальные расширения к протоколу TLS, только разрабатываются.

  1. Главная ссылка к новости (https://blog.mozilla.org/secur...)
  2. OpenNews: Представлено TACK, расширение SSL/TLS для борьбы с MITM-атаками и поддельными сертификатами
  3. OpenNews: Предложение по использованию TLD-доменов ".secure" для гарантированно защищённых ресурсов
  4. OpenNews: Mozilla объявляет ультиматум удостоверяющим центрам
  5. OpenNews: GlobalSign временно приостановил выдачу SSL-сертификатов из-за возможной компрометации
  6. OpenNews: Опубликован полный список обманных SSL-сертификатов. В списке ЦРУ и МИ-6
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/35754-cert
Ключевые слова: cert, ssl
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (79) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, pavlinux (ok), 00:47, 04/01/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Поднимите руку, кто доверяет TurkTrust, а так же Machachkala Security Center, корневым центрам Тегерана и Кабула? :)
     
     
  • 2.8, anonymous (??), 01:26, 04/01/2013 [^] [^^] [^^^] [ответить]  
  • +15 +/
    Клоуны в треде, скорее в машину.
     
  • 2.13, Stream (?), 01:58, 04/01/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Турецкие провайдеры снифят трафик юзеров ?
     
     
  • 3.24, ъ (?), 10:15, 04/01/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Я в турецком отеле хотел парнушку посмотреть по местному ви-фи. Обломись. Не дало. Написало, что контент нехороший.
     
     
  • 4.31, Аноним (-), 15:14, 04/01/2013 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Вы хотели сказать "не дала". :)
     
  • 2.17, Аноним (-), 05:19, 04/01/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Вы таки доверяете другим удостоверяющим центрам?
     
  • 2.59, robux (ok), 00:03, 05/01/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Поднимите руку, кто доверяет TurkTrust

    Ты доверяюешь Гуглю. Гугль доверяет туркишу. Туркиш доверяет хулиганам.
    Итак: ты довряешь хулиганам.

    Как это работает:
    1) ты лезешь на сайт https://money.google.com
    2) хулиган посередине подсовывает самопальный ключ туркиша
    3) твой браузер спокоен, ибо цепочка доверия работает
    4) твои явки и пароли уходят хулигану
    5) ?????
    6) PROFIT!!11

     
     
  • 3.67, Andrew Kolchoogin (?), 10:48, 05/01/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Во-первых, работает это не совсем так твой браузер доверяет Туркишу Туркиш дов... большой текст свёрнут, показать
     
     
  • 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.
     
     
  • 3.6, анончик (?), 01:12, 04/01/2013 [^] [^^] [^^^] [ответить]  
  • +/
    тихо она даже отдельно обновляется.
     
     
  • 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. ваш комментарий груб и неинформативен.
     
  • 6.41, linux must _RIP_ (?), 17:21, 04/01/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    ты прикинь братан - там думать надо, а тебе хотелось только на кнопки жать ?
     
     
  • 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 +/
    > в датацентрах находится специальное оборудование для снифинга не только внешнего трафика, но и внутреннего, который не зашифрован

    Делись.

     
     
  • 4.34, Евгений (??), 15:28, 04/01/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Читать до посинения: http://ru.wikipedia.org/wiki/SSL
     
  • 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.me/opennews/art.shtml?num=33034).

     

  • 1.22, unscrubber (?), 09:23, 04/01/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    diginotar2 aka turktrust - "давай, до свиданья" :-)
     
  • 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 [^] [^^] [^^^] [ответить]  
  • +/
    >> Рекомендую вначале почитать-таки Брюса - он как-никак ведущий
    >> криптограф а не хрен собачий с опеннета. И знает толк в
    >> криптографии.
    > и какое у него решение текущей проблемы для сертификатов?

    И не только текущей. Пойди на его сайт и почитай. Может, просветление наступит.

     

  • 1.60, arisu (ok), 01:38, 05/01/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    SSL — это надёжно!
     
     
  • 2.72, Аноним (-), 18:40, 05/01/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > SSL — это надёжно!

    (лениво) Толсто же, Арису. Толстенный наброс, аж жыр из монитора потек.

     
  • 2.73, Аноним (-), 19:44, 05/01/2013 [^] [^^] [^^^] [ответить]  
  • +/
    SSK + TLS v1.2 + DNSSEC
     
     
  • 3.74, arisu (ok), 00:28, 06/01/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > SSK + TLS v1.2 + DNSSEC

    лучше, чем «голый» ssl, но не намного. к тому же — подписывать весь сайт? если он, например, динамически генерируется? не лучший вариант.

    остаётся, опять же, вопрос доверия ключу. решаемый, но тем не менее.

    p.s. ах, да. DNS. с ключевым словом «централизация».

     

  • 1.76, lincz (?), 02:57, 06/01/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    MITM-атаки. Охохо, MIT - это турецкая гэбня.
     
  • 1.77, iZEN (ok), 15:56, 06/01/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Порт библиотеки nss на FreeBSD обновили: http://www.freshports.org/security/nss/
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру