O SSL unidirecional pode proteger um dispositivo IoT?

Estou considerando um dispositivo IoT conectado à minha rede local (configurações padrão, sem VPN, sem NAT, sem DMZ) com ou sem acesso à Internet. Meu dispositivo será executado como um servidor HTTP, oferecendo um mecanismo RPC com autenticação e autorização. Ele se anuncia com o mDNS e eu converso com ele usando meu aplicativo móvel ou meu RaspberryPi.

Parece que a norma no desenvolvimento da IoT é ter SSL mútuo (bidirecional). Isso significa que o SSL unidirecional não pode proteger meu tráfego? Por quê?

Notas:

• Entendo as diferenças técnicas entre o SSL unidirecional e bidirecional, não entendo por que o One-way (quase) nunca é considerado na produção da IoT.
• Entendo que é difícil ter SSL mútuo para um dispositivo local: você precisa compartilhar a chave pública do servidor e o certificado para o cliente e vice-versa. O one-way, por outro lado, parece mais fácil (não requer ação do usuário).
• Alguns dispositivos produzidos em massa, como a Philips Hue, preferem ter um endpoint http local aberto e não seguro do que uma criptografia SSL unidirecional. Por que alguém faria essa escolha?
• Espero que essa pergunta não seja baseada em opiniões. Desculpas se este for o caso.

O SSL / TLS funciona bem quando o "servidor" está em um local conhecido (um nome de host fixo) que pode corresponder ao CN do certificado que ele apresenta.

Isso não funciona bem para dispositivos em redes domésticas (por exemplo, a maioria dos dispositivos IoT) porque eles tendem a receber endereços IP emitidos a partir de blocos RFC1918 e não possuem entradas DNS. Isso significa que eles não podem ser emitidos com certificados (eles podem, mas a maioria dos navegadores os rejeitará). É por isso que dispositivos como o Philips Hue usam pontos de extremidade HTTP não seguros do dispositivo, basicamente eles contam com o acesso à rede que está sendo protegido para proteger o dispositivo.

Quando o TLS mútuo é usado, é para quando o dispositivo está se conectando a algum serviço central, o cliente possui sua própria chave cert / privada para autenticar que é capaz de agir em nome do proprietário com esse servidor central.

Como um ponto de esclarecimento para sua pergunta, você não precisa distribuir o certificado / chave de servidor a todos os clientes, apenas o certificado da CA que emitiu o certificado é necessário para provar que o certificado é confiável.

EDITAR:

Um bom exemplo de uma conexão segura de dispositivo local é a iluminação Tradfri da IKEA, que usa COAP sobre DTLS com uma chave pré-compartilhada (em um código QR) no dispositivo usado para gerar uma chave por cliente. Isso garante acesso físico para configurar um novo cliente e protege os dados em voo na rede local.

Geralmente, o TLS é bom para muito mais que x.509, mas muitas implementações o limitam a apenas x.509.

x.509 é uma técnica para uma confiança indireta segura. "A" confia em "B", se "B" tiver um certificado assinado por "C" e "C" como confiável "A". Isso funciona também na vida real; você confia em alguém que não conhece, se uma carta for apresentada assinada por uma pessoa em quem você confia. Talvez você veja a armadilha: se a carta diz, por favor, dê uma xícara de café que você não dará ao seu carro. Portanto, as informações adicionais no certificado também são relevantes para o escopo da confiança. É por isso que um servidor geralmente tem seu nome DNS ou endereço IP em seu certificado. Geralmente, você pode incluir informações diferentes (por exemplo, "lâmpada da sala"), mas muitas implementações também são pelo menos pré-configuradas para usar / verificar o material DNS / IP. E tudo isso só funciona se alguém se importa com os confiáveis ​​"

Se você pode gastar algum tempo, verifique sua implementação, se ela também oferece conjuntos de cifras PSK. Caso contrário, talvez você possa ajustar a "verificação de validação" do certificado do servidor. Mas é preciso muita leitura para encontrar uma boa solução. E às vezes a implementação TLS usada simplesmente não oferece isso.