О!!! Тоже приходилось читать - правда, сейчас, слава богу, отошёл от этого
-
Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram
ESP8266 + SSL
- Автор темы alfik777
- Дата начала
Алексей.
Active member
shuraf, Вы настроили москиту для аутентификации клиента? Довольно странно, обычно ограничиваются только аутентификацией хоста (как в обычном https соединении). В таком случае вопрос относится уже не к WiFiClientSecure а к моските.
Если это не так, настроена только аутентификация хоста, то ничего удивительного, в момент хэндшейка, хост подписывает своё хелло и присылает сертификат с публичным ключем для проверки подписи, WiFiClientSecure радостно проверяет подпись, а проверка подлинности сертификата это уже не её проблема
Если это не так, настроена только аутентификация хоста, то ничего удивительного, в момент хэндшейка, хост подписывает своё хелло и присылает сертификат с публичным ключем для проверки подписи, WiFiClientSecure радостно проверяет подпись, а проверка подлинности сертификата это уже не её проблема
pvvx
Активный участник сообщества
Там наверно надо всё с нуля объяснять, иначе несведущему человеку в терминах TLS/SSL не разобраться...
Как работает TLS, в технических подробностях
Как видите длина 'записи' (хоть при Handshake) составляет 16 килобайт + мелочи и кучу ресурсов для обработки этого. Вот оно и не лезет в RAM ESP8266.
Как работает TLS, в технических подробностях
Как видите длина 'записи' (хоть при Handshake) составляет 16 килобайт + мелочи и кучу ресурсов для обработки этого. Вот оно и не лезет в RAM ESP8266.
Судя по всему где-то косяк с сертификатами.
Дело было так, сгенерил сертификаты и ключи с помощью OpenSSL. Настроил mosquittu как брокер с этими сертификатами. Настроил spyMQTT с полученными сертификатами. Также задал логин и пароль для доступа к моските. Все заработало. Если что-то задавал неправильно то выдавало ошибку и я посчитал, что это признак правильной настройки.
Потом настроил ESP12 без сертификата и она подключилась и опубликовала топики. Меня это озадачило.
Я накидал на Питоне скриптик и получил ошибку "Неверный сертификат са". Долго ковырял и пробовал разные варианты создания сертификатов, пробовал варианты pem и crt. Все безрезультатно.
Потом попробовал запустить mosquitto_pub и получил "Ошибка сертификата".
Кстати, spyMQTT исправно работает.
Теперь у меня две задачки, но нет вопросов, потому что я уже вообще ничего не понимаю
Дело было так, сгенерил сертификаты и ключи с помощью OpenSSL. Настроил mosquittu как брокер с этими сертификатами. Настроил spyMQTT с полученными сертификатами. Также задал логин и пароль для доступа к моските. Все заработало. Если что-то задавал неправильно то выдавало ошибку и я посчитал, что это признак правильной настройки.
Потом настроил ESP12 без сертификата и она подключилась и опубликовала топики. Меня это озадачило.
Я накидал на Питоне скриптик и получил ошибку "Неверный сертификат са". Долго ковырял и пробовал разные варианты создания сертификатов, пробовал варианты pem и crt. Все безрезультатно.
Потом попробовал запустить mosquitto_pub и получил "Ошибка сертификата".
Кстати, spyMQTT исправно работает.
Теперь у меня две задачки, но нет вопросов, потому что я уже вообще ничего не понимаю
Ну разобрался я своими косяками.
1. В одной из 'мурзилок' было у москиты активировать require_certificate. Я активировал и забыл. И клиенты видно не все умеют правильно это отрабатывать.
2. mosquitto_pub надо задавать имя сервера к которому генерился ключ, а не 127.0.0.1, localhost и т.д. Хотя и не понятно почему работает spyMQTT с заданным 127.0.0.1
Теперь работает. Клиенты проверяют сертификат сервера по TLS1.2. Но сами ничего не предоставляют и далее идёт идентификация user/password.
1. В одной из 'мурзилок' было у москиты активировать require_certificate. Я активировал и забыл. И клиенты видно не все умеют правильно это отрабатывать.
2. mosquitto_pub надо задавать имя сервера к которому генерился ключ, а не 127.0.0.1, localhost и т.д. Хотя и не понятно почему работает spyMQTT с заданным 127.0.0.1
Теперь работает. Клиенты проверяют сертификат сервера по TLS1.2. Но сами ничего не предоставляют и далее идёт идентификация user/password.
Алексей.
Active member
Вы в этом уверены? На WiFiClientSecure Вы можете только проверить fingerprint и DN, может есть ещё недокументированные возможности проверки подлинности сертификата, поделитесь знаниями.
Конечно не уверен.
Сейчас у меня больше вопросов чем ответов.
Почему у клиентов на Питоне, spyMQTT, mosquitto требуется ca.crt, а esp12 хватает только логин и пароль?
Почему сгенерированные сертификаты для клиентов не проходят проверку?
Для дальнейшего анализа вероятно надо Wireshark, но думаю это я уже не осилю
Алексей.
Active member
shuraf, У Вас нет понимания, я думаю, канального и интерфейсного уровня.
На канальном уровне ЕСП устанавливает защищенное соединение и при этом сертификата с публичным ключом, который приходит от хоста, достаточно для того чтоб проверить подпись хостового хелло. Далее для выполнения запросов для mqtt, интерфейсный уровень предполагает аутентификацию клиента по логину и паролю и клиент mqtt на ЕСП успешно с этим справляется.
Что касается клиентов на питоне и spyMQTT, то не ясен вообще сценарий установления защищенного соединения у них. Если они не проходят канальный уровень, то что говорить об интерфейсном, до логина просто не доходит.
Если используется вторая фаза хендшейка, т.е. кроме аутентификации хоста требуется выполнить аутентификацию клиента, то на стороне хоста должен быть сертификат, который удостоверяет подлинность сертификата клиента.
Если совсем просто (для двойной аутентификации):
1. Генерим ключи и изготавливаем самоподписанный сертификат центра эмиссии.
2. Генерим ключи для хоста и строим сертификат с публичным ключом, подписываем его на ключе центра эмиссии.
3. Для клиента аналогично генерим ключи и строим сертификат с публичным ключом, подписываем его на ключе центра эмиссии.
Итого: На хосте и клиенте есть сертификат сертификат центра эмиссии и свои ключ и сертификат с публичным ключом.
А зачем Вам нужен клиент на питоне и spyMQTT?
Просто я использовал один и тот же код mqtt клиента на ЕСП и на ПК, один подписывается другой публикует и наоборот, и проблем как то и не было.
На канальном уровне ЕСП устанавливает защищенное соединение и при этом сертификата с публичным ключом, который приходит от хоста, достаточно для того чтоб проверить подпись хостового хелло. Далее для выполнения запросов для mqtt, интерфейсный уровень предполагает аутентификацию клиента по логину и паролю и клиент mqtt на ЕСП успешно с этим справляется.
Что касается клиентов на питоне и spyMQTT, то не ясен вообще сценарий установления защищенного соединения у них. Если они не проходят канальный уровень, то что говорить об интерфейсном, до логина просто не доходит.
Если используется вторая фаза хендшейка, т.е. кроме аутентификации хоста требуется выполнить аутентификацию клиента, то на стороне хоста должен быть сертификат, который удостоверяет подлинность сертификата клиента.
Если совсем просто (для двойной аутентификации):
1. Генерим ключи и изготавливаем самоподписанный сертификат центра эмиссии.
2. Генерим ключи для хоста и строим сертификат с публичным ключом, подписываем его на ключе центра эмиссии.
3. Для клиента аналогично генерим ключи и строим сертификат с публичным ключом, подписываем его на ключе центра эмиссии.
Итого: На хосте и клиенте есть сертификат сертификат центра эмиссии и свои ключ и сертификат с публичным ключом.
А зачем Вам нужен клиент на питоне и spyMQTT?
Просто я использовал один и тот же код mqtt клиента на ЕСП и на ПК, один подписывается другой публикует и наоборот, и проблем как то и не было.
gerkimuyda
New member
Как проверить подлинность сертификата? Правильно - проверить достоверность подписавшего сертификат. Т.е. ваш сертификат подписывает своим сертификатом организация, которой все доверяют (CA). А для этого - надо держать у себя базу всех сертификатов доверенных организаций. А где взять память для этого в ESP ?
На Питоне клиент подписанный на топики и складывающий в базу MS-SQL (москита я так понял сама этого не может)
spyMQTT только для тестирования.
Для того чтоб использовать один и тот же код и в ардуинке и на пк, вероятно нужны знания С.., а для меня пока и процесс компиляции недостижим ))
Ну на это и не рассчитывал, но использование сертификаты самоподписанные видил реализации.
Я опять со своими баранами
Установил Wireshark. Посмотрел как идет обмен на 8883 порту.
В описании как происходит обмен сообщениями при TLC есть картинка. И обмен сообщениями на 883 порту совпадает с картинкой. По сообщениям видно, что сервер отправляет сертификат и тд. И т.к. "У ESP не хватит мощей переварить все это"(с), то получается еспешка просто выкидывает все это и "Верю на слово, давай шифроваться"?
Т.е. до установления связи любой может прикинутся сервером и есп его примет?
Нет запроса сертификата от клиента и любой может прикинуться клиентом?
Но данные шифруюся и подмена в момент связи не возможна?
Установил Wireshark. Посмотрел как идет обмен на 8883 порту.
В описании как происходит обмен сообщениями при TLC есть картинка. И обмен сообщениями на 883 порту совпадает с картинкой. По сообщениям видно, что сервер отправляет сертификат и тд. И т.к. "У ESP не хватит мощей переварить все это"(с), то получается еспешка просто выкидывает все это и "Верю на слово, давай шифроваться"?
Т.е. до установления связи любой может прикинутся сервером и есп его примет?
Нет запроса сертификата от клиента и любой может прикинуться клиентом?
Но данные шифруюся и подмена в момент связи не возможна?
