Может ли односторонний SSL защитить IoT-устройство?

Я рассматриваю устройство IoT, подключенное к моей локальной сети (настройки по умолчанию, нет VPN, нет NAT, нет DMZ) с доступом к Интернету или без него. Мое устройство будет работать как HTTP-сервер, предлагающий механизм RPC с аутентификацией и авторизацией. Он рекламирует себя с помощью mDNS, и я общаюсь с ним с помощью своего мобильного приложения или RaspberryPi.

Кажется, что нормой в разработке IoT является наличие взаимного (двустороннего) SSL. Означает ли это, что односторонний SSL не может защитить мой трафик? Почему?

Ноты:

• Я понимаю технические различия между одно- и двухсторонним SSL, я не понимаю, почему односторонний (почти) никогда не рассматривается в производстве IoT.
• Я понимаю, что использование взаимного SSL для локального устройства затруднительно: вам необходимо предоставить общий ключ сервера и сертификат для клиента и наоборот. Односторонний, с другой стороны, кажется проще (не требует действий пользователя).
• Некоторые массово выпускаемые устройства, такие как Philips Hue, предпочитают иметь открытую и незащищенную локальную конечную точку http, а не одностороннее шифрование SSL. Зачем делать такой выбор?
• Я ожидаю, что этот вопрос не будет основываться на мнении. Извинения, если это так.

SSL / TLS хорошо работает, когда «сервер» находится в известном месте (фиксированное имя хоста), которое может соответствовать CN сертификата, который он представляет.

Это не очень хорошо работает для устройств в домашних сетях (например, для большинства устройств IoT), поскольку они, как правило, получают IP-адреса из блоков RFC1918 и не имеют записей DNS. Это означает, что они не могут быть выданы с сертификатами (ну, они могут, но большинство браузеров их отклоняют). Вот почему такие устройства, как Philips Hue, используют незащищенные конечные точки HTTP устройства, они в основном полагаются на защищенный доступ к сети.

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

В качестве пояснения к вашему вопросу вам не нужно распространять сертификат / ключ сервера всем клиентам, просто сертификат ЦС, выдавший сертификат, необходим для подтверждения того, что сертификат является доверенным.

РЕДАКТИРОВАТЬ:

Хорошим примером защищенного подключения к локальному устройству является освещение IKEA Tradfri, которое использует COAP поверх DTLS с предварительным общим ключом (в QR-коде) на устройстве, которое используется для генерации ключа для каждого клиента. Это обеспечивает физический доступ для настройки нового клиента и защищает данные во время полета в локальной сети.

Как правило, TLS подходит гораздо больше, чем x.509, но многие реализации ограничивают его только x.509.

x.509 - это метод безопасного косвенного доверия. «A» доверяет «B», если «B» имеет сертификат, подписанный «C», а «C» - «A». Это работает и в реальной жизни; Вы доверяете кому-то, кого не знаете, если представлено письмо, подписанное лицом, которому вы доверяете. Может быть, вы видите ловушку: если в письме говорится, дайте чашку кофе, вы не дадите машину. Поэтому дополнительная информация в сертификате также имеет отношение к сфере доверия. Вот почему сервер обычно имеет имя DNS или IP-адрес в своем сертификате. Как правило, вы можете включать различную информацию (например, «лампа для гостиной»), но многие реализации также по крайней мере предварительно настроены для использования / проверки содержимого DNS / IP. И все это работает, только если кто-то заботится о доверенных

Если вы можете потратить на это время, проверьте свою реализацию, если она предлагает также наборы шифров PSK. Если нет, возможно, вы можете настроить «проверку достоверности» сертификата сервера. Но это требует много чтения, чтобы найти хорошее решение. И иногда используемая реализация TLS просто не предлагает этого.