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
On 9/7/2016 00:41, Jakob Bohm wrote:
Given the specific name in those certificates, and the place where the
private key was seen, I would guess the actual use case is this:
...
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.
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.
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.
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
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
