¿Cómo usaría HTTPS en la configuración del dispositivo basada en la web que ejecuta un punto de acceso y no tiene acceso a Internet?

Estoy construyendo un dispositivo basado en Raspberry Pi para jardineros de jardín que tiene una página web y un punto de acceso para la configuración inicial, incluida la configuración de Wi-Fi. La conexión utiliza WPA2 y los únicos dos dispositivos en esa red interna serían el dispositivo en sí y el teléfono / tableta / computadora portátil del usuario. El punto de acceso solo es visible durante la configuración, lo que reduce la probabilidad de que los atacantes externos puedan adivinar la contraseña aleatoria, enviada de fábrica. Así que he encriptado el tráfico, casi con seguridad solo dos nodos, por un corto tiempo, y una contraseña aleatoria. Por lo tanto, no hay necesidad de HTTPS que pueda ver, y había planeado ejecutar HTTP.

Sin embargo, hoy supe que a partir de julio Chrome comenzará a marcar todos los sitios HTTP como inseguros. [1] Pero debido a que la configuración de Wi-Fi se realizará por punto de acceso, aún no hay acceso a Internet disponible para verificar los certificados TLS, lo que entiendo es necesario para un funcionamiento adecuado. [2] Podría autofirmar el certificado, pero eso presenta otros problemas. [3]

Entonces mis opciones parecen ser:

Presente la página de configuración con un mensaje grande y aterrador, "Este sitio web no es seguro"
Presente la página de configuración con un mensaje grande y aterrador, "Este certificado no es confiable" (por ejemplo, autofirmado)

¿Cómo proporcionaría ese hermoso bloqueo verde de forma predeterminada para una página de configuración del dispositivo?

[1] https://www.theverge.com/2018/2/8/16991254/chrome-not-secure-marked-http-encryption-ssl

[2] /security/56389/ssl-certificate-framework-101-how-does-the-browser-actually-verify-the-validity?utm_medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa

[3] https://www.globalsign.com/en/ssl-information-center/dangers-self-signed-certificates/

https tls

— Hermano lento
fuente

Parte de su pregunta se basa en malentendidos: en realidad no necesita acceso a Internet en general para verificar un certificado. El archivo de cadena de certificado en el dispositivo debe rastrearse hasta una raíz de confianza conocida por el navegador. Si no es así, el simple hecho de tener acceso a Internet no será suficiente, en realidad debería seguirse un proceso para agregar una CA adicional al navegador.

— Chris Stratton

Ya tengo un certificado de confianza para la mayoría de los navegadores de mi sitio web principal. Entonces, ¿usaría mi certificado actual, si fuera un comodín, en el que ya confían los iPhones y los androides?

— Bro lento

¡¡¡No absolutamente no!!! si hiciera eso, estaría revelando el secreto que permitiría hacerse pasar por su sitio web a todos los que compraron uno de sus productos. El certificado que use para este propósito solo debe usarse para este propósito y considerarse comprometido desde el principio. Si necesita proteger a los usuarios unos de otros, necesitará un certificado único por caja hecha. Eso es relativamente fácil de hacer con una CA personalizada para un cliente que controlas como una aplicación móvil personalizada, pero es mucho más difícil de hacer para un navegador que solo tiene raíces de confianza.

— Chris Stratton

Para tener un certificado único por dispositivo, necesita una CA dispuesta a firmar económicamente muchos de ellos. Si puede crear un cliente personalizado como una aplicación móvil que escriba, puede hacer que confíe en su propia CA personalizada. Pero si los navegadores de inventario con listas de confianza de inventario deben confiar en sus cajas, entonces deberá trabajar con una CA reconocida.

— Chris Stratton

Gracias, esto se está volviendo más claro ahora. ¿Por qué no publicas esto como respuesta y lo votaré?

— Bro lento

Una opción posible es usar HTTPS y enviar un certificado real en el dispositivo:

Dado que usted controla el punto de acceso, presumiblemente controla el servidor DHCP en el punto de acceso, por lo que puede hacer que proporcione una dirección de servidor DNS al mismo tiempo.

Este servidor DNS puede estar en el AP y puede resolver un nombre de host totalmente calificado para que se señale a sí mismo.

Luego puede comprar un certificado para ese nombre de dominio totalmente calificado y combinarlo con el producto para crear una conexión HTTPS totalmente verificada.

Un gran problema con esta idea es que está enviando la clave privada y el certificado para ese nombre de dominio, por lo que debe asumir que se verá comprometido en algún momento, por lo que nunca debe colocar una máquina real (es posible que deba ejecutar una máquina con esto nombre por un tiempo muy corto para obtener realmente el certificado) en Internet que usa ese nombre de host ya que los atacantes podrían falsificarlo fácilmente.

Además, el firmware para el AP tendría una vida limitada ya que el certificado caducará (probablemente después de un año por defecto, iirc), entonces obtendría advertencias desagradables del certificado caducado.

Siguiente idea:

Elimine el modo de punto de acceso WiFi y use Bluetooth, por ejemplo

https://www.hardill.me.uk/wordpress/2016/09/13/provisioning-wifi-iot-devices/

La desventaja es que Apple actualmente no es compatible con WebBluetooth, pero Chrome en Windows / Linux / Mac sí y podría enviar una aplicación iOS nativa para usuarios de teléfonos / tabletas Apple.

— hardillb
fuente

Así que estoy imaginando esto, en función de su respuesta: configure DNS y DHCP en el dispositivo. Uno de los registros DNS es device1234.myrealdomain.com, donde myrealdomain.com es um, mi dominio real :-) El certificado de device1234 fue firmado por mi CA antes de salir de fábrica, y el iPhone / Android ya tiene esa cadena de confianza integrada , y sabe confiar en ese dispositivo. No tengo que tener acceso a Internet para verificar, y cuando el certificado está a punto de caducar, presiono un certificado recién firmado. Funcionaría eso?

— Lento hermano

No, absolutamente no debe usar un certificado en el que se confíe para nada significativo (como su sitio web) para este propósito, ya que lo distribuirá en muchas cajas. Cuando haces eso, estás publicando efectivamente la parte supuestamente secreta para que todos la vean. También necesitará algo con un tiempo de caducidad mucho más largo que el que muchas CA ofrecen hoy en día, de lo contrario, un navegador forzado no podrá acceder a una caja que estuvo apagada durante un año o dos, incluso el tiempo suficiente para configurar para acceder a Internet para poder extraer un certificado actualizado para satisfacer al navegador.

— Chris Stratton

Chris eche un vistazo a mi respuesta justo por encima de la suya, en la que describo una situación en la que envío certificados específicos del dispositivo, no el certificado del sitio web principal, con cada dispositivo. En el caso de que el dispositivo permanezca fuera de línea por más de un año, lo consideraría roto. No se fabricarán ni se colocarán en un estante, se configurarán justo antes de salir de la fábrica.

— Bro lento

Si tiene su propia CA, entonces no necesita el servidor DNS, puede emitir certificados para la dirección IP del dispositivo, lo que simplifica todo. Y los certificados pueden caducar cuando lo desee

— hardillb

Un certificado de 90 días es completamente, totalmente, absolutamente inviable para empacar en un producto de hardware. Sería una pesadilla de atención al cliente y probablemente hundiría su negocio. No lo hagas Ni siquiera pienses en hacerlo.

— Chris Stratton