Perché le interfacce Web sui router di consumo non attivano avvisi di certificati non attendibili?

Purtroppo la maggior parte di loro non usa affatto https.

Se non viene utilizzato https, non è necessario eseguire il controllo del certificato. Questo è in realtà più insicuro rispetto al TLS con certificati verificati manualmente, ma suppongo che i venditori tentano di evitare di spaventare le persone e ottenere il gioco di supporto.

In futuro, quando il browser avviserà i moduli inviati, questo potrebbe cambiare.

A proposito, il vero problema non è il mutevole indirizzo IP, dato che la maggior parte dei router si fa conoscere con un nome costante locale. Il vero problema è che i produttori hanno difficoltà a distribuire un certificato per tale nome in modo che i proprietari non possano recuperare la chiave segreta. (Richiederebbe una protezione HSM / TPM)

L'altra risposta non è completamente corretta, quindi cercherò di risolverlo.

Esistono due diversi tipi di interfacce Web per i router: L'interfaccia web interna ed esterna.

Mentre l'esterno dovrebbe essere disabilitato per molte ragioni, quello interno non ha bisogno di https per essere implementato: mentre si accede al router dalla propria LAN (supponiamo, CRACK potrebbe essere risolto un giorno e il Wi-Fi è considerato sicuro di nuovo), un MITM può funzionare solo localmente, che non rappresenta una grande minaccia nella maggior parte dei casi di consumo.

Tuttavia, generalmente sarebbe auspicabile avere https sui router COTS. Questo pone problemi significativi. Mentre l'IP stesso non sarebbe un problema enorme dato che l'IP reale viene controllato solo quando si accede direttamente tramite IP (dato che l'IP è considerato il dominio), c'è un altro problema: la maggior parte dei router SOHO non ha una zona DNS per i dispositivi oppure possono essere configurati.

Anche se tutti i router di un modello dovessero essere configurati con un nome di dominio locale non modificabile come "routerxy.local", .local è un dominio per il quale CA non creerebbe mai un certificato. Questo è il punto che mancano le altre risposte. Non è l'archiviazione del certificato e della chiave che è l'interruttore di vendita (è uno però benché, ma potrebbe essere mitigato con un HSM), è il dominio locale e il modo in cui funzionano le CA.

Ci sarebbe un modo per mitigare anche questo problema:

Maker x può creare routery.x.tld e ottenere un certificato per questo - e distribuirlo nell'HSM di ogni scatola che spediscono. Se questo viene fatto trapelare (da una vulnerabilità nell'HSM, ad esempio - sono ora nelle mani del potenziale aggressore), sei di nuovo in guai enormi.

Inoltre, la maggior parte delle CA potrebbe revocare il certificato quando vedono un abuso del genere (poiché l'entità per cui il certificato è utilizzato non è quella che lo utilizza)

Tutto sommato: ci sono difficoltà tecniche che ostacolano l'usabilità (non vogliamo avvisi sui certificati sul nostro router COTS) e c'è poco beneficio dall'usare TLS su una connessione che è semplicemente all'interno della LAN.

Per il certificato HTTPS, l'indirizzo IP non ha importanza, ciò che conta è il nome di dominio DNS a cui è assegnato il dispositivo. Finché il dispositivo viene fornito con un certificato e una chiave privata corrispondenti al nome DNS assegnato al router, può servire HTTPS per quel nome di dominio.

Poiché in genere i router fungono anche da DNS per la rete che sta servendo, è in grado di aggiungere qualsiasi nome DNS alla rete. Quindi tutto ciò che rimane è ottenere un certificato pubblicamente attendibile per quel nome di dominio.

Le autorità pubbliche di fiducia non possono rilasciare certificati pubblici per i nomi DNS che non sono registrati nel sistema DNS pubblico. Secondo la mia ricerca, un numero di siti afferma di disporre di alcuni router ASUS con pagina di amministrazione HTTPS automatica su un nome di dominio simile a link , che è pubblicamente indirizzo DNS registrato che appartiene ai produttori del router. I produttori di router, ASUS in questo caso, possono ottenere un certificato valido e pubblicamente attendibile per quel nome di dominio che possiedono il nome di dominio asus.com.

Tutto ciò che serve ora è che il produttore del router includa la chiave privata per il certificato di fiducia pubblica nei dispositivi che vendono. Ciò suggerisce che, quando si utilizza il certificato predefinito, un utente malintenzionato sufficientemente avanzato potrebbe essere in grado di estrarre la chiave privata dal dispositivo per falsificare la pagina di amministrazione del router. Si spera che questo non dovrebbe essere semplice poiché il router non avrebbe dovuto permettere che il suo nome di dominio admin venisse violato da altri utenti.