>> 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-атаки выявляются и преследуются по закону.
