Jump to content
Калькуляторы

Применимость самоподписанных сертификатов

Не нужно смешивать в кучу транспорт и прикладные данные.

Клиентский сертификат менее гибок и удобен. Например у токена может быть срок действия или контекст.

Клиентский сертификат как инструмент авторизации даже корпоративных информационных системах применяют далеко не так часто — как раз из-за того, что он недостаточно удобен.

Share this post


Link to post
Share on other sites

@Sergey Gilfanov вот как вы не зная пароль сможете заслать фейковый колбэк? 

ну т.е. банк проверяет что клиент это клиент по https, а клиент банк проверяет по паролю, переданному по шифрованному каналу. ничего страшного здесь не видно

Share this post


Link to post
Share on other sites

10 минут назад, s.lobanov сказал:

вот как вы не зная пароль сможете заслать фейковый колбэк?

Пароль он же shared secret украдут именно у того, кто callback ждет (а хранить его надежно - достаточно сложная проблема. Тогда как публичный ключ своего CA для проверки клиентского сертификата можно в открытом виде держать.). И потом этот самый фейковый callback и сформируют.

Share this post


Link to post
Share on other sites

4 часа назад, alibek сказал:

Можно сделать сертификат с таким же CN и прочими атрибутами, но его нельзя будет подписать моим ключом. 

А Яндексу или Сбербанку вы свой ключ отправляли? Заверяли? Понятно что можно (сам когда-то бумажку с паблик ключом подписывал), но обычно никто этим не заморачивается.

Share this post


Link to post
Share on other sites

Если не ошибаюсь, то Сбербанк не проверяет сертификат, а с Яндексом достаточно было устного согласования — но точно не помню, это давно делалось.

Share this post


Link to post
Share on other sites

37 минут назад, alibek сказал:

Если не ошибаюсь, то Сбербанк не проверяет сертификат

Проверяет. Идет дядя/тетя, тузой запрашивает серт с сервера, заносит себе в софт/реестр. Вобщем, минут от 40 на круг по замене (как-то незаметно у нас раз у самоподписанного пятилетняя подпись стухла... :-). 

 

Share this post


Link to post
Share on other sites

А вот яндекс, правда совсем другое подразделение, даже для теста отказался принимать наш ЦА или просто игнорить... (на продакшне был честно купленный, но покупать еще и на тест что то  как то неправильно, свой ЦА есть и активно используется внутри)

Share this post


Link to post
Share on other sites

16 минут назад, st_re сказал:

А вот яндекс, правда совсем другое подразделение, даже для теста отказался принимать наш ЦА или просто игнорить...

Вообще говоря, и правильно делает. Т.к. в большинстве случаев добавление такого в список доверенных означает, что этот ЦА (или тот, кто из него ключ сопрет) сможет выпустить сертификат на сервера самого Яндекса и вообще кого попало. А ограничивать применимость  - это не всегда тривиально.

Share this post


Link to post
Share on other sites

30 минут назад, Sergey Gilfanov сказал:

Вообще говоря, и правильно делает. Т.к. в большинстве случаев добавление такого в список доверенных означает, что этот ЦА (или тот, кто из него ключ сопрет) сможет выпустить сертификат на сервера самого Яндекса и вообще кого попало. А ограничивать применимость  - это не всегда тривиально.

Ну вот, а деньги значит можно... :/

Share this post


Link to post
Share on other sites

1 час назад, Sergey Gilfanov сказал:

Т.к. в большинстве случаев добавление такого в список доверенных означает, что этот ЦА (или тот, кто из него ключ сопрет) сможет выпустить сертификат на сервера самого Яндекса и вообще кого попало.

А практический кейс какой? Сотрудники Яндекса загрузили сертификат приватного CA не в конкретное приложение и даже не в системное хранилище на конкретном сервере, а во все свои сервера и репозиторий Яндекс.Браузера?

Share this post


Link to post
Share on other sites

@alibek ну смотрите. вы даёте яндексу свой CA, допустим они ему доверяют, далее вы делаете bgp hijacking IP-адресов с кем ещё работает система и спокойно получаете чужие колбэки (т.к. вы сможете подписать ответ)

 

если уж доверять самоподписке, то не CA, а конкретному сертификату на конкретное доменное имя

Share this post


Link to post
Share on other sites

27 минут назад, s.lobanov сказал:

допустим они ему доверяют

Они же ему не во всем Яндексе доверяют.

По правильному они ему доверяют только в сервисе, ответственном за callback.

Если не совсем по правильному, то доверяют в операционной системе, на которой функционирует сервис.

Иные альтернативы я просто не могу себе представить.

Share this post


Link to post
Share on other sites

1 минуту назад, alibek сказал:

Они же ему не во всем Яндексе доверяют.

По правильному они ему доверяют только в сервисе, ответственном за callback.

Если не совсем по правильному, то доверяют в операционной системе, на которой функционирует сервис.

Иные альтернативы я просто не могу себе представить.

так а я и написал, что доверяет в рамках системы (т.е. сервиса), т.е. системы которая шлёт колбэки

Share this post


Link to post
Share on other sites

32 минуты назад, s.lobanov сказал:

далее вы делаете bgp hijacking IP-адресов

Ну это уже допущение уровня "ставим прокси перед фронтендом и пропускаем все через себя".

Share this post


Link to post
Share on other sites

@alibek это не допущение, а суровая реальность. в настоящий момент нет на 100% эффективных механизмов борьбы с hijacking. для финансового сектора это особо актуально (не так давно обокрали какой-то сервис для криптовалют через hijacking)

Share this post


Link to post
Share on other sites

Только что, s.lobanov сказал:

так а я и написал, что доверяет в рамках системы (т.е. сервиса)

Кроме того, я конечно не знаю, как все сделано в Яндексе, но я не вижу никакой проблемы в том, чтобы получить текущие отпечатки (сертификата сервера или CA) и сравнить их с эталонными.

Когда я делал самописную ИС для ФСБ с использованием клиентских сертификатов для авторизации, то первым делом убедился, что подобным образом нельзя подсунуть сертификат от постороннего CA. Не думаю, что в Яндексе люди глупее.

 

3 минуты назад, s.lobanov сказал:

не так давно обокрали какой-то сервис для криптовалют через hijacking

А подробности есть?

Просто когда я слышу про взломы в определенных сферах, то я предполагаю, что скорее всего взлом был основан не на технической реализации, а на социальной инженерии. Обычно уязвимость бывает в людях, а не в алгоритмах.

Share this post


Link to post
Share on other sites

@alibek я и говорю, можно доверять не всему CA, а конкретному сертификату, тогда воровство ip-адресов не поможет. вопрос - яндексу это надо? вот согласитесь, что это по-любому модификация системы (доработка для работы со всякими самопальными CA, скорее всего какие-то изменения в коде или в опредлениях способах деплоя). а в нормальных компаниях любая модификация это тестирование, включение это в план и т.д. и т.п. Это вам не операторы, которые зашли на сервер и через mc поправили конфиг - никто в здравом уме так не делает

Share this post


Link to post
Share on other sites

2 минуты назад, s.lobanov сказал:

вот согласитесь, что это по-любому модификация системы (доработка для работы со всякими самопальными CA, скорее всего какие-то изменения в коде или в опредлениях способах деплоя)

В принципе я ответ на свой вопрос получил еще тут.

Вполне приемлемые аргументы, которые мне понятны.

Если бы другой сервис их привел мне, то этого мне было бы достаточно; я либо сделал бы бесплатный публичный сертификат, либо забыл бы про callback и использовал периодический опрос (как у меня сделано сейчас).

Просто мне другой сервис рассказывал про какую-то ерунду, что так делать вообще нельзя и что самописный сертификат полностью скомпрометирует HTTPS.

 

Сейчас я спорить с этим не буду, просто замечу, что для прямого взаимодействия между двумя системами (то есть точка-точка, а не точка-многоточка) публичный сертификат вовсе необязателен и ограничения к его применению не технические, а организационные.

 

Что касается этого:

9 минут назад, s.lobanov сказал:

это по-любому модификация системы

то не соглашусь — это необязательно модификация системы.

Подобное может быть предусмотрено архитектурно, например в Киви.

Как устроено в Яндексе — полагаю, что этого точно присутствующие в топике тоже не знают.

Может быть там тоже архитектурно предусмотрено, что у каждого клиента/партнера может быть свой сертификат и CA.

Share this post


Link to post
Share on other sites

10 часов назад, alibek сказал:

Хотелось бы узнать мнение общественности, когда и где применимы самоподписанные сертификаты. 

Для генерации корневого сертификата. Все корневые сертификаты самоподписанные.

 

10 часов назад, alibek сказал:

И оказалось, что новый сервис проверяет цепочку доверия сертификатов и самоподписанные сертификаты естественно отклоняет.

Он отклоняет цепочку с неизвестным CA.

 

Убедите, что ваш CA самый лучший, и рекомендован местным ФСБ для использования. А всякие там rsa и прочие sha - они плохие, за них на бутылку сажают. Там же.

Share this post


Link to post
Share on other sites

Почитал я всю ветку. Лень писать подробно. Простое решение в данном случае одно - letsencrypt. Если платежная система проверяет его по публичным CA, то больше не надо.

 

Лично мне за 20 лет таких платежных систем не попадалось. Ну, которые не хотят принимать клиентский CA, но хотят удостоверений по https сертификату. В большинстве случаев они свободно принимали собственный CA. Собственно говоря, им какое дело. Я представил платежной системе публичный ключ, которым подписываю сертификаты своего сайта, принимающего платежные уведомления. Да в общем-то, после появления LE, надобность в своем центре сертификации практически отпала, за исключением тех банков, которые хотят уведомлять с аутентификацией клиентским сертификатом.

 

Share this post


Link to post
Share on other sites

В 07.03.2019 в 15:57, alibek сказал:

Если не ошибаюсь, то Сбербанк не проверяет сертификат, а с Яндексом достаточно было устного согласования — но точно не помню, это давно делалось.

Если не проверяют, то примут любой ключ вместо вашего. Вот вам и MITM.

 

В 07.03.2019 в 16:37, snvoronkov сказал:

Проверяет. Идет дядя/тетя, тузой запрашивает серт с сервера, заносит себе в софт/реестр. Вобщем, минут от 40 на круг по замене (как-то незаметно у нас раз у самоподписанного пятилетняя подпись стухла... :-).  

 

Меняли серт на летсэнктипотовский, ничего не случилось.

Share this post


Link to post
Share on other sites

16 минут назад, ixi сказал:

Если не проверяют, то примут любой ключ вместо вашего. Вот вам и MITM.

Во-первых, тут одного постороннего ключа мало, нужно еще и трафик перехватить, подменить dns/ip.

Во-вторых, есть еще токен (shared secret), без которого даже при наличии корректного сертификата транзакция не будет принята. Правда конкретно у Сбербанка токена кажется нет.

В-третьих, тут отсутствует цель. Платежный шлюз только проверяет реквизиты транзакции и подтверждает или не подтверждает ее выполнение. Максимум что получится — это дезинформировать Сбербанк о том, что зачисление средств на указанный лицевой счет выполнено, хотя на самом деле оно не выполнено.

Share this post


Link to post
Share on other sites

Перехватить https, подсмотреть sharedKey и самому от имени сбербанка нафигачить "платежей" ?

Хотя я не знаю что там в обмене у сбера, нормальные платежные системы используют криптографическую подпись

Share this post


Link to post
Share on other sites

4 минуты назад, Heggi сказал:

Перехватить https

Чей? Сбербанк->Я или Я->Сбербанк?

 

5 минут назад, Heggi сказал:

подсмотреть sharedKey

Каким образом?

Он не передается в открытом виде, им подписываются запросы и ответы.

 

6 минут назад, Heggi сказал:

самому от имени сбербанка нафигачить "платежей" ?

Для этого нужно подменить сертификат Сбербанка, а не сертификат платежного шлюза.

Share this post


Link to post
Share on other sites

48 minutes ago, alibek said:

Для этого нужно подменить сертификат Сбербанка, а не сертификат платежного шлюза.

чота какая-то каша началась :) при колбэка сертификат сбербанка вообще нигде не проверяется.

"нафигачить платежей" - это как раз тот самый интерес злоумышленника.

эквайринг сбербанка, к примеру

image.thumb.png.dd63a2b90167aca05094a926d9a9a8a8.png

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.