Meer dan 150 miljoen domeinen gebruiken tls-certificaat van Let's Encrypt

Het aantal websitedomeinen dat gebruikmaakt van een tls-certificaat van Let's Encrypt is gestegen naar 152 miljoen. De organisatie achter Let's Encrypt verwacht voor dit jaar een verdere stijging, tot 215 miljoen websites.

Er zijn bijna 88 miljoen tls-certificaten van Let's Encrypt voor de 152 miljoen sites actief, blijkt uit statistieken van de Internet Security Research Group, of ISRG, de juridische entiteit achter het Let's Encrypt-initiatief. De organisatie verwacht dat in 2019 de aantallen zullen stijgen naar 120 miljoen actieve tls-certificaten voor 215 miljoen websites.

De ISRG bedankt verder iedereen die is betrokken bij de ontwikkeling van de meer dan 85 softwareclients voor het acme-protocol van Let’s Encrypt. Verder hoopt de organisatie dat dit jaar Nginx ingebouwde acme-ondersteuning krijgt, zoals Apache al heeft. Met acme kunnen gebruikers certificaten voor hun sites verkrijgen.

Het Let's Encrypt-initiatief nam in 2015 het eerste tls-certificaat in gebruik. Het doel is om met gratis verstrekking en eenvoudige implementatie elke site via https benaderbaar te maken. Achter het initiatief zitten onder andere de EFF, Mozilla, Cisco, Akamai, IdenTrust en onderzoekers van de universiteit van Michigan. ISRG wijst erop dat volgens Mozilla inmiddels 77 procent van de page loads versleuteld was, een stijging ten opzichte van de 67 procent van het jaar ervoor.

Reacties (126)

[CAPSLOCK2000]

Geweldig project. We geven geen Nobel-prijzen voor IT maar dit project verdient er een. Ik kan weinig andere bedrijven of projecten bedenken die zo veel impact hebben gehad op de beveiliging van internet.

Ik had gedacht dat na het succes van LE de traditionele CA's in actie zouden komen om hun producten en diensten aantrekkelijker te maken ten opzichte van het gratis LE. Dat lijkt nauwelijks te gebeuren, maar ondertussen is die markt wel in aan het storten. De ene na de andere CA wordt op gekocht en het komt steeds meer in handen van de paar overgebleven reuzen.
Dat vind ik geen goede ontwikkeling, er moet geen monopolie op commerciele CA's ontstaan. Dat zou veel te veel een zwak punt worden voor de beveiliging van de hele wereld.

De kern achter het succes is natuurlijk het ACME-protocol. Dat maakt het allemaal zo makkelijk dat je wel gek bent om er geen gebruik van te maken. De traditionele CA's hebben ook wel API's maar geen die zo fijn is als ACME en al helemaal geen universele standaard.

Mijn werkgever heeft bulk-contract met een CA waardoor het voor ons heel goedkoop, praktisch gratis, is om certificaten te krijgen. Toch kijken we naar het gratis LE omdat het makkelijker te automatiseren is. Helaas kun je LE niet voor alle doelen gebruiken, daarom moeten ook een traditionele CA blijven gebruiken. Als we daar hetzelfde protocol voor zouden kunnen gebruiken zou dat makkelijker zijn.

[bbob]

Maak er zelf dankbaar ook al een tijdje gebruik van. Werkt zoals je zegt ook heel eenvoudig en geautomatiseerd met de meeste controle panelen.
Voor sommige zaken zul je het misschien niet kunnen gebruiken voor een heel groot deel van alle websites wel.

Kwam vorig jaar helaas 1 webshoster in Nederland tegen die het niet ondersteunde. Flexwebhosting en daar kreeg ik dit commentaar over let's encrypt.

[/quote]
Tevens liggen de certificaten van Let's Encrypt op dit moment onder vuur daar er geen controle is op welke domeinnaam deze worden uitgegeven. Er worden derhalve op dit moment zeer veel phishing sites opgezet met een L.E. certificaat om het voor de bezoekers weer net iets geloofwaardiger te maken. Het is niet ondenkbaar dat in de komende tijd deze certificaten door de grote browsers als onveilig zullen worden aangemerkt.

Mocht u echter een gedegen beveiliging wensen op basis van een Comodo Certificaat, inclusief installatie support en onderhoud kunnen wij u voor 42 euro ex btw per jaar een standaard Comodo SSL certificaat leveren.
[/quote]
tja die wilden dus gewoon dure certificaten verkopen of klanten onzin verkopen. Veel van hun klanten weten waarschijnlijk niet beter en kopen dan maar certificaat.

Gelukkig doen de meeste webhosters daar niet aan mee en bieden ze standaard let's encrypt aan.

[Ventieldopje]

Grotendeels onzin maar met een kern van waarheid, echter heeft dat niks met LE te maken maar met het type certificaat (DV, domain validation). Daarbij wordt het bedrijf niet gechecked zoals bij OV (organisation validation) en EV (extended validation) wel gebeurd.

Die bieden zeker meerwaarde voor bedrijven

[GertMenkel]

Daarbij wordt het bedrijf niet gechecked zoals bij OV (organisation validation) en EV (extended validation) wel gebeurd.

Klopt wel, maar dat maakt het nog niet veel veiliger.

Het staat leuk voor de bedrijven (en dan vooral voor managers), maar het voegt weinig beveiliging toe.

Je bezoekers weten niet dat jij EV gebruikt en je bezoekers gaan daarom ook niet op zoek naar een EV meldertje. Daarom markeren Chrome en Firefox HTTP-websites ook als onveilig in plaats van "veilige" HTTPS-websites als veilig te markeren.

[AddictIT]

Ik kwam enige tijd geleden onderstaand artikel tegen van Scott Helme, onder andere bekend van websites zoals securityheaders.io.


https://scotthelme.co.uk/...d-other-related-nonsense/


Alle zin en onzin van betaalde/free certificaten...
Maar het idiote is dan wel weer dat de overheid (zeker in NL) alle overheids-gerelateerde diensten verplicht om een Overheids PKI-certificaat te gebruiken... Ik snap het wel, maar toch...

[GertMenkel]

Ik kan PKI Overheid eigenlijk wel waarderen. Het heeft me meer dan eens bevestigd dat bepaalde initiatieven/informatiesites daadwerkelijk van de overheid waren. Misschien niet het normale gebruik van een CA infrastructuur, maar toch.

Ook voegt het wat onafhankelijkheid toe voor de overheid. Zo kan een Amerikaans certificaatboer geen rare eisen stellen aan/prijzen vragen van de overheid.

[The Zep Man]

Die bieden zeker meerwaarde voor bedrijven

Tenzij het vanuit wet-/regelgeving verplicht is bieden OV en EV maar weinig toegevoegde waarde. EV biedt soms een groen balkje. OV doet eigenlijk niets extra's, behalve wat meer attributen in het certificaat.

De massa van gebruikers boeit het helemaal niets wat voor soort certificaat gebruikt wordt.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 23:53]

[morphje]

Ik had toch waarschijnlijk een heel kribbig mailtje teruggestuurd, dit zijn pure leugens om de eigen certificaten tegen grof geld te verkopen.

Je kan ook gewoon heel eerlijk zeggen naar je klant. Luister, LE is gratis, maar opzetten kost tijd, daarvoor brengen wij X in rekening. (dat doen ze nu ook trouwens, want 42 euro is een belachelijke prijs)

[To_Tall]

Opzetten kost tijd???

Ik heb al een aantal reverse proxy servers opgebouwd die Lets encrypt gebruiken. Helaas wordt acme nog niet gebruikt bij nginx. Maar dat staat op stapel.

Hoeveel werk het is om LE in Cpanel in te bouwen weet ik niet. Maar LE opzetten is half uurtje werk via terminal.

[Verwijderd]

Een half uurtje is toch gauw 40..50 euro wat de klant moet betalen. Hopelijk leest jouw baas niet mee....

[To_Tall]

Wordt de context niet begrepen??

40 euro eenmalig opzet kosten is goedkoper dan jaarlijks 42 euro neer te tellen. Of meerdere domeinen Een certificaat te geven.

Dus nee dan is LE goedkoper voor de klant ook al zou je de opzet/onderhoud kosten door berekenen.

Het gaat hier dat de installatie kosten en tijd gemoeid gering is LE Inc scripting voor autorenew elke 20 dagen. Kost mij 5 min om dit op een RP te plaatsen. Onderhoud?? Paar min per jaar door certbot te updaten en een renew test uit te voeren. Misschien hier en daar een keer extra kijken naar de config. Maar draaide het dan draait het.

[sylvester79]

En een half uur is geen tijd?

[laracroftonline]

Le zit al in cpanel net zoals cpanel eigen gratis certificaten.

[To_Tall]

Het ging om een webhoster geen enterprise omgeving.

Ik kan me niet indenken dat flexhoster 1000den servers heeft staan. En deze dan ook voor 24 euro kan aanbieden

Deze kan vrij eenvoudig een script opbouwen waarbij de eigenaar met een druk op de knop een certificaat krijgt en deze elke drie maanden automatisch laat verlengen.

[dbzokphp]

Wat een onzin. Ze willen inderdaad gewoon certificaten verkopen.
Zelf ben ik inmiddels overgestapt naar mijn.host, waarbij ik ook tevreden gebruik maak van Let’s Encrypt op al m’n websites. Heeft me al veel geld bespaard tegenover normale certificaten.

[MrFax]

Maar de certificaten worden uitgegeven voor een bepaald domein om te verifiëren dat het ook echt bij de server achter de domein aankomt. Dit is om zeker te weten dat een HTTPS verbinding wel echt van die server vandaan komt. Als dus bijv. de server achter het domein/HTTPS certificaat gehackt wordt heb je er nog niks aan.

Dat is het. Je moet dus nog steeds zelf controleren op het domeinnaam wel klopt.

[Reactie gewijzigd door MrFax op 22 juli 2024 23:53]

[BytePhantomX]

Ik zit bij Flexwebhosting en zeur al sinds de start om ondersteuning van LE. Dat weigeren ze volgens mij alleen omdat ze dan een verdien optie verliezen.

Serieus overwogen om over te stappen. Dat was me echter iets teveel werk voor een simpel blogje. Nu achter een gratis cloudflare account gezet. Gratis ssl en goede performance. Helaas wordt dat officieel ook niet ondersteund, maar het werkt tot nu toe prima.

[bbob]

Ik ben meteen opgestapt, was een simpel blogje voor seo. Probleem is echter google wil graag ssl zien en dus is geen ssl slecht voor je ranking.

Snap dus nog steeds niet dat dit soort bedrijven dit soort onzin blijft verkopen en niet meer klanten gewoon weglopen.

[jordynegen11]

Het is natuurlijk groot en deels onzin.

“Tevens liggen de certificaten van Let's Encrypt op dit moment onder vuur daar er geen controle is op welke domeinnaam deze worden uitgegeven.

Er word door letsencrypt wel degelijk gecontroleerd voor welk domeinnaam het certificaat wordt aangevraagd. Dit doe je door een bestandje up-te-loaden naar je webserver. (Afhankelijk van je platform gaat dit automatisch)

Daarnaast is een vertificatie sws al ruck bij ieder certificaat. Als je een EV certificaat aanvraagd bij bijvoorbeeld Comodo, dan word je alleen gebeld door een indiër met slecht verstaandbaar engels en is een inschrijving bij de kvk voldoende.

[bbob]

Klopt helemaal maar bij flexwebhosting gaan ze er denk ik van uit dat de meeste klanten weinig kennis hebben en dus de onzin die ze verkopen geloven.

[CAPSLOCK2000]

Wat bij google, Mozilla, Facebook, etc etc gratis is lijkt zijn, is in veel gevallen iets te veel van het goede... Ergens voel ik nattigheid!het zoveelste bedrijf!onthoud goed niks is gratis in deze wereld.helemaal niks.

Ik snap niet waarom je Mozilla in dat lijstje zet, maar goed.
Ik snap wel waarom je argwaan hebt, daar ben ik zelf namelijk erg goed in.

In dit geval kan ik echter begrijpen waarom ze dit doen en daar zie ik niks verkeerds in.
Het is uiteraard eigenbelang.
Deze partijen zijn afhankelijk van internet en het succes en de reputatie van internet is van directe invloed op hun eigen succes. Zonder SSL was internet te onveilig geworden. Dat was (en is) een gigantisch risico voor die bedrijven en organisaties. Via LE wordt het voor iedereen veiliger. Daardoor loopt er meer handel via internet en daar profiteren deze bedrijven dan weer van.

[DigitalExorcist]

Het doel is om met gratis verstrekking en eenvoudige implementatie elke site via https benaderbaar te maken.

Certificaat of niet verandert toch niks aan het toegankelijk zijn via https? Het is alleen een soortement van waarborg dat je praat met wie je denkt te praten... https werkt technisch ook prima zonder certificaat.

[Blokker_1999]

HTTPS werkt niet zonder certificaat. Hoe kom je daar in hemelsnaam bij. De S staart voor Secure en dat bekom je net met behulp van een certificaat. Dat certificaat in combinatie met de private sleutel van dat certificaat wordt gebruikt om de inhoud te versleutelen.

En een certificaat is geen bewijs van identiteit, het betekend alleen dat de verbinding tussen je browser en de webserver is versleuteld. Wil je bewijs van identiteit dan zal je voor EV certificaten moeten gaan, en die zijn niet gratis.

[.oisyn]

En een certificaat is geen bewijs van identiteit, het betekend alleen dat de verbinding tussen je browser en de webserver is versleuteld

Natuurlijk is dat het wel, alleen is de indentiteit bij DV certificaten beperkt tot louter de domeinnaam.

[aikebah]

En een certificaat is geen bewijs van identiteit, het betekend alleen dat de verbinding tussen je browser en de webserver is versleuteld. Wil je bewijs van identiteit dan zal je voor EV certificaten moeten gaan, en die zijn niet gratis.

Certificaat is wel een bewijs van identiteit, echter in de standaardeditie (DV) alleen een bewijs van identiteit van de server. Het is namelijk een combi van

• de publieke sleutel die hoort bij de private sleutel van de server
• meta-informatie over de eigenaar van die sleutel, bij een DV certificaat alleen de domeinnaam, bij OV/EV ook info over de rechtspersoon die het certificaat heeft verkregen
• de handtekening van de uitgever, die daarmee aangeeft dat de informatie over de identiteit correct is

Dan is het alleen nog aan de ontvanger om vertrouwen te hebben in de uitgever om te komen tot een betrouwbaar vastgestelde identeit (van ofwel slechts de webserver ofwel tevens de rechtspersoon achter de website)

[latka]

Nope. Certificaat is nodig. Self-signed kan ook, maar dan gaat je browser bokken, dus dat wil je niet.

[DigitalExorcist]

Werkt dus wél en staat dus los van het https protocol..

EDIT: ja, je hebt dan wel een self-signed certificaat nodig ja.

[Reactie gewijzigd door DigitalExorcist op 22 juli 2024 23:53]

[.oisyn]

Een website waarbij het door de browsermaker zo onhandig mogelijk wordt gemaakt om het ongeldige certificaat toch te accepteren noem ik niet "werken" .

Bovendien klopt het gewoon niet wat je zegt. Https is er om mitm aanvallen tegen te gaan. Het certificaat geeft de andere partij het vertrouwen dat jij bent wie je zegt dat je bent. Dat vertrouwen heb je niet bij zelf ondertekende certificaten - iedereen, dus ook de man in het midden, kan een eigen certificaat ondertekenen voor élke website. Als jij als gebruiker een zelfondertekend certificaat accepteert, is er dus geen enkele veiligheid en kun je net zo goed geen https gebruiken.

[Reactie gewijzigd door .oisyn op 22 juli 2024 23:53]

[DigitalExorcist]

Dat eerste is puur een kwestie hoe browsers dit afhandelen en staat los van het protocol...

[.oisyn]

En het tweede en belangrijkste punt negeer je voor het gemak maar even?

[DigitalExorcist]

Gezien het aantal recente problemen met certificeringen en de instanties die dat moeten doen is het maar één van de broodnodige middelen, en zéker geen wondermiddel tegen MITM-aanvallen.

Encryptie blijft hetzelfde, of een certificaat self-signed is of niet.

[.oisyn]

Dan heb je het onderliggende punt niet begrepen. Zonder certificaat heb je simpelweg geen idee met wie je praat. Het kan net zo goed de persoon zijn van wie je het verkeer wil afschermen.

[WhatsappHack]

Toch ben ik het niet helemaal met je eens. Ik snap je punt mbt authenticatie, maar een self-signed certificaat is wat mij betreft nog altijd beter dan helemaal geen encryptie... Bij beiden moet je op je hoede zijn, maar als ik moet kiezen: dan liever self-signed dan helemaal niets.

Ik heb dat altijd achterlijk gevonden eigenlijk... Krijg je een site met een self-signed certificaat dan screeuwt de browser moord en brand en rode schermen met “BRENG ME IN VEILIGHEID!!1!”, maar bezoek je een http site? Joe, geen probleem. Geen foutmelding. Niets. Pas recent zijn ze maar een rood slotje gaan tonen, maar dan nog is ‘t allemaal vrij alarmloos...

Een betere situatie zou zijn dat ALLES standaard versleuteld is. Self-signed of niet zal me een rotzorg zijn als het niet anders kan: prima, laat alles dat nu nog niet versleuteld is maar self-signed gebruiken (of nouja: een variant op...) en call it a day; beschouw dat maar ‘t zelfde als hoe plain-text http nu behandeld wordt. En dan SSL certificaten écht enkel nog gebruiken voor authenticatie en verificatie (dus waarschuwingen als de sleutel opeens wijzigt of is verlopen), maar niet als vereiste om überhaupt versleuteling te gebruiken. Het moet gewoon altijd versleuteld zijn, opbokken met dat hele http://.

-edit- Rare typo fix.

[Reactie gewijzigd door WhatsappHack op 22 juli 2024 23:53]

[.oisyn]

Dan snap jij het ook niet . Stel Tweakers.net heeft een self-signed cert. Jij doet een request naar de site, accepteert dat hij self-signed is en je denkt dat het allemaal koek en ei is. Maar ondertussen zit ik ertussen. De handshake die jij met tweakers.net dacht te maken heb je met mij gemaakt omdat ik het domain heb gehijackt (of wat dan ook, is niet belangrijk). Aan het certificaat kun je het niet zien, want ik kan de details van het self-signed cert exact overnemen (met uitzondering van de public key). Je verkeer is dus helemaal niet veilig, ookal was het https.

Bottom line, op het moment dat je geen idee hebt met wie je praat (wat dus het geval is bij een self-signed cert), heeft het encrypten van dat verkeer geen enkel nut, want iedereen kan als proxy fungeren. Vooral bij https, wat kortlevende stateless verbindingen zijn waarbij de handshake bij elk request opnieuw wordt gedaan. Het is echt niet voor niets dat browsers hier zo anal over zijn.

[Reactie gewijzigd door .oisyn op 22 juli 2024 23:53]

[WhatsappHack]

Ik snap het wel, maar jij snapt mij niet denk ik.
Even versimpelen: Tweakers heeft geen certificaat en ondersteund enkel http. Jij doet een request naar de site, accepteer helemaal niets en alles en iedereen die ook maar ergens op de route toegang heeft tot het verkeer kan meelezen of zelfs manipuleren (eg: MitM). Aan het certificaat kan je het niet zien, want die is er simpelweg niet. De barriere om overheen te springen om dat met een self-signed cert te doen is een stuk hoger, niet elk 12 jarig ventje met WireShark kan dan meelezen. Daarnaast vinden op self-signed certificaten ook controle plaats overigens in de manier waarop het op dit moment werkt. Als het certificaat opeens wijzigt krijg je alsnog een melding.

Dat encryptie geen nut zou hebben zonder authenticatie ben ik het niet mee eens. Encryptie met, relatief gezien veel lagere, risico’s is beter dan helemaal geen encryptie... En daarom pleit ik er ook voor om gewoon al het verkeer te encrypten. Standaard. Geen plain-text verbindingen meer.
Wat je nu eigenlijk zegt is dat plain-text even onveilig is als een versleutelde verbinding met self-signed certificaat. Vanuit het oogpunt van authenticatie klopt dat, vanuit oogpunt van versleuteling niet. Immers moet dan de signer evil zijn of de privésleutel gejat zijn, maar dat hoeft niet zo te zijn. Dat je zonder extra stappen, en dus niet automatisch, niet kan controleren dat het is wie het certificaat zegt dat het is: soit, maar daar gaat het mij helemaal niet om. Ik wil gewoon af van plain-text verbindingen, en enkel een certificaat controle doen voor authenticatie en verificatie; maar de rest moet hoe dan ook versleuteld zijn.

Als ik zou moeten kiezen wat ik liever heb: helemaal geen versleuteling, of versleuteling met een self-signed certificaat: doe mij dan maar lekker versleuteld met self-signed cert en de risico’s hou ik zelf wel in de gaten of vang ik af. Je komt er ook niet altijd omheen, zo kan ik voor bepaalde apparatuur hier in huis geen geldig certificaat aanvragen: maar echt wel dat ik er een self-signed certificaat opgooi en de communicatie lekker versleutel hoor. En zeker dat dat vele malen veiliger is dan plain-text. Dus nee, ik ga absoluut niet mee in je stelling dat self-signed even onveilig is als plain-text. Het voegt niet veel toe, akkoord... Maar het is vele malen beter dan alles maar in plain-text over het internet knallen.

Het liefst gaat dat op protocollevel overigens. Dus standaard encryptie zonder dat er perse certificaten nodig zijn. Dan kan je ‘t laten werken zoals ‘t nu werkt met certificaten en voor de rest hebben gebruikers het niet eens door; maar zit de encryptie wel op de lijn. Het was ooit een doelstelling voor HTTP/2, maar volgens mij heeft dat het uiteindelijk toch niet helemaal gehaald. Voornamelijk vanwege de opzet met TLS en omdat sommige apparaatjes het niet aankunnen. Toko’s als Firefox stellen het wel verplicht, maar dan moet je alsnog werken met certificaten... Mijn ideaal is dus als dat niet hoeft *tenzij* je wilt authenticeren. (Slim plan!) Ik wil dat al het http verkeer te allen tijde volledig versleuteld is, ook zonder wat voor certificaat dan ook, en dat certificaten ingezet worden voor extra beveiliging, authenticatie/verificatie. Je zou het zelfs zo kunnen bouwen dat “http” voortaan weliswaar volledig encrypt is maar niet met certificaten werkt en “https” blijft werken zoals nu: self-signed of verlopen cert = waarschuwing, geldig certificaat = groen balkje. Dan hoeft men ook nergens aan te wennen, het is op de achtergrond versleuteld: maar het blijft als http bekend staan. En https blijft werken zoals het altijd al gewerkt heeft met certificaten en validatie. Win-win, ben je in ieder geval af van die plain-text verbindingen. Dat lijkt me beter dan blijven hangen op plain-text HTTP... Maar goed, daar mogen de meningen natuurlijk over verdeeld zijn.


-edit- Trouwens, nu ik er over nadenk. Apple iMessage heeft defacto ook geen authenticatie in de zin van controle of je wel praat met wie je denkt te praten (zoals Signal en WhatsApp bijvoorbeeld wel aanbieden dmv fingerprints die je out-of-band kan controleren.). Wel is het rete goed versleuteld. Dan kan je twee dingen denken. 1) Kak, dan heb ik liever helemaal geen encryptie want dat is even onveilig (wat jij eigenlijk zegt als het om http vs https gaat ), 2) Ik heb liever encryptie, maar snap dat het caveats heeft en dat ik de verwerker (Apple) moet vertrouwen. (En als ik dat niet doe: dan geen gevoelige details sturen.) Is het ideaal? Vanuit beveiligingsoogpunt zeker niet, ondanks de sterke encryptie. Maar het blijft beter dan plain-text...

[Reactie gewijzigd door WhatsappHack op 22 juli 2024 23:53]

[.oisyn]

Ik snap je best, maar je bagatelliseert het probleem. Vraag het elke security expert en hij zal je vertellen dat het verschil tussen afluisteren en het manipuleren van verkeer flinterdun is. Jij bent simpelweg op zoek naar een schijnveiligheid. Je wil graag denken dat je veilig bent zolang je alleen maar afgeluisterd kan worden, maar die situatie bestaat vrijwel nooit.

Ik had het overigens niet over self signed certificaten in het algemeen. Uiteraard kun je prima een specifiek certificaat vertrouwen, of een self signed CA opzetten (wat ik voorheen deed thuis) en die gebruiken om certs te genereren die je vertrouwt binnen je netwerk.

Maar het sleutelpunt is natuurlijk het vertrouwen. Jij wil encryptie ook zonder vertrouwen. Dat is simpelweg relatief nutteloos. Een afluisteraar kan ook manipuleren, en als je kunt manipuleren kun je als proxy werken. Daarom is er een public key infrastructure.

[WhatsappHack]

Ho ho, ik wil niet denken dat ik veilig ben. Ik wil gewoon standaard meer veiligheid dan de plain-text verbindingen die we nu hebben... Ik had een toevoeging gedaan aan m’n post, maar kreeg steeds 400-errors dus heeft ff geduurd, wellicht heb je dat gemist. Wat mij echt ideaal lijkt is als het op protocol niveau geregeld is. http blijft http (“onveilig”), maar de verbinding is wel versleuteld. Je kan https met dat hele certificaat, CA, PKI en het hele rataplan dan laten functioneren hoe het nu is: maar je bent wél van het plain-text verbinding gezeik af... Je kan toch niet serieus ervoor pleiten dat het dan maar onversleuteld laten beter is of even veilig als tenminste enige encryptie?
Mind you, nergens zeg ik dat je je veilig zou moeten wanen zonder authenticatie: maar het is simpelweg beter dan helemaal geen encryptie én geen authenticatie. Liever 1 van de 2 dan all or nothing helemaal niets...

Het verschil tussen afluisteren en manipuleren is erg groot overigens, maar ik neem aan dat je bedoelde dat de vervolgstappen zonder authenticatie makkelijk zijn. Dat klopt. Maar dat neemt niet weg dat enige default versleuteling nog altijd beter is dan helemaal geen versleuteling. Ik ben het sowieso niet eens met de stelling dat als je kan afluisteren dat je dan ook per definitie kan manipuleren. Dat hoeft niet zo te zijn, zeker niet omdat je daar iets meer kennis voor moet hebben dan louter wireshark oid starten. Zonder authenticatie is het een stuk makkelijk om onopvallend te manipuleren, dat is zeer zeker waar. Maar het manipuleren zelf is lang niet altijd zomaar te doen. Dat ik naar het gesprek van Bob en Alice kan luisteren wil niet zeggen dat ik dan automatisch ook en-route wat Bob of Alice zegt zomaar kan manipuleren. Natuurlijk kan ik me zonder certificaat makkelijker voordoen als Bob of Alice, maar dat wil niet zeggen dat ik dat altijd zomaar kan.

Dus: ja, eigenlijk wel. Ik wil inderdaad ook encryptie zonder vertrouwen, dat heb je goed. Dat wordt in mijn idee dan wat we nu kennen als http. https blijft encryptie mét (redelijk) vertrouwen, dus op certificaat basis. Maar de standaard plain-text van http moet gewoon verdwijnen en plaats maken voor een variant met encryptie.
Uiteraard kunnen we het er over oneens zijn hoeveel verschil dat maakt, maar ik vind het een wezenlijk groot verschil dat ik het graag zou zien... En de originele HTTP/2 spec lijkt het op dat punt eigenlijk met me eens te zijn, al waren er helaas teveel hurdles om dat ook daadwerkelijk onderdeel van de standaard te maken ivm vereiste resources.

Maar ik had het prachtig gevonden! Gewoon altijd versleutelen en https blijven inzetten voor versleuteling mét authenticatie als vereiste. Het beste van twee wereleden en eindelijk af van die encryptieloze http-verbindingen. Ik ben er heilig van overtuigd dat dit absoluut veiliger zou zijn dan de 0,0 encryptie die nu op http-verkeer zit. Ik snap echt niet hoe je kan stellen dat plain-text communiceren beter zou zijn dan op z’n minst een soort basis-encryptie in te voeren, maar goed... Ik respecteer je mening. Ik vind een basis encryptie geen scheinveiligheid, maar simpelweg beter dan de “dan maar helemaal geen versleuteling!” gedachtengang. 100x liever een basisencryptie op http dan het plain-text houden waarbij je sowieso maar één garantie hebt: iedereen met toegang tot de datastream kan meelezen; zelfs als die toegang enkel read-only is. Met een basisencryptie kan dat niet meer zomaar.

[Reactie gewijzigd door WhatsappHack op 22 juli 2024 23:53]

[.oisyn]

Het verschil tussen afluisteren en manipuleren is erg groot overigens, maar ik neem aan dat je bedoelde dat de vervolgstappen zonder authenticatie makkelijk zijn.

Ik heb het over het verschil tussen kunnen afluisteren en kunnen manipuleren. Dat is erg klein voor zover het internetverbindingen aangaat. Daadwerkelijk naar bits luisteren zonder er zelf tussen te zitten is vrij ongebruikelijk.

Je edit is irrelevant, je vertrouwt nog steeds een specifieke partij. Jij wil encryptie zonder vertrouwen - daar kan iedereen gewoon tussen gaan zitten en dus is de encryptie zinloos. (En ik zeg dus niet dat geen encryptie béter is, leg me die woorden niet in de mond. Ik stel dat je er weinig aan hebt. Jij doet alsof het een wereld van verschil maakt; dat doet het niet.)

[Reactie gewijzigd door .oisyn op 22 juli 2024 23:53]

[WhatsappHack]

Om mee te luisteren hoef je er niet tussen te zitten, je hoeft er hoogstens (op een afstandje) naast te staan. Als ik al het verkeer afluister op de publieke wifi van de bibliotheek, betekent dat niet dat ik dan overal tussen ben gaan zitten; tussen elke gebruiker en hun bestemming en vice-versa. Tenzij je “tussen” bedoelde in de zin van “je onder de massa mengen/ik zit tussen allerlei mensen in (eg: in een volle kroeg zitten te luisteren naar gesprekken van anderen)”, maar over het algemeen bedoelen we met “er tussen zitten” dat jij je pakketje (onbewust) aan mij stuurt en ik het (eventueel aangepast) doorstuur naar de bedoelde ontvanger - een actieve MitM-aanval dus ipv passieve eavesdropping. Ik heb het idee dat je dit haast gelijkstelt aan elkaar (“Daadwerkelijk naar bits luisteren zonder er zelf tussen te zitten is vrij ongebruikelijk.” - ben ik het niet mee eens, dat gebeurt juist best vaak!), misschien omdat je met een MitM (normaliter) óók kan eavesdroppen.

Een “man” in het midden is (meestal)(ook) een eavesdropper, maar een eavesdropper is geen man in het midden - en dat is het belangrijke detail dat het voor mij een compleet andere situatie maakt.

Die pakketjes vliegen in dit voorbeeld gewoon door de lucht. Ik vang die slechts op, maar hoef verder geen actie te ondernemen noch wil mijn mogelijkheid om te luisteren garanderen dat ik ook kan manipuleren (laat staan bij iedereen op dat netwerk.). (En nog relevanter: dat ik weet hoe ik dat moet doen is ook een vereiste, wat toch wel een stapje verder gaat dan puur een packet capture starten...)

Als er echter een basisversleuteling op al die pakketjes die ik uit de lucht pluk zou zitten: dan kan ik eavesdroppen wat ik wil, maar ik versta er echt geen hol van. (same met https verbindingen via self-signed certs overigens.)

Dit hoeft van mij ook niet te eindigen bij http trouwens. Graag bij alles. IMAP/SMTP, FTP, et cetera: nog veel te vaak gebruikt men compleet onversleutelde verbindingen (met inloggegevens notabene!), zelfs als de server versleuteling ondersteund. Als er iig enige versleuteling op zou zitten zou al zoveel fijner zijn. (Ik zelf forceer het overigens. Onveilige verbindingen naar services worden doodleuk geweigerd. Je stelt je mail-/ftp-client maar goed in...)

Je edit is irrelevant, je vertrouwt nog steeds een specifieke partij. Jij wil encryptie zonder vertrouwen - daar kan iedereen gewoon tussen gaan zitten en dus is de encryptie zinloos. (En ik zeg dus niet dat geen encryptie béter is, leg me die woorden niet in de mond. Ik stel dat je er weinig aan hebt. Jij doet alsof het een wereld van verschil maakt; dat doet het niet.)

Ik had het niet over de Apple-edit, maar over de basale encryptie op “http” edit, die passage stond er eerst niet. Maar ik snap de verwarring omdat ik daar specifiek “edit” bij heb gezet, my bad en sorry voor de onduidelijkheid.

Having said that: dan zullen we het oneens moeten blijven, helaas! Ik vind dat het wel degelijk een flink verschil maakt en had dan ook heel graag gezien dat er een basis encryptie was en plain-text http tot een schim uit het verleden gereduceerd zou zijn.
Er is een flink veiligheidsvoordeel te behalen uit het afschaffen van plain-text communicatie. Dat het niet de heilige graal is en (mogelijk, ligt aan implementatie eigenlijk... Kan wel wat dingen verzinnen om het iets veiliger te maken en enige controle toe te kunnen passen.) nog gemanipuleerd kan worden: yup. Maar liever dat dan stug door blijven kachelen op http zoals het nu werkt, het maakt imho wel degelijk een flink verschil. Het doet niets voor authenticatie/vertrouwen, maar het zorgt er wel voor dat simpel afluisteren een stuk moeilijker wordt; en dat is het wat mij betreft absoluut waard en wel degelijk een significant verschil; ongeacht dat een MitM, wellicht, mogelijk blijft.

Ik snap jouw invalshoek wel trouwens, we zien de noodzaak ervoor en de toegevoegde waarde gewoon compleet anders zo te zien. No worries, even goede vrienden.

[Reactie gewijzigd door WhatsappHack op 22 juli 2024 23:53]

[DigitalExorcist]

Well that escalated quickly... 😜 gaan we dit jaar voor een record langste reacties? Haha...

Ik kwam onlangs in een bedrijfsmatige omgeving beveiligingscamera’s tegen die alleen via HTTP praatten (incl inlogscherm!) en het Diginotar en Symantec debacle geven aan dat ook DV/EV certificaten opknipt altijd betrouwbaar hoeven te zijn...

Het is één van de manieren om mitm-aanvallen moeilijk te maken, maar naast een ‘echt’ certificaat heb je met zoveel andere factoren te maken... een site kan HTTPS gebruiken en oude TLS- en SSL protocollen uit hebben staan maar als je tegelijkertijd SQL-poorten forward naar binnen toe maakt dat allemaal geen fluit uit. En als een websitebeheerder je data als ruilmiddel gebruikt kun je certificaten hebben maar dat zegt dan ook niks (zie oa. de lekken van Facebook!).

Maar mijn punt was inderdaad dat encryptie los staat van het soort certificaat en self-signed beter is dan helemaal niks.

[.oisyn]

Als ik al het verkeer afluister op de publieke wifi van de bibliotheek, betekent dat niet dat ik dan overal tussen ben gaan zitten

Dan zit je er gewoon tussen en is manipulatie extreem simpel . Wanneer besef je dat nou? Juist wifi is in feite gewoon een groep waarin iedereen naar elkaar schreeuwt, en ook iets schreeuwen waarin je anderen om de tuin leidt is een koud kunstje. Dat je dat niet hóeft te doen staat los van het feit dat het gewoon mogelijk is.

Evenzo met lokale netwerken. Switches zijn wel om te tuin te leiden om pakketjes jouw kant op te sturen ipv naar de juiste persoon.

[Reactie gewijzigd door .oisyn op 22 juli 2024 23:53]

[WhatsappHack]

Nee, ik zit er dan niet tussen - ik sta er naast. Ik snap werkelijk niet dat je dat verschil niet begrijpt. (Ik bedoel, er is een reden dat in de gangbare voorbeelden Eve en Mallory compleet andere personages zijn...) Dat ik de aanval misschien zou kunnen uitbreiden en er misschien wél daadwerkelijk tussen kan gaan zitten doet daar helemaal niets aan af.

Als jij van mening bent dat eavesdropping en een Man in the Middle aanval exact hetzelfde is, dan zullen we het nimmer eens gaan worden en lijkt een verdere discussie me zinloos. Het maakt verder overigens ook geen verschil voor mijn standpunt dat we af moeten van plain-text verbindingen.

Nogmaals, een man in the middle is een eavesdropper maar een eavesdropper is geen man in the middle. Er zit een enorm verschil tussen actieve en passieve aanvallen, als we het daar al oneens over zijn zullen we het hoe dan ook niet eens gaan worden.

[Reactie gewijzigd door WhatsappHack op 22 juli 2024 23:53]

[.oisyn]

Nee, ik zit er dan niet tussen - ik sta er naast

Tussen als in tussen de mensen in de menigte. Het is dan een koud kunstje om de boel zo te manipuleren dat je er alsnog wel tussenín komt. Dát is mijn punt, dat jij niet wil accepteren.

Nogmaals, een man in the middle is een eavesdropper maar een eavesdropper is geen man in the middle

Ik zeg ook niet dat het hetzelfde is, ik zeg dat in de meeste gevallen het ene impliceert dat het andere ook mogelijk is. Volgens jou is dat niet zo, prima, jouw mening, maar security experts zijn het over het algemeen dan niet met je eens.

[Reactie gewijzigd door .oisyn op 22 juli 2024 23:53]

[Verwijderd]

Even uit mijn hoofd; zonder certificaat krijg jij je Apache of NGINX webserver niet in de lucht. Je zult op zijn minst een self-signed certificaat nodig hebben om die up en running te krijgen.

Het gevolg bij een self-signed certificaat is dat bezoekers een irritante melding krijgen die ze moeten weg klikken. Gevolg, de bezoeker gaat er vanuit dat de site onveilig is. Een omweg kan ook, dan hoef je zelf geen ssl/tls te activeren op je website maar laat je het via de CDN van Cloudflare lopen.

Maar zonder certificaten bereikbaar zijn via https is een no-go.

[Pilovali]

Helaas wordt dit tegenwoordig ook gebruikt voor phishing websites. Mensen denken tegenwoordig "als er een groen slotje staat, is de website veilig".

[HollowGamer]

Ik denk dat het merendeel van de mensen nog nooit van zo'n slotje hebben gehoord. Tevens heeft Google deze groene kleur inmiddels uit Chrome gesloopt en wordt nu niet meer aangetoond dat het daarom veilig is. Het is nu eerder andersom en worden nu deze sites juist harder aangepakt (lagere ranking Google, onveilig kenmerk in adresbalk, waarschuwingen/blokkades, etc.).

Dankzij LE zijn we nu wel zo ver dat het eindelijk mogelijk is het via deze weg te doen, ik denk dat het nog langer had geduurd als dit project er niet was gekomen.

Overigens 'haat' ik wel de manier hoe LE werkt met wildcard domeinen, namelijk met een DNS-aanpassing. Gelukkig zijn er clients als acme.sh, die ik over het algemeen fijner vind als je met meerdere (sub)domeinen zit dan certbot zelf.

[Reactie gewijzigd door HollowGamer op 22 juli 2024 23:53]

[Verwijderd]

"Het is nu eerder andersom en worden nu deze sites juist harder aangepakt (lagere ranking Google, onveilig kenmerk in adresbalk, waarschuwingen/blokkades, etc.)."

Dat klopt, maar ik vind dat we niet genoeg stilstaan bij de gevolgen hiervan.

Een enorm gedeelte van het www kun je het "old web" noemen. Dit zijn paginas die in feite niet onderhouden worden. De aanname dat achter iedere website een ontwikkelteam zit klopt natuurlijk niet. Deze sites hebben wel degelijk (informatieve) waarde en zie je beetje bij beetje afbreken door dit soort veranderingen. Ze stoppen met werken, zijn niet meer vindbaar, etc. en gaan op die manier verloren.

We kunnen natuurlijk blijven roepen dat dat hun eigen schuld is maar dat veranderd niets aan de situatie: het merendeel van de web paginas wordt niet onderhouden, dus we zouden er zuiniger mee om moeten gaan vind ik.

[HollowGamer]

Tja, oldtimers worden ook niet meer gemaakt, zijn ook moeilijk te vinden en hebben nog altijd een waarde. Moeten we die ook nog steeds produceren? En ook maar niet kijken naar betere filters voor deze auto's, ook al is dat slechter voor het mileu?

Verder vraag ik mij af welke informatie we daarvan nu echt missen. Het Archive project heeft er genoeg op staan, maar wanneer heb je die nu echt nodig? Sterker nog, misschien het beter dat sommige informatie voorgoed verdwijnt. Waarom moet bv. dit project een site opslaan, die ik gemaakt hebt toen ik 10 jaar oud was?

Ben het overigens wel met je eens, voor veel sites is het implementeren van SSL/TLS nog steeds een probleem en heb ik met genoeg legacy code gewerkt om te weten wat er allemaal mis kan gaan. De beste oplossing voor dat soort sites is dan ook opnieuw beginnen en niet blijven hangen met technieken uit het verleden (o.a. Flash, ActiveX).

[Reactie gewijzigd door HollowGamer op 22 juli 2024 23:53]

[CAPSLOCK2000]

Verder vraag ik mij af welke informatie we daarvan nu echt missen. Het Archive project heeft er genoeg op staan, maar wanneer heb je die nu echt nodig? Sterker nog, misschien het beter dat sommige informatie voorgoed verdwijnt. Waarom moet bv. dit project een site opslaan, die ik gemaakt hebt toen ik 10 jaar oud was?

Als backup- en archief-beheerder is mijn reactie dat je beter te veel kan bewaren dan te weinig, want je weet vooraf vaak niet wat je later nog nodig hebt. Als je mensen vraagt wat belangrijk is dan is de kans groot dat ze iets vergeten of over het hoofd zien. Zo zijn mensen. Daarom probeer ik zo veel mogelijk en zo lang mogelijk te bewaren (natuurlijk zijn er grenzen).

Een paar honderd jaar geleden werd er bijvoorbeeld heel anders over kunst gedacht. Schilders zetten niet eens hun naam onder hun schilderij. Hun werk was in de eerste plaats functioneel, niet "mooi". Gelukkig is er nog genoeg bewaard gebleven. Het gevaar met digitale middelen is dat ze razendsnel verdwijnen, 1 commando en alles is weg. 100 schilderijen afkrabben en recyclen is een stuk meer werk.

[Reactie gewijzigd door CAPSLOCK2000 op 22 juli 2024 23:53]

[Sfynx]

Het is gewoon een afweging tussen de kosten van het bewaren en de baten. Sommigen verklaren me voor gek als ik zeg dat ik nog e-mails van voor 2001 heb bewaard en eigenlijk nooit serverlogs weggooi, maar schijfruimte is zo goedkoop (en het merendeel zo goed comprimeerbaar) dat het nauwelijks invloed heeft op de kosten. Was ik maar wat blij mee toen ik eens iets wilde terugzoeken in mailserver logs van jaren terug
Fysieke spullen zijn veel duurder om op te slaan, dan ga je redelijkerwijs eerder over op weggooien/recyclen.

[freaky]

Waarom moet bv. dit project een site opslaan, die ik gemaakt hebt toen ik 10 jaar oud was?

Hoe moeten wij dat weten? Dat jij 10 jaar oud was zegt mij iig helemaal niks over de inhoud van de site. Ms was je wel een hoogbegaafd wiskundige op die leeftijd al en heb je hele interessante algoritmes op je site staan ofzo.

[Verwijderd]

"Verder vraag ik mij af welke informatie we daarvan nu echt missen. Het Archive project heeft er genoeg op staan, maar wanneer heb je die nu echt nodig?"

Ik heel erg vaak. Jij wellicht niet. Het lijkt me een heiloze discussie om de waarde te bepalen aangezien die subjectief en persoonlijk is. Verder weet je ook niet hoeveel waarde iets heeft als je niet eens wat dat het bestaat.

De auto anologie vind ik vrij krom, het is niet zo dat een oude statische web pagina kwaadaardig is.

[jcvw]

Over auto's gesproken... Ik heb eens mijn auto particulier verkocht waarvan ik de folder niet had. En de website had natuurlijk dat model niet meer... Maar archive.org wel!

Kon ik de koper dus mooi de oorspronkelijke website geven waar mijn specifieke model op beschreven stond (met name de technische gegevens)

[Wim-Bart]

En er zijn nog steeds hosters zoals Argeweb die Lets Encrypt niet eens aanbieden. Komen ze met een vergelijk "hoe goed" ze wel niet zijn maar je moet wel ff een flink bedrag aftikken voor SSL.... Gelukkig zit Lets Encrypt bij Yourhosting bijvoorbeeld standaard in het meest voordelige pakket.

Helaas dus zijn de "oldtimers" niet alleen afhankelijk van ontwikkelaars maar ook van de hosting partijen.

[Reactie gewijzigd door Wim-Bart op 22 juli 2024 23:53]

[Blokker_1999]

De sites verdwijnen niet, ze blijven beschikbaar. Alleen zullen ze minder snel naar boven komen. Maar is dat niet met alle verouderde dingen zo? Als er echt een waarde is moet iemand een initiatief ondernemen om te zorgen dat dit niet gebeurd. Neem contact op met de eigenaar om hem/haar aan te sporen verbeteringen aan te brengen, of om de site desnoods over te nemen. Of maak een backup die je wel correct op het internet kan houden.

En moeten we vooruitgang tegenhouden omdat er mogelijk dingen verloren gaan? We moeten ons ook wel de vraag durven stellen: wat heeft voorrang? Een veiliger internet of het behoud van sites die amper bezocht worden zonder bijkomende hindernissen?

[Verwijderd]

Als de interesse groot genoeg is, komt er vanzelf een oplossing om die informatie weer wel beschikbaar te krijgen. Het staat een ieder vrij om een zoekmachine en een bare bone browser te ontwikkelen.

[Verwijderd]

Het staat een ieder ook vrij om president van amerika te worden of topvoetballer.
Onzin statement.

[latka]

Ik denk dat je je vergist. Mijn ouders zijn redelijke digibeten maar belden direct met de bank nadat chrome het slotje niet meer groen maakte om te melden dat de site gehacked was.

[Blokker_1999]

Ik zou van een bank verwachten dat ze een EV certificaat gebruiken, en die blijven wel zichtbaar in de browser.

[latka]

Geen idee. Ik gebruik geen Rabobank (dat was de bank in kwestie). En het was idd. de hele balk die groen was en nu niet meer.
Toevoeging: net getest. Chrome met ING: slotje is grijs. Balk is gewoon. Firefox: Slotje is groen. Balk is gewoon. Internet Explorer: balk is helemaal groen. Edge: geen idee heb Windows 10 LTSB en Server 2016 hier dus geen Edge. Vroeger was ook Firefox en Chrome de hele balk groen. Nu niet meer (en zelfs het slotje niet meer in Chrome). Dus EV of niet EV is ook niet meer zo belangrijk: de browser met het grootste marktaandeel scheert ze over een kam.

[Reactie gewijzigd door latka op 22 juli 2024 23:53]

[Verwijderd]

Ik denk dat het merendeel van de mensen nog nooit van zo'n slotje hebben gehoord. Tevens heeft Google deze groene kleur inmiddels uit Chrome gesloopt en wordt nu niet meer aangetoond dat het daarom veilig is. Het is nu eerder andersom en worden nu deze sites juist harder aangepakt (lagere ranking Google, onveilig kenmerk in adresbalk, waarschuwingen/blokkades, etc.).

Mensen kennen over het algemeen het groene slotje of de groene adresbalk wel maar je kwam ze over het algemeen weinig tegen. Alleen bij de echte grote organisaties (bank, DigiD etc.) kwam je deze tegen. De enige wijze waarmee je de veiligheid bij deze websites nog kunt herkennen is dat de gegevens van het certificaat worden getoond in de adresbalk. Zo zie je bij de Rabobank bijvoorbeeld Coörperatieve Rabobank U.A. [NL] (of te wel, domain validation).

Overigens 'haat' ik wel de manier hoe LE werkt met wildcard domeinen, namelijk met een DNS-aanpassing.

Des te beter! Dan is er tenminste nog één controle die misbruik voorkomt. Even simpelweg via Let's Encrypt een certificaat aanvragen voor een willekeurige site wordt hiermee afgevangen.

Gelukkig zijn er clients als acme.sh, die ik over het algemeen fijner vind als je met meerdere (sub)domeinen zit dan certbot zelf.

True, zelfs ik heb (ondanks dat DirectAdmin, Let's Encrypt ondersteuning heeft) gewoon acme.sh in gebruik. Dit omdat enkele domeinnamen niet op eigen nameservers worden gedraaid. acme.sh maakt het dan mogelijk om die externe DNS-servers even via een API te configureren en de validation te doorlopen (in geval van wildcards wel heel erg prettig zo).

[WhatsappHack]

“domain validation”
Extended validation (EV) in ‘t geval de hele balk groen is. Domain validation is louter een email of DNS record controleren en ‘t wordt goedgekeurd. Om een EV-certificaat te krijgen moet je heel wat meer moeite doen gelukkig.

[klakkie.57th]

je kunt je altijd afvragen of Google het "groene slotje" niet heeft gesloopt ten voordele van hun eigen Let's encrypt ? Groen slotje zou eigenlijk alleen mogen duiden op Extended Validation en niet op gewoon "envrypted"


Trouwens Chrome, dat zou iedereen onderhand toch al echt moeten verbannen ten voordele van Firefox

[SKiLLa]

Dat komt omdat banken en overheden jarenlang erg domme 'Postbus 51' spotjes maakten die zaken te simpel weergaven ....

[erikmeuk3]

Ook sites zoals DigiD en overheid.nl geven het slechte voorbeeld.
Een simpel slotje zonder EV

[Sfynx]

Ook sites zoals DigiD en overheid.nl geven het slechte voorbeeld.
Een simpel slotje zonder EV

EV heeft ook steeds minder meerwaarde, wat was ooit heel duidelijk een bedrijfsnaam, dat wordt ook al lagzaam afgebroken, in Safari geen bedrijfsnaam meer en is nu alleen de kleur van het slotje nog anders, en in Chrome is de kleur juist altijd hetzelfde, het wordt er niet echt duidelijker op voor de gemiddelde gebruiker.
Firefox is zo te zien nog wel lekker duidelijk met een dikke groene bedrijfsnaam.

[Reactie gewijzigd door Sfynx op 22 juli 2024 23:53]

[Stoney3K]

En met EV schiet je nog altijd weinig op, want phishers kunnen ook een eigen certificaat aanmaken om EV te doen met een valse bedrijfsnaam.

Dan verplaats je het probleem alleen maar, want niemand gaat kijken of "ING Bannk N.V." wel echt klopt.

[eborn]

Behalve dat je bij de KvK zo'n naam niet geregisteerd krijgt.

[klakkie.57th]

Dat zou toch echt wel moeten ...
Als ze dit niet checken zullen ze snel op een blacklist komen te staan en is heel hun business model naar de haaien.

[Gropah]

Yup, precies dit. Er werd alleen gewezen op het groene slotje/adresbalk (wat tegenwoordig in heel veel browsers niet meer gedaan word) en er werd niet bijgezegd dat je ook het domein moest controleren. Als ze dat wel hadden gedaan was er al een hoop ellende voorkomen.

[Verwijderd]

Hoe zou jij de doorsnee, niet technisch onderlegde/niet technische geinteresseerde gebruiker aanspreken voor dit onderwerp?

Daarnaast: als iets niet simpel kan worden uitgelegd, is het onze taak (als ICT-er) om oplossingen te leveren die wel simpel zijn. Iedere ander product is zo doorontwikkeld dat iedereen er mee om kan gaan zonder al te veel kennis. Als jij het gaspedaal van je auto indrukt hoef je helemaal niks te weten wat er onder de motorkap gebeurt. Als jij je camera op volautomatisch zet, hoef je niks over diafragma/sluitertijd/ISO te weten. Pas in uitzonderingssituaties moet je meer weten. Maar gewoon internetgebruik is geen uitzonderingssituatie.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 23:53]

[hans3702]

Hoe zou jij de doorsnee, niet technisch onderlegde/niet technische geïnteresseerde gebruiker aanspreken voor dit onderwerp?

Je zou kunnen zegen dat een Certificaat te vergelijken is met dat je autogordels om doet tijdens de reis, waardoor de kans kleiner is dat je uit de auto geslingerd wordt. Je kunt echter nog steeds naar een bestemming reizen die niet veilig is. En het zegt ook niks over de kwaliteit van de gordels, pas als deze
EU en APK gekeurd zijn enz enz heb je meer zekerheid en evt. een recht op een schade vergoeding als er toch wat gebeurt vergelijkbaar met een EV cert. Een LE cert is met alleen een Domein validatie niets meer dan ze bij het type/merk auto behoren. Het zegt niks over de partij achter de domain naam.
op https://www.sslcertificaten.nl/ staan volgens mij de 3 soorten en het doel duidelijk aangegeven.
========================

Het vervelende is dat browsers steeds minder bruikbare info geven en alles in Jip en Janneke taal moet worden verteld. Ook hier kun je weer de auto er bij pakken waar is de tijd gebleven van een reserve wiel en de kennis bij de automobilist om dat zelf te wisselen bij een lekke band. Ze bellen nu hulpdienst die trouwens niet gratis is. En jammer dat er in mijn ogen verkeerde info over wat veilig is wordt uitgegeven, tikkie en en ideal als voorbeeld, wat veilig de route die je geld van koper naar verkoper neemt maar zegt niks over betrouwbaarheid van de verkoper.
Wat hier wel iets mee van doen heeft is in nieuws: Google wil url in toekomst niet langer weergeven in Chrome
========================
Met een klein beetje goede wil is het zo uit te leggen en zullen veel mensen het begrijpen, als je gaat zoeken zijn er ook zeker scenarios te bedenken waar dit voorbeeld mank gaat.

PS. Gratis cert. waren er al jaren via http://www.cacert.org/ echter geen een browser/OS lmaker wou het root cert. in browsers opnemen waardoor het vergelijkbaar was met een zelfsigned en nu met LE is het root cert wel opgenomen.

EDIT: Typos

[Reactie gewijzigd door hans3702 op 22 juli 2024 23:53]

[DigitalExorcist]

En dan nog, het zegt alleen dat MITM attacks moeilijk zijn en is in die zin één van de waarborgen van een veilige communicatie.

Maar dat je met de duvel zelf communiceert maakt niet uit. Ook Facebook gebruikt https, en toch sluizen ze je data via de achterdeur sneller weg dan dat jij via de voordeur aanlevert.

[LEDfan]

Het is misschien juist een goede zaak dat zoveel mogelijk phishing sites dit doen. Tegenwoordig als een CA een certificaat uitgeeft wordt dit geregistreerd in een Certificate Transparency log (dit is verplicht, anders wordt het cert niet als valide herkent door browsers). Wat je dan doet als bank, is deze logs inspecteren naar domeinnamen die woorden bevatten die met de bank hebben te maken. Kom je deze tegen dan stuur je dat naar Google Safe Browsing en de site is geblokkeerd (voor veel mensen).
Meer info: https://scotthelme.co.uk/...-phishing-sites-on-https/

[Zebby]

Daar hebben de banken destijds zo op gehamerd ja, "slotje in de balk is veilig", naïef zelfs voor de tijd toen. Althans, vanuit het IT oogpunt. Het heeft echter wel gezorgd dat "internet bankieren" als meer veilig wordt gezien. Nu is er de strijd met de apps, die in weze veiliger zijn omdat je minder snel een neppe app zal downloaden, maar toch is er weer die weerstand.

Het internet is ook erg lastig als je er niet mee bent opgegroeid, er is zo veel om op te letten. Ik zie wel vaak dat er alleen gezegd wordt om bijvoorbeeld "nooit bijlagen openen!!!" terwijl vrolijk alle "facturen" uit de mail blind geopend worden. Als er niet (eenvoudig) uitgelegd kan worden waarom iets niet mag of moet zal het nooit landen.

We kunnen de beste beveiligingen verzinnen, maar zolang de mens achter de knoppen zit is er wel een weg omheen.

[Verwijderd]

In 2016 geleden ben ik begonnen met het overschakelen van betaalde jaarlijkse certificaten naar het gratis certificaat. Het werkt prima voor wat het moet doen.

[Luchtbakker]

In 2016 geleden ben ik begonnen met het overschakelen van betaalde jaarlijkse certificaten naar het gratis certificaat. Het werkt prima voor wat het moet doen.

Een gratis certificaat is voor websites die geen persoonsgegevens / betalingen verwerkt ook prima. Maar betaalde certificaten hebben bepaalde financiële garanties. 99% van de sites hebben die niet nodig, dus is lets encrypt ruim voldoende.

[LEDfan]

In de security community wordt de waarde van die "garantie" als (heel) laag gezien.
Bv. https://scotthelme.co.uk/...s-rocks-keep-tigers-away/
Zo is de voorwaarde van een bepaald certificaat dat de gebruiker altijd revocation moet nakijken, maar standaard doen browsers dat niet of met soft-fail, en dus kan je eigenlijk niet bewijzen dat je gebruikers dat doen....

[latka]

Financiele garanties? Volgens mij voornamelijk financiele gevolgen (als in: EV certificaten zijn stervensduur voor de garanties die geboden worden). Kun je me eens wijzen naar een SSL certificaat met garanties?

[Luchtbakker]

Financiele garanties? Volgens mij voornamelijk financiele gevolgen (als in: EV certificaten zijn stervensduur voor de garanties die geboden worden). Kun je me eens wijzen naar een SSL certificaat met garanties?

Yes:

https://www.sslcertificat...ntie_bij_SSL_certificaten

Mocht het toch zo zijn dat bovenstaand voorbeeld zich voor doet, dan wordt het genoemde bedrag vergoed aan de partij die schade heeft geleden.

Hoe duurder het certificaat, hoe hoger een financiële vergoeding kan zijn.

[latka]

Max. 2 miljoen over alle incidenten waarbij directe financiele schade is. En dat certificaat kost 4k. Alleen uit te keren als de CA per ongeluk het certificaat nog een keer uitgeeft omdat ze niet goed controleren. Dus dat voegt niet zoveel toe. Als je CA via social engineering zover te krijgen is dat ze het cert nogmaals uitgeven moet wellicht de CA gesloten worden. Lijkt me een betere verzekeringspremie dat ze hun werk goed doen dan het met een lullig bedrag afdekken.

[bbob]

Dit staat er bij jou link:

De garantie of verzekerde waarde is het bedrag wat maximaal aan een eindgebruiker wordt uitgekeerd wanneer het SSL certificaat wordt uitgegeven aan een onbevoegde partij, waarbij de eindgebruiker geld is kwijt geraakt. De eigenaar van het certificaat is dus verzekerd in geval van claims van bijvoorbeeld websitebezoekers. De exacte voorwaarden voor het uitkeren van dit bedrag verschillen per leverancier. Voor zover bekend is dit garantiebedrag nog nooit uitgekeerd.

vooral het laatste het garantiebedrag is nog nooit uitgekeerd.

Waar het eerder om gaat is dat mensen geleerd moet worden wat ssl is. Het zegt alleen maar dat de verbinding met de andere website beveiligd is. Het zegt totaal niets over de betrouwbaarheid van de andere website.

Heel simpel lees eens over webshop die failliet gegaan zijn. Mensen hebben tot op de laatste dag nog gewoon besteld, betaal, krijgen niet geleverd en kunnen achteraan in de rij aansluiten. Al heeft die website een duur certificaat, je hebt er als eindgebruiker niet aan, geen garantie voor de financiële gevolgen.

[Euronitwit]

Bij Plesk kan je het ook inschakelen.
Helaas laten niet alle hosters het toe, want dat kost ze inkomsten.

[Luchtbakker]

Bij Plesk kan je het ook inschakelen.
Helaas laten niet alle hosters het toe, want dat kost ze inkomsten.

Dan moet je daar heel snel weg gaan. Een beetje hoster laat je de voor- en nadelen zien van een gratis certificaat.

[Reactie gewijzigd door Luchtbakker op 22 juli 2024 23:53]

[Euronitwit]

Welke nadelen?
Wat heeft bijv. een Rapid SSL voor €35/jaar wat Let's Encrypt niet heeft?

[YoMarK]

Certificaten die langer geldig zijn.
Bij combodo 14 euro voor 2 jaar.
Sommige zaken zijn nu eenmaal lastig te automatiseren(we hebben het niet alleen maar over websites die ssl certificaten gebruiken).

Laat ik verder allereerst zeggen dat ik zelf LE veel gebruik, en het eigenlijk ideaal vind. Je kan er lekker lui mee om gaan, certificaten worden automatisch vernieuwd, je hebt er geen omkijken meer naar. Prima toch!?
Ja, maar toch ook nee. Dat groene slotje staat er b.v. over 6 jaar nog als ik al 5 jaar niet naar die site heb omgekeken. De geldigheidduur van een certificaat is er om meerdere redenen, en een minder belangrijke maar toch ook wel een belangrijke is mijns inziens om gebruikers te waarschuwen voor onbeheerde sites.

[Xatom]

De achterliggende code van een site die actief beheerd wordt kan net zo onveilig of zelfs onveiliger zijn dan een site die niet actief beheerd wordt.

Ik snap dat een groen slotje het gevoel heeft dat een site veilig is, maar het is natuurlijk alleen bedoeld om te verifiëren of je met de juiste partij verbonden bent en om deze verbinding te beveiligen. Dit zegt niks over de veiligheid van de website zelf.

Een kortere geldigheidsduur heeft als voordeel dat eventuele fouten in uitgegeven certificaten relatief snel kunnen worden verholpen, omdat het (in het geval van Let's Encrypt) na 3 maanden alle certificaten vervangen hebt.

[YoMarK]

Klopt natuurlijk, maar sites waar niet naar omgekeken wordt incl de backend(security an sich) krijgen nu wel netjes een nieuw certificaat. Doe je het (semi)handmatig, dan zegt een recent geldig certificaat toch op z'n minst een beetje.

[WhatsappHack]

Wat zegt het dan? Het kan nog steeds zo lek als een mandje zijn, terwijl die site waar jaren niet naar omgekeken is nog prima veilig kan zijn als ‘t vanaf begin af aan goed in elkaar was gezet. Een certificaat of het ontbreken ervan zegt echt helemaal niets over de veiligheid van de back-end, noch of deze (adequaat) onderhouden wordt of eigenlijk zou moeten worden.

[DeCo]

Dus geeft dit alles een vorm van schijnveiligheid. Een leek ziet immers een groen slotje... het is me allemaal iets te makkelijk. Dit moet veranderen, vind ik.

[WhatsappHack]

Dat is lastig ben ik bang. Dat komt neer op mensen onderwijzen en dat is nu al een probleem, zeker omdat men over ‘t algemeen zeer onverschillig is. Niets is veilig, het gaat er puur om of de verbinding versleuteld is. (En zelfs dat garandeert niets natuurlijk. Zeker om een DV-certificaat aan te vragen zijn er meerdere wegen naar Rome zullen we maar zeggen.) Overigens zijn mensen opeens een stuk minder onverschillig als ze zo’n “I know your password, here it is <password gejat uit dump, die ze uiteraard op veel plekken gebruikt hebben>. Dok ff €300 of ik zet de beelden van hoe jij je zit af te beren online!!1!” mailtje krijgen, hehe

Ik zou zo 1,2,3 niet weten hoe je dat werkelijk kan verbeteren. Browsermakers lijken wel een andere route te kiezen. Die gaan helemaal niets meer tonen tenzij de verbinding onveilig is. Maar of je daar het probleem mee oplost...? Ik weet het niet man.

[Verwijderd]

Let's encrypt heeft tools voor diverse platformen die het automatisch her registreren, is alleen een extra regel aan de crontab van de server toevoegen

[YoMarK]

Dat weet ik, zoals ik zeg, gebruik het zelf ook.

[klakkie.57th]

Websites die niet bereikbaar zijn vanaf het internet om 1 te noemen

[.oisyn]

Kan met LE ook, dmv een DNS challenge. Heb op mijn NAS ook een LE certificaat terwijl die niet van buiten te bereiken is.

[klakkie.57th]

Dat het kan ok , maar interne servers ga je toch niet publiceren op publieke DNS servers, daarenboven wil dat zeggen dat je interne domeinnaam ook publiek is ... lijk me niet gewenst

[Reactie gewijzigd door klakkie.57th op 22 juli 2024 23:53]

[.oisyn]

maar interne servers ga je toch niet publiceren op publieke DNS servers

Dat hoeft ook niet. Voor een DNS challenge heb je tijdelijk een TXT entry op de nameserver nodig voor de betreffende host (in de vorm van _acme-challenge.<host>, zodat LE kan controleren dat jij de administrator van het domeinnaam bent). De hostnaam zelf hoeft verder niet publiekelijk te bestaan, die kun je gewoon privé houden.

Een andere optie is een wildcard cert, dat gaat ook via een DNS challenge maar dat hoef je maar 1 keer te doen en dan kun je de cert uitrollen over alle devices binnen het domein die er gebruik van maken.

[Reactie gewijzigd door .oisyn op 22 juli 2024 23:53]

[klakkie.57th]

Ok bedankt ik ga het nog een keertje bekijken. Het is al wel een hele tijd geleden en toen kon je toch echt geen interne DNS namen gebruiken voor let’s Encrypt

[ari]

Let's Encrypt biedt simpel gezegd alleen het 'standaard' slotje aan. Je weet dat je verbinding beveiligd is, maar je weet niet met zekerheid met wiens server je verbinding hebt. Dit heeft bijvoorbeeld Tweakers en is voor veel sites voldoende.

De commerciëlen bieden ook een EV SSL-certificaat aan, waarbij EV staat voor Extended Validation. Dan ziet de gebruiker niet alleen een slotje, maar ook de naam van de eigenaar/huurder van de betreffende server. Dit heeft bijvoorbeeld de NOS en dat is handig omdat je zo zeker weet dat de informatie afkomstig is van wie je denkt dat die afkomstig is. Kost wel wat meer dan een standaard SSL-certificaat, dat lijkt te beginnen bij zo'n 95 euro per jaar exclusief BTW.

De goedkopere 'standaard' certificaten hebben voor zover ik kan zien geen meerwaarde boven Let's Encrypt, behalve dat je al je certificaten bij hetzelfde bedrijf hebt lopen als je toevallig ook een EV SLL-certificaat hebt.

[WhatsappHack]

Al tonen steeds minder browsers die complete balk met bedrijfsinformatie, dus vanuit dat oogpunt boeit dat ook minder en minder.

Overigens vind ik EV-certificaten ook geen sluitende authenticatie aanbieden. Het maakt het louter een stuk aannemelijker dat het goed zit.

[ari]

Chrome op de laptop toont nog netjes 'Nederlande Omroep Stichting' in de balk bij de NOS, dus wat dat betreft zit het goed. Op mijn telefoon wordt alleen het slotje getoond. Maar zo lang laptops veel gebruikt blijven heeft EV meerwaarde.

En inderdaad, niets is sluitend. Zie DigiNotar.

[WhatsappHack]

Ik geloof dat dat per Chrome 70 er ook uitgesloopt wordt. Google wil blijkbaar helemaal afstappen van indicatoren of een verbinding versleuteld is of niet, en overstappen op een systeem dat uitsluitend waarschuwt voor onveilige verbindingen.

Ik ben er niet over uit of ik dat een goed idee vindt trouwens. EV heeft slechts enig nut, maar voor bijvoorbeeld banken vind ik het toch wel iets toevoegen ondanks dat het niet waterdicht is.

[WhiteDog]

Je onderschat wel even hoeveel extra werk dit meebrengt voor de hoster. Een paar voorbeelden:
- mensen die denken dat hun site niet gehackt kan worden als ze SSL hebben.
- eens het certificaat geïnstalleerd, niet weten en/ of snappen waarom ze niet op de https site uitkomen
- http <> https redirect loops
- sites die "niet meer werken" omdat ze ineens naar https gaan en de helft van hun site naar http resources wijst (mixed content).

Die gratis certificaten worden je volgens jaar gewoon doorgerekend in een prijsverhoging

[bbob]

Jou argumentatie gaat op voor ssl in het algemeen.
Ook met een betaald ssl certificaat heb je de zaken die je omschrijft.
Daar kan de hoster dan misschien iets op verdienen maar zo veel is dat niet.

Sowieso is het verstandig om ssl te gebruiken. Daarnaast heb je een webshop is het vanwege privacy al bijna verplicht, idem met een formulier op je website.
Als hoster kom je er dus gewoon niet omheen dat te ondersteunen.

[WhiteDog]

Mee eens, maar aan een betaald certificaat kon je dan toch nog 10€ verdienen terwijl je nu 10x meer vragen hebt over iets dat je er gratis bijgeeft. Als hoster wil je de klant dan graag nog helpen en correct informeren, maar daar kruipt tijd in waar ze doorgaans niet voor betaald hebben.

Vooral het feit dat de "verbinding" alleen maar beveiligd is een hun site er eigenlijk niet veiliger op wordt snapt men meestal niet zo goed. Vragen over SSL stonden hier op #2 in 2018.

[WhatsappHack]

Ik bied al jaren gratis en volautomatisch SSL aan en eigenlijk snapt iedereen het wel. Page met goede info aanmaken (plus wat juridische disclaimers) en het is helder. Support vragen gaan zelden over https zelf, maar als ze er zijn gaan ze voornamelijk over “ik heb alles gedaan zoals in de instructies, maar krijg nog steeds “mixed-content” foutmeldingen?”. Negen van de tien keer lossen ze dat zelf op nadat je ze wijst op whynopadlock.com (statische advertenties zijn vaak de boosdoener) of omdat ze bijvoorbeeld een toggle vergeten zijn om externe afbeeldingen te proxy’en Kleine moeite (gemiddeld nog geen minuut) om ze daar mee te helpen, immers dragen we graag bij aan een veilig internet.

En de site wordt er in principe wel degelijk veiliger op, zeggen dat dat eigenlijk niet zo is vind ik incorrect. Immers bescherm je zowel jezelf als je bezoekers tegen eavesdropping. Goed, op een standaard HTML site is dat misschien niet direct heel boeiend (afhankelijk van content), maar alles met een login/post-functie is het toch wel erg prettig om te hebben en bevordert dat wel degelijk de veiligheid enorm. Het beschermt niet tegen beveiligingslekken in de software nee, dat is idd een ander verhaal. Maar dat kan je toch allemaal prima afvangen in een FAQ...? Als ze die niet lezen is dat niet jouw probleem.

Ik vind het wel meevallen iig. Het is volledig geautomatiseerd, een pagina met heldere uitleg; zelfs een bejaard stel begreep het prima. Dus zoveel moeite is het nou ook weer niet imho. 1x goed uitleggen en een FAQ schrijven en je hebt de lading wel gedekt eigenlijk. De basis die ze moeten kennen is dan ook geen rocket science.

[Timo002]

Dit is in Plesk verschrikkelijk eenvoudig. Als je via Plesk een LE certificaat kunt installeren, lukt dat andere ook wel.

[ThaJens]

OVH is hier een prachtig voorbeeld van. Toen ik een jaar geleden op de website van Lets Encrypt keek, stond dat OVH een supporter van het project was. Echter kon ik geen Lets Encrypt certificaat (of een ander custom certificaat) installeren op mijn OVH hosting maar moest ik 50 euro per jaar betalen voor een door hen geïnstalleerd certificaat.

[Verwijderd]

Dan was je net te vroeg, sinds (uit mijn hoofd) de 3e kwartaal van 2017 (even uit mijn hoofd) is Let's Encrypt bij OVH voor alle hostingaccounts verkrijgbaar.

Dat OVH op de website van Let's Encrypt getoond wordt is mede omdat ze partner/sponsor zijn. Het implementeren ervan duurde net even wat langer. Maar qua betaalde certificaten is OVH altijd één van de duurste geweest.

[WhatsappHack]

Klopt. Volgens mij spande GoDaddy de kroon. Die deden me ooit een “aanbieding” om een certificaat te verlengen voor “slechts” €120... Toen was LE er nog niet, maar RapidSSL e.d. wel. €7 of €120 voor een cert, dat is makkelijk kiezen.

[lecrab]

Het is dan ook, buiten praktisch, kosteloos. Digitalocean biedt het voorgeinstalleerd aan op hun one-click droplets, en ze zijn vast niet de enige.

[WhatsappHack]

cPanel heeft het ook als optie toegevoegd. Standaard COMODO, maar je kan ook LE activeren en als standaard instellen. Dan gaat ‘t rap

[Xthemes.us]

Het is jammer dat het opzetten nog steeds niet zo makkelijk is als het kan zijn op vele 'shared' hosting sites. Hostinger en namecheap b.v. zouden dit makkelijk in hun cpanel kunnen stoppen maar nee beide doen ze dit niet zodat ze hun eigen SSL certificate kunnen verkopen. Namecheap voor jaarlijkse kosten en Hostinger voor een éénmalige lifetime setup fee.

Handmatig doen blijft het helaas nog een flink aantal stappen. Ik ben letsencrypt echter wel dankbaar, de enige partij die het wel makkelijker/gratis maakt.

[Ventieldopje]

Tsja, je betaald dan ook amper wat ga ik van uit. Ze moeten ergens geld mee verdienen en op SSL certificaten zit een aardige marge.

[RVE_NL]

Ligt maar net aan de partij waarmee je zakendoet, stukje service. Er zijn ook diverse partijen (zoals: Vimexx) die dit wel netjes in je admin panel implementeren.

[Verwijderd]

Betekent dit nu niet dat dit een dikke single point of failure is?

[Blokker_1999]

Waarom is dit een single point of failure? De infrastructuur erachter is redundant uitgevoerd. Alleen wanneer de dienst ooit de stekker eruit zou trekken heb je een probleem en zal iedereen die er gebruik van maakt terug moeten naar andere CAs waarvan sommige ook gaan werken met het ACME protocol en gratis domain based certificaten.

[Ventieldopje]

Dat kennen we ja, er was een tijd geleden nog storing waardoor je geen enkele website met LE certificaat kon bezoeken. En door de korte geldigheid van een certificaat werden een hoop certificaten ongeldig en konden op dat moment niet verlengd worden.

Redundant of niet, als er een (menselijke) fout optreed is de schade enorm. Iets waar je met een normale CA minder last van zal hebben door de langere geldigheid.

[Blokker_1999]

Huidige certificaten hebben een levensduur van 90 dagen en kunnen zonder forcering na 45 dagen hernieuwd worden. Als er iemand last van heeft gehad dan heeft hij/zijn een slechte configuratie. Gewoon wekelijks controleren of er een vernieuwing mogelijk is en je komt nooit in de problemen.

Wat niet mogelijk was op dat moment en waar potentieel problemen ontstonden was bij mensen die nieuwe aanvragen deden.

En ik zou zeggen dat je bij een traditionele CA er net meer last van gaat hebben. Daar wacht men net vaak tot op het laatste moment om te vernieuwen want dat kost daar wel geld. En als dan de vernieuwing niet lukt om wat voor reden dan ook vervalt je certificaat vaak voordat je het hebt opgelost.

[Brousant]

Nee, als je er tenminste van uitgaat dat de kans dat de certificaten van Let's Encrypt gehackt worden of er op een andere manier iets mee aan de hand is, niet groter is dan bij andere aanbieders.
Als je dan "ter risicospreiding" zou kiezen voor een certificaat van een andere club, dan heeft dat geen zin, want de kans dat je website lek raakt wordt daardoor niet kleiner.

[Verwijderd]

Ik snap je denk ik, voor jou zelf als gebruiker maakt het niet uit. Maar als er iets mis gaat bij Let's Encrypt zijn wel veel meer partijen benadeeld, dus voor het ecosysteem als geheel is het wat vervelend. (Ik herinner me een Verisign dingetje in 2010..)

[lagefrequentie]

https://nl.wikipedia.org/wiki/Transport_Layer_Security

goed initiatief!
Lets make the www a better place.


https://nl.wikipedia.org/...ient_server_handshake.jpg

TLS Record Protocol
Record Protocol is verantwoordelijk voor de fragmentatie en groeperen van gegevens die uit de bovenste lagen verzonden worden. De gegevens worden eerst gefragmenteerd en gecomprimeerd. Daarna zal een message authentication code (MAC) toegevoegd worden. Ten slotte wordt er nog een TLS record header geplaatst voor het ontvangen en herkennen van de gegevens.

TLS Handshake Protocol
Handshake Protocol maakt het mogelijk om vertrouwelijke informatie tussen client/server-applicaties te versturen zodanig dat als een derde partij de informatie mocht onderscheppen deze niet leesbaar zal zijn.

TLS Change Cipher Protocol
Change Cipher Protocol is een zeer eenvoudig protocol. Het wordt gebruikt om onderbrekingen te verhinderen bij het opzetten van de TLS-sessie.

TLS Alert Protocol
Alert Protocol verstuurt alarm bij verbindingen tussen client/server-applicaties. Er zijn twee niveaus: waarschuwing en fataal. Wanneer een fataal alarm wordt gesignaleerd, wordt de verbinding verbroken.

How it works:
https://letsencrypt.org/how-it-works/

[Reactie gewijzigd door lagefrequentie op 22 juli 2024 23:53]

[TheUninvited]

Goede vooruitgang, denk ook dat als browsers voor http gaan waarschuwen dat steeds meer webmasters geneigd zijn om overal https toe te passen, ook voor de kleinere websites van verenigingen/sportclubs e.d. wat wel nodig is omdat die ook vaak met gegevens van leden te maken hebben.