Security Professionals - ipfw add deny all from eindgebruikers to any

Scam? En pubkey hergebruik

Reageer met quote
03-11-2023, 01:30 door Erik van Straten, 12 reacties
In vervolg op https://www.security.nl/posting/816952/Internetbedrijven+slaan+alarm+over+certificaatplan+Europese+digitale+identiteit en mijn reacties daaronder:

last-chance-for-eidas.org - scam of echt?
Op meerdere plaatsen (Mastodon, Reddit, HackerNews) zie ik verwijzingen naar https://last-chance-for-eidas.org/ (archief: https://archive.is/Ilhes). Die site zou gemaakt zijn door Mozilla, maar hoe weet ik of dat echt zo is?

Voor genoemde site zijn op 26 oktober twee Let's Encrypt certificaten toegekend, zie https://crt.sh/?q=last-chance-for-eidas.org (je ziet 4 regels, twee zijn "precertificates" die door browsers als ongeldig horen te worden aangemerkt).

Identieke public key
Toevallig viel het mij op dat beide geldige certificaten dezelfde public key gebruiken:
00:ab:c7:1b:0c:ed:c6:01:f8:ea:a9:b3:cf:08:17:
4f:a2:cb:7c:34:c4:66:12:e6:ef:f3:98:17:79:c9:
65:ee:66:4c:1f:9a:92:7d:33:ee:07:fa:2e:15:62:
f7:b4:f3:1f:d5:4f:2e:b1:67:a8:49:42:bf:e3:cc:
9a:b7:30:46:c2:68:f5:28:a9:64:69:6f:4c:4b:64:
24:c9:dc:ed:46:9f:a4:1f:c2:ef:6f:36:d0:bc:69:
27:b8:e2:d6:18:70:40:2c:b4:f5:ee:8f:f7:0d:8c:
6e:03:92:e7:5d:d6:3e:bc:bb:c9:5b:28:10:a0:5a:
f6:37:f5:e1:9e:15:23:72:6e:8e:69:01:09:a4:8c:
a4:c9:d7:db:05:01:90:48:4b:90:20:8c:38:7a:0a:
60:74:79:18:26:30:8e:60:0b:17:b9:24:a0:80:df:
3f:14:00:d3:09:e7:34:47:35:63:7c:54:d2:a0:9d:
e1:57:d1:cb:13:d3:3c:30:24:97:8e:ea:34:00:9f:
cc:6c:0c:6a:f7:54:bc:5e:60:dc:46:31:c2:09:de:
d9:c3:e3:63:1e:8f:1c:c5:90:90:e8:da:86:be:7d:
f1:c3:1f:1a:86:69:9b:0b:e0:b2:0c:47:08:c8:92:
59:2b:66:2f:fa:a1:38:a1:2f:10:65:f6:97:fd:16:
87:33

Genoemde site verwijst naar een "open letter" op https://eidas-open-letter.org/ (die site stuurt je browser momenteel door naar https://nce.mpi-sp.org/index.php/s/cG88cptFdaDNyRr, hoe vaag wil je het hebben - maar hier ga ik niet verder op in).

Volgens https://crt.sh/?q=eidas-open-letter.org zijn er 4 geldige certificaten voor deze site. Allen gebruiken dezelfde public key als boven.

Daar blijft het niet bij
Googlen naar "00:ab:c7:1b:0c:ed:c6:01:f8:ea:a9:b3:cf:08:17" (inclusief de "") laat zien dat er nog veel meer websites bestonden/bestaan met een certificaat met diezelfde public key, met een aantal vermeldingen op Virustotal (zo te zien zonder dat iets kwaadaardigs werd aangetroffen).

Zo vond ik exact diezelfde public key terug in https://github.com/liferay/alloy-editor/issues/1229#issuecomment-486554385 - voor "alloyeditor.com" geldig vanaf 23 april 2019 en een ander cert voor "www.alloyeditor.com" - geldig vanaf 9 april 2019.

Via https://crt.sh/?q=alloyeditor.com kun je zien dat "[www.]alloyeditor.com" inderdaad die public key gebruikte, om precies te zijn vanaf https://crt.sh/?id=1374476805, zo te zien t/m https://crt.sh/?id=9066527137 (geldig tot 2 juli 2023).

Via https://crt.sh/?q=rocknsm.io ondekte ik dat "onze" public key al in gebruik is sinds zeker 19 augustus 2018 (zie https://crt.sh/?id=753233320 en ook voor die site nog geldig is: https://crt.sh/?id=10698016497).

Wat is hier aan de hand?
Hoewel het in alle gevallen om Let's Encrypt certificaten lijkt te gaan, is het niet Let's Encrypt die de sleutelparen genereert. Aanvankelijk vreesde ik wel voor een versie van ACME die een hardcoded sleutelpaar gebruikt (of een dode CSPRNG), maar dat lijkt onjuist.

Een overeenkomst tussen alle sites lijkt te zijn dat hun IPv4 adressen beginnen met 185.199 - dat kan geen toeval zijn. Het lijkt om sites van/via Fastly te gaan. Kennelijk heeft Fastly het probleem van shared hosting "opgelost" door één sleutelpaar voor verschillende virtuele sites te gebruiken, die wél allemaal een privé certificaat krijgen - dat op het eerste gezicht meer vertrouwen zou kunnen wekken dan uiterst "gezellige" certificaten (met tig ongerelateerde domeinnamen) zoals bijvoorbeeld https://crt.sh/?q=jagersbouw.nl.

De "oplossing" voor privé-certificaten leidt wel tot een probleem: je kunt het sleutelpaar niet eenvoudig vervangen, want de certificaten zijn gedurende verschillende (overlappende) periodes geldig.

Conclusie
Notabene van een website die het heeft over "Secret EU law threatens Internet security" kan ik niet opmaken of deze echt is of nep. Bovendien bevat het certificaat een public key uit een sleutelpaar dat al meer dan 5 jaar gebruikt wordt (en niet Let's Encrypt, maar ik kom daar -toevallig- achter).

eIDAS QWACs gaan het internet er waarschijnlijk niet veiliger op maken, maar onveiliger kan nauwelijks.
Reacties (12)
Reageer met quote
03-11-2023, 08:49 door Anoniem
Oei !
Nu ben ik benieuwd naar de reakties hierop.

Noob
Reageer met quote
03-11-2023, 10:22 door Anoniem
Wellicht heeft het te maken met een oplossing voor het registreren van de certificaten via DNS (CERT), waarbij je normaal met het probleem zit dat iedere keer dat je een andere key gebruikt ook een nieuw DNS CERT record moet worden aangemaakt.
Dat geeft een hoop gedoe en de "oplossing" die men dan suggereert is je key niet veranderen bij re-issue van je certificaat.
In een shared hosting omgeving zou dat wellicht kunnen betekenen dat iedereen dezelfde key gebruikt en ook blijft gebruiken.
Reageer met quote
03-11-2023, 21:55 door Anoniem
download een pem van het certificaat
__$ openssl x509 --in bangumiapp-skyperfectv-co-jp.pem --text
zie x.509v3 extension Subject Alternative Names, lees rfc4985, geen scam, wel handig
Reageer met quote
06-11-2023, 15:30 door majortom
Dat betekent dus hergebruik van de sleutelparen voor verschillende doeleinden. Dat lijkt me niet een goede security practice (mogelijk worden dus ook de private keys (die dan niet meer private zijn) gedupliceerd over meerder locaties. Dat betekent dan ook dat alleen deze sleutelparen nooit vervangen gaan worden. Maak dan de certificaten meteen maar 30 jaar geldig, want dan heeft een beperkte geldigheid ook geen zin meer.

Ik heb zelf op mijn VPS ook meerdere "hosts" en zie het probleem niet om deze allen van een eigen certificaat met uniek keypair te voorzien. Dus welk probleem probeert men hier dan op te lossen?

Ik zie alleen een security probleem ontstaan.
Reageer met quote
06-11-2023, 15:45 door Anoniem
Door majortom: Dat betekent dus hergebruik van de sleutelparen voor verschillende doeleinden. Dat lijkt me niet een goede security practice (mogelijk worden dus ook de private keys (die dan niet meer private zijn) gedupliceerd over meerder locaties. Dat betekent dan ook dat alleen deze sleutelparen nooit vervangen gaan worden. Maak dan de certificaten meteen maar 30 jaar geldig, want dan heeft een beperkte geldigheid ook geen zin meer.
Dan begrijp jet het verschil tussen een private key en een signed certificaat niet!
Reageer met quote
07-11-2023, 09:08 door majortom
Door Anoniem:
Door majortom: Dat betekent dus hergebruik van de sleutelparen voor verschillende doeleinden. Dat lijkt me niet een goede security practice (mogelijk worden dus ook de private keys (die dan niet meer private zijn) gedupliceerd over meerder locaties. Dat betekent dan ook dat alleen deze sleutelparen nooit vervangen gaan worden. Maak dan de certificaten meteen maar 30 jaar geldig, want dan heeft een beperkte geldigheid ook geen zin meer.
Dan begrijp jet het verschil tussen een private key en een signed certificaat niet!
Ik denk dat jij het niet snapt: je hebt de private key nodig in combinatie met een signed certificate, anders kun je nooit bewijzen dat jij de rechtmatige eigenaar van het signed certificate bent.
Reageer met quote
07-11-2023, 11:35 door Anoniem
Waarom denk jij dat het gebruiken van steeds dezelfde private key betekent "Maak dan de certificaten meteen maar 30 jaar geldig, want dan heeft een beperkte geldigheid ook geen zin meer"?
Dat slaat namelijk nergens op.
Reageer met quote
07-11-2023, 16:45 door majortom
Door Anoniem: Waarom denk jij dat het gebruiken van steeds dezelfde private key betekent "Maak dan de certificaten meteen maar 30 jaar geldig, want dan heeft een beperkte geldigheid ook geen zin meer"?
Dat slaat namelijk nergens op.
Vanwegede volgende zin
De "oplossing" voor privé-certificaten leidt wel tot een probleem: je kunt het sleutelpaar niet eenvoudig vervangen, want de certificaten zijn gedurende verschillende (overlappende) periodes geldig.
In de praktijk betekent dit dus dat, wanneer iets problematisch is, het niet meer plaatsvindt. Dan kun je wel nieuwe certificaten uitgeven met beperkte geldigheid, maar als het sleutelpaar niet wijzigt dan schiet je met die renewal niet veel op. De sleutelparen zouden ook vervangen moeten worden (rekey), net zoals je je wachtwoord regelmatig vervangt door een nieuwe.

Ook bij compromitatie van de private key (die kans wordt groter naarmate je de key meer hergebruikt) is problematisch: normaal gesproken zou je dan 1 certificaat revoken, echter in dit geval zou je in zo'n geval alle certificaten moeten revoken die hetzelfde sleutelpaar gebruiken.

Zoals ik al eerder opmerkte: ik zie niet welk "probleem" met deze aanpak wordt opgelost; wel zie ik een heleboel andere problemen ontstaan door deze aanpak.
Reageer met quote
07-11-2023, 19:23 door Anoniem
Door majortom: Dat betekent dus hergebruik van de sleutelparen voor verschillende doeleinden. Dat lijkt me niet een goede security practice (mogelijk worden dus ook de private keys (die dan niet meer private zijn) gedupliceerd over meerder locaties. Dat betekent dan ook dat alleen deze sleutelparen nooit vervangen gaan worden. Maak dan de certificaten meteen maar 30 jaar geldig, want dan heeft een beperkte geldigheid ook geen zin meer.

Ik heb zelf op mijn VPS ook meerdere "hosts" en zie het probleem niet om deze allen van een eigen certificaat met uniek keypair te voorzien. Dus welk probleem probeert men hier dan op te lossen?

Ik zie alleen een security probleem ontstaan.

Zou Google dan voor elk "doeleind", of voor elke host, een apart sleutelpaar beheren? Lijkt mij veel practischer om dezelfde private key te gebruiken voor dezelfde categorie services zoals https of email. Dat zijn vast heel erg veel servers. Dan kun je bij wijzigingen een maal op alle hosts dezelfde private key vervangen e.d. als een key compromised is dan revoke je een certificaat en vervang je die op alle hosts. De hosts zijn allemaal zelf al "private" dus daar kan je als je dat goed doet veilig keys plaatsen. Deze kun je niet lezen. als je naar het certificaat van Google kijkt zie je precies hetzelfde, YouTube en andere diensten vallen blijkbaar onder hetzelfde certificaat. Een private key managen is al moeilijk, laat staan miljoenen voor elke server of loadbalancer een.
Reageer met quote
07-11-2023, 21:16 door Anoniem
Nee dat klopt niet, de geheime key van je certificaat is niet de signing key, dat is de key van de certificaatuitgever.
En het revoken van je certificaat gebeurt niet op basis van je eigen geheime key maar op het serienummer van je certificaat.
Reageer met quote
08-11-2023, 06:24 door Anoniem
Door majortom: Ik denk dat jij het niet snapt: je hebt de private key nodig in combinatie met een signed certificate, anders kun je nooit bewijzen dat jij de rechtmatige eigenaar van het signed certificate bent.
(Andere anoniem hier)
Zonder privésleutel kan je helemaal geen versleutelde verbinding opzetten met iemand die de bijbehorende publieke sleutel gebruikt. Je bewijst met je privésleutel niet dat je een certificaat bezit, het certificaat dient als bewijs dat de publieke sleutel bij een identiteit hoort, bijvoorbeeld een hostnaam. Je bewijst dat je het certificaat bezit doordat de server als onderdeel van de TLS handshake het certificaat aan de client verstrekt. Dat de versleutelde communicatie vervolgens lukt is wat bewijst dat je behalve het certificaat ook de privésleutel bezit.

Als niet alles met elkaar klopt lukt de TLS-verbinding niet, en in zekere zin kan je dan zeggen dat elk onderdeeltje de rest "bewijst". Maar een privésleutel heeft niet als doel om te bewijzen dat je rechtmatig eigenaar van een certificaat bent, het is juist het certificaat dat dient om een bewijs toe te voegen aan het geheel.

PS. Ik gebruik bewust de formulering "dient als bewijs" en niet "is het bewijs" om niet te suggereren dat een certificaat een waterdicht bewijs is.

Door Anoniem: Nee dat klopt niet, de geheime key van je certificaat is niet de signing key, dat is de key van de certificaatuitgever.
En het revoken van je certificaat gebeurt niet op basis van je eigen geheime key maar op het serienummer van je certificaat.
Was dit ook een antwoord op majortom? Nu is niet duidelijk voor anderen waar het "dat" in "Nee dat klopt niet" precies aan refereert, en dat is nogal bepalend voor waar je antwoord eigenlijk over gaat.

Geef dus alsjeblieft even expliciet aan waarop je antwoordt, bijvoorbeeld door "reageer met quote" te gebruiken (en zo nodig zelfs het deel weg te slopen waar "dat" niet aan refereert). Anders wordt het op een plek waar meer mensen meepraten heel makkelijk een puzzel om nog uit te vogelen wat je nou precies aan het zeggen bent, mogelijk zelfs voor degene op wie je reageert.
Reageer met quote
08-11-2023, 09:56 door Anoniem
de certificaten van in firefox zijn ook niet veilig heb ik wat gemist????
Reageren
Ondersteunde bbcodes
Bold: [b]bold text[/b]
Italic: [i]italic text[/i]
Underline: [u]underlined text[/u]
Quote: [quote]quoted text[/quote]
URL: [url]https://www.security.nl[/url]
Config: [config]config text[/config]
Code: [code]code text[/code]

Je bent niet en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.

Zoeken
search