Onderzoek: 30 procent sites gebruikt Let's Encrypt-certificaat
Let's Encrypt is de voornaamste certificaatverstrekker op het web, zo blijkt uit onderzoek van Lee Butterman onder ruim 158 miljoen domeinen die een versleutelde verbinding aanbieden. Van de 158,7 miljoen geanalyseerde certificaten waren er 47,2 miljoen afkomstig van Let's Encrypt.
Op de tweede en derde plek volgen DigiCert en Comodo met respectievelijk 28,9 en 13,8 miljoen certificaten. Let's Encrypt is een initiatief van de ISRG en wordt gesteund door Mozilla, Akamai, Cisco, de Amerikaanse burgerrechtenbeweging EFF en andere partijen. Het heeft een volledig versleuteld web als doel en wil dit bereiken door gratis tls-certificaten voor websites uit te geven. Inmiddels maken meer dan 180 miljoen websites gebruik van de certificaten van Let's Encrypt.
Het onderzoek van Butterman laat verder zien dat er meer dan vier miljoen domeinen het verouderde TLS 1.0-protocol gebruiken. Verschillende browserleveranciers hebben aangekondigd dat ze de ondersteuning van TLS 1.0 begin volgend jaar zullen stopzetten, waardoor de websites niet meer zijn te bezoeken. Tevens ontdekte Buttermann 3,7 miljoen domeinen met een verlopen certificaat en duizenden certificaten die na het jaar 3000 verlopen. In vergelijking, de certificaten van Let's Encrypt zijn drie maanden geldig.
Reacties (14)
Voor zover ik weet hebben ze, net als bijna alle andere certificaatverstrekkers, toegang tot de privé sleutels.
10-09-2019, 13:49 door
Briolet
Door Anoniem: Voor zover ik weet hebben ze, net als bijna alle andere certificaatverstrekkers, toegang tot de privé sleutels.
Onderbouw deze zware beschuldigingen. Of houd anders je bek.Door Briolet:
Door Anoniem: Voor zover ik weet hebben ze, net als bijna alle andere certificaatverstrekkers, toegang tot de privé sleutels.
Onderbouw deze zware beschuldigingen. Of houd anders je bek.Helemaal eens met de constatering dat de makers van het certificaat toegang hebben tot de privé sleutel.
1. Om een certificaat te verkrijgen moet de aanvrager het wachtwoord voor het certificaat aan de certificaatverstrekker opgeven waarna het certificaat (sleutelpaar) kan worden gedownload.
2. Uit niets blijkt dat de certificaatverstrekker daarna het gegenereerde certificaat (sleutelpaar) vernietigd.
3. Dit geld voor zover niet tegengesproken voor alle certificaatverstrekkers.
Door Anoniem:
Helemaal eens met de constatering dat de makers van het certificaat toegang hebben tot de privé sleutel.
1. Om een certificaat te verkrijgen moet de aanvrager het wachtwoord voor het certificaat aan de certificaatverstrekker opgeven waarna het certificaat (sleutelpaar) kan worden gedownload.
2. Uit niets blijkt dat de certificaatverstrekker daarna het gegenereerde certificaat (sleutelpaar) vernietigd.
3. Dit geld voor zover niet tegengesproken voor alle certificaatverstrekkers.
LetEncrypt werkt op basis van het ACME protocol, dat staat hier gedocumenteerd:Helemaal eens met de constatering dat de makers van het certificaat toegang hebben tot de privé sleutel.
1. Om een certificaat te verkrijgen moet de aanvrager het wachtwoord voor het certificaat aan de certificaatverstrekker opgeven waarna het certificaat (sleutelpaar) kan worden gedownload.
2. Uit niets blijkt dat de certificaatverstrekker daarna het gegenereerde certificaat (sleutelpaar) vernietigd.
3. Dit geld voor zover niet tegengesproken voor alle certificaatverstrekkers.
https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.html
Waar zie jij de private key en passowrd naar de CA gaan?
Door Briolet:
Door Anoniem: Voor zover ik weet hebben ze, net als bijna alle andere certificaatverstrekkers, toegang tot de privé sleutels.
Onderbouw deze zware beschuldigingen. Of houd anders je bek.Iets meer fatsoen zou je sieren.
Eens dat de onderbouwing mist maar dat is hier tegenwoording in 99% van de gevallen.
?e hebben echt een groot probleem als de KSM van Let's Encrypt wordt gecompromitteerd vanwege juist die proliferatie. Dan heeft het voordeel van beveiligd verkeer weg en most alles opnieuw oo de schop. Daarom was Let's Encrypt ale vanaf aanvang zo'n slecht idee.
luntrus
luntrus
10-09-2019, 17:23 door
Erik van Straten
Door Anoniem: Voor zover ik weet hebben ze, net als bijna alle andere certificaatverstrekkers, toegang tot de privé sleutels.
Huh? Ik ken ze niet. Ik kan echter niet zeggen dat dit nooit gebeurd is, maar dat is wel even geleden - zie https://www.security.nl/posting/10194/Gratis+SSL+cerficaten+niet+te+vertrouwen#posting97944.Uit https://www.heise.de/newsticker/meldung/Vorsicht-bei-kostenlosen-SSL-Zertifikaten-137817.html:
Vorsicht bei kostenlosen SSL-Zertifikaten
24.02.2005 00:12 Uhr, Von Holger Bleich
[...]
Schon bei der Schlüsselerstellung geht StartCom nicht sonderlich seriös vor: Der "Certificate Creation Wizard" erzeugt den Private Key auf dem Server der israelischen Firma und übermittelt ihn dem Website-Betreiber über eine (SSL-gesicherte) Web-Seite. Eine Garantie, dass nicht eine Kopie des geheimen Schlüssels bei StartCom verbleibt, erhält er nicht. Mit einer solchen Kopie wäre es möglich, alle verschlüsselten Verbindungen des Servers zu dechiffrieren. Bei seriösen Anbietern erzeugt der Anwender seinen geheimen Schlüssel lokal; an die CA übermittelt er nur den Zertifizierungsantrag, den diese unterschrieben zurück sendet.
[...]
24.02.2005 00:12 Uhr, Von Holger Bleich
[...]
Schon bei der Schlüsselerstellung geht StartCom nicht sonderlich seriös vor: Der "Certificate Creation Wizard" erzeugt den Private Key auf dem Server der israelischen Firma und übermittelt ihn dem Website-Betreiber über eine (SSL-gesicherte) Web-Seite. Eine Garantie, dass nicht eine Kopie des geheimen Schlüssels bei StartCom verbleibt, erhält er nicht. Mit einer solchen Kopie wäre es möglich, alle verschlüsselten Verbindungen des Servers zu dechiffrieren. Bei seriösen Anbietern erzeugt der Anwender seinen geheimen Schlüssel lokal; an die CA übermittelt er nur den Zertifizierungsantrag, den diese unterschrieben zurück sendet.
[...]
Ik heb de "Certificate Creation Wizard" in het archief van de toenmalige pagina https://web.archive.org/web/20050226033448/https://cert.startcom.org/ niet uitgeprobeerd, maar wie weet werkt dat ook nog op archive.org ;-)
Terug naar nu, noem eens een of meer certificaatproviders die schrijven dat zij het sleutelpaar voor jouw server moeten genereren om jou een certificaat te kunnen verstrekken?
10-09-2019, 18:29 door
eMilt
Helemaal eens met de constatering dat de makers van het certificaat toegang hebben tot de privé sleutel.
Klinkklare onzin! Een CA (Certificate Authority) heeft alleen een CSR (Certificate Signing Request) nodig om een certificaat aan te maken. De private key hoeft hiervoor niet opgestuurd te worden, bij geen enkele CA.Er zijn wel CA's (geweest) die een private key en CSR voor je kunnen / konden aanmaken omdat soms klanten niet weten hoe dit te doen. Je moet er dan maar op vetrouwen dat ze die ook weer weggooien als je deze gedownload. Maar het is zeker geen common practice en al helemaal niet nodig.
Door Anoniem:
https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.html
Waar zie jij de private key en passowrd naar de CA gaan?
Door Anoniem:
Helemaal eens met de constatering dat de makers van het certificaat toegang hebben tot de privé sleutel.
1. Om een certificaat te verkrijgen moet de aanvrager het wachtwoord voor het certificaat aan de certificaatverstrekker opgeven waarna het certificaat (sleutelpaar) kan worden gedownload.
2. Uit niets blijkt dat de certificaatverstrekker daarna het gegenereerde certificaat (sleutelpaar) vernietigd.
3. Dit geld voor zover niet tegengesproken voor alle certificaatverstrekkers.
LetEncrypt werkt op basis van het ACME protocol, dat staat hier gedocumenteerd:Helemaal eens met de constatering dat de makers van het certificaat toegang hebben tot de privé sleutel.
1. Om een certificaat te verkrijgen moet de aanvrager het wachtwoord voor het certificaat aan de certificaatverstrekker opgeven waarna het certificaat (sleutelpaar) kan worden gedownload.
2. Uit niets blijkt dat de certificaatverstrekker daarna het gegenereerde certificaat (sleutelpaar) vernietigd.
3. Dit geld voor zover niet tegengesproken voor alle certificaatverstrekkers.
https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.html
Waar zie jij de private key en passowrd naar de CA gaan?
https://pcmweb.nl/artikelen/nieuws/acme-de-techniek-achter-ssl-certificaat-aanvragen/
In een notendop, de aanvrager hoeft om het certificaat te ontvangen inderdaad geen wachtwoord meer aan de ( certificaatautoriteit) CA te verstrekken. De aanvrager moet middels een procedure die in de link duidelijk wordt uitgelegd met ACME Cliënt encryptie software een op eigen computer een sleutelpaar aanmaken en kan daarmee aantonen dat hij de rechtmatige eigenaar van de website is. Deze techniek geld niet voor email certificaten, en voor zover ik heb begrepen geeft LetsEncrypt die ook niet uit.
Allemaal gekke verhalen hier. Het is heel simpel:
Sommige providers geven de mogelijkheid voor de gemakzuchtige gebruikers van tegenwoordig om automatisch een pair te genereren. Iedereen die dit doet is DOM. Heeft niets met de provider te maken. Ik ben nog nooit een provider tegengekomen die geen CSR kon signen.
Voor de duidelijkheid in een CSR zit geen private key.
https://www.sslcertificaten.nl/support/Terminologie/Certificate_Signing_Request_(CSR)
Sommige providers geven de mogelijkheid voor de gemakzuchtige gebruikers van tegenwoordig om automatisch een pair te genereren. Iedereen die dit doet is DOM. Heeft niets met de provider te maken. Ik ben nog nooit een provider tegengekomen die geen CSR kon signen.
Voor de duidelijkheid in een CSR zit geen private key.
https://www.sslcertificaten.nl/support/Terminologie/Certificate_Signing_Request_(CSR)
Door Anoniem:
Helemaal eens met de constatering dat de makers van het certificaat toegang hebben tot de privé sleutel.
1. Om een certificaat te verkrijgen moet de aanvrager het wachtwoord voor het certificaat aan de certificaatverstrekker opgeven waarna het certificaat (sleutelpaar) kan worden gedownload.
2. Uit niets blijkt dat de certificaatverstrekker daarna het gegenereerde certificaat (sleutelpaar) vernietigd.
3. Dit geld voor zover niet tegengesproken voor alle certificaatverstrekkers.
Door Briolet:
Door Anoniem: Voor zover ik weet hebben ze, net als bijna alle andere certificaatverstrekkers, toegang tot de privé sleutels.
Onderbouw deze zware beschuldigingen. Of houd anders je bek.Helemaal eens met de constatering dat de makers van het certificaat toegang hebben tot de privé sleutel.
1. Om een certificaat te verkrijgen moet de aanvrager het wachtwoord voor het certificaat aan de certificaatverstrekker opgeven waarna het certificaat (sleutelpaar) kan worden gedownload.
2. Uit niets blijkt dat de certificaatverstrekker daarna het gegenereerde certificaat (sleutelpaar) vernietigd.
3. Dit geld voor zover niet tegengesproken voor alle certificaatverstrekkers.
Fout, je maakt ZELF de sleutel paar. Je maakt ZELF het verzoek (deze bevat ALLEEN de publiek sleutel). Deze lever je in en wordt ondertekend. Als je het anders doet, snap je niet wat je doet. Tijd om je te verdiepen in certificaten.
Door Anoniem:
Fout, je maakt ZELF de sleutel paar. Je maakt ZELF het verzoek (deze bevat ALLEEN de publiek sleutel). Deze lever je in en wordt ondertekend. Als je het anders doet, snap je niet wat je doet. Tijd om je te verdiepen in certificaten.
Door Anoniem:
Helemaal eens met de constatering dat de makers van het certificaat toegang hebben tot de privé sleutel.
1. Om een certificaat te verkrijgen moet de aanvrager het wachtwoord voor het certificaat aan de certificaatverstrekker opgeven waarna het certificaat (sleutelpaar) kan worden gedownload.
2. Uit niets blijkt dat de certificaatverstrekker daarna het gegenereerde certificaat (sleutelpaar) vernietigd.
3. Dit geld voor zover niet tegengesproken voor alle certificaatverstrekkers.
Door Briolet:
Door Anoniem: Voor zover ik weet hebben ze, net als bijna alle andere certificaatverstrekkers, toegang tot de privé sleutels.
Onderbouw deze zware beschuldigingen. Of houd anders je bek.Helemaal eens met de constatering dat de makers van het certificaat toegang hebben tot de privé sleutel.
1. Om een certificaat te verkrijgen moet de aanvrager het wachtwoord voor het certificaat aan de certificaatverstrekker opgeven waarna het certificaat (sleutelpaar) kan worden gedownload.
2. Uit niets blijkt dat de certificaatverstrekker daarna het gegenereerde certificaat (sleutelpaar) vernietigd.
3. Dit geld voor zover niet tegengesproken voor alle certificaatverstrekkers.
Fout, je maakt ZELF de sleutel paar. Je maakt ZELF het verzoek (deze bevat ALLEEN de publiek sleutel). Deze lever je in en wordt ondertekend. Als je het anders doet, snap je niet wat je doet. Tijd om je te verdiepen in certificaten.
Was mij inmiddels duidelijk zie (Gisteren, 19:01 door Anoniem). Mijn ervaring was een email certificaat enige jaren geleden voor zover ik herinner bij CA Comodo, waarbij ik een wachtwoord moest invoeren en daarna het certificaat ontving.
Door Anoniem:
Helemaal eens met de constatering dat de makers van het certificaat toegang hebben tot de privé sleutel.
1. Om een certificaat te verkrijgen moet de aanvrager het wachtwoord voor het certificaat aan de certificaatverstrekker opgeven waarna het certificaat (sleutelpaar) kan worden gedownload.
Door Briolet:
Door Anoniem: Voor zover ik weet hebben ze, net als bijna alle andere certificaatverstrekkers, toegang tot de privé sleutels.
Onderbouw deze zware beschuldigingen. Of houd anders je bek.Helemaal eens met de constatering dat de makers van het certificaat toegang hebben tot de privé sleutel.
1. Om een certificaat te verkrijgen moet de aanvrager het wachtwoord voor het certificaat aan de certificaatverstrekker opgeven waarna het certificaat (sleutelpaar) kan worden gedownload.
Onzin. Dan doe je iets verkeerd en snap je het proces niet.
Je privesleutel houd je zelf en geeft je nooit af. Het enige wat de CA voor je doet is om een door jouw gegenereerde certificaat (dat bij jouw privesleutel hoort, maar niet die sleutel zelf) verpakt als een signing request, op jouw verzoek ondertekenen en de ondertekende versie als certificaat weer aan jouw geeft.
Natuurlijk kan je ook vragen dat iemand anders die sleutel voor je maakt, maar als je daarvoor kiest, ben je wel erg stom bezig (en je hebt teveel vertrouwen in die ander).
16-09-2019, 09:28 door
Briolet
Door Anoniem: Helemaal eens met de constatering dat de makers van het certificaat toegang hebben tot de privé sleutel.
1. Om een certificaat te verkrijgen moet de aanvrager het wachtwoord voor het certificaat aan de certificaatverstrekker opgeven waarna het certificaat (sleutelpaar) kan worden gedownload.
1. Om een certificaat te verkrijgen moet de aanvrager het wachtwoord voor het certificaat aan de certificaatverstrekker opgeven waarna het certificaat (sleutelpaar) kan worden gedownload.
De privé sleutel wordt lokaal aangemaakt en verlaat je privé omgeving niet. Je stuurt alleen een certificate signing request (CSR) naar de certificaat verstrekker, zoals anoniem hierboven aangeeft.
Het komt voor dat mensen soms de privé sleutel uit onwetendheid meesturen met de CSR, maar een serieuze verstrekker zal dan vragen een nieuwe privé sleutel aan te maken en dan alleen de CSR op te sturen.
Maar het ging hier over Let's Encrypt en daar loopt alles automatisch. Het zijn ook maar een paar bytes die je systeem verlaten bij de aanvraag. Als daar een privé sleutel tussen zat, viel dat direct op en was het al lang wereldnieuws geweest.
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
