[alibek]

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

Есть у меня сервер исключительно для технологических нужд — платежный шлюз для работы с различными платежными системами. Общедоступность в нем не предусматривается, для каждой системы есть своя точка входа (веб-скрипт) со своими ACL.

Работает по HTTPS с использованием самоподписанного сертификата (если точнее, то сертификата, выпущенного собственным приватным CA).

С этим сертификатом даже у таких записных бюрократов, как в Яндексе или Сбербанке вопросов не возникало.

Но вот недавно добавлял новый сервис и некоторое время не мог разобраться, почему не срабатывают callback-вызовы на платежный шлюз.

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

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

Вот и хотелось бы знать, что об этом думают другие.

Сейчас от callback пришлось отказаться, вместо этого используется периодический опрос.

[Sergey Gilfanov]

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

Вот и хотелось бы знать, что об этом думают другие.

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

 

 

 

[kpv]

17 minutes ago, alibek said:

во-первых он стоит денег

есть бесплатный https://letsencrypt.org/ посадите его на любой новый поддомен и настройте на него каллбэк

[alibek]

9 минут назад, kpv сказал:

есть бесплатный https://letsencrypt.org/

Я про него знаю, но по-моему это намного хуже.

Во-первых, это как сервисная почта на mail.ru.

Во-вторых, у этих сертификатов есть ряд ограничений, которые меня не устраивают.

 

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

добавляет его в свой список доверенных и подписывает им сертификаты контрагентов.

Вот с этим у нового сервиса проблема.

По какой-то причине он не может это сделать.

[s.lobanov]

@alibek вот проблему раздули. делаете новый домен/поддомен, покупаете за 15-30$/2 года нормальный сертификат и просите сбер поменять колбэк

 

проблема в 15-30$ за 2 года?

[Sergey Gilfanov]

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

Вот с этим у нового сервиса проблема.

По какой-то причине он не может это сделать.

По описанию - не так. По описанию он не хочет доверять вашему внутреннему CA. В данном случае нужно, чтобы сертификат точки входа callback вызовов был подписан их CA.

[alibek]

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

покупаете за 15-30$/2 года нормальный сертификат

А что значит «нормальный»?

Сертификат, заверенный публичным CA, работает как-то по другому?

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

 

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

В данном случае нужно, чтобы сертификат точки входа callback вызовов был подписан их CA.

У них нет своего CA, они проверяют по публичным корневым CA.

Но да, теперь я понял смысл предложения.

[s.lobanov]

@alibek проблема в том, что Сбербанк не хочет добавлять ваш сертификат в своё хранилище сертификатов (которое с вероятностью 99.9% это просто то что идёт с java), потому что потом им это надо всё переносить/менять процедуру деплоя, бэкапа, восстановления

 

Не очень понятно что вы хотите обсудить с комьюнити. как продавить Сберанк? (ну ответ, очевидно, никак)

 

И ещё. Подписанный публичными центрами можно нормально отменить (revoke) и, возможно, сбрф использует ocsp. в случае самоподписанного так сделать (через ocsp) не получится

[alibek]

Причем тут Сбербанк? Как раз Сбербанк спокойно работает с самоподписанными сертификатами.

Другой сервис хочет публичный сертификат, возможно по этой же самой причине.

Вопрос — зачем в подобных случаях вообще публичная цепочка доверия?

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

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

Ну или не глупо, а я просто что-то не учитываю.

[s.lobanov]

@alibek да, я не дочитал до конца первый пост(слишком много букв)

 

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

[ixi]

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

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

Без проверки сертификата шифрование и безопасность так себе, любой MITM сработает.

 

Сбер, кстати, вполне работал по простому http.

Изменено 7 марта, 2019 пользователем ixi

[kpv]

8 minutes ago, alibek said:

Ну или не глупо, а я просто что-то не учитываю.

не учитываете стоимость решения. сами не хотите ни бесплатный поставить ни за смешные $15 взять готовое решение.

на на 99% уверен, что вы же первый откажитесь от оплаты ведения и поддержку приватных сертификатов сбербанком, когда ежегодно попросят уже не $15, а несколько больше.

 

[Sergey Gilfanov]

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

У них нет своего CA, они проверяют по публичным корневым CA.

 

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

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

С вероятностью 90% у сервиса где-то внутри есть виндовый домен. А в нем, соответственно, готовый CA, который умеет собственные сертификаты отслеживать, отзывать итд. Так что мой вариант вполне осуществим и не так уж сложен в исполнении.

Разве что созвониться или еще как связаться придется, чтобы проверить, что Certificate Request пришел именно от того, от кого должен.

[alibek]

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

Без проверки сертификата шифрование и безопасность так себе, любой MITM сработает.

Вот это интересно. Каким образом?

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

А отпечаток, CN и IP-адрес другой стороне можно передать хоть по email, хоть зафиксировать в договоре.

 

[kpv]

Just now, alibek said:

А отпечаток, CN и IP-адрес другой стороне можно передать хоть по email, хоть зафиксировать в договоре.

всё можно. а потом при каждом чихе или изменении будете тащить бумагу с "живой синей печатью" за подписью директора и бухгалтера и выпиской из егрюл. 

 

3 minutes ago, alibek said:

можно передать хоть по email

а вот и прекрасный вариант MITM

[st_re]

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

Вот это интересно. Каким образом?

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

А отпечаток, CN и IP-адрес другой стороне можно передать хоть по email, хоть зафиксировать в договоре.

 

я так понял "без проверки" это дословно "без проверки", Т.е. сказать клиенту чтобы он не проверял цепочку доверия итд и работал с чем дали. в таком виде дать могут все что угодно.  (типа как curl -k) защита от пассивного снифа трафика, от МИТМ не поможет совершенно.

 

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

 

 

Ну и "самоподписанный" это наверное не то, что имелось в виду, самоподписанный, когда он сам себе ЦА и сам себя подписал, тут вообще не бывает цепочки доверия., а тут всетаки по тексту есть ЦА, пускай и не публичный...

 

зы в приватном ЦА никто не мешает использовать ocsp. оно работает.

[s.lobanov]

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

зы в приватном ЦА никто не мешает использовать ocsp. оно работает.

да. если поднято. автор топика, вероятно, не собирался этого делать (кстати, по затратам на поднятие и обслуживание (трудочасам) это дороже выйдет 15-20$)

[st_re]

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

да. если поднято. автор топика, вероятно, не собирался этого делать (кстати, по затратам на поднятие и обслуживание (трудочасам) это дороже выйдет 15-20$)

ну со своим ЦА да еще для внешнего потребления заморачиваться смысл есть только для больших объемов.. для 1-2 случаев купить за 30 сребренников в год и не париться...

[alibek]

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

автор топика, вероятно, не собирался этого делать

Нет, разумеется. Если уж мне нужен будет именно публичный сертификат, то я его буду покупать или использовать LetItEncrypt, а не поднимать и обслуживать свой CA.

Просто в данной задаче (технологическое взаимодействие двух систем) я вообще не вижу необходимости в публичном CA. HTTPS нужен, чтобы данные не ходили в открытом виде.

 

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

я так понял "без проверки" это дословно "без проверки"

Ну либо так (хотя это и слишком радикально, зато просто), либо добавить мой приватный CA в список доверенных.

 

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

В общем вопрос реализации и удобства обслуживания.

Да, тут вполне нормально аргументировано и такая позиция мне понятна.

 

[Sergey Gilfanov]

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

HTTPS нужен, чтобы данные не ходили в открытом виде.

HTTPS нужен для того, чтобы убеждаться, что стороны - те, за кого себя выдают.

Кстати, в описанном случае - как проверять, что в callback постучался именно сервис а не непонятно кто?

По хорошему бы ваша сторона должна попросить у стучавшегося клиентский сертификат и проверить его. Вот его - можно/нужно подписывать как раз вашим CA.

[alibek]

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

Кстати, в описанном случае - как проверять, что в callback постучался именно сервис а не непонятно кто?

Ну в моем случае непонятно кто постучать не сможет — callback принимается только с IP-адресов из согласованного списка.

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

 

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

ваша сторона должна попросить у стучавшегося клиентский сертификат и проверить его. Вот его - можно/нужно подписывать как раз вашим CA.

Логика понятная, но мне кажется, что избыточная.

Например в Киви все сделано гораздо проще — к анкете прикладывается сертификат своего шлюза и Киви проверяет именно его, без всяких цепочек доверия и CA.

Правда такой сертификат нельзя отозвать (через CA), но такое и не предусматривалось — изменение/отключение сервиса делается бумажно.

[Sergey Gilfanov]

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

Ну в моем случае непонятно кто постучать не сможет — callback принимается только с IP-адресов из согласованного списка.

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

Ага. А чем клиентский https сертификат в качестве 'токена доступа' плох. Для того и придуман, как бы.

[s.lobanov]

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

Кстати, в описанном случае - как проверять, что в callback постучался именно сервис а не непонятно кто?

да легко. просто делаете URL вида https://url-for-callback/xxx/KEYWORD/receive.lang

 

если KEYWORD не совпал, то значит платёж по такому запросу не принимаем. да сотрудники той организации будут знать KEYWORD, но с другой стороны они и так смогу сэмулировать левый запрос

[alibek]

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

А чем клиентский https сертификат в качестве 'токена доступа' плох.

Не то чтобы плох, но гораздо менее гибок, чем токен в заголовках/аргументах.

[Sergey Gilfanov]

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

если KEYWORD не совпал, то значит платёж по такому запросу не принимаем. да сотрудники той организации будут знать KEYWORD, но с другой стороны они и так смогу сэмулировать левый запрос

Весь https с открытыми ключами и прочими сложными алгоритмами потому и придуман, что использование просто пароля, что тут KEYWORD называется, не очень хорошо работает.