Перейти к содержимому
Калькуляторы

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

 

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

 

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

 

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

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

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

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

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

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

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

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

 

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

48 minutes ago, alibek said:

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

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

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

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

image.thumb.png.dd63a2b90167aca05094a926d9a9a8a8.png

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

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

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.