форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	+/–
Сообщение от opennews (??) on 24-Мрт-11, 12:11
Компания Comodo, спустя восемь дней с момента обнаружения проблемы, опубликовала заявление (http://www.comodo.com/Comodo-Fraud-Incident-2011-03-23.html) в котором обобщила суть инцидента, в результате которого злоумышленникам удалось получить девять валидных HTTPS-сертификатов для ряда известных web-ресурсов. Используя данные сертификаты злоумышленники могли сформировать поддельный сайт, который был бы неотличим от настоящего и содержал не вызывающий подозрение SSL-сертификат. Перенаправить пользователя на подобные сайты можно используя, например, атаки man-in-middle (http://ru.wikipedia.org/wiki/%D0%A7%D0%B...) или отравление DNS-кэша. По данным  Comodo, 9 обманных сертификатов злоумышленникам удалось сгенерировать в результате взлома пользовательского аккаунта в одного из доверенных регистрирующих центров (RA, Registration Authority). Инфраструктура удостоверяющего центра (CA (http://ru.wi... URL: http://www.comodo.com/Comodo-Fraud-Incident-2011-03-23.html Новость: http://www.opennet.dev/opennews/art.shtml?num=30013
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	+3 +/–
Сообщение от Аноним (??) on 24-Мрт-11, 12:11
Для защиты от подмены сертификатов есть хорошее расширение для Firefox - Certificate Patrol. Оно хранит базу сертификатов посещенных сайтов и в случае изменения сертификата выводит окно, где выведены старый и новый сертификат. К сожалению, этот аддон не совместим пока с только вышедшей 4 версией Лисы.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	7. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	–1 +/–
	Сообщение от Аноним (??) on 24-Мрт-11, 12:32
	Вы думаете народ при этом станет звонить в ЦС и уточнять правда ли у них изменился сертификат ? И это не защищает от подмены сертификата при изначальном его получении.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	11. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	+/–
	Сообщение от Аноним (??) on 24-Мрт-11, 13:01
	Звонить не обязательно. К примеру было бы видно, что гугловский сертификат выдан вместо thawte теперь comodo. Этого достаточно чтобы забеспокоиться.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	13. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	–5 +/–
	Сообщение от Аноним (??) on 24-Мрт-11, 13:07
	Дык там же что угодно написать можно, он же не оригинальный а подмененный, челом сидящим на вашем канале.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	49. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	+/–
	Сообщение от Одмин on 25-Мрт-11, 00:33
	нельзя, в сертификате от комодо будет написано что он от комодо.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	50. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	–3 +/–
	Сообщение от Аноним (??) on 25-Мрт-11, 00:40
	на заборе тоже много че написано, а в реальности есть косяки, читайте ниже
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	57. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	+/–
	Сообщение от Michael Shigorin (ok) on 25-Мрт-11, 21:14
	Где именно ниже, а то уже много?  Ну и написанное на заборе не валидируется по прибитому в браузере. (хотя... смотря как родители воспитали :)
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	33. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	+/–
	Сообщение от Комментатор on 24-Мрт-11, 19:01
	Будет интересней, если поломают просроченные сертификаты которые необходимы Windows. http://support.microsoft.com/kb/293781 :))
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

2. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	+1 +/–
Сообщение от Аноним (??) on 24-Мрт-11, 12:12
Полезная ссылка на описание того, как люди из "Tor project" разбирались с этой проблемой. https://blog.torproject.org/blog/detecting-certificate-autho...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

3. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	+1 +/–
Сообщение от Аноним (??) on 24-Мрт-11, 12:15
Открытая децентрализованная p2p валидация. Систему можно будет свалить только при условии внедрения взломанного кода в бОльшую часть узлов сети, что гораздо сложнее в условиях открытости кода.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	10. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	+/–
	Сообщение от Аноним (??) on 24-Мрт-11, 12:42
	+ соединение по изначально защищенному каналу, т.е. хранить на клиенте закрытый ключ а получать его первично по др. каналу.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	15. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	–1 +/–
	Сообщение от Анонимиус on 24-Мрт-11, 13:40
	Выше отпостившим авторам и по тексту новости. Вам не кажется, что немного теряется смысл самих сертификатов, при их постоянной проверке онлайн-средствами? ;) Тогда уж можно просто пользовать те или иные протоколы аутентификации, вероятно, также на основе ассиметричной криптографии, но это уже будет немного не тот "сертификат".
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	18. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	+/–
	Сообщение от Аноним (??) on 24-Мрт-11, 14:00
	Так и есть. С одной стороны понятно что идеальной защиты все равно не добиться, терморектальный криптоанализ никто не отменял, с другой понятно что усиливать защиту все равно надо. Если сертификаты и инициация по открытому каналу, при ситуации "человек в середине", то по моему усиление возможно только запутыванием, но в принципе подлом всегда остается возможен обратным распутыванием, чисто технически, без социальной инженерии и терморектальностей. А вот если распределенная сеть валидации то уже гораздо сложнее, тем более если инициация изначально закрыта, тут без социальной инженерии и терморектальностей уже не обойтись.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	63. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	+/–
	Сообщение от Aleksey Salow (ok) on 27-Мрт-11, 23:25
	сертификаты используются не только в web-е, а и много где за пределами. Так зачем ломать рабочую инфраструктуру, да и проблема то не в сертификатах.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

4. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	–9 +/–
Сообщение от Аноним (??) on 24-Мрт-11, 12:17
Если злоумышленник в состоянии вклинится в трафик жертвы, в самом начале, когда соединение еще не защищено, а соединение изначально не защищено, ключи получаются по незащищенному и могут быть подменены, как и запросы на их проверку, организовать прокси, то он может все.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	27. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	–3 +/–
	Сообщение от Аноним (??) on 24-Мрт-11, 17:12
	Че минусовать то ? Неужели не очевидно что ключи, даже открытые, надо охранять ?
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	62. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	+1 +/–
	Сообщение от Aleksey Salow (ok) on 27-Мрт-11, 23:23
	Школоло в криптографии не разбирается. Откуда им знать что против mitm работают только схемы с третьим доверенным лицом.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

5. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	+1 +/–
Сообщение от Иван Иванович Иванов on 24-Мрт-11, 12:27
А о скольки таких breach'ах мы ещё не знаем, интересно? Ведь пока один разработчик не раскопал эту проблему, просматривая commit'ы в Firefox/Chrome, никто даже и не заикнулся о проблеме.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	22. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	+1 +/–
	Сообщение от Аноним (??) on 24-Мрт-11, 15:24
	> А о скольки таких breach'ах мы ещё не знаем, интересно? О многих. А зачем Вам об этом знать? А для специалиста или интересующихся совершенно очевидно что удостоверяющий центр тоже может быть скомпрометирован, это же очевидно, там же тоже люди работают.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

6. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	+1 +/–
Сообщение от Александр (??) on 24-Мрт-11, 12:30
Может кто-нибудь пояснить как сочитаются: "В ситуации когда злоумышленник в состоянии вклинится в трафик жертвы и подменить содержимое сайта, он с тем же успехом может блокировать проверочные CRL/OCSP запросы" "В качестве одного из вариантов решения проблемы называется создание производителями браузеров собственных кэширующих OCSP-серверов" Если злоумышленик в состоянии блокировать проверочные CRL/OCSP запросы, то какая разница сколько серверов блокировать? Ну создадут собственный кэширующий сервер, а злоумышленик и его заблокирует, где смысл?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	8. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	+/–
	Сообщение от Аноним (??) on 24-Мрт-11, 12:38
	Смысл в усложнении, устроить злоумышленнику больший гемор, но в принципе в данном случае он конечно не особо большим получается.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	9. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	+/–
	Сообщение от Александр (??) on 24-Мрт-11, 12:40
	я бы даже сказал, совсем не получается.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	12. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	+1 +/–
	Сообщение от Аноним (??) on 24-Мрт-11, 13:07
	> Если злоумышленик в состоянии блокировать проверочные CRL/OCSP запросы, то какая разница > сколько серверов блокировать? Ну создадут собственный кэширующий сервер, а злоумышленик > и его заблокирует, где смысл? Смысл в том, что у некоторых CA OCSP-сервисы безбожно глючат и в их временной недоступности нет ничего удивительного. Добавив независимый OCSP-сервис можно в случае недоступности сразу двух систем не просто игнорировать ошибку, а выводить по умолчанию предупреждение.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	14. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	–2 +/–
	Сообщение от Аноним (??) on 24-Мрт-11, 13:21
	Про предупреждение справедливости ради там ничего не сказано. Да хоть и так, во первых многие на это просто положат, как покладывают на предупреждения о самоподписанности, а во вторых, если мы перехватываем трафик клиента, то что нам запрещает не глушить а ответить на запрос о валидности утвердительно ?
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	20. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	+1 +/–
	Сообщение от К.О. on 24-Мрт-11, 15:02
	То, что CRL тоже подписан ключом, которого у Тебя нет?
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	24. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	–2 +/–
	Сообщение от Аноним (??) on 24-Мрт-11, 16:43
	В том то и дело что есть, сессионный ключ которым все шифруется получается злоумышленником в начале соединения, злоумышленник садится посередине между клиентом и сервером и выступает для клиента как сервер, они обмениваются открытыми ключами и устанавливают честное с точки зрения клиента соединение. При необходимости злоумышленник также может общаться с сервером, выдавая себя за клиента. В результате имеем всю необходимую инфу.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	30. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	+2 +/–
	Сообщение от Аноним (??) on 24-Мрт-11, 18:54
	> В том то и дело что есть, сессионный ключ которым все шифруется > получается злоумышленником в начале соединения, злоумышленник садится посередине между > клиентом и сервером и выступает для клиента как сервер, они обмениваются > открытыми ключами и устанавливают честное с точки зрения клиента соединение. При > необходимости злоумышленник также может общаться с сервером, выдавая себя за клиента. > В результате имеем всю необходимую инфу. Кроме подписи на CRL сертификате, которая делается секретным ключом удостоверяющего центра, который Вы не знаете, а публичный ключ CA используемый для проверки CRL у клиента вшит в браузер или ОС и Вы его не подмените. Именно для защиты от m-in-m и придумали всю эту архитектуру с удостоверяющими центрами, и она давным давно проверена и безопасна и найти в ней дырку Вас не светит. Речь не об этом, а о том что удостоверяющий центр может под угрозой или по ошибке выдать _правильный_ сертификат, но не тем.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	36. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	–3 +/–
	Сообщение от Аноним (??) on 24-Мрт-11, 19:32
	Ничего там секретным ключом не шифруется, он используется только для расшифровки на принимающей стороне. Естественно если публичный ключ вшит (получен по закрытому каналу) то ничего не получится, но мы то какраз о получении публичных ключей по открытому каналу, протокол это позволяет и это используется, изначально вшито очень мало ключей, добавьте к этому использование самоподписанных, так что от m-in-m зачастую не спасает.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	40. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	+1 +/–
	Сообщение от Аноним (??) on 24-Мрт-11, 22:38
	> Ничего там секретным ключом не шифруется Божежтымой... почитайте описание TLS :) Там НЕСКОЛЬКО секретных ключей, сертификат сайта это секретный + публичный ключ + подпись секретным ключом удостоверяющего центра. Вы можете выдать свой сертификат за сертификат сайта при m-in-m, но Вы не сможете его заверить секретным ключом удостоверяющего центра потому что у Вас его нет, поэтому Ваш m-in-m будет сразу раскрыт по некорректной подписи, ведь публичный ключ удостоверяющего центра вшит в браузер или ОС и не передаётся.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	45. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	+/–
	Сообщение от Аноним (??) on 24-Мрт-11, 23:24
	Не все вшито в браузер. Не может он быть сразу раскрыт, проверка в удостоверяющем центре может вообще не осуществляться, либо может быть отложена, либо заблокирована.
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	64. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	+/–
	Сообщение от Aleksey Salow (ok) on 27-Мрт-11, 23:53
	> В том то и дело что есть, сессионный ключ которым все шифруется > получается злоумышленником в начале соединения, злоумышленник садится посередине между > клиентом и сервером и выступает для клиента как сервер, они обмениваются > открытыми ключами и устанавливают честное с точки зрения клиента соединение. При > необходимости злоумышленник также может общаться с сервером, выдавая себя за клиента. > В результате имеем всю необходимую инфу. Вы о чём? У сервера есть его pub/priv ключи и сертификат с pub ключём подписанным CA. В начале он формирует посылку для клиента (для DH, например), подписывает своим приватным ключём и высылает клиенту вместе с сертификатом. Клиент проверяет сертификат на валидность по всей цепочке или, хотябы, самый первый CA, сертификат от которого у него точно есть, принимает решение доверять сертификату или нет, и уже только потом проверяется подпись посылки и всё такое. Если кто-то вклинится в середину, то он отпадёт ещё на этапе проверки клиентом сертификата. Обратная посылка шифруется открытым ключём сервера, так что вклинившийся узнать сессионный ключ никак не может. Это всё, есно, работает только если мы доверяем CA, если же нет, то вся PKI, как уже сказали, разваливается к чертям.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	17. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	+2 +/–
	Сообщение от iZEN (ok) on 24-Мрт-11, 13:44
	Если OCSP-сервисы безбожно глючат, то нету никакой уверенности в достоверности сертификатов, и вся система PKI рассыпается как карточный домик. В Firefox 4.0 по умолчанию сертификат считается валидным, если нет доступа к серверу OCSP. Это самая настоящая дыра в безопасности! В настройках Дополнительные -> Шифрование -> Настройки OCSP можно/нужно изменить это злосчастное умолчание, отметив галочку "При ошибке соединения с сервером OCSP, рассматривать сертификат как недействительный". ;)
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	23. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	+/–
	Сообщение от Аноним (??) on 24-Мрт-11, 16:31
	А вот интересно что мешает устроить MITM атаку при обращении к OCSP?
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	25. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	+/–
	Сообщение от Аноним (??) on 24-Мрт-11, 16:56
	Если обмен первичными ключами идет по открытому каналу то ничто не мешает. А вот если ключи вы заранее получили по др. каналу то злоумышленник не сможет их подменить и соответственно расшифровать ваш обмен.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	29. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	+/–
	Сообщение от Frank (ok) on 24-Мрт-11, 18:51
	Получить открытый ключ что сервера, что клиента, просто и... бесполезно! Пакеты, зашифрованные закрытыми ключами, расшифровать, имея только открытые, не получится. Нужно иметь закрытый ключ одной из сторон, а его ты не перехватишь потому что он не передаётся. Единственный вариант - становится посредине (MiM) и шифровать самому, своим закрытым ключом, но для этого тебе потребуется заставить жертву считать тебя сервером - например, отравлением кэша ДНС сервера, используемого жертвой. Иначе жертва пойдёт устанавливать SSL соединение по айпи адресу настоящего сервера и у тебя опять обломится.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	34. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	–2 +/–
	Сообщение от Аноним (??) on 24-Мрт-11, 19:12
	Приблизительно так, но проще. Во первых закрытыми ключами ничего не шифруют, нет смысла т.к. они не передаются и соответственно вообще никто не сможет расшифровать. Закрытыми ключами расшифровывают, то что зашифровано открытым ключом. Получать открытый ключ просто и очень полезно, все шифруется сессионным ключом а он формируется на основе открытых, соответственно став посередине можно перехватить открытую передачу открытого ключа и подсунуть вместо него свой, на основе этого ключа будет сформирован сессионный и далее мы сможем расшифровать все остальное. DNS можно не травить, если правильно встать то все запросы будут идти через нас, тогда можно отвечать вместо любых абонентов и глушить лишнее.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	37. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	+/–
	Сообщение от iZEN (ok) on 24-Мрт-11, 21:52
	> Приблизительно так, но проще. Во первых закрытыми ключами ничего не шифруют, нет > смысла т.к. они не передаются и соответственно вообще никто не сможет > расшифровать. Откуда ты это выдумал? Закрытый ключ используется для генерации ПОДПИСИ открытого ключа и дайджеста сообщения. Это позволяет подтвердить аутентичность владельца открытого ключа, создателя сообщения. > все шифруется сессионным ключом а он формируется на основе открытых, Плюс ещё дайджест сообщения, который защищает сессионный ключ от подделки. > соответственно став посередине можно перехватить открытую передачу открытого ключа и подсунуть вместо него свой, Нельзя — дайджест сообщения невозможно подделать, не имея секретного ключа создателя сообщения. Получатель быстро выявит подделку.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	39. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	+/–
	Сообщение от Аноним (??) on 24-Мрт-11, 22:36
	Ничего я не выдумал, это из описания протокола, пакеты закрытым ключом не шифруются, они шифруются сессионным. Да, сессионный ключ зависит от ключа сервера, но дело в том что сервером в данном случае становится злоумышленник, он генерирует свой ключ, открытую часть может подсунуть клиенту а закрытой сгенерить дайджест.
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	41. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	+1 +/–
	Сообщение от Аноним (??) on 24-Мрт-11, 22:44
	> Ничего я не выдумал, это из описания протокола, пакеты закрытым ключом не > шифруются, они шифруются сессионным. Да, сессионный ключ зависит от ключа сервера, > но дело в том что сервером в данном случае становится злоумышленник, > он генерирует свой ключ, открытую часть может подсунуть клиенту а закрытой > сгенерить дайджест. И как Вы подтвердите валидность Вашей открытой части подсунутого клиенту ключа? Вы понимаете что открытая часть ПОДПИСАНА удостоверяющим центром, а публичный ключ удостоверяющего центра встроен в браузер?
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	42. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	+/–
	Сообщение от Аноним (??) on 24-Мрт-11, 22:52
	Естественно понимаю, по этому и говорю что если открытый ключ изначально встроен или получен по защищенному каналу то ничего не получится. Но сколько ключей встроены изначально ? Неужели вы ни разу не получали запрос на установку нового ключа ? На практике ключ может быть передан по открытому каналу, или вообще может быть самоподписанным.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	43. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	+/–
	Сообщение от iZEN (ok) on 24-Мрт-11, 23:11
	> Естественно понимаю, по этому и говорю что если открытый ключ изначально встроен > или получен по защищенному каналу то ничего не получится. Но сколько > ключей встроены изначально ? В браузер встроены не публичные ключи, а сертификаты с публичными ключами. Сертификаты заверены подписями центров сертификации (CA) из доверяемой цепочки. > Неужели вы ни разу не получали запрос > на установку нового ключа ? На практике ключ может быть передан > по открытому каналу, или вообще может быть самоподписанным. Ключ сам по себе не может быть передан, так как не имет определённого формата. Можно передать короткий отпечаток публичного ключа — хэш. Формат (алгоритм генерации) публичного ключа определяет сертификат.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	46. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	+/–
	Сообщение от Аноним (??) on 24-Мрт-11, 23:50
	Не ключи а сертификаты, правильно. Но суть то не меняется, протокол не устанавливает их жесткой проверки.
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	44. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	+/–
	Сообщение от Аноним (??) on 24-Мрт-11, 23:16
	Процедура подтверждения в удостоверяющем центре может быть заблокирована, см. текст новости, и вообще стандарт не обязывает проверять ключ, это может быть отложено.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	26. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	–1 +/–
	Сообщение от User294 (ok) on 24-Мрт-11, 17:08
	> В Firefox 4.0 по умолчанию сертификат считается валидным, если нет доступа к > серверу OCSP. Это самая настоящая дыра в безопасности! А теперь прикинь, OCSP сервер взял да и умер. Ну, умирают вот иногда сервера. Даже самые хорошие, белые и пушистые. И это что, мне теперь по этому поводу без доступа в онлайн-банк чтоли остаться из-за даунайма ПОСТОРОННЕГО сервера? Мля, тогда банкоматом пользоваться наверное вообще не надо - там кардеры могли ридер привинтить в принципе. Поэтому надо самому дуть в отделение и получать бабло в кассе и никак иначе. К кассиру то ридер не привинтишь :)
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	28. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	–2 +/–
	Сообщение от Аноним (??) on 24-Мрт-11, 17:24
	Предлагается что OCSP серверов будет несколько, все сразу не помрут. Тут другая проблема, до тех пор пока ключики будут изначально распространяться по открытому каналу и самоподписываться дыра будет оставаться.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	32. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	+/–
	Сообщение от Аноним (??) on 24-Мрт-11, 19:00
	> Тут другая > проблема, до тех пор пока ключики будут изначально распространяться по открытому > каналу и самоподписываться дыра будет оставаться. Вы сейчас о чём? Самоподписанный сертификат по определению не верен, его проверять не надо. О чём например все браузеры предупреждают.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	35. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	–1 +/–
	Сообщение от Аноним (??) on 24-Мрт-11, 19:15
	Какраз о том что самоподписанный сертификат небезопасен, но их используют ;)
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	48. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	+/–
	Сообщение от User294 (ok) on 25-Мрт-11, 00:25
	> Предлагается что OCSP серверов будет несколько, все сразу не помрут. Угу, с ауторитями что-то тоже предполагалось. Что они не будут помирать, что подписывать будут не что попало и не кому попало, etc. > Тут другая проблема, до тех пор пока ключики будут изначально > распространяться по открытому каналу и самоподписываться дыра будет оставаться. Погодите, так если канал УЖЕ защищен и мы уверены в том что он именно с тем кем надо, тогда на кой черт нам еще раз проверять то что мы уже и так установили? Гарантии будут не сильнее чем гарантии по поводу шифрования исходного канала и уверенности в том что он - именно с тем с кем надо был установлен. Потому что если нас обманут на этой фазе - обманут по цепочке и на всех остальных, впарив левый сертификат, с левой инфо о том как его проверяить и прочая, что логично :)
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	51. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	+/–
	Сообщение от Аноним (??) on 25-Мрт-11, 00:55
	> Угу, с ауторитями что-то тоже предполагалось. Ну както эту проблему всеравно надо решать. > Погодите, так если канал УЖЕ защищен... Теоретически можно не проверять, но практически в этом нельзя быть уверенным, сертификаты даже в штатном режиме могут отзываться и т.п, поэтому надо перепроверять. А вот дальше самое интересное, насколько это надо делать жестко ? С одной стороны не переборщить с гемороем, трафиком, диктатурой и т.п, а с другой - убрать возможности подлома. Задачи прямопротивоположные и ни одна не решается идеально.
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	54. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	+/–
	Сообщение от User294 (ok) on 25-Мрт-11, 07:38
	> а с другой - убрать возможности подлома. Задачи прямопротивоположные и ни > одна не решается идеально. Браузеры могли бы грузить в фоне блеклисты плохих сертификатов как блеклисты фишеров и при натыкании на сертификат из списка верещать в том же духе как при визите фишерского сайта, а дальше - ну оставить сильно сбоку возможность оверрайда, но по дефолту показывать страшилку, как с фишерами и даже позлее. При этом единоразовый срыв обновления БД плохих парней вообще ни на что особо не повлияет, но массовые факапы в случае реального взлома чьих-то привкеев будут предотвращены. ИМХО вполне разумный компромисс: и реалтаймного факапа не получается и информация о плохих парнях все-таки будет распостраняться.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	31. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	+1 +/–
	Сообщение от Frank (ok) on 24-Мрт-11, 18:58
	Не иди в кассу, там тебе фальшивок всучат монетчики под видом работников банка. Натуробмен наше всё!
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	58. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	+/–
	Сообщение от Michael Shigorin (ok) on 25-Мрт-11, 21:20
	> Натуробмен наше всё! А если всё-таки не всё, то тут ещё про bitcoin.org подсказывают.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	38. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	+/–
	Сообщение от iZEN (ok) on 24-Мрт-11, 22:05
	> А теперь прикинь, OCSP сервер взял да и умер. Ну, умирают вот > иногда сервера. Даже самые хорошие, белые и пушистые. И это что, > мне теперь по этому поводу без доступа в онлайн-банк чтоли остаться > из-за даунайма ПОСТОРОННЕГО сервера? OCSP сервер не может быть посторонним. Он является структурообразующим PKI, ведущим актуальный список скомпрометированных сертификатов. Клиентская программа на момент своего выпуска, как правило, уже имеет в своём составе хранилище доверенных сертификатов от тех сайтов, с которыми она должна работать по защищённому соединению. Но время идёт, сайты взламываются, подбираются пароли, узнаются секретные ключи владельцев защищённых сервисов. Когда это обнаруживается, центры сертификации (CA) отзывают сертификаты у взломанных сайтов и размещают списки потерявших валидность сертификатов на серверах OCSP (адреса серверов OCSP указываются в сертификатах, которые подписывает CA — по этим адресам клиентская программа определяет валидность сертификатов). Клиентская программа, чтобы быть в курсе последних событий по конкретному сертификату, должна сначала обратиться к его серверу OCSP,  чтобы проверить его валидность. Если сертификат отозван (заблокирован, нет возможности проверить подлинность и т.д.), то вычеркнуть его из хранилища доверенных сертификатов и не позволить пользователю работать с потерявшим доверие (скомпрометированным) сайтом. > Мля, тогда банкоматом пользоваться наверное вообще > не надо - там кардеры могли ридер привинтить в принципе. Поэтому > надо самому дуть в отделение и получать бабло в кассе и > никак иначе. К кассиру то ридер не привинтишь :) Именно! А лучше за новым подписанным CA сертификатом банка, а старый скомпрометированный сертификат уничтожить.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	47. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	+/–
	Сообщение от Аноним (??) on 25-Мрт-11, 00:18
	Это в идеале, а в реальности CA ломают, сертификаты подписывают сами, вовремя не проверяют, протокол позволяет вольности, клиенты не реагируют должным образом и т.п.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	53. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	+/–
	Сообщение от User294 (ok) on 25-Мрт-11, 07:32
	> OCSP сервер не может быть посторонним. Есть я, клиент. Есть банк, сервер. Все остальные по определению посторонние. Чем их меньше, тем лучше. А если от этого зависит надежность - то и подавно. Я конечно понимаю что ты теорию вероятности проходил, очевидно, мимо. Однако чем больше в цепочке звеньев, тем вероятнее что она откажет в самый неподходящий момент. > Он является структурообразующим PKI, ведущим актуальный > список скомпрометированных сертификатов. Как по мне - я не имею ничего против получения блеклиста изредка (типа как файрфокс синхронизирует с гуглом БД фишинговых сайтов), но я против если каждая транзакция начнет требовать лишнего дергания постороннего сервера. Который хрен бы его знает как будет работать и прочая. > Клиентская программа на момент своего выпуска, как правило, уже имеет в своём > составе хранилище доверенных сертификатов от тех сайтов, с которыми она должна > работать по защищённому соединению. Чего? Кого? Какая нахрен программа? Нормальные люди работают по обычному SSL, обычным домашним хомякам иметь мозг авторизацией по сертификату - это как минимум достаточно негуманно. Ну как максимум - клиентский сертификат, как у вебманей в кипер лайт. Что-то сложнее сорвет крышу и сократит число юзеров в разы. Онлайн проверка сертификата - и здорово тормозит, и снижает надежность. Ты уж извини, но верисайн например по моим сведениям умудряется лажать даже на сервисах подписывания кода и прочая, они тупо оказываются в дауне иногда по той или иной причине. И да, если я могу уповать на то что между мной и местным сайтом банка довольно короткий маршрут с небольшим числом хопов и потому более-менее надежный, то вот уповать на какой-то сервер за парой океанов в США, подключеный через гирлянду из нескольких десятков роутеров - мне как-то совсем не улыбается. Ведь если какие-нить гребаные рыболовы нечаянно порвут межконтинентальную оптику - я не смогу использовать мои бабки. А мне это надо??? > Но время идёт, сайты взламываются, подбираются пароли, узнаются секретные > ключи владельцев защищённых сервисов. Я что-то так подозреваю что если банк настолько поломали что умыкнули аж приватный ключ, мне уже мало поможет отзыв их сертификата, т.к. у хаксоров и так есть доступ в самое сердце банковских систем в наиболее защищенные области. Они, извини, просто сделают транзакции которые им были нужны, да и все дела. А что им помешает то, если они настолько все расхреначили что у них аж ключи есть? > Когда это обнаруживается, центры сертификации (CA) отзывают сертификаты > у взломанных сайтов Оно, конечно, логично, но... - Оно в таком виде сильно тормозит конект. - Оно в таком виде снижает надежность. - Оно в таком виде дает возможность реалтаймного саботажа в меру дури ауторити. - ДДОС данных серверов или создание высокого траффика где-то на путях ведущих к ним вызовет огромную пачку лулзов, поэтому толпа хаксоров ессно выстроится в очередь. Не говоря уж о том что толпы юзерей сами будут их долбить запросами. Не, я понимаю что нагибон "анонимусами" платежных систем которые плохо себя ведут - заслуженный, но это не значит что я хочу чтобы мои транзакции тоже обломались просто потому что "анонимусам" приспичило надрать зад и им очень кстати предоставили очередной single point of failure :) > и размещают списки потерявших валидность сертификатов > на серверах OCSP (адреса серверов OCSP указываются в сертификатах, > которые подписывает CA — по этим адресам клиентская программа определяет > валидность сертификатов). Мне кажется тупой идея на ходу соваться на сервера. Умнее было бы 1) Помнить с какими сертификатами работали и проверять не изменились ли они. Досканально проверять новые и 1 раз - можно, как и верещать что почему-то сертификат стал не тем (возможно MITM на проводе). 2) Качать в фоне блеклисты типа того как сделано с БД фишеров. Откровенно наглые и долговременные взломы таким макаром будут довольно эффективно срублены. Ессно это я про нормальные браузеры и онлайн-банки говорю, а не про очередные высеры кульпрограмеров, которые пыжатся изобразить в своих какашках то что уже сто лет есть в SSL, только браузер то протестит 100500 миллионов хомячков, а вот их какашку - намного меньше юзеров, поэтому там могут быть воистину идиотские баги. > валидность. Если сертификат отозван (заблокирован, нет возможности проверить подлинность > и т.д.), то вычеркнуть его из хранилища доверенных сертификатов и не > позволить пользователю работать с потерявшим доверие (скомпрометированным) сайтом. Замечательно. А теперь посмотрим на обратную сторону медали? Вот есть у нас конкурент. Мы очень хотим ему насолить. Достаточно просто уронить его канал на некоторое время когда он соберется юзать онлайн-банк, заддосить OCSP сервера или роутеры по пути к ним или (если MITM) - убить сильно некоторые пакеты (малозаметно, а потом уже поздно пить боржоми будет). И вот конкурент уже сам себе вынесет сертификаты как невозможные к проверке. И сам же создаст себе прорву геморроя на ровном месте. На ровном месте обув себя на *валидные* сертификаты и поимев массу гемора по этому поводу. В результате можно несложными и недорогими действиями сорвать конкуренту транзакции на значительный срок и вообще вызвать у него кипишь. При этом конкурент и его банк ничего особо с этим сделать не смогут. Ну в общем хаксорам будет где развернуться - как говорится, "failure is not an option, it's default in each Windows version". :) >> Мля, тогда банкоматом пользоваться наверное вообще >> не надо - там кардеры могли ридер привинтить в принципе. Поэтому >> надо самому дуть в отделение и получать бабло в кассе и >> никак иначе. К кассиру то ридер не привинтишь :) > Именно! Что - именно? Мне теперь каждый раз чтобы получить 100 рублей убивать полдня на визит в банк? А не пойти ли тебе нафиг, а? Секурити - это хорошо. Если от нее геморрой у хакеров а не у легитимных клиентов. Иначе это не секурити а обычное нагибание клиентов, пардон. Ну да, совкобанки очень любят ИБД и имитацию секурности путем задрюкивания процедур. При том обычно по факту почему-то секурити оказывается весьма хилой, а вот геморроя у клиентов оказывается много. > А лучше за новым подписанным CA сертификатом банка, а старый скомпрометированный > сертификат уничтожить. Угу. Прикольный метод факапа конкурентов получается: можно довольно тривиальными и дешевыми действиями надолго срубить конкуренту онлайн банкинг, ведь по дефолту оно уже нацелено на его пятку, достаточно чтобы хоть что-то пошло не так и конкурент сам же себе и прострелит пятку, ха-ха :))). Лично мне с учетом потерь пакетов кажется довольно ссыкотной идея отзывать сертификаты просто потому что пакеты до OCSP сервера не долетели. Могу себе представить продвинутости типа атак на вайфай когда хоть и не видно что происходит из-за шифрования, зато обнаружен типовой паттерн пакетов по времени, похожий на процедуру OCSP. Тогда просто засираем эфир в нужное время, и ... :). Ну а при первом же дауне какогонить крупного магистрального роутера - резко выстроится большая очередь за новыми сертификатами. Прикольно :)
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	56. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	+/–
	Сообщение от iZEN (ok) on 25-Мрт-11, 18:06
	>> OCSP сервер не может быть посторонним. > Есть я, клиент. Есть банк, сервер. Все остальные по определению посторонние. Чем > их меньше, тем лучше. А если от этого зависит надежность - то и подавно. Почитай, что ли, об SSL-сертификатах и на чём держится протокол HTTPS. OCSP-сервер является важным дополнительным средством подтверждения подлинности сертификата и его срока действия, что увеличивает защищённость транзакций, но никак не уменьшает. > Я конечно понимаю что ты теорию вероятности проходил, очевидно, мимо. Теорвер я проходил в СУЗе и в ВУЗе, не беспокойся за меня. > Однако чем больше в цепочке звеньев, тем вероятнее что она откажет в самый неподходящий момент. Угу. Вот только роутеры на пути следования зашифрованного сообщения НЕ_ВХОДЯТ в эту цепочку и по умолчанию считаются незащищёнными. ;) >> Он является структурообразующим PKI, ведущим актуальный список скомпрометированных сертификатов. > но я против если каждая транзакция начнет требовать лишнего дергания постороннего сервера. Он не сторонний. Он — доверенный CA. > Который хрен бы его знает как будет работать и прочая. Вот если "хрензнаткак_он_работает", значит стоит обратить внимание на культуру обслуживания клиентов в этой организации. Бардак начинается с малого. >> Клиентская программа на момент своего выпуска, как правило, уже имеет в своём >> составе хранилище доверенных сертификатов от тех сайтов, с которыми она должна >> работать по защищённому соединению. > Чего? Кого? Какая нахрен программа? Нормальные люди работают по обычному SSL, обычным > домашним хомякам иметь мозг авторизацией по сертификату - это как минимум > достаточно негуманно. Ни один сайт, поддерживающий HTTPS для организации защищённого соединения, не станет работать с клиентской программой, не поддерживающей работу с SSL/TLS-сертификатами. > Ну как максимум - клиентский сертификат, как у вебманей > в кипер лайт. Что-то сложнее сорвет крышу и сократит число юзеров > в разы. В схеме интернет-банкинга между физическим и юр.лицом используются только сертификаты банка, предъявляемые клиенту и заверенные подписями тех CA, сертификаты которых уже установлены в пользовательском ПО. > Онлайн проверка сертификата - и здорово тормозит, и снижает надежность. Откуда ты это выдумал? > Ты уж извини, но верисайн например по моим сведениям умудряется > лажать даже на сервисах подписывания кода и прочая, они тупо оказываются > в дауне иногда по той или иной причине. Причём тут Верисайт? Сертификаты Верисайта включены в поставку защищённых программно-аппаратных платформ и считаются корневыми сертификатами, которые не нуждаются в дополнительной проверке, поскольку не имеют вышестоящего CA. Загляни в хранилище сертификатов своего сотового телефона, убедись в наличии ряда сертификатов и сроках их действия. > И да, если > я могу уповать на то что между мной и местным сайтом > банка довольно короткий маршрут с небольшим числом хопов и потому более-менее > надежный, то вот уповать на какой-то сервер за парой океанов в > США, Роутеры на пути следования защищённого сообщения не являются членами доверенной цепочки обслуживания соединения. Про "тунеллирвоание" в незащищённой среде что-нибудь слышал? > Я что-то так подозреваю что если банк настолько поломали что умыкнули аж > приватный ключ, мне уже мало поможет отзыв их сертификата, т.к. у > хаксоров и так есть доступ в самое сердце банковских систем в > наиболее защищенные области. У банков идёт внутреннее разделение служб, обслуживающих счета пользователей и сосбственные счета. Компрометация сертификата, используемого для Web-транзакций, всего лишь — компрометация сертификата и ничего сверх того. >> Когда это обнаруживается, центры сертификации (CA) отзывают сертификаты >> у взломанных сайтов > Оно, конечно, логично, но... > - Оно в таком виде сильно тормозит конект. Почему? > - Оно в таком виде снижает надежность. С чего бы вдруг? > - Оно в таком виде дает возможность реалтаймного саботажа в меру дури ауторити. Не менее, как и тот же пользовательский сайт. > - ДДОС данных серверов или создание высокого траффика где-то на путях ведущих > к ним вызовет огромную пачку лулзов, поэтому толпа хаксоров ессно выстроится > в очередь. Не менее, как и тот же пользовательский сайт. > Не говоря уж о том что толпы юзерей сами > будут их долбить запросами. Не, я понимаю что нагибон "анонимусами" платежных > систем которые плохо себя ведут - заслуженный, но это не значит > что я хочу чтобы мои транзакции тоже обломались просто потому что > "анонимусам" приспичило надрать зад и им очень кстати предоставили очередной single > point of failure :) Это НЕ техническая проблема. > Мне кажется тупой идея на ходу соваться на сервера. Умнее было бы > 1) Помнить с какими сертификатами работали и проверять не изменились ли они. > Досканально проверять новые и 1 раз - можно, как и верещать > что почему-то сертификат стал не тем (возможно MITM на проводе). > 2) Качать в фоне блеклисты типа того как сделано с БД фишеров. > Откровенно наглые и долговременные взломы таким макаром будут довольно эффективно срублены. Ты описал DRM во все поля. ;) >> валидность. Если сертификат отозван (заблокирован, нет возможности проверить подлинность >> и т.д.), то вычеркнуть его из хранилища доверенных сертификатов и не >> позволить пользователю работать с потерявшим доверие (скомпрометированным) сайтом. > Замечательно. А теперь посмотрим на обратную сторону медали? Вот есть у нас > конкурент. Мы очень хотим ему насолить. Достаточно просто уронить его канал > на некоторое время когда он соберется юзать онлайн-банк, заддосить OCSP сервера > или роутеры по пути к ним или (если MITM) - убить > сильно некоторые пакеты (малозаметно, а потом уже поздно пить боржоми будет). Это НЕ техническая проблема. DDoS-атаки выявляются и преследуются по закону.
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	59. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	+/–
	Сообщение от User294 (ok) on 25-Мрт-11, 22:27
	> Почитай, что ли, об SSL-сертификатах и на чём держится протокол HTTPS. Я в курсе на чем он держится, спасибо. OCSP не является обязательной частью. А ты предлагаешь аж прибивать сертификаты если он не сработает. Спасибо, елки. Этак любой даунтайм сетевого оборудования будет вызывать столпотворения в банках. > OCSP-сервер является важным дополнительным средством подтверждения подлинности сертификата По-моему, фичу блеклиста можно сделать и менее через анус. Например как БД плохих парней у мозиллы, так что единичный неконект к серверу вообше ничего не даст кроме возможно устаревания БД плохих парней на некий не сильно большой срок. А вот если банковская транзакция сорвется только потому что по OCSP не смогли достукаться до сервера - это будет не прикольно. Частота отказов вырастет в РАЗЫ, если это будет поводом не проводить транзакцию вообще. > и его срока действия, что увеличивает защищённость транзакций, но никак не > уменьшает. Все хорошо в меру. А то так можно дойти до того что тебя (для защиты, разумеется) нужно посадить в основательно укрепленное здание. И надзирателей приставить. Ну так, для защиты, ну и чтобы ты не сбежал по глупости своей, не поняв своего счастья. Правда вот когда защита начинает мешать достигать целей, мы почему-то начинаем называть укрепленное здание ... тюрьмой. Странно. > Теорвер я проходил в СУЗе и в ВУЗе, не беспокойся за меня. Мимо ты его проходил, судя по всему.   > Угу. Вот только роутеры на пути следования зашифрованного сообщения НЕ_ВХОДЯТ в эту > цепочку и по умолчанию считаются незащищёнными. ;) Что значит "не входят?" Пакеты передаются до OCSP сервера методом телепатии чтоли? oO  А то если сбойнет роутер по пути - очевилно, пакеты доставлены не будут и соединиться с OCSP сервером я не смогу. Если это будет поводом убить сертификат, как ты предлагал - я, очевдно, на раз лишусь сертификата по причине всего лишь отваливания роутера. Достаточно частого явления в интернете в общем то. > Он не сторонний. Он — доверенный CA. Да хоть лысый черт. Это третья сторона между мной и банком, не являющаяся участником операции. Поэтому для меня и банка он сторонний, как ни крути. > Вот если "хрензнаткак_он_работает", значит стоит обратить внимание > на культуру обслуживания клиентов в этой организации. Бардак начинается с малого. Так иди и построй всех провов на планете Земля чтобы у них роутеры не падали. А то только вчера наблюдал дивный трейсроут где-то в европе, когда парочка роутеров устраивала между собой пинг-понг до посинения моими пакетами вплоть до истечения ТТЛ :). Если бы эти красавцы были по пути к OCSP серверу а софт писал бы ты - я бы уже лишился сертификата и двигал бы в банк, да? Всю жизнь мечтал убить полдня только потому что роутер где-то упал, мля :) > Ни один сайт, поддерживающий HTTPS для организации защищённого соединения, не станет работать > с клиентской программой, не поддерживающей работу с SSL/TLS-сертификатами. Кэп, вы ли это? :))) > установлены в пользовательском ПО. Не, ты сегодня определенно решил заделаться в капитаны, да?! >> Онлайн проверка сертификата - и здорово тормозит, и снижает надежность. > Откуда ты это выдумал? Теорвер подсказал. Ну и практика работы с разными системами. Включая достаточно сложные и многостадийные. Чем больше звеньев - тем чаще загибается. Так что теорвер отлично согласуется с тем что на практике. Предпочитаю чтобы теорвер на меня работал, а не против меня. > Причём тут Верисайт? Как пример ауторити, предоставляюшей некие, достаточно критичные (для тех кто ими пользуется) в общем то сервисы. Всего лишь. > платформ и считаются корневыми сертификатами, которые не нуждаются в дополнительной проверке, [...] Кэп, ну ты уже перелогинься чтоли? Или расскажи что дважды два - четыре, например? :) >> надежный, то вот уповать на какой-то сервер за парой океанов в США, > Роутеры на пути следования защищённого сообщения не являются членами доверенной цепочки > обслуживания соединения. Про "тунеллирвоание" в незащищённой среде что-нибудь слышал? Я слышал про теорию вероятности, роутинг и здравый смысл. Они мне говорят что если по пути к OCSP серверу нагнется роутер, протокольные пакеты не смогут доставиться. И я получу волшебную фигу вместо конекта к OCSP серверу. И как-то не прикольно по этому поводу обламываться то. Если я еще могу надеяться на то что прововский DNS близко, и банковский сервак не так уж далеко, то вот про OCSP этого не скажешь. А т.к. ты предлагаешь все обломать и даже убить сертификат - мне несложно представить столпотворение в банке после отвала любого крупного магистрального роутера, из-за которого толпа хомяков не смогла проверить серт по OCSP :))) > У банков идёт внутреннее разделение служб, обслуживающих счета пользователей и сосбственные > счета. Можно подумать, хакерам большая разница с каких счетов бабла потырить. Потырят с тех к которым доступ получили, прикинь? :))) > Компрометация сертификата, используемого для Web-транзакций, всего лишь — > компрометация сертификата и ничего сверх того. Как-то слишком оптимистично. Как минимум хаксоры смогут делать что угодно от лица якобы сервера. Которому по идее доверять полагается, хе-хе :). Доверять хаксорам - неплохо придумано. Может им сразу еще и кошелек отдать, доверив управление бабками в более простой и доступной форме? :) >> - Оно в таком виде сильно тормозит конект. > Почему? Потому что плюсуется время на обмен с OCSP сервером, ессно. Если ты хочешь выносить решение на основании этого обмена - тебе придется дождаться его окончания. Я тоже Кэп, ага :) >> - Оно в таком виде снижает надежность. > С чего бы вдруг? С того что в игру вступает уйма лишних узлов. OCSP сервер. DNS оного. Роутеры по пути к им обоим. И т.п.. Если что-то из этого облажается - ну мы не сконектимся к OCSP серверу тогда. И по твоей логике должны убить сертификат. Ох и часто они будут убиваться, имхо. Очереди в банках определенно возрастут за счет тех кто будет получать сертификаты при любом дауне роутеров и прочая :))) >> - Оно в таком виде дает возможность реалтаймного саботажа в меру дури ауторити. > Не менее, как и тот же пользовательский сайт. Опять же - возвращаясь к теории вероятности, одна точка возможного отказа лучше чем две точки возможного отказа. По факту точек отказа намного больше ибо есть еще DNS-сервера, роутеры по пути, етц - 100500 разных узлов. Их и так то немало, а станет еще в разы больше. > Не менее, как и тот же пользовательский сайт. Сайт банка обычно стараются разместить близко к юзеру и скажем русскоязычный сайт не ставит себе целью обслужить всю планету. А OCSP-серверу придется обслуживать имено всю планету. Не, конечно можно их везде наставить но тогда их надежность снизится т.к. возрастет риск взлома, а во вторых, не очень понятно кто это будет оплачивать. Банк с неуспеха моей транзакции имеет вагон проблем - я им долго полоскаю мозг, они несут затраты на саппорт и разбирательства. Обладатель OCSP сервера - никаких убытков не несет. Завалил транзакцию? Да и черт и с ним! Это у банка и у юзера проблемы, мля. >> point of failure :) > Это НЕ техническая проблема. Угу, а какая? Политическая чтоли? Лишние точки отказа - вполне себе технические проблемы. > Ты описал DRM во все поля. ;) При чем тут DRM? Я описал обычный антифишинговый фильтр как в файрфоксе. Не вижу чьи права он ограничивает.   > Это НЕ техническая проблема. DDoS-атаки выявляются и преследуются по закону. Ну да, когда тебе на сервак со всей планеты валится крап - конечно же сразу становится понятно кого надо преследовать. Наверное те легионы ботов которые трафф валят. Правда, они про это даже не в курсе что их компы срут, а к сожалению, за тупость и ненадлежащее содержание компьтерных систем почему-то не сажают. Поэтому судебные перспективы выглядят довольно сомнительно (кроме случая когда ты адвокт и хочешь срубить бабла, не важно с какой из сторон :D). А организаторы ддосов кроме случаев совсем уж клинического даунизма обычно забывают оставить свой адрес для упрощения поимки. Поэтому пойманых почему-то сильно меньше чем количество ддос-атак.
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	60. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	+/–
	Сообщение от iZEN (ok) on 26-Мрт-11, 01:12
	>> OCSP-сервер является важным дополнительным средством подтверждения подлинности сертификата > По-моему, фичу блеклиста можно сделать и менее через анус. У Mozilla это делается перевыпуском версии браузера, в которой обновляется хранилище сертификатов CA. Либо включением обязательно проверки актуальности сертификатов в настройках устаревшей версии браузера, как я написал. > А вот если банковская транзакция сорвется только потому что по OCSP не смогли достукаться до сервера - это будет не прикольно. > Частота отказов вырастет в РАЗЫ, если это будет поводом не проводить транзакцию вообще. Ещё один повод банку задуматься о поддержке инфраструктуры защищённых транзакций. С ломаемой, не выдерживающей натиска инфраструктурой никто связываться не захочет, с банком её имеющей — тем более! > А то если сбойнет роутер по пути - очевилно, > пакеты доставлены не будут и соединиться с OCSP сервером я не > смогу. Если это будет поводом убить сертификат, как ты предлагал - > я, очевдно, на раз лишусь сертификата по причине всего лишь отваливания > роутера. Достаточно частого явления в интернете в общем то. Я не предлагал убивать сертификат. Если программа не может подтвердить легитимность сертификата ни по блэклисту, ни при связи с OCSP-сервером, то она не должна давать пользователю права совершать транзакцию с "сертифицированным" сайтом, так как защищённость соединения под сомнением. Нужно обязательно выяснить, можно всё ещё доверять сайту или уже нельзя, а как это делается (автоматизированно или звонком в банк) — решать пользователю.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	61. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	+/–
	Сообщение от Аноним (??) on 26-Мрт-11, 12:58
	> Если программа не может подтвердить легитимность сертификата то она не должна давать пользователю права совершать транзакцию Ну так вот и получается, если сторонний OCSP сервер оказался в дауне по внутренним причинам, задосили, скомпроментировали, роутер сбойнул, и т.п, то наша организация сразу атакуется толпой хомяков, теряет клиентов, а потом этой толпой атакуется OCSP сервер, если поднимется. Представьте что по этому принципу начнет работать не ноль целых хренадцать десятых, а большая часть сайтов. Далеко не всегда как вы говорите возможно организовать соответствующую архитектуру, а терять клиентов никому не хочется, по этому и сделали возможность отложенной проверки, а она повлекла возможность подлома.
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

52. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	+1 +/–
Сообщение от StrangeAttractor (ok) on 25-Мрт-11, 01:31
> занесены в черные списки web-браузеров Firefox, Chrome/Chromium и Internet Explorer. А Opera? Я вот только сегодня товарищу, пользователю Opera, комп чистил от какой-то гадости, забившей в hosts на свой айпишник (к сожалению не подумал сохранить) все варианты Gmail и Yahoo и поднявшей на локалхосте прокси и перенаправившей браузеры через него.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

65. "Взлом аккаунта в удостоверяющем центре Comodo привёл к генер..."	+/–
Сообщение от Аноним (??) on 01-Май-11, 18:25
Статья подготовленна оперативно, но непрофессионально. Причем здесь перекрестная сертификация? Для её акуализации нужны аргументы весомее, чем нарушения элементарных политик безопасности центрами сертификации. Метод, которым получены эти отозванные сертификаты получены другим способом, а не тем, который описан Вами. Потому у поддельников нет шансов "вломать" таким же способом и корневые ЦС. А критика в адрес политики "Комодо" уже давно существует, только они ничего слушать не хотят, пока гром не грянет.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема