Чи може односторонній SSL захистити пристрій IoT?

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

Здається, що норма в розвитку IoT полягає в тому, щоб мати взаємний (двосторонній) SSL. Чи означає це, що одностороння SSL не може захистити свій трафік? Чому?

Примітки:

• Я розумію технічні відмінності між одно- і двосторонніми SSL, я не розумію, чому в виробництві IoT односторонній (майже) ніколи не розглядається.
• Я розумію, що взаємний SSL для локального пристрою є складним: вам потрібно поділитися відкритим ключем та сертифікатом сервера клієнтові та навпаки. Одностороння, з іншого боку, здається простішою (не вимагає дій користувача).
• Деякі пристрої масового виробництва, такі як Philips Hue, швидше мають відкриту та незахищену локальну кінцеву точку http, ніж одностороннє шифрування SSL. Чому можна було б зробити такий вибір?
• Я очікую, що це питання не буде ґрунтуватися на думці. Вибачте, якщо це так.

SSL / TLS добре працює, коли "сервер" знаходиться у відомому місці (фіксоване ім'я хоста), яке може відповідати ЦН представленого ним сертифіката.

Це не добре працює для пристроїв в домашніх мережах (наприклад, більшість пристроїв IoT), оскільки вони, як правило, отримують IP-адреси, видані з блоків RFC1918, і не мають записів DNS. Це означає, що їм не можна видавати сертифікати (добре, але вони можуть, але більшість браузерів відхиляє їх). Ось чому такі пристрої, як Philips Hue, використовують незахищені кінцеві точки HTTP пристрою, вони в основному покладаються на доступ до захищеної мережі для захисту пристрою.

Якщо використовується взаємна TLS, це відбувається, коли пристрій підключається до якоїсь центральної служби, у клієнта є власний сертифікат cert / private для підтвердження того, що він може діяти від імені власника з цим центральним сервером.

Для уточнення вашого запитання вам не потрібно розповсюджувати сервер cert / ключ всім клієнтам, для підтвердження довіри до сертифіката потрібен лише сертифікат ЦА, який видав сертифікат.

Редагувати:

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

Як правило, TLS хороший для набагато більше, ніж x.509, але багато реалізацій обмежують його лише x.509.

x.509 - це техніка надійної непрямої довіри. "A" довіряє "B", якщо "B" має сертифікат, який підписується "C", а "C" довіряється "A". Це працює і в реальному житті; ви довіряєте тому, кого не знаєте, якщо лист підписується особою, якій ви довіряєте. Можливо, ви бачите підводний камінь: якщо в листі написано, дайте, будь-ласка, чашку кави, яку не дасте вашій машині. Тому додаткова інформація в сертифікаті також має значення для розширення довіри. Ось чому сервер зазвичай у своєму сертифікаті має ім'я dns або ip-адресу. Як правило, ви можете містити різну інформацію (наприклад, "світильник для вітальні"), але багато реалізацій також принаймні попередньо налаштовані для використання / перевірки даних DNS / IP. І все це працює лише в тому випадку, якщо хтось дбає про довіреного "

Якщо ви можете провести в ньому час, перевірте свою реалізацію, якщо вона пропонує також шифрові пакети PSK. Якщо ні, можливо, ви можете налаштувати "перевірку перевірки" сертифіката серверів. Але для того, щоб знайти хороше рішення, потрібно багато читати. І іноді використовувана реалізація TLS просто не пропонує цього.