On 9/12/2016 20:20, Jakob Bohm wrote: > On 13/09/2016 03:03, Kyle Hamilton wrote: >> I would prefer not to see a securelogin-xxxxxxxxxxxx.arubanetworks.com >> name, because such makes it look like Aruba Networks is operating the >> captive portal. If (for whatever reason) the system is compromised, or >> the login process is altered, or there's a need to enter credit card >> information [I do not know if these devices can be configured to require >> payment, but since this group typically discusses policy in general I >> think it's appropriate to address during this discussion] but there are >> then unauthorized charges caused by the device being compromised, then >> Aruba Networks is going to be the one who's called to answer for it. >> Because Aruba sells the devices and plays no part in their ongoing >> operation, they'll quite rightly shut any claim down. This leads the >> user to have no recourse. I think it would be better if there were a >> mandate that all of these devices obtain ACME (i.e., Let's Encrypt) >> certificates when they first start up. >> >> Provisioning a self-signed certificate for the administrator to >> configure the device with prior to obtaining an ACME certificate would >> in my mind be legitimate, as a warning that "hey, the device isn't >> completely configured yet". However, since I'm not a User Experience >> guy, I may be incorrect here. >> >> I also suggest that the now-revoked certificate should be put in the >> OneCRL, because of its widespread >> captive-DNS/captive-network/no-CRL-or-OCSP-retrieval environment and >> compromised private key. >> >> -Kyle H >> > Just to clarify, I never said that the use was for a "captive portal" > or other such 3rd party hit address. My presumption was that > https://securelogin.arubanetworks.com would be a manually entered URL > printed in the user manual or on the device itself. However you may > have other sources for it being a captive portal.
http://community.arubanetworks.com/t5/Wireless-Access/Certificate-securelogin-arubanetworks-com-and-trial-SSL-certs/td-p/28158 is an Aruba Networks customer request to alter the name that the users are directed to with a "guest wifi pass". This, and other things, indicate that the name in the now-revoked certifcate is used for captive portal authentication (to prevent users from having their credentials sniffed over an unencrypted wifi connection). > The securelogin-xxxxxxxxxxxx.arubanetworks.com domain name was my > hypothetical/suggested name for a cert not associated with a > shared/compromised key, but with a per-device certificate and key > generated on a secure production line before the device was put in a > cardboard box and shipped on a slow boat from China. Understood. > The point of having a real trusted cert rather than a self-signed cert > for the first-time login would be to protect the user against a WiFi > spoofed MiTM, a protection which is gone for the revoked cert due to > the publicly compromised key. I understand. In this instance, I don't think it's quite as much a problem as you're concerned about. The configuration of such a (managed, non-consumer-level) device would generally be performed over the hardware network -- either in the configuration lab of the network provider who purchased and is installing it, or on-site via the hardwired network connection that it's bridging access to. That interface is guaranteed not to have guests connecting directly to it, and so is really the only appropriate interface for secure things like configuration to be done over. (That said, there's a lot of security-unconscious manufacturers out there -- but if they're security-unconscious, they probably won't listen to this bit of security advice, either.) For actual instances of configuration interfaces exposed over WiFi, this approach is probably infeasible without a reworking of the architecture of such devices (perhaps akin to the changes required by FCC for consumer wifi routers in US to prevent installers of DD-WRT from setting their region to Japan and using unauthorized 2.4GHz spectrum above 802.11a/b/g channel 11), as updated device firmware would need to be distributed without the keys and certificates (which would need to stay in secure memory, approximately like the firmware wifi chip driver configurations now used to meet FCC's mandate). I understand that this is what you suggested. However, the firmware of those devices would need to prevent the proposed key and certificate from being used for anything other than the administration interface, in order to prevent a misattribution attack against the user and hardware manufacturer. It would be difficult to achieve this with any platform that had an open platform for third-party firmware. (I'm not saying these devices of Aruba's have an open platform, but many consumer-level devices do -- and https://build.slashdot.org/story/16/08/01/1855206/fcc-requires-tp-link-to-support-open-source-router-firmware suggests that FCC has an interest in enforcing such support. I think that if we're going to suggest or recommend anything, we should try to address the security risks across the entire breadth of use cases before the recommendation is finalized.) -Kyle H _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
