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: > > Each router (presumably a SOHO router) contains a DNS server that > responds with its own internal RFC1918 IP address for the name > securelogin.arubanetworks.com and then the routers internal user > interface shows a https page with the router configuration user > interface. The printed 1 page manual that accompanies those routers > probably says to plug in the router then open your browser and type in > that name with https in front. No actual legitimate public server > would use that DNS name or certificate, and arubanetworks.com > presumably ensures this (that is certainly the current status of the > public DNS). > > If that is indeed the use case, users are not going to replace that > certificate by any "real" certificate and will probably either generate > a per device self-signed certificate and then add a browser exception > OR they will just add a browser exception for the certificate that is > now going to be revoked. Depending on the actual router firmware > available at github (and any older versions incorporating the same > certificate), the user may not even have the ability to replace the > certificate with a self-signed one. Now sharing a single private key > among thousands of router user interfaces is obviously bad security, > but the common alternative (used by most other routers) is to use > unencrypted http, perhaps over an (initially) unencrypted WiFi link. > > The correct, but more expensive, option would be for each router to get > a unique certificate for securelogin-xxxxxxxxxxxx.arubanetworks.com > (where xxxxxxxxxxxx is the MAC address of the router) with an > intercepting redirect from securelogin.arubanetworks.com or something > similar. However the process to securely generate and install a > different private key and certificate for each router on the > assembly line, and preserve those across routine firmware upgrades > would probably be costly in a cost-competitive market, even if the > router manufacturer ran a trusted sub-ca or could otherwise get the > certificates for free. I guess that is why this router manufacturer > (presumably) chose to get a single low cost certificate and embed the > private key in the firmware images. > > On 07/09/2016 01:26, Steve Medin wrote: >> Agree, regardless of 4.9.5's investigation gap, in this case 4.9.1.1(3) >> clearly applies as well as other clauses. At this point, revocation >> is less >> harm than the key compromise. It may be an effective way to get the >> message >> to the affected device operators who have not replaced the default >> certificate with a purchased one. >> >> Kind regards, >> Steven Medin >> PKI Policy Manager, Symantec Corporation >> >> -----Original Message----- >> From: Jeremy Rowley [mailto:[email protected]] >> Sent: Tuesday, September 06, 2016 7:06 PM >> To: Steve Medin <[email protected]> >> Cc: Gervase Markham <[email protected]>; Kyle Hamilton >> <[email protected]>; >> [email protected] >> Subject: Re: Compromised certificate that the owner didn't wish to >> revoke >> (signed by GeoTrust) >> >> BRs require revocation within 24 hours of notice. It's a terrible >> timeline >> but one the browsers have strictly enforced for even wide spread >> deployments. >> >>> On Sep 6, 2016, at 4:30 PM, Steve Medin <[email protected]> >>> wrote: >>> >>> We have become aware of this certificate and its key compromise, >>> thank you >>> for this information. We are contacting the owner to understand >>> impact to >>> the deployed devices, but with clear intent to revoke. We will provide >>> updates while we make progress. >>> >>> Kind regards, >>> Steven Medin >>> PKI Policy Manager, Symantec Corporation >>> >>> >>> >>> >>> -----Original Message----- >>> From: dev-security-policy >>> >> [mailto:dev-security-policy-bounces+steve_medin=symantec.com@lists.mozilla.o >> >>> rg] On Behalf Of Gervase Markham >>> Sent: Tuesday, September 06, 2016 2:02 PM >>> To: Kyle Hamilton <[email protected]>; >>> [email protected] >>> Subject: Re: Compromised certificate that the owner didn't wish to >>> revoke >>> (signed by GeoTrust) >>> >>>> On 06/09/16 18:25, Kyle Hamilton wrote: >>>> Aruba chose not to notify GeoTrust that it needed to be revoked due to >>>> compromised private key. I am notifying because I believe it >>>> violates the Basic Requirements for someone other than the identified >>>> subject to possess the private key for a publicly-trusted certificate. >>> >>> It does; have you notified GeoTrust using whatever mechanism they make >>> available for such notifications? They are supposed to have one, >>> according >>> to the BRs. I'm not sure posting here would count. >>> > > > Enjoy > > Jakob _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
