Сертификат может быть выпущен на IP. Например https://1.1.1.1/ . Правда кому попало такой сертификат доверенный центр не выпустит и на 192.168 точно не выпустит, но самоподписанный сертификат выпустить можно, стандарты позволяют указывать IP, а не DNS-имя.
В вашем случае разумно всю заботу о сертификатах сложить на плечи пользователей-администраторов. Пользуйтесь стандартными средствами операционной системы, а администраторы пусть сами решают, выпустить им нормальный сертификат или делать локальный удостоверяющий центр с самоподписанным корневым сертификатом и устанавливать его как доверенный на нужные машины. От вас требуется предоставить возможность загружать ключ и сертификат в ваше приложение.
Для тупых можете предоставить возможность генерации сертификата через letsencrypt. От админа в данном случае нужно будет настроить DNS и указать у вас в настройках hostname, т.е. myserver.aws.com, например, который указывает на публичный IP-адрес с открытым 80 портом. Тогда вы сможете используя letsencrypt и слушая 80 порт на этой машине выпустить сертификат на этот домен и в дальнейшем его использовать в своих целях.
Ну можете ещё автоматически сгенерировать самоподписанный сертификат на произвольный домен/IP-адрес, выгрузить его пользователю и показать инструкцию, как его установить в доверенные на другом конце.
SVZ>Как эта проблема решается в мобильных интернет банках, например? SVZ>Вот есть клиентское приложение, оно обязано иметь сертификат, чтобы доказать серверу, что оно "настоящее"? SVZ>Или любое приложение может приконнектиться к веб АПИ?
Любое приложение может приконнектиться к веб АПИ. Любой сертификат тут будет бессмысленнен, т.к. расковырять apk и вытащить оттуда ключ это не так уж сложно, то бишь защита тут примерно как захардкодить пароль в исходниках. Обычно защиту делают с другого конца: в исходниках хардкодят публичный ключ сервера и при соединении проверяют, что сервер показывает именно его. Это позволяет затруднить анализ трафика, хотя всё равно пытливый ум расковыряет, но тут хотя бы никаких секретов в коде не прячут, просто дополнительные проверки.
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Как эта проблема решается в мобильных интернет банках, например? SVZ>Вот есть клиентское приложение, оно обязано иметь сертификат, чтобы доказать серверу, что оно "настоящее"? SVZ>Или любое приложение может приконнектиться к веб АПИ?
Защищать "настоящесть" приложения сертификатом на стороне клиента бессмысленно. Рано или поздно этот сертификат найдут внутри приложения, после чего любой желающий сможет подключиться к веб АПИ.
Вообще, что должен сертифицировать сертификат на клиентской стороне? Идентичность пользователя? Ну тогда его лично пользователю в руки и надо раздавать.
А что должен сертифицировать сертификат на серверной стороне? То, что сервер заслуживает доверия? Но тогда ни в коем случае нельзя использовать один сертификат на все сервера, он где-нибудь утечет, и навсегда будет скомпроментирован.
Если клиент — это не веб-бровсер, а самодельная программа, использующая http в качестве транспорта, можно со стороны сервера использовать самодельные сертификаты, тщательно продумав их распределение именно с точки зрения смысла наличия у сервера валидного сертификата, а со стороны клиента сделав нестандартную процедуру их проверки.
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>В существующую версию вбухано примерно 30 человеко-лет. Переписать на другой язык можно, но придется потратить уйму времени и сил, а полезного и ценного для пользователей не добавится. SVZ>В общем всё как всегда
Прекрасный способ отметить юбилей программы — переписать ее на другом языке программирования
Имеется десктопное GUI приложение и множество т.н. агентов (Win сервисов),
к которым гуй подключается по http протоколу и запускает удаленные вычисления.
Потребовалось обеспечить TLS1.2 compliance.
https приделать, вроде бы несложно (используем Poco, если это важно),
но что-то с сертификатами у нас не ладится.
Собственно, непонятно главное: с каким сертификатом должны запускаться агент и гуй?
Должны ли мы (разработчики) предоставлять какой-то сертификат (персональный или универсальный)
или сертификаты это забота пользователей?
Агентов в сети может быть много, устанавливаются они клиентами
(или их IT подразделениями) на любые машины, никаких ограничений на установку нет.
Работает всё преимущественно в локальной сети, но возможна установка и на амазоновских "облачных" машинах.
Во всех шпаргалках DV-сертификат требует указания FQDN. В больших компаниях оно
может быть и будет, а в мелких может не быть ничего, кроме локального ИП адреса 192.168.1.хх.
Т.е. получается, что выпустить один сертификат, пригодный сразу для всех агентов, не получится?
Обязать пользователей использовать самоподписанные сертификаты? Или можно как-то
упростить эту задачу?
Конечная цель — любая домохозяйка должна любой инженер без навыков сисадминства должен
иметь возможность установить приложение и начать его использовать.
Как эта проблема решается в мобильных интернет банках, например?
Вот есть клиентское приложение, оно обязано иметь сертификат, чтобы доказать серверу, что оно "настоящее"?
Или любое приложение может приконнектиться к веб АПИ?
В общем нужен совет.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Pzz, Вы писали:
Pzz>Защищать "настоящесть" приложения сертификатом на стороне клиента бессмысленно. Рано или поздно этот сертификат найдут внутри приложения, после чего любой желающий сможет подключиться к веб АПИ.
Pzz>Вообще, что должен сертифицировать сертификат на клиентской стороне? Идентичность пользователя? Ну тогда его лично пользователю в руки и надо раздавать.
Pzz>А что должен сертифицировать сертификат на серверной стороне? То, что сервер заслуживает доверия? Но тогда ни в коем случае нельзя использовать один сертификат на все сервера, он где-нибудь утечет, и навсегда будет скомпроментирован.
Pzz>Если клиент — это не веб-бровсер, а самодельная программа, использующая http в качестве транспорта, можно со стороны сервера использовать самодельные сертификаты, тщательно продумав их распределение именно с точки зрения смысла наличия у сервера валидного сертификата, а со стороны клиента сделав нестандартную процедуру их проверки.
Пользователь проверяет нашу софтину на TLS1.2 compliance при помощи утилиты testssl.sh
Один из тестов проверяет на уязвимость "Secure Client-Initiated Renegotiation". Документированный способ защиты от нее — certificate-based client authentication. Может есть и другие, но я пока не нашел — читаю rfc.
Но в целом да, полнейшая глупость — потому что агент может запускаться даже на той же машине, что и установленный гуй. Т.е. у пользователей может быть доступ не только к сертификату клиента, но и к сертификату сервера.
В принципе, камрад vsb кмк прав, если пользователю приспичило иметь защиту на таком уровне, то пущай сам и обеспечивает сертификаты. Буду пока придерживаться этой версии.
Но самоподписанные сертификаты меня добивают. Проще в каком-нибудь САПРе разобраться, чем заставить опенссл сгенерить работающий сертификат.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Пользователь проверяет нашу софтину на TLS1.2 compliance при помощи утилиты testssl.sh SVZ>Один из тестов проверяет на уязвимость "Secure Client-Initiated Renegotiation". Документированный способ защиты от нее — certificate-based client authentication. Может есть и другие, но я пока не нашел — читаю rfc.
Client-Initiated Renegotiation можно просто запретить на серверной стороне.
SVZ>Но самоподписанные сертификаты меня добивают. Проще в каком-нибудь САПРе разобраться, чем заставить опенссл сгенерить работающий сертификат.
А ты openssl в качестве библиотеки используешь, или в качестве тулзы?
Здравствуйте, Pzz, Вы писали:
SVZ>>Пользователь проверяет нашу софтину на TLS1.2 compliance при помощи утилиты testssl.sh SVZ>>Один из тестов проверяет на уязвимость "Secure Client-Initiated Renegotiation". Документированный способ защиты от нее — certificate-based client authentication. Может есть и другие, но я пока не нашел — читаю rfc.
Pzz>Это ты про эту проблему?
Pzz>https://blog.qualys.com/ssllabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks
Видимо да.
testssl говорит вот что:
Secure Renegotiation (CVE-2009-3555) not vulnerable (OK)
Secure Client-Initiated Renegotiation VULNERABLE (NOT ok), DoS threat
Pzz>Client-Initiated Renegotiation можно просто запретить на серверной стороне.
Ну я пока не нашел, как это сделать иначе чем через клиентский сертификат. А его серверная сторона не принимает. Пишет, мол, "неивестный са" и всё тут. Хотя корневой сертификат вроде бы предоставляю, правда тоже самовыпущенный.
SVZ>>Но самоподписанные сертификаты меня добивают. Проще в каком-нибудь САПРе разобраться, чем заставить опенссл сгенерить работающий сертификат.
Pzz>А ты openssl в качестве библиотеки используешь, или в качестве тулзы?
Для работы с http(s) мы используем Poco. У ей внутре крутится openssl. Какие-то ручки для доступа к опенссл Поко таки предоставляет, но знать бы что именно надо дёрнуть.
А сертификаты я пытаюсь генерить из комстроки по инструкциям, надерганным из сети.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Ну я пока не нашел, как это сделать иначе чем через клиентский сертификат. А его серверная сторона не принимает. Пишет, мол, "неивестный са" и всё тут. Хотя корневой сертификат вроде бы предоставляю, правда тоже самовыпущенный.
Просто положи сертификат в trusted root на сервере и всё заработает (если винда), по сертификату сразу же видно нормальный он или нет, на "плохом" красный крест стоит.
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Ну я пока не нашел, как это сделать иначе чем через клиентский сертификат. А его серверная сторона не принимает. Пишет, мол, "неивестный са" и всё тут. Хотя корневой сертификат вроде бы предоставляю, правда тоже самовыпущенный.
Client-Initiated Renegotiation, это такая фича протокола TLS о которой я узнал час назад, которая позволяет клиенту изменить параметры существующей сессии вместо того, чтобы закрыть ее, и начать новую. Я уверен, что тебе эта фича вообще не нужна. Поэтому ее надо не засекуривать, а просто запретить. Должна быть какая-то ручка на серверной стороне, чтобы сервер не соглашался на ренеготиацию, а просто слал клиента куда подальше с этой инициативой.
SVZ>А сертификаты я пытаюсь генерить из комстроки по инструкциям, надерганным из сети.
А ты битик CA в самодельном рутовом сертификате не забыл поставить?
Здравствуйте, bnk, Вы писали:
SVZ>>Ну я пока не нашел, как это сделать иначе чем через клиентский сертификат. А его серверная сторона не принимает. Пишет, мол, "неивестный са" и всё тут. Хотя корневой сертификат вроде бы предоставляю, правда тоже самовыпущенный.
bnk>Просто положи сертификат в trusted root на сервере и всё заработает (если винда),
OpenSSL умеет в виндовое хранилище сертификатов ходить? Сертификат заимпортировал в хранилище, но это не помогло.
Я передаю имя файла сертификата в SSL_CTX_load_verify_locations().
Но всё равно получаю ошибку на сервере
error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca
bnk>по сертификату сразу же видно нормальный он или нет, на "плохом" красный крест стоит.
Ты имеешь в виду браузер? У Лисы, если интернет не врёт, собственное хранилище сертификатов и там конкретный сертификат добавляется в список исключений.
С отключенной проверкой клиентского сертификата firefox сперва ругается на серверный сертификат, но после добавления в исключения коннектится и даже корректно отображает полученное.
А если на сервере включить SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT то уже никто не может подключиться.
Чую пятой точкой , что проблема в сертификатах, продолжаю ковырять.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Pzz, Вы писали:
SVZ>>Ну я пока не нашел, как это сделать иначе чем через клиентский сертификат. А его серверная сторона не принимает. Пишет, мол, "неивестный са" и всё тут. Хотя корневой сертификат вроде бы предоставляю, правда тоже самовыпущенный.
Pzz>Client-Initiated Renegotiation, это такая фича протокола TLS о которой я узнал час назад, которая позволяет клиенту изменить параметры существующей сессии вместо того, чтобы закрыть ее, и начать новую. Я уверен, что тебе эта фича вообще не нужна. Поэтому ее надо не засекуривать, а просто запретить. Должна быть какая-то ручка на серверной стороне, чтобы сервер не соглашался на ренеготиацию, а просто слал клиента куда подальше с этой инициативой.
Ну документация у OpenSSL — без слёз не взглянешь. А уж диагностика и того хлеще.
В интернете упоминания только про запрет insecure renegotiation.
Продолжаю искать этот заветный крыжик.
SVZ>>А сертификаты я пытаюсь генерить из комстроки по инструкциям, надерганным из сети.
Pzz>А ты битик CA в самодельном рутовом сертификате не забыл поставить?
Не знаю. Надо проверить. Делал по шпаргалке.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Stanislav V. Zudin, Вы писали:
bnk>>Просто положи сертификат в trusted root на сервере и всё заработает (если винда),
SVZ>OpenSSL умеет в виндовое хранилище сертификатов ходить? Сертификат заимпортировал в хранилище, но это не помогло.
OpenSSL тут ни при чем, или по крайней мере я не про него. Я имел в виду открываешь хранилище сертификатов руками,
смотришь что там есть, при необходимости добавляешь твой сертификат в доверенные.
bnk>>по сертификату сразу же видно нормальный он или нет, на "плохом" красный крест стоит.
SVZ>Ты имеешь в виду браузер?
Нет, просто файл сертификата в эксплорере.
Если его дабл-кликнуть сертификат, будет большой крест с инфой что не так (если что-то не так)
Здравствуйте, bnk, Вы писали:
bnk>OpenSSL тут ни при чем, или по крайней мере я не про него. Я имел в виду открываешь хранилище сертификатов руками, bnk>смотришь что там есть, при необходимости добавляешь твой сертификат в доверенные.
Туда я его добавлял. Но похоже, что OpenSSL туда ходить не умеет.
bnk>>>по сертификату сразу же видно нормальный он или нет, на "плохом" красный крест стоит. bnk>Нет, просто файл сертификата в эксплорере. bnk>Если его дабл-кликнуть сертификат, будет большой крест с инфой что не так (если что-то не так)
Показывает цепочку из двух самодельных сертификатов.
Видимо это означает, что сами сертификаты корректны.
_____________________
С уважением,
Stanislav V. Zudin
SVZ>Собственно, непонятно главное: с каким сертификатом должны запускаться агент и гуй? SVZ>Должны ли мы (разработчики) предоставлять какой-то сертификат (персональный или универсальный) SVZ>или сертификаты это забота пользователей? SVZ>Агентов в сети может быть много, устанавливаются они клиентами SVZ>(или их IT подразделениями) на любые машины, никаких ограничений на установку нет. SVZ>Работает всё преимущественно в локальной сети, но возможна установка и на амазоновских "облачных" машинах.
Для этого в Windows есть целый огромный раздел на тему Certificate Authority, и настройка его не так проста как кажется. Тебе нужно именно это.
Если кроме Windows будет что-то еще, задача усложняется на порядок. Но в любом случае тебе нужно свой сертификационный центр громоздить.
Или вколхозить выдачу сертификатов в свое приложение (центральное). Тогда придется еще и научиться делать все то, что делает CA.
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Ну документация у OpenSSL — без слёз не взглянешь. А уж диагностика и того хлеще. SVZ>В интернете упоминания только про запрет insecure renegotiation. SVZ>Продолжаю искать этот заветный крыжик.
Ох, сдался вам этот OpenSSL. У Go в стандартной библиотеке есть своя реализация TLS, с куда как более внятным API и хорошо задокументированная.
SVZ>>>А сертификаты я пытаюсь генерить из комстроки по инструкциям, надерганным из сети.
Pzz>>А ты битик CA в самодельном рутовом сертификате не забыл поставить?
SVZ>Не знаю. Надо проверить. Делал по шпаргалке.
В итоге я тоже пришел к этому флагу.
Запрос сертификата от клиента убрал, подкрутил сертификат.
В общем testssl уязвимостей не находит, гуй к агенту коннектится, всё считается.
Можно расслабиться и выпить!
Pzz>Ох, сдался вам этот OpenSSL. У Go в стандартной библиотеке есть своя реализация TLS, с куда как более внятным API и хорошо задокументированная.
А городить смесь из нативного Виндового гуя и GO кмк еще более забористая штука
На агенте можно было бы замутить, там можно обращение к числодробительной части повесить на интероп. Но это надо Go осваивать.
В общем, как-нибудь потом.
Спасибо, коллеги!!!
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Stanislav V. Zudin, Вы писали:
Pzz>>Ох, сдался вам этот OpenSSL. У Go в стандартной библиотеке есть своя реализация TLS, с куда как более внятным API и хорошо задокументированная.
SVZ>А городить смесь из нативного Виндового гуя и GO кмк еще более забористая штука
Win32 API можно из Go напрямую дергать
SVZ>На агенте можно было бы замутить, там можно обращение к числодробительной части повесить на интероп. Но это надо Go осваивать. SVZ>В общем, как-нибудь потом.
Я не уверен, что числодоробильная часть на Go будет так уж и медленнее, чем на C++.
Я сравнивал скорость некоторых тяжелых криптографических вычислений, таких, как генерация сертификатов, между стандартной библиотекой Go и написанным на C openssl. Что-то получается быстрее у Go, что-то у openssl. Большая разница наблюдается, если на одной стороне имеется ассемблерная оптимизация, а на другой почему-то нет. А если ее нигде нет, результаты получаются достаточно близкие.
Здравствуйте, SkyDance, Вы писали:
SD>Или вколхозить выдачу сертификатов в свое приложение (центральное). Тогда придется еще и научиться делать все то, что делает CA.
Совершенно не обязательно, кстати.
Если сертификатов немного, и распостраняются они ручками, то можно на другой стороне просто иметь (в настройках) список фингерпринтов сертификатов, которым эта сторона доверяет. TLS-протокол убедится в том, что программа, предъявившая сертификат, обладает и закрытым ключом от него, а факт того, что предъявленному сертификату можно верить, проверяется поиском его фингерпринта в списке. CA при этом не нужен, сертификаты должны быть самоподписанными.
Pzz>Если сертификатов немного, и распостраняются они ручками, то можно на другой стороне просто иметь (в настройках) список фингерпринтов сертификатов, которым эта сторона доверяет.
Это и есть CA только на основе whitelist.
Можно сделать себе один root CA cert, и закрытым ключом к этому сертификату подписывать "сертификаты, которым эта сторона доверяет" — результат тот же.
Но я так понимаю, проблема именно с "распространением ручками". Требуются некие enrollment services, и enrollment policies, ибо ручками утомительно. Тут-то и начинаются сложности.
Здравствуйте, SkyDance, Вы писали:
SD>Можно сделать себе один root CA cert, и закрытым ключом к этому сертификату подписывать "сертификаты, которым эта сторона доверяет" — результат тот же.
Не совсем тот же. Надо очень аккуратно хранить этот root CA cert. Иначе возможность подписывать им сертификаты может еще у кого-нибудь появиться. И настолько я понимаю задачу, в данном случае пользовательские сертификаты раздают локальные администраторы, лучше бы, чтобы у каждого заказчика был свой собственный "рутовый" сертификат.
В общем, у этого подхода свои сложности.
SD>Но я так понимаю, проблема именно с "распространением ручками". Требуются некие enrollment services, и enrollment policies, ибо ручками утомительно. Тут-то и начинаются сложности.
А это уже топикстартер должен решить, что в его случае проще.
Здравствуйте, SkyDance, Вы писали:
Pzz>>Если сертификатов немного, и распостраняются они ручками, то можно на другой стороне просто иметь (в настройках) список фингерпринтов сертификатов, которым эта сторона доверяет.
SD>Это и есть CA только на основе whitelist.
Здравствуйте, Pzz, Вы писали:
Pzz>Я не уверен, что числодоробильная часть на Go будет так уж и медленнее, чем на C++.
В существующую версию вбухано примерно 30 человеко-лет. Переписать на другой язык можно, но придется потратить уйму времени и сил, а полезного и ценного для пользователей не добавится.
В общем всё как всегда
_____________________
С уважением,
Stanislav V. Zudin
