Alle browsers ondersteunen nu de gratis ssl-certificaten van Let's Encrypt

Gebruikers wier browser geen sites wil openen die van de gratis ssl-certificaten van Let's Encrypt gebruikmaken, hoeven niet meer handmatig hun instellingen aan te passen om een beveiligde verbinding op te kunnen zetten met deze sites.

Alle webbrowsers ondersteunen de ssl-certificaten van Let's Encrypt inmiddels. Josh Aas van de Internet Security Research Group meldt dat het initiatief inmiddels cross-signatures van IdenTrust ontvangen heeft. De root-certificaat van IdenTrust wordt vertrouwd door alle grote browsers en Let's Encrypt kan als tussen-ca hierop meeliften dankzij het cross-signen.

Let's Encrypt heeft een Hello World-pagina opgezet om aan te tonen dat browsers de site via https kunnen openen zonder dat de gebruiker het certificaat handmatig hoeft te importeren. Dat was half september nog wel nodig, toen de organisatie haar eerste certificaat uitvaardigde. Zowel het Authority X1- als het Authority X2-certificaat wordt vertrouwd door de browsers.

Let’s Encrypt is een initiatief dat zoveel mogelijk sites via https benaderbaar wil maken, door gratis ssl-certificaten te verstrekken en het gebruik ervan te vergemakkelijken. Het project is onderdeel van het Encrypt the Web-project van de Electronic Frontier Foundation. De EFF werkt hiervoor samen met Mozilla, Cisco, Akamai, IdenTrust en onderzoekers van de universiteit van Michigan.

Reacties (122)

[Bor]

There's no such thing as a free lunch. Ik vraag mij af waar het geld vandaan zal moeten komen om de benodigde infrastructuur / procedures en personeel en huisvesting van te gaan betalen. Nu is het aanbieden van gratis certificaten een nobel streven maar ergens zal er geld binnen moeten komen, zeker wanneer je het eea veilig wilt houden (want security kost nu eenmaal geld).

[walkstyle]

Daarom hebben ze ook sponsors (https://letsencrypt.org/sponsors/) zoals Akamai, Mozilla, Cisco, Automatic(Wordpress) en meer. Het is ook onderdeel van de Linux Foundation.

[gooos]

Als je er blij mee bent dan is een (kleine) donatie ook niet misplaatst enne... vele kleine donaties maken ook een groot bedrag beschikbaar.

[Gomez12]

Deels hoeft de benodigde infra / personeel absoluut niet groot te zijn.
Het zijn niet echt de bank-certificaten die ze hier uitgeven... Dus eigenlijk hoeven ze niets te checken.
En dan is het enkel genereren en opslaan en uitgeven zonder enige menselijke tussenkomst.

Plus dat het ook bij de grotere partijen een redelijk issue is hoeveel een cert kost. Het klinkt allemaal als heel weinig, maar als je server aantallen zoals akamai hebt dan is het alsnog een giga-kostenpost die ze hiermee kunnen afschrijven.

[CAPSLOCK2000]

There's no such thing as a free lunch. Ik vraag mij af waar het geld vandaan zal moeten komen om de benodigde infrastructuur / procedures en personeel en huisvesting van te gaan betalen. Nu is het aanbieden van gratis certificaten een nobel streven maar ergens zal er geld binnen moeten komen, zeker wanneer je het eea veilig wilt houden (want security kost nu eenmaal geld).

In het artikel staat dat het komt van de EFF, Cisco, Akamai, IdenTrust en onderzoekers van de universiteit van Michigan. De volgende vraag is dan waarom ze het geven.
De EFF vertrouw ik er op dat ze het doen uit ideele redenen.
De universiteit doet natuurlijk mee omdat het een leuk onderzoek is.
Cisco en Akamai hebben belang bij een groot en succesvol internet, daar verdienen ze hun geld mee. Die steunen dus alles waar internet van groeit.
IdenTrust zal wel hopen dat er meer interesse voor SSL komt waardoor zij meer van hun dure certificaten kunnen verkopen. Misschien dat ze ook wel een vinger aan de pols willen houden bij een potentiele concurrent. Of het zijn gewoon nerds die technologie leuk vinden.
Er zijn nog veel meer donateurs en die zullen hun eigen redenen hebben om SSL te steunen, ik geloof niet dat het de bedoeling is dat dit project direct geld gaat verdienen.

[Reactie gewijzigd door CAPSLOCK2000 op 23 juli 2024 10:05]

[D11]

Heb me gelijk ingeschreven voor het beta programma, zodat ik mijn prive domein onder https kan draaien.

Wordt dit de doodsteek voor de reguliere Certificaat Autorities? Of is DNSSec hier een betere kandidaat voor?

[CH4OS]

DNSSec zorgt niet dat het dataverkeer tussen client en server versleuteld is dat doet TLS/SSL wel.

Of dit de doodsteek gaat zijn voor reguliere CA's? Geen idee, ik denk het niet. Gratis certificaten zijn vaak beperkt, bijvoorbeeld aan slechts 1 domein. Wil je meer, dat kan, maar dan moet je dus betalen. Zou mij niet verbazen als een dergelijk verdien model ook bij Let's Encrypt komt.

[Reactie gewijzigd door CH4OS op 23 juli 2024 10:05]

[CAPSLOCK2000]

DNSSec zorgt niet dat het dataverkeer tussen client en server versleuteld is dat doet TLS/SSL wel.

Hij heeft het over DANE (DNS-based Authentication of Named Entities).

Het idee is dat je via DNS publiceert welk certificaten je gebruikt. De webbrowser van je bezoekers kan zo controleren dat het certificaat van je website echt van jou is. Daar is dus geen CA meer bij nodig, je kan net zo goed een self-signed certificaat gebruiken.
Op een bepaalde manier lijkt dat op hoe veel DV-certificaten werken, daar moet je ook iets in DNS publiceren om te bewijzen dat jij de eigenaar van het domein bent.

DNSSEC wordt bij beide systemen gebruikt om DNS te beveiligen tegen spoofing zodat je ook echt op die info kan vertrouwen.

[WaaaghNL]

Ik denk dat het voor de grotere bedrijven een doodsteek krijgen voor hun DV certs. Gezien LE alle domeinen op je server in een DV cert gooien. Hier door kan je dus eigenlijk het zelfde doen als met een wildcard, en dit zonder extra kosten. Als ik het persoonlijk goed begrijp kun je zelfs op het moment dat je een domein op je server toevoegt een nieuw certificaat genereren en installeren die dat domein ook opneemt. Ik weet van verschillende video's dat ze met de grote hosters als GoDaddy bezig zijn om dit op die manier in te zetten. Dan komt er wel degelijk een doodsteek voor de DV handel!

[The Zep Man]

Ik denk dat het voor de grotere bedrijven een doodsteek krijgen voor hun DV certs.

Wildcard-certificaten kan je ook verkrijgen met DV. Ik twijfel of Let's Encrypt die uit gaat geven. En in een certificaat kan je volgens mij maar zoveel domeinen stoppen.

Let's Encrypt certificaten zijn handig als je een enkele of een paar webservers hebt. Zodra je ook andere diensten gaat aanbieden die niet door hun software ondersteund worden (mailservers, etc.) is een wildcard certificaat simpeler in beheer.

Gratis is leuk voor de thuis- en kleine gebruiker. Voor de grotere jongens zal het huidige systeem voldoende zijn.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 10:05]

[Gomez12]

[...]
Gratis is leuk voor de thuis- en kleine gebruiker. Voor de grotere jongens zal het huidige systeem voldoende zijn.

Totdat je weer de nog grotere jongens krijgt (Akamai en co) waar deze kleine kostenpost per cert toch een grote kostenpost is op het totaal.

[Gomez12]

reguliere CA's zullen nog steeds de "echte" Certificaten uitgeven waar verificatie achter zit etc.

Dit soort certificaten zijn leuk voor om je persoonlijke webpage op https te krijgen, maar als bank neem je hier geen genoegen mee.

[marcelvb]

reguliere CA's zullen nog steeds de "echte" Certificaten uitgeven waar verificatie achter zit etc.

Dit soort certificaten zijn leuk voor om je persoonlijke webpage op https te krijgen, maar als bank neem je hier geen genoegen mee.

Wat is dan het verschil volgens jou tussen "echte" en "niet echte" certificaten?

[Gomez12]

De handmatige verificatie die erachter zit en waarvoor je betaald.
Zodat ik in mijn browserbalk echt zie staan dat het echt de ABN-AMRO / ING is

Tenminste, het doorgestreepte stuk wilde ik opschrijven, maar ik checkte het eerst even met Safari / Abnamro en ik kan op het eerste gezicht niets meer zien / vinden dan een slotje en een groene balk.
Ik meen dat ik in Chrome wel kan zien aan wie die is uitgegeven en wat het beveiligingsnivo etc is van een certificaat (wat dus bij een gratis lager zal zijn) alleen bij een Safari op Mac kon ik het zo snel niet vinden.

Edit : Gevonden, op het slotje klikken alleen dat blijkt nou nergens echt duidelijk uit, ook als ik dan de info bekijk zie ik enkel een subject aanvrager in de vorm van ABN staan maar nergens dat dit nou beter geverifieerd is dan een bijna self-certified certificaat.
Dus helaas moet ik het met je eens zijn.

Qua verificatie zit er verschil tussen, technisch zit er verschil tussen. Maar als consument kan ik amper het verschil zien, dus in de praktijk zie ik geen verschil.

[marcelvb]

Dat was mijn punt inderdaad. Als een tweaker het verschil al niet ziet, wie dan wel? Het is vooral belangrijk dat de verbinding ge-encrypt is en dat je op de site zit waarvan je het adres hebt ingetypt.

[Gomez12]

Adres zegt ook steeds minder en minder met de vele tld's.

Is www.ing.amsterdam nou fout of de vestiging in Amsterdam, is www.ing.tv nou spam of een speciaal adres voor de tv-reclames.

Registreer een www.ing.museum en naak een leuk spam-mailtje over dat ING een speciale aanbiedingsjaar heeft voor allerlei musea en daarom ook een speciale site heeft geïntroduceerd en het klinkt nog goed ook.

Gewoon even een random godaddy gedaan op dat ik www.ing.nl wil hebben (kan niet is schijnbaar al bezet) krijg ik daaruit dus bijv wel als beschikbaar :
ing.tips
ing.company
ing.technology
ing.training
ing.clothing
ing.singles
ing.academy
ing.graphics

Registreer er eentje van, stuur een brief / mailing (geen elektronische) naar het halve kvk-bestand met mooi neergezet waarom je als ing die site hebt opgezet en welke doelgroep je probeert te bereiken en de bezoekers komen vanzelf.

Niemand weet straks meer of het nou .nl of .friesland of toch .amsterdam was en als al die partijen ook weer SSL-certificaten kunnen aanvragen gratis die weer niet van EV-certs te onderscheiden zijn, tja dan kan je je lol op.

[marcelvb]

Daarom ben ik er ook op tegen dat bedrijven zoveel domeinen gebruiken. Veel bedrijven maken voor elke reclamecampagne of afdeling een apart domein aan. Op die manier weet je dus als bezoeker nooit op je van doen heb met een echte of nepsite.

Wat ING betreft, weet iedereen wel dat ing.nl de officiële site is. Maar als ze gaan komen met inghypotheken.nl en ingbeleggen.nl, dan weet niemand het meer. Zelfde geldt voor verschillende TLDs. Kies liever bv. voor ing.nl/hypotheken. ING doet dit trouwens al goed.

[aikebah]

Als consument zie jet het verschil juist wel, door het groene balkje net de validated bedrijfsnaam (bij een EV SSL certificaat) tegenover een grijs slotje (bij een DV SSL certificaat, zoals bijvoorbeeld de Hello-world pagina van Let's Encrypt). En als tweaker kun je het daarnaast nog afleiden uit de details van het certificaat (issued by Symantec Class 3 EV SSL CA - G3, die geeft enkel de EV (Extended Validation) certificaten uit)

[keesdewit]

Kon al veel langer: http://www.startssl.com/

[SA007]

Startssl is ivm letsencrypt verschikkelijk omslachtig.

Letsencrypt is 1 commando draaien en klaar.

StartSSL is een csr genereren, een mailserver inrichten zodat je admin@ hebt, mailverificatie doen, dan handmatig keys instellen, certs downloaden etc.

Daarnaast is startssl niet gratis, een simpel cert voor non-profit dingen is gratis, revoken is duur, wildcard heeft opeens extra verificatie nodig en is duur, etc.

[Warbringer]

Hier ben ik ontzettend blij mee! Niet langer meer 'verplicht' om certificaten af te nemen van dure bedrijven of om je eigen root certificaten van je eigen CA overal te moeten installeren. Meteen maar eens een CSR bij ze neerleggen

[gooos]

Wat is duur... ik betaal net geen 5 dollar op jaarbasis voor mijn Comodo PositiveSSL certificaten

Neemt trouwens niet weg dat ik wel degelijk naar Let's Encrypt certificaten ga kijken want eerlijk gezegd geef ik die 5 dollar per certificaat ook liever aan andere dingen uit. Heb nu 8 domeinnamen met certificaten dus als ik de helft van de kosten die ik nu heb doneer aan Let's Encrypt dan is dat een win-win.

[Reactie gewijzigd door gooos op 23 juli 2024 10:05]

[Verwijderd]

5 dollar is niet duur, maar als je een paar honderd servers beheert gaat het aardig in de papieren lopen.

Overigens is de prijs niet het enige mooie aan letsencrypt. Vooral de tools om eenvoudig een certificaat te verkrijgen en te installeren maken het erg prettig.

[gooos]

Eens. Bij een boel servers kan het inderdaad in de papieren lopen, maar als je er zoveel beheert mag ik hopen dat je toch ook inkomsten ervan hebt. Als dan een SSL verbinding gewenst is, dan kan er ook voor betaald worden, toch?

Ik heb 8 certificaten momenteel, dus de kosten voor mij zijn relatief beperkt. Moet er wel bij zeggen dat 6 van de certificaten voor websites zijn die ik voor vrienden beheer en ik sponsor hun SSL certificaten aangezien ik de toegevoegde waarde ervan zie.

[Lisadr]

Waar koop je het voor 5 dollar?

[gooos]

Heb je een PM gestuurd.

SSLs.com

[Reactie gewijzigd door gooos op 23 juli 2024 10:05]

[dragonlords1]

Ik vind dat al relatief duur aangezien je zelf een certificaat kan maken op je server voor niets. Natuurlijk wordt het dan niet vertrouwd.

[MsG]

Dan is het hele idee toch ook weg van zo'n certificaat? Als je verwacht dat je bezoekers hem handmatig gaan toevoegen.

[xleeuwx]

Een wildcard domein das duur

[Woutske]

35 euro per jaar...

[lrietveld]

Bron? Heb onlangs gezocht en inderdaad alleen duurdere oplossingen gevonden. 35 euro klinkt erg goedkoop

[Yggdrasil]

Dat vind ik ook te goedkoop klinken. De goedkoopste die ik vond is van StartSSL.com voor €52 ($59). Bij xolphin.nl ben je zo'n €75 kwijt. In mijn ervaring ben je elders duurder uit, dus waar die €35 vandaan komt...?

[onedutch]

Link please.. 35 Euro ..

[Woutske]

Oeps ik had dat betaald om hem te 'verlengen'. Prijs is 75 euro normaal, stuk hoger dan 35 inderdaad. Vind het nog steeds geen eind van de wereld, is 6 euro per maand.

[CH4OS]

Een SSL certificaat is zo duur als je zelf wilt. Er zijn goede hosters, die een tientje per jaar vragen voor hun simpelste certificaat. Geen idee of dat al jouw definitie van duur is, maar dat is nog geen euro in de maand.

[Warbringer]

(ook een reactie op Gooos)

Gelukkig zijn de tijden van honderden euro's per certificaat (verisign/thawte) per jaar wel voorbij. Met bedrijven als Komodo en GoDaddy (alhoewel ik kots op GoDaddy) heb je al certificaten voor onder een tientje per jaar. Dat is prima als je *.tweakers.net doet en er maar 1 nodig hebt. Doe je serviceA.tweakers.net tot en met serviceZ.tweakers.net dan heb je er al 26 nodig. Ik heb zo al 11 certificaten nodig voor 1 domein dus dat is al 110 euro en ik ben toch een echte Nederlander

Verder wil ik gewoon het initiatief steunen van de open-source community dus wanneer ze certificaten aan het publiek gaan leveren zet ik mijn spul om naar let's encrypt.

[demonic]

noob vraag,

waarom zou je voor sub-domeinen opnieuw een certificaat aanvragen, ipv een wildcard-certificaat gebruiken?

[ari3]

Omdat als het wildcard certificaat onverhoopt ingetrokken moet worden je meteen een groot aantal servers gelijktijdig moet vernieuwen. Niet iedere organisatie kan of wil dit.

[Warbringer]

Als je serviceA.tweakers.net tot en met serviceF.tweakers.net hebt kun je 6 certificaten met subdomeinen registreren. Je kunt ook een wildcard certificaat pakken voor *.tweakers.net en dan vang je daarmee serviceA t/m serviceF mee af en eventueel serviceG, H en I. Slim toch?

Nou, er zit ook een nadeel aan. Als je certificaat gestolen wordt (dit was een van de redenen waarom de Heartbleed bug so gevaarlijk was) dan zijn dus ineens al je sites niet meer veilig. Hackers richten misschien zelf een site op met serviceZ.tweakers.net als naam waarbij jij denkt echt op Tweakers te zitten vanwege het slotje, maar dat is dus niet het geval. Dat laatste is niet makkelijk en vergt nog wel wat DNS exploitation maar het is niet onmogelijk.

Verder is het lastiger als er ooit een certificaat ingetrokken moet worden. Je kunt dan alleen maar je wildcard certificate intrekken en ipv. heel specifiek het certificaat van 1 van je subdomeinen. De impact is daarmee mogelijk groter op je infrastructuur, vooral als je public-facing websites hebt die erop vertrouwen dat je veilig bent, zoals banken.

[ZeromaNoiS]

Misschien is het een idee een wildcard certificaat aan te schaffen als je voor meerdere sub domeinen een certificaat nodig hebt?!

Bij startssl niet zo duur, maar binnenkort dus gratis.

[Reactie gewijzigd door ZeromaNoiS op 23 juli 2024 10:05]

[.oisyn]

StartCom SSL is ook gratis voor DV certs. www.startssl.com

[_JGC_]

Alleen niet commercieel gebruik en max 1 jaar geldig. Ik bestel certificaten altijd per 3 jaar, scheelt gedoe met vervangen elk jaar.

[.oisyn]

Hun class 1 free certs zijn in principe gewoon commercieel in te zetten als je dat wilt.

quote: http://www.startssl.com/?app=1

The StartCom Certification Authority, provides the StartSSL™ Free certificates instantly, without limitations and free of charge under the condition, that the subscriber provides his/her complete, correct personal details and accepts the Subscriber Obligations of the StartCom CA Policy.

Die policy gaat verder voornamelijk over het aanvraagproces (dat je bent wie je zegt en je het betreffende domein ook echt beheert, etc)

[Reactie gewijzigd door .oisyn op 23 juli 2024 10:05]

[Verwijderd]

Ben blij dit initiatief te zien, eigenlijk zou alles encrypted moeten zijn op het web. Nu is het vooral "het kost geld" en "het is extra belasting".

Dat eerste gaat hiermee vervallen, dat 2e is een urban myth aangezien decryptie in vele CPU instructie sets zitten en bij goed belaste servers van Google werd al aangetoond dat SSL vs niet SSL 1% cpu load scheelde.

Oa op https://istlsfastyet.com/

Het is voornamelijk een kwestie van goed configureren. Als iedereen SSL doet en browsers eerst een site checken op HTTPS ipv HTTP en websites HSTS gaan instellen https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security dan weten we zeker dat er minder kans is op fouten bij websites die http en httpS door elkaar gebruiken waardoor soms inlog delen over http te bereiken zijn terwijl er een ssl (tls) certificaat aanwezig is. Zeker gezien de toename in wifi.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 10:05]

[deadinspace]

Ben blij dit initiatief te zien, eigenlijk zou alles encrypted moeten zijn op het web. Nu is het vooral "het kost geld" en "het is extra belasting".

Dat eerste gaat hiermee vervallen, dat 2e is een urban myth

Nou, urban myth is wel een beetje overdreven hoor. Op een van onze sites:

• % ab -c4 -t5 'http://####.nl/' | grep Requests
• Requests per second: 397.82 [#/sec] (mean)
• % ab -c4 -t5 'https://####.nl/' | grep Requests
• Requests per second: 123.16 [#/sec] (mean)

Dus dat is nogal een significant verschil. Overigens is dat voor ons geen reden om geen https te doen, en op complexere pagina's is de TLS overhead relatief lager, maar evengoed scheelt het veel.

... aangezien decryptie in vele CPU instructie sets zitten

Alleen in recente Intel en AMD CPUs. Recenter dan vrijwel alles wat wij hier hebben staan.

Bovendien helpen die instructies vrijwel niks hiervoor; die instructies waar jij het over hebt zijn om AES te versnellen, maar relatief kleine TLS requests is het vooral het opzetten van de verbinding wat pijn doet. Daarvoor moet je RSA doen, en dat is hetgene wat lang duurt. En dat wordt niet versneld door die nieuwe instructies.

Ik wil hiermee niet zeggen dat we geen https moeten gebruiken, maar doen alsof er geen performance penalty is, is op zijn minst kort door de bocht

[lrietveld]

Ik snap deze niet helemaal. Er zijn minder requests per seconde voor https, maar dit betekent toch niet automatisch dat https requests significant duurder zijn om te beantwoorden?
Een andere verklaring is dat https simpelweg minder vaak gebruikt wordt toch?

[deadinspace]

Ik snap deze niet helemaal. Er zijn minder requests per seconde voor https, maar dit betekent toch niet automatisch dat https requests significant duurder zijn om te beantwoorden?
Een andere verklaring is dat https simpelweg minder vaak gebruikt wordt toch?

Wat ik laat zien is een benchmark, geen daadwerkelijke bezoeken. Dus ja, het betekent daadwerkelijk dat https requests significant duurder zijn (grofweg een factor 3 in dit geval).

[Blokker_1999]

In de HTTP 2.0 standaard is encryptie standaard opgenomen. Daarom ook dat dit initiatief zo belangrijk is. Op deze manier kan men stilaan beveiligde verbindingen gaan verplichten.

[Gomez12]

dat 2e is een urban myth aangezien decryptie in vele CPU instructie sets zitten en bij goed belaste servers van Google werd al aangetoond dat SSL vs niet SSL 1% cpu load scheelde.

A: Jij hebt het over hedendaagse hardware, terwijl het verwijt komt vanuit oudere hardware.
B : Volgens je eigen link heeft Google het over less than 10kb memory per connection, 2% extra traffic. Dat is niet niks voor heel veel partijen hoor.

Geef mij bijv maar 1% van de traffic-rekening van een Google of een Netflix en ik zeg mijn baan op en ga rentenieren. Bij een twitter is een 10kb memory per connectie toch allicht best wel relevant hoor.

[Maurits van Baerle]

Heeft Let's Encrypt eigenlijk plannen om uiteindelijk 'hoger' in de certificatenketen te komen? Hoe minder tussenlagen en afhankelijkheden hoe beter.

[CH4OS]

Jep, maar dat kost ook geld. Dus zou mij niet verbazen als er ook premium certificaten k omen bij Let's Encrypt en dat zij daar hun verdienmodel op gaan baseren. Net als StartSSL eigenlijk al doet.

[Reactie gewijzigd door CH4OS op 23 juli 2024 10:05]

[Verwijderd]

Het is een officiele non-profit. Ze kunnen voor sommige dingen wel een vergoeding vragen mochten de donaties tegenvallen, maar echt "verdienen" is niet het doel. In die zin wezenlijk anders dan StartSSL.

Overigens denk ik dat het met de donaties wel goed komt. Er zijn veel partijen die belang hebben bij een brede inzet van SSL. Ook automatiseren ze bijna alles, wat de kosten verder drukt.

Dit soort 501c3 non-profits moeten al hun cijfers publiceren, dus over een jaar (of misschien 2) weten we precies hoe het financieel in elkaar zit.

[Gomez12]

Het is een officiele non-profit. Ze kunnen voor sommige dingen wel een vergoeding vragen mochten de donaties tegenvallen, maar echt "verdienen" is niet het doel. In die zin wezenlijk anders dan StartSSL.

Maar ipv verdienen kan je ook gewoon een toekomstreservering maken voor bijv een eigen CA op te zetten.

Of je kan spelen met de lonen van medewerkers, of je kan spelen met benodigdheden.

Non-profit op zichzelf zegt totaal niets, er zijn 101 manieren om je winst anders te benoemen.

Dit soort 501c3 non-profits moeten al hun cijfers publiceren, dus over een jaar (of misschien 2) weten we precies hoe het financieel in elkaar zit.

Ik ken het niet, maar ik hoop dat ze echt al hun cijfers publiekelijk moeten publiceren zodat het echt inzichtelijk wordt of het echt non-profit is.

[Plofkotje]

Ja, ze willen hun root CA in elke browser hebben, maar aangezien dat veel tijd kost is er als tussenoplossing gekozen voor het cross-signen met de CA van Identrust.

Als een browser hun eigen CA vertrouwd valideert hij op die manier het certificaat en anders valt hij terug op de ondertekening van hun CA door Identrust.

[Maurits van Baerle]

Top, dat vroeg ik me af. Een eigen root CA is natuurlijk de zekerste en veiligste weg (maar niet makkelijk!).

[FerronN]

Gebruik al een tijd Startssl voor gratis certificaten. @elbizarre, het gaat vaak om klasse 1 certificaten die gratis zijn. Deze certificaten bevestigen alleen dat het domein van diegene is die het certificaat heeft aangevraagd. Als je wildcard certificaten wilt of een hogere klasse (voor bedrijven) zul je toch bij betaalde instanties blijven.

[marcelvb]

Is daar een technische reden voor? Of is dat alleen omdat nu eenmaal zo is?

[Yggdrasil]

Omdat daar het geld te verdienen is.

[gooos]

Inderdaad - gratis wildcard certificaten (alleen al op domein validatie niveau) zou helemaal super zijn!

[isama]

Helaas is Let's encrypt nog niet publiek beschikbaar, maar ze zeggen zelf q4 2015 beschikbaar te willen zijn.

de dag dat ik zie dat ze beschikbaar zijn ga ik mijn privespul overzetten naar https.

[Verwijderd]

Volgens mij kun je vanavond je agenda leegvegen: https://letsencrypt.org/howitworks/

[The Zep Man]

Volgens mij kun je vanavond je agenda leegvegen: https://letsencrypt.org/howitworks/

De Technical Overview laat beter zien wat Let's Encrypt doet.

Kort samengevat bestaat het uit twee delen. Het eerste is een standaard CA die via domain validation (bestand op de webserver via een SSL/TLS verbinding die vermoedelijk alleen door Let's Encrypt wordt vertrouwd, of via een DNS record) kan controleren of iemand controle heeft over een bepaald domein. Dit lijkt op zoals andere CA's DV certificaten aanbieden en is niet zo bijzonder.

Het bijzondere is het tweede deel: Let's Play automatiseert de aanvraag, uitgifte, configuratie en verder beheer van het certificaat voor Apache of nginx.

Het interessante wordt nu het volgende aanvalsscenario:
1. Ik registreer www.opkomendberoemdenaam.extensie en vraag daarvoor een gratis SSL/TLS certificaat aan.
2. Het certificaat wordt toegewezen.
3. Ik laat mijn registratie voor www.opkomendberoemdenaam.extensie vervallen/annuleren. Het gevolg is dat het domein nu opnieuw te registreren is.
4. Het domein wordt gekocht door degene met een beroemde naam.
5. Zolang het certificaat niet gerevoked wordt, heb ik een geldig certificaat voor het domein dat ik niet meer bezit.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 10:05]

[hakog2]

Ik zie wat je bedoeld, maar wat doen andere uitgifte punten van certificaten anders dan Let's Encrypt ? Pas geleden nog een certificaat aangevraagd, maar het enige wat ik heb moeten doen is een een e-mail beantwoorden die naar [e-mail] werd gestuurd.

Volgens mij controleren certificaten boeren niet of er al een geldig certificaat voor een specifiek domein uitgegeven is. Dus het aanvalsscenario wat jij schets zou altijd van toepassing zijn. Of mis ik iets ?

[frozensky_]

Er zijn een aantal zaken die dit aanvalscenario tegen gaan:

1. Let's encrypt geeft niet certificaten van een jaar uit, maar van slechts een paar maanden. Ze willen dit terugbrengen naar een week op termijn. Omdat de Let's encrypt software automatisch voor het hernieuwen van een certificaat zorgt, is dit geen probleem. Maar, als je het domein laat verlopen, dan is tegen die je aanval ingaat, je certificaat ook niet meer geldig.

2. Er is rate limiting, je kan dus niet zomaar duizenden certificaten aanvragen. Natuurlijk kan je daar wellicht omheen werken, maar dat is niet heel triviaal

3. Er wordt door een AI process en een blacklist, een zooi uitgefiltered. Of dat dit scenario ook tegengaat is misschien te betwijfelen, maar wellicht wel.

Ik zeg niet dat het geen onmogelijk scenario is, maar ik denk dat de praktijd wel een stuk lastiger zal zijn.

[Gomez12]

Ik vraag me toch heel erg sterk af hoe 1 en 2 samen moeten werken.

Automatisch verstrekken klinkt leuk, maar in de realiteit zal de gemiddelde magento-shopeigenaar dit niet doen en dus zal het bij de webhoster terechtkomen.
Echter een gemiddelde webhoster heeft wel al heel snel duizenden certificaten te beheren en dan loop je dus tegen 2 aan.

Voor de mensen met "eigen" servers en die een beetje kunnen scripten is het mooi, maar bij "de massa" vraag ik me toch wel af hoe dat bedacht is.

[Yggdrasil]

Ze hebben er juist veel moeite in gestoken om het aanvragen, verifiëren en installeren veel eenvoudiger te maken dan dat tot nu toe is, zodat zelfs de Magento-shopeigenaar dat kan door één commando uit te voeren.

Zie https://letsencrypt.org/howitworks/ voor een voorbeeld.

[Gomez12]

Menig magento shop-eigenaar heeft enkel ftp-toegang en kan geen commando's uitvoeren.

Oftewel jouw voorbeeld is niet van toepassing, wil je grote magento-integratie van mensen die het zelf doen zal je een magento-plugin moeten maken. Maar dan moet je ook een joomla-plugin maken en een wordpressplugin en nog 1000 andere plugins.

Oftewel of je kan een oneindig aantal plugins gaan optuigen, of je laat het liggen bij de mensen die wel commando's uit kunnen voeren en je hebt kans dat je tegen je rate-limiting aan gaat lopen.

[Yggdrasil]

Het is een open API dus ik vind het aannemelijk dat hostingplatforms zoals Plesk en cPanel inderdaad plugins gaan inbouwen. Misschien dat ook CMS-en die nu al updaters inbouwen, zoals Magento en WordPress, een Let's Encrypt plugin maken. Of die ook werkelijk bruikbaar zijn hangt af van of de webserver-gebruiker ook de config van Apache mag aanpassen. Dat zal bij veel hosting niet het geval zijn.

Ik geloof best dat sommigen tegen rate-limiting aan gaan lopen, maar LE zal die waarschijnlijk zo afstellen dat de meeste gebruikers hier geen last van ondervinden. Daar hebben ze immers baat bij.

[hakog2]

Ik denk dat de wat grotere webhost vooral SSL Offloading gebruikt. De certificaten worden dan door de load balancer beheerd. Vraag me af of hier ook iets voor bedacht is.

[hakog2]

Dank. Duidelijk verhaal.

Ik zie twee voordelen:
- Nooit meer uit m'n bed gebeld worden vanwege verlopen certificaat
- Gratis

[The Zep Man]

Ik zie wat je bedoeld, maar wat doen andere uitgifte punten van certificaten anders dan Let's Encrypt ? Pas geleden nog een certificaat aangevraagd, maar het enige wat ik heb moeten doen is een een e-mail beantwoorden die naar [e-mail] werd gestuurd.

Dat klopt. Om dat mailtje te ontvangen moet het domein immers in DNS een MX record hebben dat naar jouw mailserver verwijst. Dit impliceert dat jij controle over de DNS server en daarmee dus het domein hebt. Dat is ook een manier van domain validation en wordt vaak toegepast (zoals door StartSSL, waar men ook een gratis certificaat kan verkrijgen).

Volgens mij controleren certificaten boeren niet of er al een geldig certificaat voor een specifiek domein uitgegeven is. Dus het aanvalsscenario wat jij schets zou altijd van toepassing zijn. Of mis ik iets ?

Het verschil is dat in het aanvalsscenario je vroeger een certificaat moest kopen of via StartSSL een certificaat moest aanvragen (die ze niet altijd vrijgegeven wanneer het om een risicovolle naam gaat). Nu kan je geautomatiseerd een certificaat aanvragen voor het betreffende domein, dus de drempel voor dit scenario wordt een stuk lager.

Overigens is het hele PKI systeem zoals gebruikt in browsers sowieso brak. Een vlotte telling in een Firefox installatie geeft aan dat er standaard al CA's van 99 partijen vertrouwd worden. Je hoeft maar één corrupte CA te hebben en daar gaat je veilige verbinding.

Overigens zijn daar wel verzachtende middelen tegen, maar dat die middelen al nodig zijn geeft aan dat het hele CA systeem eens op de schop zou moeten. Helaas is het nu te populair en zit iedereen er te diep in om er nog iets aan te wijzigen. Let's Encrypt doet in ieder geval een moedige poging om kartelvorming door bestaande CA's tegen te gaan.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 10:05]

[hakog2]

Je moet wel degelijk bewijs leveren dat je controle hebt over het domein.

Zie https://letsencrypt.org/howitworks/technology/

To kick off the process, the agent asks the Let’s Encrypt CA what it needs to do in order to prove that it controls example.com. The Let’s Encrypt CA will look at the domain name being requested and issue one or more sets of challenges. These are different ways that the agent can prove control of the domain. For example, the CA might give the agent a choice of either:

Provisioning a DNS record under example.com, or
Provisioning an HTTP resource under a well-known URI on https://example.com/

[Paul - K]

Bij de README op Github staat nog het volgende:

This is a DEVELOPER PREVIEW intended for developers and testers only.

DO NOT RUN THIS CODE ON A PRODUCTION SERVER. IT WILL INSTALL CERTIFICATES SIGNED BY A TEST CA, AND WILL CAUSE CERT WARNINGS FOR USERS.

[duckson]

Let's encrypt geeft helaas nog geen certificaten uit aan het publiek. Dit is te zien in de disclaimer op de GitHub pagina van hun client en ook wanneer je deze probeert te installeren.

[tunnelforce1]

128 bit AES encryptie vind ik alleen wel een beetje magertjes.. we hebben het tegenwoordig over maanden in plaats van jaren, weldra is hij er echt: de quantum-computer.....

[Reactie gewijzigd door tunnelforce1 op 23 juli 2024 10:05]

[Yggdrasil]

Waar baseer je die maanden of zelfs jaren op? Voor zover ik weet wordt 128-bit AES nog beschouwd als zeer veilig. Zie o.a. https://en.wikipedia.org/...on_Standard#Known_attacks. Als er zwaktes zijn, dan komen die vooralsnog door slechte implementatie van het algoritme en kunnen die door een zogenaamde side-channel-attack worden aangevallen.

Quantum computers zijn inderdaad een toekomstig risico, maar staan nog in de kinderschoenen. Tot dusver is, zelfs door bedrijven die al commercieel QC's verkopen zoals D-Wave, nog onvoldoende aangetoond dat hun berekeningen exponentieel sneller zijn dan bij klassieke computers. Theoretisch ja, maar praktisch zijn we daar nog lang niet. Zodra die techniek in het zicht komt zullen de regels voor wat als een veilige encryptie beschouwd mag worden zeker moeten worden aangescherpt.

Voor de voorzienbare toekomst (gezien de maximale geldigheidsduur van de certificaten) is 128-bits AES veilig. Volgens dit artikel van Bruce Schneier zou het zelfs iets veiliger zijn dan 256-bits AES. Een hoger getal is niet altijd beter

[tunnelforce1]

Yes ik denk inderdaad maanden in laats van jaren.

zie bijvoorbeeld dit onlangs verschenen artikel:
http://phys.org/news/2015-10-crucial-hurdle-quantum.html

Vele encrypties werken met priemgetallen, er is 100 jaar geleden al bewezen dat quantum computers grootte priemgetallen extreem makkelijk kunnen bepalen.

[Yggdrasil]

Sorry, ik heb het artikel gelezen en denk dat je overdrijft. Van een enkele werkende quantum logic gate naar een werkende quantum computer met voldoende qubits om een bedreiging te vormen voor sterke cryptografische algoritmen gaat nog welwat jaren duren. Voor het breken van crypto heb je grootschalige parallellisatie nodig, niet slechts enkele tientallen qubits die we nu met moeite kunnen bouwen.

Ook met je "100 jaar geleden" ben ik het niet eens. De eerste ideeën over de quantummechanica ontstonden pas 90 jaar geleden met Heisenberg en Schrödinger en dan heb ik het nog niet eens over wanneer de eerste echte computers ontwikkeld zijn.

Wat jij beschrijft is Shor's algoritme om met grote integers te kunnen rekenen. Dat was het moment waarop men zich realiseerde hoe krachtic QC's kunnen zijn voor cryptografie. Het is bedacht door Peter Shor van Bell Labs in 1994 (20 jaar geleden dus). Zie https://en.wikipedia.org/wiki/Timeline_of_quantum_computing en https://en.wikipedia.org/wiki/Shor's_algorithm.

Voorzichtigheid is altijd op zijn plaats in de cryptografie, maar niemand heeft er wat aan om ongefundeerde paniek te zaaien.

[tunnelforce1]

Hoeveel qubits moet een quantum computer hebben volgens jou ?

Vooral deze paragraaf vond ik erg interessant :
A key advantage of the UNSW approach is that they have reconfigured the 'transistors' that are used to define the bits in existing silicon chips, and turned them into qubits. "The silicon chip in your smartphone or tablet already has around one billion transistors on it, with each transistor less than 100 billionths of a metre in size," said Dr Menno Veldhorst, a UNSW Research Fellow and the lead author of the Nature paper.
"We've morphed those silicon transistors into quantum bits by ensuring that each has only one electron associated with it. We then store the binary code of 0 or 1 on the 'spin' of the electron, which is associated with the electron's tiny magnetic field," he added.
Dzurak noted that that the team had recently"patented a design for a full-scale quantum computer chip that would allow for millions of our qubits, all doing the types of calculations that we've just experimentally demonstrated.""


Read more at: http://phys.org/news/2015-10-crucial-hurdle-quantum.html#jCp

[Yggdrasil]

Dat zou inderdaad ruim voldoende zijn, als ze dat kunnen waarmaken. Ik ga het in de gaten houden.

[Bollux]

We hebben al een aantal jaar een aantal Premium SSL wildcard certificaten rechtstreeks van Comodo voor zo'n 450,- euro per jaar. Hier toen voornamelijk voor gekozen om zonder veel research te doen zeker weten gelijk goed te zitten en geen gezeur krijgen met web applicaties en andere zaken.

Als ik dan zulke nieuws berichten zie ga ik toch achter m'n oren krabben. Aan dergelijke gratis certificaten zullen we ons niet gaan wagen, maar als ik dan (door de reacties die ik hier lees over goedkope comodo certificaten) ga rondkijken en ik zie bijv. op een willekeurige nederlandse site waar je een Comodo (Positive)SSL wildcard certificaat voor 75,- euro per jaar kunt afnemen, ga ik nog harder achter mijn oren krabben.
Betalen wij nou dan ook echt te veel en kunnen we beter overstappen??

[MadEgg]

Uh, ja. Ik zelf heb wat betaalde certificaten via Xolphin SSL, die levert ze vanaf 8 euro per jaar. Als je een EV certificaat hebt (en wil je daar echt meer voor betalen? De gebruiker merkt het hoogstwaarschijnlijk niet omdat browsers het tegenwoordig niet zo duidelijk meer aangeven als vroeger), betaal je daar ongeveer 125 euro per jaar. Waar jullie dan dus 450 euro voor betaald is mij een raadsel, maar ik zou daar toch nog eens heel goed naar kijken.

[Bollux]

Toch maar eens meer in verdiepen inderdaad. Ze leveren bij Xolphin ook comodo certificaten zie ik, alleen dan een heel stuk goedkoper!

[Yggdrasil]

Doen. Wij gebruiken al jaren Comodo PositiveSSL certificaten voor al onze hostingklanten, via Xolphin. De meerwaarde voor Premium of EV is er vaak niet echt, dus kiezen we meestal voor de goedkoopste DV (domain-validated)-certificaten. Als je bij Xolphin reseller wordt krijg je nog eens 10% korting waardoor je maar €7,20 ex. BTW kwijt bent.

[pennywiser]

StartSSL is ook gratis en werkt goed.

[Yggdrasil]

Klopt, maar het vereist vrij veel systeembeheerkennis om het aan te vragen en correct te installeren. Hierdoor gebruiken veel mensen gaan SSL/TLS of wordt het onveilig geconfigureerd. Eén van de speerpunten van Let's Encrypt is juist dat ze zoveel mogelijk proberen te automatiseren, ook aan de kant van de gebruiker. Zie https://letsencrypt.org/howitworks/ voor een voorbeeld.