alibek Опубликовано 7 марта, 2019 · Жалоба Не нужно смешивать в кучу транспорт и прикладные данные. Клиентский сертификат менее гибок и удобен. Например у токена может быть срок действия или контекст. Клиентский сертификат как инструмент авторизации даже корпоративных информационных системах применяют далеко не так часто — как раз из-за того, что он недостаточно удобен. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 7 марта, 2019 · Жалоба @Sergey Gilfanov вот как вы не зная пароль сможете заслать фейковый колбэк? ну т.е. банк проверяет что клиент это клиент по https, а клиент банк проверяет по паролю, переданному по шифрованному каналу. ничего страшного здесь не видно Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sergey Gilfanov Опубликовано 7 марта, 2019 · Жалоба 10 минут назад, s.lobanov сказал: вот как вы не зная пароль сможете заслать фейковый колбэк? Пароль он же shared secret украдут именно у того, кто callback ждет (а хранить его надежно - достаточно сложная проблема. Тогда как публичный ключ своего CA для проверки клиентского сертификата можно в открытом виде держать.). И потом этот самый фейковый callback и сформируют. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ixi Опубликовано 7 марта, 2019 · Жалоба 4 часа назад, alibek сказал: Можно сделать сертификат с таким же CN и прочими атрибутами, но его нельзя будет подписать моим ключом. А Яндексу или Сбербанку вы свой ключ отправляли? Заверяли? Понятно что можно (сам когда-то бумажку с паблик ключом подписывал), но обычно никто этим не заморачивается. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 7 марта, 2019 · Жалоба Если не ошибаюсь, то Сбербанк не проверяет сертификат, а с Яндексом достаточно было устного согласования — но точно не помню, это давно делалось. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
snvoronkov Опубликовано 7 марта, 2019 · Жалоба 37 минут назад, alibek сказал: Если не ошибаюсь, то Сбербанк не проверяет сертификат Проверяет. Идет дядя/тетя, тузой запрашивает серт с сервера, заносит себе в софт/реестр. Вобщем, минут от 40 на круг по замене (как-то незаметно у нас раз у самоподписанного пятилетняя подпись стухла... :-). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 7 марта, 2019 · Жалоба А вот яндекс, правда совсем другое подразделение, даже для теста отказался принимать наш ЦА или просто игнорить... (на продакшне был честно купленный, но покупать еще и на тест что то как то неправильно, свой ЦА есть и активно используется внутри) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sergey Gilfanov Опубликовано 7 марта, 2019 · Жалоба 16 минут назад, st_re сказал: А вот яндекс, правда совсем другое подразделение, даже для теста отказался принимать наш ЦА или просто игнорить... Вообще говоря, и правильно делает. Т.к. в большинстве случаев добавление такого в список доверенных означает, что этот ЦА (или тот, кто из него ключ сопрет) сможет выпустить сертификат на сервера самого Яндекса и вообще кого попало. А ограничивать применимость - это не всегда тривиально. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 7 марта, 2019 · Жалоба 30 минут назад, Sergey Gilfanov сказал: Вообще говоря, и правильно делает. Т.к. в большинстве случаев добавление такого в список доверенных означает, что этот ЦА (или тот, кто из него ключ сопрет) сможет выпустить сертификат на сервера самого Яндекса и вообще кого попало. А ограничивать применимость - это не всегда тривиально. Ну вот, а деньги значит можно... :/ Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 7 марта, 2019 · Жалоба 1 час назад, Sergey Gilfanov сказал: Т.к. в большинстве случаев добавление такого в список доверенных означает, что этот ЦА (или тот, кто из него ключ сопрет) сможет выпустить сертификат на сервера самого Яндекса и вообще кого попало. А практический кейс какой? Сотрудники Яндекса загрузили сертификат приватного CA не в конкретное приложение и даже не в системное хранилище на конкретном сервере, а во все свои сервера и репозиторий Яндекс.Браузера? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 7 марта, 2019 · Жалоба @alibek ну смотрите. вы даёте яндексу свой CA, допустим они ему доверяют, далее вы делаете bgp hijacking IP-адресов с кем ещё работает система и спокойно получаете чужие колбэки (т.к. вы сможете подписать ответ) если уж доверять самоподписке, то не CA, а конкретному сертификату на конкретное доменное имя Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 7 марта, 2019 · Жалоба 27 минут назад, s.lobanov сказал: допустим они ему доверяют Они же ему не во всем Яндексе доверяют. По правильному они ему доверяют только в сервисе, ответственном за callback. Если не совсем по правильному, то доверяют в операционной системе, на которой функционирует сервис. Иные альтернативы я просто не могу себе представить. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 7 марта, 2019 · Жалоба 1 минуту назад, alibek сказал: Они же ему не во всем Яндексе доверяют. По правильному они ему доверяют только в сервисе, ответственном за callback. Если не совсем по правильному, то доверяют в операционной системе, на которой функционирует сервис. Иные альтернативы я просто не могу себе представить. так а я и написал, что доверяет в рамках системы (т.е. сервиса), т.е. системы которая шлёт колбэки Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 7 марта, 2019 · Жалоба 32 минуты назад, s.lobanov сказал: далее вы делаете bgp hijacking IP-адресов Ну это уже допущение уровня "ставим прокси перед фронтендом и пропускаем все через себя". Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 7 марта, 2019 · Жалоба @alibek это не допущение, а суровая реальность. в настоящий момент нет на 100% эффективных механизмов борьбы с hijacking. для финансового сектора это особо актуально (не так давно обокрали какой-то сервис для криптовалют через hijacking) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 7 марта, 2019 · Жалоба Только что, s.lobanov сказал: так а я и написал, что доверяет в рамках системы (т.е. сервиса) Кроме того, я конечно не знаю, как все сделано в Яндексе, но я не вижу никакой проблемы в том, чтобы получить текущие отпечатки (сертификата сервера или CA) и сравнить их с эталонными. Когда я делал самописную ИС для ФСБ с использованием клиентских сертификатов для авторизации, то первым делом убедился, что подобным образом нельзя подсунуть сертификат от постороннего CA. Не думаю, что в Яндексе люди глупее. 3 минуты назад, s.lobanov сказал: не так давно обокрали какой-то сервис для криптовалют через hijacking А подробности есть? Просто когда я слышу про взломы в определенных сферах, то я предполагаю, что скорее всего взлом был основан не на технической реализации, а на социальной инженерии. Обычно уязвимость бывает в людях, а не в алгоритмах. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 7 марта, 2019 · Жалоба @alibek я и говорю, можно доверять не всему CA, а конкретному сертификату, тогда воровство ip-адресов не поможет. вопрос - яндексу это надо? вот согласитесь, что это по-любому модификация системы (доработка для работы со всякими самопальными CA, скорее всего какие-то изменения в коде или в опредлениях способах деплоя). а в нормальных компаниях любая модификация это тестирование, включение это в план и т.д. и т.п. Это вам не операторы, которые зашли на сервер и через mc поправили конфиг - никто в здравом уме так не делает Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 7 марта, 2019 · Жалоба 2 минуты назад, s.lobanov сказал: вот согласитесь, что это по-любому модификация системы (доработка для работы со всякими самопальными CA, скорее всего какие-то изменения в коде или в опредлениях способах деплоя) В принципе я ответ на свой вопрос получил еще тут. Вполне приемлемые аргументы, которые мне понятны. Если бы другой сервис их привел мне, то этого мне было бы достаточно; я либо сделал бы бесплатный публичный сертификат, либо забыл бы про callback и использовал периодический опрос (как у меня сделано сейчас). Просто мне другой сервис рассказывал про какую-то ерунду, что так делать вообще нельзя и что самописный сертификат полностью скомпрометирует HTTPS. Сейчас я спорить с этим не буду, просто замечу, что для прямого взаимодействия между двумя системами (то есть точка-точка, а не точка-многоточка) публичный сертификат вовсе необязателен и ограничения к его применению не технические, а организационные. Что касается этого: 9 минут назад, s.lobanov сказал: это по-любому модификация системы то не соглашусь — это необязательно модификация системы. Подобное может быть предусмотрено архитектурно, например в Киви. Как устроено в Яндексе — полагаю, что этого точно присутствующие в топике тоже не знают. Может быть там тоже архитектурно предусмотрено, что у каждого клиента/партнера может быть свой сертификат и CA. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
TheUser Опубликовано 7 марта, 2019 · Жалоба 10 часов назад, alibek сказал: Хотелось бы узнать мнение общественности, когда и где применимы самоподписанные сертификаты. Для генерации корневого сертификата. Все корневые сертификаты самоподписанные. 10 часов назад, alibek сказал: И оказалось, что новый сервис проверяет цепочку доверия сертификатов и самоподписанные сертификаты естественно отклоняет. Он отклоняет цепочку с неизвестным CA. Убедите, что ваш CA самый лучший, и рекомендован местным ФСБ для использования. А всякие там rsa и прочие sha - они плохие, за них на бутылку сажают. Там же. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vop Опубликовано 7 марта, 2019 · Жалоба Почитал я всю ветку. Лень писать подробно. Простое решение в данном случае одно - letsencrypt. Если платежная система проверяет его по публичным CA, то больше не надо. Лично мне за 20 лет таких платежных систем не попадалось. Ну, которые не хотят принимать клиентский CA, но хотят удостоверений по https сертификату. В большинстве случаев они свободно принимали собственный CA. Собственно говоря, им какое дело. Я представил платежной системе публичный ключ, которым подписываю сертификаты своего сайта, принимающего платежные уведомления. Да в общем-то, после появления LE, надобность в своем центре сертификации практически отпала, за исключением тех банков, которые хотят уведомлять с аутентификацией клиентским сертификатом. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ixi Опубликовано 11 марта, 2019 · Жалоба В 07.03.2019 в 15:57, alibek сказал: Если не ошибаюсь, то Сбербанк не проверяет сертификат, а с Яндексом достаточно было устного согласования — но точно не помню, это давно делалось. Если не проверяют, то примут любой ключ вместо вашего. Вот вам и MITM. В 07.03.2019 в 16:37, snvoronkov сказал: Проверяет. Идет дядя/тетя, тузой запрашивает серт с сервера, заносит себе в софт/реестр. Вобщем, минут от 40 на круг по замене (как-то незаметно у нас раз у самоподписанного пятилетняя подпись стухла... :-). Меняли серт на летсэнктипотовский, ничего не случилось. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 11 марта, 2019 · Жалоба 16 минут назад, ixi сказал: Если не проверяют, то примут любой ключ вместо вашего. Вот вам и MITM. Во-первых, тут одного постороннего ключа мало, нужно еще и трафик перехватить, подменить dns/ip. Во-вторых, есть еще токен (shared secret), без которого даже при наличии корректного сертификата транзакция не будет принята. Правда конкретно у Сбербанка токена кажется нет. В-третьих, тут отсутствует цель. Платежный шлюз только проверяет реквизиты транзакции и подтверждает или не подтверждает ее выполнение. Максимум что получится — это дезинформировать Сбербанк о том, что зачисление средств на указанный лицевой счет выполнено, хотя на самом деле оно не выполнено. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Heggi Опубликовано 11 марта, 2019 · Жалоба Перехватить https, подсмотреть sharedKey и самому от имени сбербанка нафигачить "платежей" ? Хотя я не знаю что там в обмене у сбера, нормальные платежные системы используют криптографическую подпись Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 11 марта, 2019 · Жалоба 4 минуты назад, Heggi сказал: Перехватить https Чей? Сбербанк->Я или Я->Сбербанк? 5 минут назад, Heggi сказал: подсмотреть sharedKey Каким образом? Он не передается в открытом виде, им подписываются запросы и ответы. 6 минут назад, Heggi сказал: самому от имени сбербанка нафигачить "платежей" ? Для этого нужно подменить сертификат Сбербанка, а не сертификат платежного шлюза. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kpv Опубликовано 11 марта, 2019 · Жалоба 48 minutes ago, alibek said: Для этого нужно подменить сертификат Сбербанка, а не сертификат платежного шлюза. чота какая-то каша началась :) при колбэка сертификат сбербанка вообще нигде не проверяется. "нафигачить платежей" - это как раз тот самый интерес злоумышленника. эквайринг сбербанка, к примеру Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...