Re: Paessler (was Re: Let's Encrypt: Failure to revoke key-compromised certificates within 24 hours)

2020-03-22 Thread Matt Palmer via dev-security-policy
On Sun, Mar 22, 2020 at 07:47:49AM +0100, Hanno Böck via dev-security-policy 
wrote:
> FWIW: Given that with the private key it's easily possible to revoke
> certificates from Let's Encrypt I took the key yesterday and iterated
> over all of them and called the revoke command of certbot.

Yes, I play revocation whack-a-mole every day or two.  I hammer crt.sh's
pgsql replicas each time to get an up-to-date list of all new certs with
keys in the pwnedkeys database, and do the needful.

> I strongly recommend Let's Encrypt (and probably all other CAs)
> blacklists that key if they haven't already done so.

That'll always be the dream... but since at least one CA can't seem to
prevent a customer from getting a new certificate for the same key *while
they're revoking a cert for the same name with the same key because it's
compromised*, I think it's going to take a BR change that forbids reusing a
reported-compromised key before CAs bake in any sort of sensible key
blacklisting.

- Matt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Paessler (was Re: Let's Encrypt: Failure to revoke key-compromised certificates within 24 hours)

2020-03-21 Thread Hanno Böck via dev-security-policy
On Sat, 21 Mar 2020 19:20:27 +
Nick Lamb via dev-security-policy
 wrote:

> Rather than mint an RSA key pair and self-signed certificate to
> bootstrap each install, they just supply a (presumably randomly
> generated) key and certificate right in the install data.

FWIW: Given that with the private key it's easily possible to revoke
certificates from Let's Encrypt I took the key yesterday and iterated
over all of them and called the revoke command of certbot.

They were all already revoked except for the latest [1], which was
issued on the 20th of march.

Now there's this [2] certificate with the same key that apparently got
revoked on the 19th.

I strongly recommend Let's Encrypt (and probably all other CAs)
blacklists that key if they haven't already done so.

[1] https://crt.sh/?id=2603336468
[2] https://crt.sh/?id=2574981982

-- 
Hanno Böck
https://hboeck.de/
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Paessler (was Re: Let's Encrypt: Failure to revoke key-compromised certificates within 24 hours)

2020-03-21 Thread Matt Palmer via dev-security-policy
On Sat, Mar 21, 2020 at 07:20:27PM +, Nick Lamb wrote:
> On Sat, 21 Mar 2020 13:40:21 +1100
> Matt Palmer via dev-security-policy
>  wrote:
> > There's also this one, which is another reuse-after-revocation, but
> > the prior history of this key suggests that there's something *far*
> > more interesting going on, given the variety of CAs and domain names
> > it has been used for (and its current residence, on a Taiwanese
> > traffic stats server):
> > 
> > 
> > https://crt.sh/?spkisha256=69fc5edbd904577629121b09c49b711e201c46213e5b175bbee08a4d1d30b3c7
> > 
> > If anyone figures out the story with that last key, I'd be most
> > pleased to hear about it.
> 
> Sure.

[snip story]

Ha ha!  Nice detective work.  It was the old wildcard for `*.new-access.net`
that threw me for a loop, but I suppose if someone's going to reuse a key,
why not reuse one for a wildcard?

Thanks, I can now sleep a little bit sounder now that I know there isn't
another Debian-style weak PRNG out there.

- Matt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Paessler (was Re: Let's Encrypt: Failure to revoke key-compromised certificates within 24 hours)

2020-03-21 Thread Nick Lamb via dev-security-policy
On Sat, 21 Mar 2020 13:40:21 +1100
Matt Palmer via dev-security-policy
 wrote:

> Oh the facepalm, it burns (probably too much hand sanitizer)... let
> me try that again.

Use soap and water where practical. And, as the BBC Comedy TV show
"That Mitchell & Webb Look" put it many years ago "Remain indoors".


> There's also this one, which is another reuse-after-revocation, but
> the prior history of this key suggests that there's something *far*
> more interesting going on, given the variety of CAs and domain names
> it has been used for (and its current residence, on a Taiwanese
> traffic stats server):
> 
> 
> https://crt.sh/?spkisha256=69fc5edbd904577629121b09c49b711e201c46213e5b175bbee08a4d1d30b3c7
> 
> If anyone figures out the story with that last key, I'd be most
> pleased to hear about it.

Sure.

This requires a small degree of insight into how little ordinary people
(even say IT people) understand about public key cryptography.

These servers are running PRTG - a network monitoring tool from an
outfit named Paessler. The software offers a web interface with SSL.

PRTG is supplied as Windows software, and I have just installed it on
my games PC (hopefully uninstalling it will be easy because this is no
time to go out shopping for a PC) to verify the following:

Rather than mint an RSA key pair and self-signed certificate to
bootstrap each install, they just supply a (presumably randomly
generated) key and certificate right in the install data.

They don't have one of those (often rather archaic but functional) UIs
where it mints new RSA keys and gives you a CSR for them. Instead it
offers either a tool that will convert keys and certificates and
install them, or you can just paste the files into the right place and
restart the software.


Now, for you or me the provided default RSA key is obviously no use and
you'd mint your own with your preferred tools before requesting a
publicly trusted certificate or indeed using your own in-house CA. But
if you don't know much about this stuff and you find there's a perfectly
nice RSA key supplied with the software it seems natural to use it.

Whereupon of course now your "real" publicly trusted certificate is for
a key which in reality is available to anybody with the insight to
guess which software you're using. Oops.

Here's their demo certificate, the associated Private Key is freely
available to download as part of their software, but there's no need
for me to paste it here.

-BEGIN CERTIFICATE-
MIIDpjCCAo6gAwIBAgIJAMM2JGwQ4/iqMA0GCSqGSIb3DQEBBQUAMEAxHjAcBgNV
BAoTFVBSVEcgRGVtbyBDZXJ0aWZpY2F0ZTEeMBwGA1UEAxMVUFJURyBEZW1vIENl
cnRpZmljYXRlMB4XDTEzMDcwODExMTUwNVoXDTIzMDcwNjExMTUwNVowQDEeMBwG
A1UEChMVUFJURyBEZW1vIENlcnRpZmljYXRlMR4wHAYDVQQDExVQUlRHIERlbW8g
Q2VydGlmaWNhdGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCsR6TJ
IF2cRzoUfElst4CxY3q6vnWzZ0U0wrO6pdrVbrWqVcmofC9bxiLpW8AtlsQ0cVAQ
r64juKbivQV6ggpIrFpYE505VDbu6tvqYR8nY2wtNJZNwKhT0hpBNmgujceaDc/q
ghTIzaZGbtzas7HX1g8bBs81mw0TUI+IJNDAz+tbQM0NPxl/BY0LSuRX7ApUp/jn
veUWXzpBb8BbCriQXPeykQuVXF2oWZ4d5B6X8mxl4GhzjmoQsTr0xGi0pWz1Tc0h
Wkcd0hU633Hw1tjL82j8x5uEwy/nrb3ShMOzKtVpsoFA0TBc5BaIgbQvJpBk0Qd6
cfCxnLPjZQj4+AcFAgMBAAGjgaIwgZ8wHQYDVR0OBBYEFO6ncMKuxL4p7cwozSn1
USIYzEK5MHAGA1UdIwRpMGeAFO6ncMKuxL4p7cwozSn1USIYzEK5oUSkQjBAMR4w
HAYDVQQKExVQUlRHIERlbW8gQ2VydGlmaWNhdGUxHjAcBgNVBAMTFVBSVEcgRGVt
byBDZXJ0aWZpY2F0ZYIJAMM2JGwQ4/iqMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcN
AQEFBQADggEBAKm6SueZqG7mVSyls2D/kFPoxsh1inctOeQPHbwMAVMCD68KGlJh
kSicHq7bISy0aSioGRZe6rS12bcYRkqtgg0DjQ+ZmtHPBJTgrXIqZW0jHuqN6vyS
d4IDCNQGrQQgQ+uC6V71EDcM6WDULuDygqdvM2D1gc8u2di8Rp3MpKfHAi8n0yRu
00B+01aqce/EA0b0dBPeJciKfB1cAU3CEGoLNVS/F8skumn7Q/kWwbuyjz0Nb66m
3WJOu1yAXPalEdRHQIiXEbnJgT5YrNU1R74CSdOATSKjk6kkWromGH63onF8wSS0
hh/btapuzGY6VPSscqMh3k9ji0+sPdxy3+U=
-END CERTIFICATE-


Nick.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy