Compromised certificate that the owner didn't wish to revoke (signed by GeoTrust)

[Kyle Hamilton]

As far as I know, GeoTrust is not at fault here. They just signed this
(domain validated) certificate, and I don't know if they've been
notified of it before. That said, I don't have GeoTrust's contact info,
and I'm presuming that someone here does.

Information here comes from
http://blog.sec-consult.com/2016/09/house-of-keys-9-months-later-40-worse.html
. The private key for this certificate was published by SEC Consult (a
Singaporean company) in a public github repo that documents static TLS
keys in embedded device firmware, located at
https://github.com/sec-consult/houseofkeys/ .

Aruba is the OEM for various Alcatel-Lucent OmniAccess firmware. They
embedded a certificate (trusted by GeoTrust) and its private key into
the firmware for more than 10 different models of OmniAccess. This
certificate is in CT logs, and is currently valid until August 11, 2017.
Issuer is OU "C=US, O=GeoTrust Inc., OU=Domain Validated SSL,
CN=GeoTrust DV SSL CA".
Subject is "serialNumber=lLUge2fRPkWcJe7boLSVdsKOFK8wv3MF, C=US,
O=securelogin.arubanetworks.com, OU=GT28470348, OU=See
www.geotrust.com/resources/cps (c)11, OU=Domain Control Validated -
QuickSSL(R) Premium, CN=securelogin.arubanetworks.com".
Serial number is 121426.

The certificate (and the usual information about it) can be found at
https://censys.io/certificates/47fa89956f2aa349e8814b21a7bbd64c9b597f0f192bfe073559945a7a846534
.

The private key for the certificate can be found at
https://github.com/sec-consult/houseofkeys/blob/master/certificates/47fa89956f2aa349e8814b21a7bbd64c9b597f0f192bfe073559945a7a846534.key
or by pulling the aforementioned github repo.

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.

[Gervase Markham]

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.

Gerv

[Jakob Bohm]

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:jeremy...@digicert.com]
> Sent: Tuesday, September 06, 2016 7:06 PM
> To: Steve Medin <Steve...@symantec.com>
> Cc: Gervase Markham <ge...@mozilla.org>; Kyle Hamilton <aero...@gmail.com>;
> mozilla-dev-s...@lists.mozilla.org
> 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 <Steve...@symantec.com> 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=symant...@lists.mozilla.o
>> rg] On Behalf Of Gervase Markham
>> Sent: Tuesday, September 06, 2016 2:02 PM
>> To: Kyle Hamilton <aero...@gmail.com>;
>> mozilla-dev-s...@lists.mozilla.org
>> 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
--
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

[Nick Lamb]

Responding to the scenario Jakob described which I agree is likely in outline

Let's Encrypt has seen a number of enquiries about relaxing their rate limits or granting some sort of exception so that firmware OEMs can use Let's Encrypt to have their devices self-issue using ACME from a name pool controlled by the OEM.

With ACME, out of the box a device can get itself unique, working Web PKI certs periodically so long as:

* It has some source of entropy
* It has an FQDN in the Internet's public DNS or can get one
* It can either make FQDN:80 or FQDN:443 reach it, or add DNS leaf records off the FQDN in the public DNS.

These are all eminently soluble problems and don't involve changes to the manufacturing process, unless entropy has to be somehow "baked in" to the devices to achieve that bullet point.

If you DIY, the rate limits obviously aren't a problem, and lots of DIY devices have Let's Encrypt issued certificates today. Home "routers" built out of a Raspberry Pi or a Mini PC are fairly popular with hobbyists. So rate limits (which exist for a perfectly sensible reason) are the only reason you can't buy a device that does this off the shelf.

[Jernej Simončič]

On Wed, 7 Sep 2016 03:55:02 -0700 (PDT), Nick Lamb wrote:

> If you DIY, the rate limits obviously aren't a problem, and lots of DIY devices have Let's Encrypt issued certificates today. Home "routers" built out of a Raspberry Pi or a Mini PC are fairly popular with hobbyists. So rate limits (which exist for a perfectly sensible reason) are the only reason you can't buy a device that does this off the shelf.

Wouldn't Let's Encrypt's 3-month certificate validity time also pose a
problem for such devices? I'm pretty sure I've bought routers that sat in
some warehouse far longer than 3 months in the past.

--
begin .sig
< Jernej Simončič ><>◊<>< jernej|s-ng at eternallybored.org >
end

[Kyle Hamilton]

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

>>>> 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.
>>>

[Jakob Bohm]

>> ...

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.

[Kyle Hamilton]

On 9/12/2016 20:20, Jakob Bohm wrote:
> On 13/09/2016 03:03, Kyle Hamilton wrote:

> 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

[Jakob Bohm]

>> 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.