Let’s Encrypt-initiatief neemt eerste ssl-certificaat in gebruik

Let's Encrypt, waar onder andere burgerrechtenbeweging EFF achter zit, heeft zijn eerste ssl-certificaat in gebruik genomen. Het certificaat is ingezet voor de beveiligde verbinding van een helloworld-pagina van het initiatief, maar het moet handmatig geïnstalleerd worden.

Bezoekers moeten het ISRG-root-certificaat nog wel zelf importeren om de Helloworld-pagina versleuteld te kunnen bereiken, Let's Encrypt is nog niet toegevoegd als certificaatautoriteit bij browsers. Over een maand moet het certificaat wel door alle browsers automatisch gevalideerd worden, als IdenTrust de certificaten van Let's Encrypt gaat cross signen. Het project mikt op november als maand van brede beschikbaarheid. Dinsdag heeft Let's Encrypt daarvoor een aanvraag voor opname van zijn rootcertificaat in de trust stores van Apple, Mozilla, Google en Microsoft ingediend.

Let’s Encrypt is onderdeel van het Encrypt the Web-initiatief van de EFF om elke site via https benaderbaar te maken. De dienst gaat gratis ssl-certificaten verstrekken en het makkelijker maken om ze te gebruiken. De EFF werkt hiervoor samen met Mozilla, Cisco, Akamai, IdenTrust en onderzoekers van de universiteit van Michigan.

Reacties (99)

[Verwijderd]

Voor de liefhebber, hier de presentatie van een aantal weken terug op CCC kamp in noord Duitsland voor alle in's ''n out's over 'let's encrypt';

https://media.ccc.de/brow...-let_s_encrypt.html#video

[Lennie]

Engelstalige video (ipv. in het Duits die daarboven):
https://www.youtube.com/watch?v=pd-h8WOiI8A

[angelina]

Alhoewel dit een goed initiatief is, zit er ook een gevaar achter. Een nietsvermoedende gebruiker heeft jarenlang gehoord dat sites met een sleuteltje te vertrouwen zijn. Helaas betekent dit niet dat de site betrouwbaar is maar dat alleen de verbinding is beveiligd. Wat als straks allerlei louche sites gratis certificaten aanvraagt? Bijvoorbeeld voor abnarno.nl ofzo...

[thof]

Vergeet niet dat er een duidelijk verschil zichtbaar is tussen een EV-certificaat en een DV-certificaat. EV certificaat is extended validated, DV is domain validated. Banken gebruiken EV-certificaten, zodat ze (kort door de bocht) niet alleen een slotje krijgen maar ook een groene balk. Bij een DV certificaat krijg je alleen een slotje om aan te geven dat de verbinding versleuteld is. Bij mijn bank wordt dit ook expliciet zo aangegeven.

SNS Bank:
Betaal jij veilig online?
Houd je inloggegevens geheim. En controleer als je gaat internetbankieren of:
- het internetadres begint met https://www.snsbank.nl/
- je adresbalk groen kleurt en/of een slotje weergeeft
- het gebruikte certificaat echt is

Andere banken hebben er ook speciale pagina's voor opgezet:
https://www.ing.nl/de-ing...trotekst_inlogscherm_link

Rabobank vind ik persoonlijk tegenvallen, die melden wat algemene tips tegen fraude en problemen. Op de inlog pagina alleen "Ga alleen verder als de adresregel begint met https://bankieren.rabobank.nl/..." Knab gebruikt trouwens eenzelfde strekking.

Op de ABN Amro pagina kan ik zo snel helemaal geen waarschuwing/hint vinden om de boel te controleren.

[Verwijderd]

Die ING pagina spreekt ook vooral over het slotje. Deze zin: "Bij een beveiligde verbinding kleurt de adresbalk in sommige browsers (deels) groen." maakt ook niet veel duidelijker. Een DV certificaat heeft ook een slotje. Om het nog lastiger te maken gebruikt de overheid ook regelmatig DV certificaten voor belangrijke inlogpagina's waar je eerder een EV certificaat zou verwachten.

[SleutelMan]

Het probleem voor de overheid is dat ze verplicht gebruik maken van PKI-overheid certificaten waarbij de EV root (die is er wel) nog niet overal vertrouwd is door alle browsermakers.

Dus tot die tijd moeten overheidspartijen zich behelpen met DV certificaten (waarbij aangetekend moet worden dat de eisen van PKI-overheid veel strenger zijn dan bij een standaard SSL certificaat, het verschil tussen DV en EV bij PKI-O is dan ook niet zo groot).

Zie voor meer info hier: https://www.logius.nl/ond...ndersteuning-pkioverheid/

[Reactie gewijzigd door SleutelMan op 26 juli 2024 09:51]

[Eagle Creek]

Rabobank vind ik persoonlijk tegenvallen, die melden wat algemene tips tegen fraude en problemen. Op de inlog pagina alleen "Ga alleen verder als de adresregel begint met https://bankieren.rabobank.nl/..." Knab gebruikt trouwens eenzelfde strekking.

Rabobank toont meer dan dat jij noemt. Wel moet je even doorklikken naar "Hoe controleert u de veiligheid van uw verbinding?" Je komt dan op een pagina uit met meer informatie.

Controleren
Controleer of u écht verbinding heeft met de Rabobank.

Meer over veilig bankieren (PDF)

Dit linkt naar een PDF met beschrijving van adresbalk, slotje en certificaatdetails.

----------

De Hello World pagina kan ik geheel niet bezoeken, krijg de melding "connection closed". Als ik het bericht van Tweakers lees lijkt het alsof de verbinding beveiligd wordt met het root-certificaat. Is dat zo?

[Reactie gewijzigd door Eagle Creek op 26 juli 2024 09:51]

[Verwijderd]

Ik ben ook benieuwd hoe ze dit oplossen.

[CAPSLOCK2000]

Volgens mij is dit de verkeerde plek om het probleem op te lossen. SSL is hier niet voor gemaakt en er zijn talloze manier om er om heen te werken. Ook het idee dat je naar de URL kan kijken om te beoordelen of iets veilig is kan wat mij betreft naar de prullenbak.
Er zijn bijvoorbeeld talloze diensten waar je formulieren kan aanmaken. Die worden gebruikt door fishers om informatie te verzamelen. Die diensten op zich zijn wel legitiem, ze worden alleen verkeerd gebruikt.
Ook is het een onhoudbaar idee dat mensen de URLs kennen van alle belangrijke websites. Grote bedrijven hebben vaak honderden domeinen. Voorbeeldje:
a) www.abnamro.nl
b) www.abnamro.com
c) www.abnamro.de
d) www.abnamro.co
e) wwww.abnamro.nl
f) www.abnamr.onl
a, b en c zijn legitiem, d, e en f niet. Aan jullie krijg ik dat uitgelegd maar niet aan mijn moeder. Als het nou nog om één website ging was het nog te doen maar een beetje modern mens heeft met tientallen organisaties en bedrijven te maken.

Dan hebben we het nog niet eens gehad over al die bedrijven die namens een ander bedrijf iets doen. Zo worden massmails vaak door externe bedrijfjes verstuurd en gebruiken ze tracker-links die geen relatie hebben met de opdrachtgever.

Dus, het hele idee dat mensen aan een paar letters tekst kunnen zien of iets te vertrouwen is moet overboord. Ik wil SSL niet afschaffen, ik wil URLs niet afschaffen, maar er moet een andere manier komen om te beoordelen of een website "echt" is.

Hoe dat moet laat ik even in het midden, ik heb wel ideetjes maar het gaat om de gedachte, niet om de implementatie.

update typo in voorbeeld f, sorry

[Reactie gewijzigd door CAPSLOCK2000 op 26 juli 2024 09:51]

[wurtel]

Waarom is wwww.abnamro.nl niet legitiem? Het is een ongebruikelijke hostnaam maar het valt wel gewoon onder abnamro.nl wat van ABN AMRO is.

www.abn.amro.nl is ook een slecht voorbeeld, amro.nl is gewoon onder controle van ABN AMRO dus zullen derden niet met www.abm.amro.nl aan de haal kunnen gaan.

Zelfs www.abnamro.co bestaat en is "gewoon" van ABN AMRO :-) Vergeet niet dat ABN AMRO een wereld speler is.

Je moet opletten voor dingen zoals www.abnamr0.com, of waarbij een van de letters door UTF8 varianten vervangen zijn; maar daar kom je niet zomaar achter...

[CAPSLOCK2000]

Waarom is wwww.abnamro.nl niet legitiem? Het is een ongebruikelijke hostnaam maar het valt wel gewoon onder abnamro.nl wat van ABN AMRO is.

Dat is fingerspitzengefühl, technisch gezien is het correct maar het is zeer onwaarschijnlijk dat ze echt die naam zouden gebruiken. Als ik dat in een mailtje zou staan dan zou ik denken dat er iets niet klopt. BV dat iemand een aanval op DNS heeft gedaan of zo iets.

www.abn.amro.nl is ook een slecht voorbeeld, amro.nl is gewoon onder controle van ABN AMRO dus zullen derden niet met www.abm.amro.nl aan de haal kunnen gaan.

Oeps. Je hebt gelijk, ik heb niet op zitten letten, ik bedoelde www.abnamr.onl .

Zelfs www.abnamro.co bestaat en is "gewoon" van ABN AMRO :-) Vergeet niet dat ABN AMRO een wereld speler is.

Volgens mijn domeinboer is het nog vrij, dat zal dan wel een bug zijn. Het punt blijft dat er heel veel varianten mogelijk zijn en dat je niet direct weet welke echt zijn. Dat wij deze discussie hebben laat het probleem mooi zien

Je moet opletten voor dingen zoals www.abnamr0.com, of waarbij een van de letters door UTF8 varianten vervangen zijn; maar daar kom je niet zomaar achter...

Yup, dat is inderdaad een hele vervelende categorie, met name die UTF-8 namen zijn vaak niet te onderscheiden. Hoe dan ook, mogelijkheden genoeg voor verwarring

[Reactie gewijzigd door CAPSLOCK2000 op 26 juli 2024 09:51]

[viccoh]

Bij Web of Trust proberen ze betrouwbaarheid aan te geven via een browser plugin :
https://www.mywot.com/
Ik zelf werd gek van de extra icoontjes bij links op webpaginas toen ik het een keer probeerde, maar schijnbaar hebben vele anderen daar geen last van.

Misschien dat browsers zoiets direct implementeren in de toekomst. Wie weet?

[Dennis]

Precies dit. Daarom is dit anderzijds wel weer goed nieuws voor de certificaatboeren, omdat serieuze sites nu misschien eerder geneigd zijn (dure) EV-SSL certificaten aan te kopen.

Aan de andere kant kun je SSL-certificaten voor minder dan € 8,- per jaar kopen, dus dat zal voor serieuze criminelen ook niet het grootste probleem vormen.

[Reactie gewijzigd door Dennis op 26 juli 2024 09:51]

[DonLexos]

Nou gratis is altijd makkelijker want met valse gevens certificaat aanvragen waarvoor je verder geen betaling hoeft te doen is altijd veel handiger natuurlijk (voor de criminelen).

Groot aantal browsers geeft wel al duidelijk aan dat beveiliging ok is maar pas vanaf EV echt een groene balk (voorbeeld https://www.mollie.nl). Gros van de huidige SSLs is ook alleen 'domain validation' (dus validatie op basis van email naar [e-mail] of iets dergelijks).

Zal verder afhangen hoeveel echte sites tov spam/scam sites dit certificaat gaan gebruiken, anders heb je kans dat browsers (of users mbv plugins) deze alsnog blokkeren (net als dat je sommige nieuwe domein extenties gewoon volledig kan droppen qua email verkeer).

[bbob]

Echte criminelen kunnen gewoon met gestolen creditcards ev certificaten kopen, dan is het mooi groen in je balk.

Waar het hier om gaat is puur dat de verbinding via ssl loopt en dus beveiligd is, niets meer niets minder. Het zegt verder niets over de inhoud en betrouwbaarheid van een website.

Daarnaast ook al heb je een ev certificaat betekend dat alleen dat er iets meer controle geweest is, maar zegt het ook wederom weinig of de site echt betrouwbaar is. Die betrouwbaarheid heeft ook alles te maken met waar het om gaat.
Bij een bank zal die betrouwbaarheid heel hoog moeten zijn. Bij een blog maakt het weinig uit. Bij een webshop zal er meer betrouwbaarheid verwacht worden dan bij een blog.

[Armin]

Echte criminelen kunnen gewoon met gestolen creditcards ev certificaten kopen, dan is het mooi groen in je balk.

Je moet wel toegang tot het domein hebben anders krijg je het niet. Ik geef toe niet alle CA's zijn even goed in controle daarop, maar het is dus niet zomaar mogelijk met een gestolen creditcard een EV certifciaat te krijgen.

En mocht dat wel lukken is het juist met EV-certifciaten veel sneller ingetrokken. Waar Google Chrome niet eens aan certificaat revocation doet bij gewone certifciaten, is het bij EV-certificaten verplicht volgens de standaard en doen alle browsers dat.

Als ik crimineel was, zou ik juist EV-certificaten mijden. Met een non-EV crtifciaat hoef ik enkel te vrezen voor Opera, Firefox, IE en Safari op MacOX (niet op iOS). Chrome, Android stock en iOS Safari is dan echter onbeschermd.

[.oisyn]

Echte criminelen kunnen gewoon met gestolen creditcards ev certificaten kopen, dan is het mooi groen in je balk.

Nou ja, achter een EV certificate zit weldegelijk een wat diepgaander identity check via officiele kanalen. Als het zo makkelijk is als jij stelt dan is het hele idee van een EV compleet nutteloos. Gewoon beschikken over een gestolen CC doesn't quite cut it, je zal ook identiteits- en adresvalidatie moeten doorlopen.

[GekkePrutser]

Je kan ze zelfs gratis krijgen (DV certs) bij StartSSL.

[lenwar]

Probleem met StartSSL, is dat dat bedrijf in Israel zit, wat voor mij niet de meest betrouwbare ICT-gerelateerde-zaken-bron is.

[GekkePrutser]

Dat is waar, maar het is 'maar' een CA. Ze hebben niks vertrouwelijks van je (je geeft ze alleen je public key om te ondertekenen, de private key hebben ze niet).

Elke (grote) CA kan een cert uitgeven in de naam van jouw server, dus welke je gebruikt maakt niet zo veel uit.

[lenwar]

Toch werk ik liever niet met bedrijven/organisaties uit dat soort landen. Just my two cents.

[jvwou123]

Je heb liever een bedrijf uit Syrië, of Rusland? Of Amerika? Daar kun je inderdaad heel betrouwbaar je gegevens kwijt?

Volgens mij zijn er weinig landen waar het wel betrouwbaar is. het liefst zou ik mijn certificaat gewoon lekker zelf signen, maar ja dat is voor de overige gebruikers zo lastig...

[lenwar]

Ik heb inderdaad liever Nederlande, Amerika, Frankrijk, Duitsland, Engeland ofzo. Een regering die open en blood raketten schiet op woonwijken omdat er een "terrorist" woont, is in mijn ogen zelf niets beter dan die genoemde terrorist.

Uiteraard kan je zeggen dat geen enkele overheid te vertrouwen is, maar ik vertrouw de ene net wat meer dan de andere zegmaar.

[WaaaghNL]

Leuk maar dan moet je wel het StartSSL cert in je browser hebben. Wat geen hond heeft. Leuk voor je DEV omgeving maar niet voor de productie.

[eBait]

Niet waar. De StartSSL Root CA (zoek maar op StartCom) zit gewoon in browsers onder zowel Linux, Windows als Mac OS X. Mobiel is het nog wel eens wat gepruts met de goede intermediate certificaten toevoegen, omdat deze browsers niet altijd zelf de tussenliggende CAs ophalen.

[Reactie gewijzigd door eBait op 26 juli 2024 09:51]

[smeedy]

je kunt de hele intermediate chain ook meesturen in je serverconfiguratie door pem goed te preppen. Staat bij StartCom ook wel een howto. Dan heeft je browser die verantwoordelijkheid niet meer.

[GekkePrutser]

Klopt, ik heb zelf de intermediate er ook gewoon bij in zitten en dat werkt perfect (Edit: Sorry was een reactie op smeedy)

[Reactie gewijzigd door GekkePrutser op 26 juli 2024 09:51]

[GekkePrutser]

Ik heb het op alle mainstream browsers geprobeerd, en zoals eBait zegt zit het overal in! Firefox, IE, Chrome, Safari.. Ook op mobiel, iOS, Android. Helemaal geen problemen mee. Je moet inderdaad wel je intermediate CA mee geven maar dat doe je op de server, hoef je niks in de clients voor aan te passen.

Dit was ook in eerste instantie de reden dat ik er mee begon, ik kreeg een iPhone van mijn werk en mijn werk had de functie om servervalidatie te negeren geblokkeerd. Ook de functie om CA's toe te voegen. Vandaar dat ik een echt cert nodig had.

[Reactie gewijzigd door GekkePrutser op 26 juli 2024 09:51]

[Prozaq]

Waarschijnlijk zul je moeten aantonen dat je de eigenaar bent van het domein

[bbob]

whois info geeft de eigenaar aan. ssl certificaat zal naar het adres van de eigenaar volgens de whois gestuurd worden. Lijkt me de eenvoudigste oplossing.

[Armin]

Whois geeft echter niet altijd de eigenaar aan, maar soms ook de proxy die er tussen hangt om de eigenaar annoniem te houden.

[wurtel]

... wat al een hele grote indicatie is dat de eigenaar niet te vertrouwen is, als ie per se anoniem wilt blijven.

[DonLexos]

Niet perse, kan ook van de branche afhangen. Daarnaast is ook bij hele grote bedrijven de informatie in de regel niet zo heel zinvol.

Daarnaast, als jij een klein webwinkeltje hebt in electronica vanaf thuis kan je je afvragen of je je eigen adres bij je domein info wilt hebben (als je bijv een postbus hebt voor je zakelijke post). Postbussen zijn bijv niet toegestaan in WHOIS info (en daarmee zeg ik niet dat ze er niet zijn, vrijwel alles op een Business Plaza "Suite xxx" is een postbus).

Los daarvan vind ik het zelf vooral irritant als je wel contact op wil nemen met een domein eigenaar (bijv omdat je deze wil overnemen) en het volstekt onduidelijk wie de eigenaar is. Als je rekent dat de WHOIS een soort Kadaster is van eigendom van een domein zou je verwachten dat deze informatie zorgvuldiger zou moeten worden beheerd dan nu (... voor bepaalde extenties .. ) het geval is.

[Aikon]

Dat zal inderdaad, maar dat is erg makkelijk te omzeilen doorgaans. Zeker als je er niks/weinig voor betaald is de controle veelal automatisch.

[CAPSLOCK2000]

Alhoewel dit een goed initiatief is, zit er ook een gevaar achter. Een nietsvermoedende gebruiker heeft jarenlang gehoord dat sites met een sleuteltje te vertrouwen zijn. Helaas betekent dit niet dat de site betrouwbaar is maar dat alleen de verbinding is beveiligd. Wat als straks allerlei louche sites gratis certificaten aanvraagt? Bijvoorbeeld voor abnarno.nl ofzo...

Hoe is dat anders dan de situatie nu? Ik kan nu ook een DV-certificaat aanvragen voor abnarno.nl en zal dat zeer waarschijnlijk krijgen. Die DV-systemen zijn meestal helemaal geautomatiseerd, daar komt geen mens meer aan te pas die kan herkennen dat het een verdachte naam is.

[Armin]

Ik kan nu ook een DV-certificaat aanvragen voor abnarno.nl en zal dat zeer waarschijnlijk krijgen. Die DV-systemen zijn meestal helemaal geautomatiseerd, daar komt geen mens meer aan te pas die kan herkennen dat het een verdachte naam is..

Ik zou zeggen, probeer het eens

Je zult ontdekken dat er wel degelijk controle is.

[CAPSLOCK2000]

Ik kan nu ook een DV-certificaat aanvragen voor abnarno.nl en zal dat zeer waarschijnlijk krijgen. Die DV-systemen zijn meestal helemaal geautomatiseerd, daar komt geen mens meer aan te pas die kan herkennen dat het een verdachte naam is..

Ik zou zeggen, probeer het eens

Dan zal ik eerst dat domein moeten kopen. Het is nu in handen van een of andere domeinboer. Het is niet van ABN AMRO, dus daar is het al "mis" gegaan.
Ik schrijf mis tussen quotjes want eigenlijk is niks mis. Misschien is er wel een bedrijf dat Abnanro heet, dat zou kunnen. Verder is het onmogelijk om alle spelfouten en alternatieve spellingen af te dekken. Ik weet dat er lijstjes zijn met verboden namen van domeinen die niet mogen worden uitgegeven en waar ook geen SSL-certificaten voor mogen worden uitgegeven maar die zijn niet bepaald waterdicht. Verder moet iedere SSL-boer dat zelf controleren. Een Nederlandse verkoper zal ABN Amro wel op z'n lijstje hebben staan maar ik zou er niet op rekenen dat bv een Chinese verkoper het zou weigeren. Je hebt er maar ééntje nodig. Als de eerste 500 bedrijven jouw aanvraag afkeuren maar de 501ste even niet oplet dan heb jij je certificaat. Gezien het enorme aantal bedrijven dat certificaten kan maken is er altijd wel eentje die z'n zaakjes niet op orde heeft.

Het hele CA-systeem is ontzettend zwak. Het is een typisch geval van de zwakste schakel die bepaald hoe sterk de ketting is. Het is nu nodig dat vele honderden (inmiddels misschien wel duizenden) SSL-boeren helemaal te vertrouwen zijn, altijd hun werk goed doen en geen fouten maken.

Voor de duidelijkheid: ik ben niet tegen SSL-certificaten voor versleuteling van verbindingen. Ik ben tegen het idee dat je CA's kan vertrouwen, vooral tegen het idee dat je _alle_ CA's kan vertrouwen.

Er zijn wel wat lapmiddelen zoals certificaat pinning om het een beetje veiliger te maken maar die zie ik niet als fundamentele oplossing voor het probleem dat alle CA's vrijwel onbeperkt vertrouwd worden. Ik zie wel projecten met potentie om deze wereld te veranderen, zoals Convergence en DANE, maar die staan nog in de kinderschoenen.

[Reactie gewijzigd door CAPSLOCK2000 op 26 juli 2024 09:51]

[Armin]

Dan zal ik eerst dat domein moeten kopen

Daar doelde ik dan ook op

Zomaar een domein kopen kan niet. Verwante domeinen kopen wel inderdaad, maar die zijn vaak al opgekocht.

[CAPSLOCK2000]

Dan zal ik eerst dat domein moeten kopen

Daar doelde ik dan ook op

Zomaar een domein kopen kan niet. Verwante domeinen kopen wel inderdaad, maar die zijn vaak al opgekocht.

Volgens mij onderschat je een beetje hoeveel TLDs er zijn en hoeveel variaties op 'abnamro' te bedenken zijn, dat lukt altijd wel. abn.am.ro is nog vrij, net als ab.nam.ro, abnamro.nf en abnamr.onl. Anders neem ik wel abnamro.shop, abnamro.creditcard of een van de vele miljoenen andere mogelijkheden. Het hoeft niet perfect te zijn, de meeste mensen kijken er toch niet naar en slechts een enkeling kijkt heel kritisch en weet waar je op moet letten.

[.oisyn]

Verwante domeinen kopen wel inderdaad

Volgens mij mis jij de clou, namelijk dat CAPSLOCK2000 expres een typfout had gemaakt.

[thegve]

Geen zin om mijn zakelijke account daar aan te riskeren of om een nieuwe account aan te maken bij startssl, maar daar krijg je DV-certificaatjes gewoon direct aan het einde van een wizard zonder wachttijd.
Tenzij daar hele ingewikkelde algoritmes achter zitten die zien van 'goh, dat lijkt veel op abnamro' ben ik er vrij zeker van dat ik dat cert gewoon zou krijgen.
De 'concurrentie' doet dit voor DV-certificaten vermoedelijk ook gewoon geautomatiseerd, en ik moet zeggen, als je als medewerker een aanvraag voor abnanro.nl krijgt en de aanvrager is de eigenaar van het domein, op basis van welke wet/regel zou je deze niet mogen uitgeven?
De enige die geblokkeerd zou moeten worden in abnamro.nl, en dat gebeurt natuurlijk wel via postmaster/[e-mail] validatie.

[JAVE]

Tja, dat krijg je als je jarenlang de massa verkeerde dingen vertelt...
Nu moeten ze dus gaan uitleggen hoe mensen hun verstand moeten gebruiken.

[.oisyn]

Wat als straks allerlei louche sites gratis certificaten aanvraagt?

Je doet net alsof het nu onmogelijk is voor louche sites om certificaten aan te vragen. Bij StartSSL kan het ook gratis, en bij alle partijen waar het niet gratis kan is het ook niet nodig om met volledige geverivieerd naam en adres te registreren. Gebruik gestolen CC gegevens voor de betaling en je bent klaar.

[mkools24]

Enige wat jammer is is dat ze voorlopig geen wildcard certificaten verstrekken en het niet zeker is of dit nog komt (dus *.domein.nl). Dus nu moet je voor elk subdomein een apart certificaat aanvragen.

[thof]

Is veiliger ook, wild card certificaten zijn bad practice naar mijn weten. Ja ze zijn extreem flexibel en breed inzet baar. Ook zijn er situaties waar je niet zonder kan (dynamische subdomeinen).

Mocht je wildcard certificaat echter uitlekken zijn meteen al je subdomeine/applicaties in gevaar. Overal moet dan het nieuwe wildcard certificaat uitgerold worden. Als je per subdomein/applicatie een certificaat heeft, hoef je het alleen daarvoor te vervangen. Nadeel is alleen wat meer aanvragen en een lijst met certificaten bijhouden.

Edit:
Wildcard certificaten op een zelfde server is natuurlijk niet zo'n probleem, ik doel inderdaad op een wildcard certificaat voor meerdere servers.

[Reactie gewijzigd door thof op 26 juli 2024 09:51]

[mkools24]

Dat is dan toch lood om oud ijzer, met aparte certificaten heb je dat werk dus sowieso. Een wildcard kun je nog centraal wegzetten en wanneer deze verloopt met bijv. een scriptje overal vervangen.

Stel dat je 100 subdomains hebt (even overdreven) dan moet je dus een lijst bijhouden met expiratiedata en ben je heel het jaar door bezig certificaten te vervangen.

[The Lord]

100 subdomeinen is zo gek niet; wel vaker gezien.

Proces automatiseren zorgt ervoor dat de gespendeerde uren wel meevalt, maar er nog steeds genoeg controle is.

[CAPSLOCK2000]

Stel dat je 100 subdomains hebt (even overdreven) dan moet je dus een lijst bijhouden met expiratiedata en ben je heel het jaar door bezig certificaten te vervangen.

Hoe zo overdreven? We hebben er "iets" meer en dat kost niet meer dan een paar minuten per week. Als je zo groot bent moet je het wel automatiseren maar daar zijn wij gelukkig goed in

Ten eerste worden die lijsten met expiratiedata automatisch opgesteld op het moment dat een certificaat wordt aangemaakt. Op grond van die lijsten kunnen er automatisch herinneringsmails worden uitgestuurd (al is dat in praktijk zelden nodig).
Ten tweede hebben we monitoring op al onze diensten. De geldigheidsduur van een certificaat hoort daar ook bij. Als een certificaat dreigt te verlopen dan wordt er alarm geslagen.
Ten derde is ook het aanmaken en aanvragen van een certificaat prima te automatiseren. Als je dat eenmaal goed hebt gedaan dan kost het niet meer dan een paar seconde om een certificaat te vernieuwen. (Eerlijk gezegd heb ik het aanvragen nog niet geautomatiseerd, de website van de huidige leverancier is zo handig en snel dat ik het nog niet de moeite waard heb gevonden om dat te automatiseren, meer dan een minuut kost het niet).

[flabber]

Of het al dan niet veiliger is hangt voornamelijk af van je opzet en beveiliging.

Als je een wildcard certificaat gebruikt voor meerdere subdomeinen op 1 server, dan heb je maar 1 certificaat. En daarmee ook maar een locatie die je hoeft te beveiligen, 1 certificaat dat je moet vervangen, enzovoort.
Dan is zo'n certificaat wellicht een beter idee dan een stapel losse certificaten.
Ga je zo'n wildcard certificaat echter gebruiken om op 40 verschillende servers te installeren, dan ga je inderdaad de risico's enorm vergroten.

Zoals zo vaak is de veiligheid van een technische oplossing niet inherent aan de techniek zelf, maar afhankelijk van de manier waarop deze ingezet wordt.
Het is wellicht moeilijker om je per ongeluk te snijden aan een moderne cirkelzaag met allerhande (automatische) beveiligingen , maar gelukkig gebruiken chirurgen gewoon een scalpel voor het fijnere snijwerk....

[Jeanpaul145]

Als de aanvraag in real time en geautomatiseerd kan worden is er weinig aan de hand lijkt me, ook voor dynamische subdomeinen. Want dan kan je gewoon een aanvraag doen op t moment dat je dat subdomein genereert. Misschien is er dan een delay maar als dat binnen zekere grenzen blijft is daar denk ik wel omheen te werken.

Dit initiatief zal dus vallen of staan bij hoe makkelijk het is om die aanvragen te doen, en te automatiseren.

[D11]

Ook van belang is of er gebruik gemaakt kan worden van SNI, anders heb je voor ieder certificaat een uniek ip-adres en poort-nummer nodig. Voor websites gebruik je meestal poort 443, dat zou dan betekenen dat je per certificaat een apart ip-adres nodig hebt. Niet zo'n probleem met IPv6, maar met IPv4 is dat een ander verhaal.

[Freedive]

Maar ach het is toch gratis ;-)

[Verwijderd]

Dat is niet nodig, je kan bij je certificaat aanvraag een subject alternative name aangeven. Hiermee kan je dus 1 certificaat aan meerdere domeinen koppelen. Nadeel is dat je dan natuurlijk wel moet weten welke subdomeinen je gaat gebruiken van tevoren.

[TKroon]

De dienst gaat gratis ssl-certificaten verstrekken (...)

Houdt dit in dat ik bijvoorbeeld ook SSL-certificaten kan aanvragen voor mijn Synology?

[SiErRa]

Ja, maar het moet natuurlijk wel aan een domein hangen.
Dus die moet je nog wel registreren.

[TKroon]

Dat wilde ik dus juist omzeilen. Ik wil puur een veilige verbinding met mijn Synology, ik hoef geen eigen domein.

[Umbrah]

SSL is in den beginselen afhankelijk van een domeinregistratie. Een binding moet dan ook absoluut zijn en matchen met het certificaat. Een goed voorbeeld krijg jij als je (de eerste keer, wininet werkt nou eenmaal zo...) https://173.194.65.93 intikt. Oftewel: youtube/google. Je zult een certificaatfout krijgen, immers, het certificaat hoort bij *.youtube.com (technisch bij *.google.com, maar youtube staat in de SAN van het certificaat), en niet bij dat IP adres.

Je zult dus ergens een domijnnaam moeten registreren waar jij zeggenschap op hebt met een publieke DNS vermelding waarop jij de synology kan benaderen. Het IP adres is niet van jou (en bovendien: niet vast), en daarnaast is de DNS vermelding (randomzut.home.ziggo.nl of iets in die trend) óók niet van jou.

[TKroon]

Ah zo, dank voor de opheldering. Heb eigenlijk geen verstand van certificaten en hoopte op deze manier van die veiligheidsmelding van de Syno af te komen. Valt dus tegen

[dlmh]

Je thuisnetwerk achter een VPN hangen en dan al je diensten gewoon over HTTP/FTP/etc (zonder SSL in ieder geval). Dit is sowieso een best-practice om te voorkomen dat je thuisnetwerk naar buiten openstaat.

[TheVMaster]

dan registreer je een domeinnaam, kost een paar euro per jaar...

[DonnieDoezoe]

self-signed cert doen

[Tk55]

Nee dan krijg je alsnog een waarschuwing omdat het certificaat niet is ondertekend door een root CA.

[SirBlade]

Als je die NAS alleen met een beperkt aantal user/devices gebrukt kan je het certificaat toevoegen als trusted root.

[Sleepkever]

Als het puur alleen om het afkomen van de veiligheidsmelding gaat dan zou je het certificaat wat je Synology heeft ook zelf kunnen importeren in je eigen keystore (van je browser of windows) zodat deze ook automatisch vertrouwd word.

Afhankelijk van je browser verschillen de instructies helaas wel, dus het handigste is om even te googlen op "add ssl certificate to chrome" of firefox of IE, etc. Vaak komen daar duidelijk genoege verhalen uit.

Ik weet alleen niet of dit ook makkelijk op mobile toe te passen is.

[.oisyn]

Op Windows devices (zowel PC als telefoon) kun je gewoon het cert toevoegen door het naar jezelf te emailen en te openen. Daarmee pak je ook meteen Chrome overigens, die gewoon de Windows certificate store gebruikt.

[davasch]

Dan kan je altijd nog zelf een certificaat genereren en installeren. De verbinding is dan wel versleuteld.

[Rudie_V]

Zie bijvoorbeeld:
How to enable HTTPS and create a certificate signing request on your Synology NAS
https://www.synology.com/en-us/knowledgebase/tutorials/611

[Armin]

Dat wilde ik dus juist omzeilen. Ik wil puur een veilige verbinding met mijn Synology, ik hoef geen eigen domein.

Het idee van een SSL/TLS certifciaat is nu net indentifciatie/authenticatie van een domein/hostname. Als je geen domein wilt, is een SSL/TLS certifciaat niet wat je zoekt.

Merk verder op dat 'veilige verbinding' nogal algemeen is. Als je verwijst naar enkel encryptie is geen certficaat nodig. Als je bang bent dat iemand een Man-in-the-Middle aanval zal uitvoeren wel, maar dan is een self-signed certificaat genoeg.

Wat jij dan moet doen is:
- zelf een certifciaat genereren
- deze eventueel koppelen aan jouw unieke hostname
- deze gebruiken met je Synology

[Adm.Spock]

't Mag zelfs een bijvoorbeeld dyndns domeinnaam zijn (er zijn meer aanbieders van deze diensten).

[pe1dnn]

Dacht ik ook meteen aan.

Maar die certificaten worden toch afgegeven voor een bepaald domein? Het probleem is dat ik mijn Synology via 3 verschillende paden kan benaderen. Allereest via de quickconnect.to relay van Synology, maar die schakeld over op mijn WAN IP adres zodra gedetecteerd wordt dat de daarvoor benodigde poorten open staan en schakeld zelfs over op mijn lokale 192.168.xxx LAN adres als ik op mijn eigen netwerk zit. Kortom, kiest de snelste en meest directe route.

Dat gaat denk ik niet werken met een certificaat want die is alleen geldig voor een bepaald domein. Onder andere de Chomecast wil een geldig certificaat zien als die een ssl verbinding gebruikt maar dat is altijd op je LAN en daar krijg je denk ik geen certificaat voor...

[Dennis]

Dat kan wel, dan moet je subject alternative names gebruiken. Alleen als je echt totaal verschillende URL's wilt, dan gaat je domeinboer dit niet leveren. Je kunt het wel zelf maken met self-signed certificaten.

[Armin]

Sterker nog self-signed certificaten zijn De Officiele Oplossing™ voor intranet systemen. Jij bent dan immers zelf de CA van jouw intranet.

Als je Microsoft Internet Explorer gebruikt kun je zelfs een server aanwijzen op jouw netwerk die extended verifciatie doet, zodat je zelfs die befaamde groene balk bij je eigen certifciaten kunt hebben Niet echt iets voor tweakers geeft ik toe, maar voor bedrijven zeer handig.

[.oisyn]

Dat kon al, bij een partij als bijvoorbeeld StartSSL. Je zult alleen wel een globale domeinnaam moeten gebruiken, voor een lokale hostname is uniciteit niet gegarandeerd en dus kun je daar geen certificaat voor krijgen. Dat zal bij Let's Encrypt niet anders zijn.

.edit: eerst refreshen voor ik antwoord

[Reactie gewijzigd door .oisyn op 26 juli 2024 09:51]

[Verwijderd]

Ja.

[Paradox]

Wanneer je een certificaat zou kunnen uitbrengen op IPadres moet het ook werken...

[Verwijderd]

Begrijp ik hieruit dat eerst iedereen het ROOT certificaat moet installeren. DUS dat de browsers dit "nog" niet willen doen?

edit:
Hier is het antwoord:
Let’s Encrypt will issue certificates to subscribers from its intermediate CAs, allowing us to keep our root CA safely offline. IdenTrust will cross-sign our intermediates. This will allow our end certificates to be accepted by all major browsers while we propagate our own root.

PS: bedankt alleen hieronder, ik was iets te vroeg

[Reactie gewijzigd door Verwijderd op 26 juli 2024 09:51]

[xtr3me]

Zoals te lezen is in het artikel wordt dit voor de general release verholpen

Dinsdag heeft Let's Encrypt daarvoor een aanmelding voor opname in de rootgegevens van Apple, Mozilla, Google en Microsoft ingediend.

[ajakkes]

Hoeft niet , acceptatie is aangevraagd. Dus tenzij je het belangrijk vind helloworld zonder waarschuwing te bekijken , kan je ook even wachten tot acceptatie is afgerond.

[Verwijderd]

Momenteel moet je deze installeren als je hun certificaten ( en deze die ze uitgeven ) wil vertrouwen. In het artikel ( en op de website ) staat dat ze hun root-certificaten zullen aanbieden aan de browser- en osbuilders voor het mee te nemen in hun trusted-certificate store. Dan zal het niet meer nodig zijn om deze zelf te installeren.

[Dennis]

Ja, maar in het nieuwsbericht zie je ook al staan dat ze hiervoor aanvragen ingediend hebben.

Ook wel leuk is om te lezen hoe het 'aanmaken' van een root CA in de praktijk gaat bij zoiets, zie hier op Wikipedia: https://en.wikipedia.org/wiki/Key_Ceremony

Uiteindelijk is het één commandline die je uitvoert maar administratief komt er nog wel iets meer bij kijken.

[thof]

Een root certificaat moet altijd eerst getrust zijn door je systeem. Deze komen bijvoorbeeld mee met Windows Updates en nieuwe versies van browsers. Vandaar dat Let's encrypt een aanvraag voor opname gedaan heeft bij Microsoft, Google, Apple en Mozilla. In de tussentijd laten ze een andere certificaat autortity crosssignen.

[Reactie gewijzigd door thof op 26 juli 2024 09:51]

[Yalopa]

Ik ben wel benieuwd hoe ze denken iets te verdienen aan deze dienst / hoe ze de kosten gaan denken van deze dienst. Iemand moet oordelen dat de aanvrager wel degelijk is wie hij claimt te zijn en dus recht heeft op het certificaat. Die verificatie kost geld, ook de CA infrastructuur en aanvraag portals kosten geld...

[Siebsel]

Iemand moet oordelen dat de aanvrager wel degelijk is wie hij claimt te zijn en dus recht heeft op het certificaat.

Nee hoor, het gaat om domeinvalidatie. Dan is een DNS record of een bestand uploaden voldoende. Kan volautomatisch

[.oisyn]

Iemand moet oordelen dat de aanvrager wel degelijk is wie hij claimt te zijn

Nee hoor, dat moet pas bij EV ceriticaten. Voor een gewoon certificaat hoef je meestal alleen maar te bewijzen dat jij de domeineigenaar bent, meestal door een registratiecode te ontvangen op een standaard admin emaildres of een adres uit de WHOIS, of na het toevoegen van een speciaal DNS record.

[Tralapo]

Dat gaat volautomatisch via DNS of een aangemaakt bestandje op je server. Op de site legt Let's Encrypt het systeem helemaal uit, met plaatjes zelfs

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

[Patrock]

Mooie ontwikkeling. Ik heb enkele sites die ik zodra het mogelijk is wel overzet naar HTTPS dmv. letsencrypt. Nu hopen dat door dit initiatief inderdaad het web overgaat naar https.

[Niemand_Anders]

Je kunt nu al gratis ssl certificaten krijgen op www.startssl.com.
Hun systeem is wel traag, dus ik hoop dat Let's Encrypt een sneller systeem straks heeft staan..

Ik heb zelf twee domeinen (www en een voor mail) en voor 30 dollar per 3 jaar ga ik niet uren verbrassen op een traag systeem.

Probleem is alleen dat steeds meer partijen slechts een oppervlakkige controle uitvoeren betreffende de authenticiteit van de aanvrager. Vaak is het niet meer dan een email naar een emailadres welke uit de DNS registraties wordt gehaald. Echter dat jij die mail kan onderscheppen betekend helemaal niet dat jij de eigenaar bent van dat domein, maar dat jij slechts toegang hebt tot de betreffende mailbox..

Om die reden zijn ook EV-SSL certificaten ingevoerd welke op technisch vlak niet afwijken van reguliere SSL certificaten. Ze hebben alleen een extra OID in het systeem en de lijst van EV-SSL CA's is hardcoded en beperkt. Als een partij geen goede controle uitvoert kunnen uit die lijst worden gegooid. Daarnaast is opname als EV-SSL CA ontzettend duur. De meeste EV-SSL certificaten komen van resellers welke door hun grote volume wel interessante prijzen aanbieden dan de root-CA zelf doet. Vergelijk het met de registratie van een .COM, .NET of .ORG domain. Verisign is de beheerder van deze TLDs, vrijwel alle aanbieders zijn goedkoper dan Verisign zelf..

Zorg wel dat je RSA key minimaal 2048 bits is. Op basis van de huidige bekende super computers duurt het kraken van een 1024 bits key een paar miljoen jaar, maar de NSA/CIA hebben decenia lang een super groot miljarden budget gehad dat niemand met zeker de decryptie kracht van de Amerikanen goed kan inschatten. Daarnaast zou het mij niets verbazen als de wetenschappers van DARPA al veel verder zijn met quantum encryptie/decryptie van de bekende universiteiten..

Daarin tegen is de kans natuurlijk ontzettend klein dat de NSA al haar computer capaciteit gaat inzetten om jouw key te kraken. Echter als je Poetin of Al-Asaad heet, ligt dat wat anders..

[gj710]

Zag wel net dat Let’s Encrypt op zijn hello pagina het certificaat 2048 bits is. StartSSL certificaten zijn 4096 bits. Misschien dat ze later wel hogere bits certificaten gaan uitgeven, maar dat is wel iets om over na te denken

[SleutelMan]

De vraag is of het handig is om key lengths langer dan 2048 bits te gebruiken. De performance van je systeem neemt daarbij sterk af terwijl het qua beveiliging niet zo heel veel toevoegt. Dan kan je beter nog elliptische curven gebruiken.

Of, in iets meer toegankelijkere taal, zie https://www.ssllabs.com/projects/best-practices/index.html

[Reactie gewijzigd door SleutelMan op 26 juli 2024 09:51]

[thegve]

Probleem is alleen dat steeds meer partijen slechts een oppervlakkige controle uitvoeren betreffende de authenticiteit van de aanvrager.

Nee, browsermakers hebben beperkte/vage eisen gesteld aan CA's. Wat de 'traditionele' CA's vervolgens zijn gaan doen is daarbij een heel moeilijk ernstig gezicht trekken. Wat geautomatiseerde checks doen, eventueel nog wat administratie miepjes inhuren die aan de lopende band wat eenvoudige controles doen, en vervolgens belachelijk veel geld vragen hiervoor. Dezelfde checks die ook bijvoorbeeld bij de aanvraag van een telefoonabonnement of zakelijk contract gedaan worden, en die je hier vervolgens niet apart gefactureerd ziet.
Steeds meer nieuwere CA's stoppen hier mee, en werken met normale marges zonder hun marktpositie uit te buiten.
Hierop is het 'Extended Validation'/EV uitgevonden die de validatie procedure beter heeft gestandaardiseerd, en waar de traditionele partijen vervolgens weer verder mee kunnen met proberen de consument uit te melken voor het controleren van een KVK-uittreksel en een paspoort.

Echter dat jij die mail kan onderscheppen betekend helemaal niet dat jij de eigenaar bent van dat domein, maar dat jij slechts toegang hebt tot de betreffende mailbox..

Als jij en toegang hebt tot de mail van het domein, en toegang tot de server waar het SSL certificaat voor bedoeld is, heb je aardig wat toegang en daarmee is het terecht dat een beperkt DV-certificaat kan worden uitgegeven. Er is niet voor niets onderscheid met een EV.

Daarnaast is opname als EV-SSL CA ontzettend duur. De meeste EV-SSL certificaten komen van resellers welke door hun grote volume wel interessante prijzen aanbieden dan de root-CA zelf doet. Vergelijk het met de registratie van een .COM, .NET of .ORG domain. Verisign is de beheerder van deze TLDs, vrijwel alle aanbieders zijn goedkoper dan Verisign zelf..

Je verwart hier DNS met SSL. SSL werkt niet met monopolies op top level domains, dat doet alleen DNS.
Edit: Ik miste je punt even, je maakte een analogie. Bij Startcom valt ook een EV-SSL certificaat wel mee qua prijs overigens.
Edit 2: Nou ja, meevallen. Nog altijd $140...

Daarin tegen is de kans natuurlijk ontzettend klein dat de NSA al haar computer capaciteit gaat inzetten om jouw key te kraken.

De vraag is of het kraken van de encryptie de meest efficiente manier is voor de NSA. Ze kunnen ook gewoon een Amerikaanse CA forceren om een geldig certificaat uit te geven voor hetgeen ze willen afluisteren, en dan een MITM aanval uitvoeren.

[Reactie gewijzigd door thegve op 26 juli 2024 09:51]

[Yodocus]

Nu zijn er meerdere CA's die gratis SSL certificaten leveren zoals StartCom. Ik heb een StartSSL certificaat op mijn Synology staan. In hoeverre verschilt Let's Encrypt van een bedrijf als StartCom? Behalve dat eerstgenoemde een nonprofit initiatief is.

[Reactie gewijzigd door Yodocus op 26 juli 2024 09:51]

[Tralapo]

Uiteraard dat laatste, StartSSL voelt toch nog steeds als een louche organisatie af en toe. Dat zal natuurlijk wel meevallen, maar de site is een gedrocht en het systeem traag.

Maar de kracht van Let's Encrypt moet ook worden dat je certificaten straks volautomatisch via de command line kunt aanvragen en ook zichzelf laten renewen. Zie ook https://letsencrypt.org/howitworks/

[Lanithro]

hmmmm klinkt interessant. Zeker dat ik er een paar ga gebruiken voor mijn Synology...

[gj710]

Je kan ook gebruik maken van StartSSL, die verstrekken ook gratis SSL certificaten voor niet commercieel gebruik.

Gebruik ze zelf ook voor 2 domeinen en werken prima!

Alleen jammer dat de aanvraag procedure/installatie wel wat makkelijker mag. Maak je een fout in de aanvraag/installatie en wil je(moet) het certificaat opnieuw aanvragen dan kan je betalen.

Maar dat is voor de gemiddelde Tweaker geen probleem

[mkools24]

Ach ik bestel ze meestal bij ssls.com, daar heb je ze al voor $5,- per jaar daar ga ik echt niet moeilijk voor lopen doen.