On 14/09/2016 16:11, Kyle Hamilton wrote:
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.
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).
OK, you had a second source for that fact.
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 non-managed devices (and some managed ones), it is common to have
only two interfaces: "outside/insecure/internet" and
"inside/secure/lan", with different classes of inside users
distinguished only by login and other such things.
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.
Existing devices typically already have a non-replaced storage (but not
secured) area that holds the per-device MAC address. FCC insistence on
locking down worldwide products to their own local rules is a pox on
the entire industry. For instance a recent over-the-air update of my
non-US made non-US used non-US bought phone dropped access to WiFi
channels 12 and 13, effectively cutting the number of non-overlapping
WiFi channels from 4 to 3. No explanation has been forthcoming from
the manufacturer, but if FCC has just done a crazy crackdown on
manufacturers with "insufficient" protection against US users
installing firmware intended for non-US users, that could be the issue.
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.)
Another possibility could be if the name made it much more clear that
this is a router name, not a public website. This would not require
special lockdown hardware of the kind so frequently abused by
corporations that security conscious buyers will often avoid it.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
