Dienst voor gratis ssl-certificaten begint 14 september

Let’s Encrypt, een dienst voor gratis ssl-certificaten, begint 14 september met zijn aanbod. De dienst verstrekt zijn eerste certificaat eind juli. De dienst wil door het gratis aanbod de overstap naar versleutelde verbindingen voor sitebeheerders versnellen.

Burgerrechtenbeweging EFF, een van de drijvende krachten achter Let's Encrypt, noemt de start van de certificaatautoriteit een 'mijlpaal voor webbeveiliging en privacy'. De dienst is onderdeel van het Encrypt the Web-initiatief van de EFF om elke site via https benaderbaar te maken.

De implementatie van ssl-certificaten is voor veel sitebeheerders nog te tijdrovend en omslachtig, constateert de organisatie. Vorig jaar vatte het EFF daarom samen met Mozilla, Cisco, Akamai, IdenTrust en onderzoekers van de universiteit van Michigan het plan voor een eigen certificaatautoriteit op. De autoriteit gaat onder de nieuw opgerichte Internet Security Research Group vallen.

Let's Encrypt maakt het aanvragen van een certificaat op basis van het ACME-protocol niet alleen gratis, maar biedt ook een client voor snelle en eenvoudige installatie. Met die tool voor webservers kunnen certificaten ook ingetrokken worden. "Voor mensen die niet hun eigen webserver draaien, verwachten we dat veel hostingproviders de Let's Encrypt-api gaan invoeren, zodat ze https standaard en zonder kosten aan hun klanten kunnen aanbieden", aldus het EFF.

Reacties (184)

[Orion84]

People without web administration skills may not be able to install one at all. We think that's not acceptable. The free and open web must be accessible to anyone who wants to publish their thoughts, not just those with technical skills.

Mensen die geen verstand hebben van de techniek en daardoor moeite hebben met het installeren van SSL certificaten moeten zich denk ik vooral afvragen waarom ze dan wel zelf een webserver willen beheren. Besteedt dat dan lekker uit aan een partij met verstand van zaken.

En wat voor identificatie en verificatie vind hier eigenlijk plaats? Dat is uiteindelijk toch de primaire rol van een CA.

Wellicht mis ik wat, maar ik zie hier vooral een prachtige laagdrempelig loket voor kwaadwillenden om vertrouwde certificaten te ritselen, zonder al te veel controle procedures. Op deze manier biedt het ogenschijnlijk maar weinig voordelen t.o.v. self-signed certs en met de vervelende bijwerking dat je browser groen licht geeft en je het gevoel geeft dat alles helemaal veilig is.

Edit: zojuist even door die ACME specs gebladerd en daar zit gelukkig wel een mechanisme in om verschillende vormen van verificatie toe te passen om zekerheid te krijgen dat de aanvrager ook daadwerkelijk eigenaar is van het domein waarvoor de aanvraag wordt ingediend. Dat voorkomt nog niet dat iemand een certificaat aanvraagt voor een domein dat sterk lijkt op dat van een bank of zo, maar het is in elk geval beter dan niets.

[Reactie gewijzigd door Orion84 op 23 juli 2024 06:16]

[Verwijderd]

En wat voor identificatie en verificatie vind hier eigenlijk plaats? Dat is uiteindelijk toch de primaire rol van een CA.

Boeien, het gaat mij bij SSL om de encryptie van het verkeer tussen mij en de server.

En totaal niet om de zogenaamde verificatie of identificatie, want die stelt geen reet voor. Zelfs een SSL EV certificaat (met groen slotje + bedrijfsnaam) is echt een lachertje. Je wordt gebeld (kan dus ook op een wegwerptelefoon met anonieme prepaid sim) door een of ander outsourced helpdeskfiguur uit India, je wordt gevraagd of jouw bedrijf inderdaad Huppeldepup B.V. heet, en als je dat bevestigt krijg je je certificaat.

[Orion84]

Dat de verificatie door sommige CA's niet betrouwbaar is, lijkt me nog geen reden om dan maar een initiatief te lanceren waarbij nog minder verificatie is.

Wat is encryptie waard als je 0 zekerheid hebt dat je de data ook daadwerkelijk stuurt naar wie je denkt dat je die stuurt?

[MadEgg]

HTTPS / SSL heeft twee functies: dat wat jij noemt, verificatie van de ontvanger, en verder het versleutelen van de gegevens voor derde partijen, onafhankelijk van wie de ontvanger van jouw data is.

Ik heb het altijd een enorme misser gevonden dat een CA-signed certificaat een noodzaak is om geen beangstigende waarschuwingen in je browser te krijgen.

Encryptie is hoe dan ook een goede zaak aangezien dit andere partijen belemmert om je communicatie in te zien. Het gaat ook een steeds grotere rol spelen voor bijvoorbeeld HTTP 2.0. Hierbij maakt het geen zak uit of de partij met wie je praat wel "gecertificeerd" is.

Voor een website als Tweakers.net zou dat wat mij betreft ruim voldoende zijn. Leuk als mijn wachtwoord niet plaintext verstuurd wordt (al kan dat feitelijk weinig kwaad aangezien ik een password manager gebruik), maar voor de rest niet zo boeiend. Daarvoor zou dus een SSL-verbinding zonder CA-certificering prima volstaan.

Voor communicatie met mijn bank verwacht ik een SSL EV certificaat, met bedrijfsnaam de groene balk. Hiervoor zou de bevestiging van de certificaathouder zeer nauwkeurig en zorgvuldig moeten plaatsvinden.

Browsers zouden dan wat mij betreft alleen veiligheidswaarschuwingen moeten geven bij ongeldige SSL EV certificaten. Voor de rest is het al heel wat om te weten dat je gegevens versleuteld worden. HTTP (zonder S) geeft ook geen enkele garantie over met wie je communiceert. Alleen encryptie biedt daar al voldoende meerwaarde.

Maar ja, het ontwerp aan de basis van SSL certificaten is verkeerd gedaan, in een tijd waarin privacy nog niet zo in opspraak is als in de afgelopen jaren.

[WhatsappHack]

Ik heb het altijd een enorme misser gevonden dat een CA-signed certificaat een noodzaak is om geen beangstigende waarschuwingen in je browser te krijgen.

Ik niet. CA's zijn een fundamenteel, en zeer belangrijk, onderdeel van hoe trusts werken.
Je moet toch iemand vertrouwen om de validiteit te controleren, en afgesproken is dat dit bij de CA's ondergebracht wordt.
Self-signen mag dus, maar dan kan er niet 100% zeker worden vastgesteld of het wel een geldig certificaat is: derhalve een melding.

Meer dan logisch.

Voor communicatie met mijn bank verwacht ik een SSL EV certificaat, met bedrijfsnaam de groene balk. Hiervoor zou de bevestiging van de certificaathouder zeer nauwkeurig en zorgvuldig moeten plaatsvinden.

Meh. Die groene balk houdt je niet veiliger ofzo.
Organization validated werkt ook zeer zorgvuldig qua controles, doet eigenlijk niets onder aan EV.
Het enige dat EV dus doet is een stukje extra marketing en makkelijker in screenshotjes verwerken hoe je phising moet herkennen.

Maar als je een goed geraffineerde phising site tegenkomt kan het zelfs daar nog mis gaan.
EV beschermt je dus niet bepaald beter ofzo. Het ziet er enkel leuker uit, en vooruit: het is iets makkelijker te herkennen, maar daar houdt 't op.

Als enkel 't groene balkje je al overtuigd, dan kan je nog wel eens in de problemen komen.

Browsers zouden dan wat mij betreft alleen veiligheidswaarschuwingen moeten geven bij ongeldige SSL EV certificaten.

Want als een ander SSL certificaat ongeldig of forged is, dan is dat opeens geen probleem?
Als het certificaat ongeldig is moet absoluut altijd een melding gegeven worden, EV of niet.
Er zijn zat systemen die geen EV gebruiken, omdat EV niet zo bijzonder boeiend is: maar waar alsnog hele belangrijke gegevens worden uitgewisseld.
Natuurlijk moet je daar ook een melding voor krijgen.

Wat eigenlijk nog belangrijker is, is dat er veel beter aangegeven wordt als een website totaal niet beveiligd is; want in principe is een self-signed SSL certificaat nog altijd een stuk veiliger dan totaal geen encryptie... Maar voor self-signed krijg je wel een waarschuwing.

[MadEgg]

Je reageert selectief. Wat ik probeer te zeggen is niet dat een trust-systeem per definitie waardeloos is. Wat ik wel zeg is dat de verplichte koppeling tussen een trust-systeem en encryptie een enorme misser is.

Onderscheid tussen SSL EV en OV interesseert me op zich niet, behalve dan dat dat groene balkje inderdaad VEEL makkelijker uit te leggen is aan mensen die er geen verstand van hebben.

Een ongeldig certificaat zou wel gemeld mogen worden, maar dat hangt van je definitie van ongeldig af. Een certificaat wat ingetrokken is mag gemeld worden. Een certificaat wat überhaubt niet correct is zou ook gemeld moeten worden. Een certificaat wat self-signed is is GEEN beveiligingsprobleem. Je communicatie met de webserver is daardoor niet minder veiliger. Het enige wat het potentieel is is een vertrouwensprobleem: kun je de partij waar je mee communiceert wel vertrouwen? En daar hebben we weer het in mijn ogen mislukte ontwerp waarin vertrouwen en encryptie verplicht aan elkaar gekoppeld zijn.

Een browser zou GEEN enorme foutmelding moeten geven als het een self-signed certificaat tegenkomt. Geen enorme waarschuwing met knoppen als 'Haal me hier weg'. Hij zou gewoon de website moeten laden en, als het dan echt moet, een popupje laten zien dat er niet met zekerheid vastgesteld kan worden met wie je communiceert. Maar dan zou ie dat ook moeten doen met elke website die over HTTP geserveerd wordt.

Een HTTPS website met een self-signed certificaat is altijd nog stukken veiliger dan een HTTP-website zonder encryptie.

[WhatsappHack]

Je reageert selectief. Wat ik probeer te zeggen is niet dat een trust-systeem per definitie waardeloos is. Wat ik wel zeg is dat de verplichte koppeling tussen een trust-systeem en encryptie een enorme misser is.

Maar waarom dan?
Ik vind het namelijk een behoorlijk slim uitgewerkt plan eigenlijk.

Een ongeldig certificaat zou wel gemeld mogen worden, maar dat hangt van je definitie van ongeldig af. Een certificaat wat ingetrokken is mag gemeld worden. Een certificaat wat überhaubt niet correct is zou ook gemeld moeten worden. Een certificaat wat self-signed is is GEEN beveiligingsprobleem. Je communicatie met de webserver is daardoor niet minder veiliger. Het enige wat het potentieel is is een vertrouwensprobleem: kun je de partij waar je mee communiceert wel vertrouwen? En daar hebben we weer het in mijn ogen mislukte ontwerp waarin vertrouwen en encryptie verplicht aan elkaar gekoppeld zijn.

Precies. Een self-signed certificaat maakt de encryptie an-sich niet onveilig, mits je maar zeker weet dat het certificaat wel het certificaat is wat zelf aangemaakt is; en van de juiste partij is. En dat is dan ook het probleem: dat valt niet te controleren bij deze certificaten. Derhalve kan je ze niet 100% vertrouwen, valt er niets te verifieren; en krijg je die melding. So far so good lijkt me, dat is een logisch gevolg.

Geen enorme waarschuwing met knoppen als 'Haal me hier weg'.

Die zijn sowieso belachelijk. "Terug naar de veiligheid!!", en dan ga je terug naar een non-SSL verbinding. Prachtig.
Snap niet wat er mis is met een simpel pop-upje, dat doet Opera ook. "Certificaat onveilig. Wil je door? Ja/Nee/Onthouden". TADAAAA.

Een browser zou GEEN enorme foutmelding moeten geven als het een self-signed certificaat tegenkomt. ... Hij zou gewoon de website moeten laden en, als het dan echt moet, een popupje laten zien dat er niet met zekerheid vastgesteld kan worden met wie je communiceert.

Nou een melding tonen lijkt me zeker wel noodzakelijk en zeer belangrijk...
Waar jij over klaagt, is meer de implementatie in de browser. Vroegah gaven alle browers een simpel pop-upje of een page met de vraag of je 't eenmalig wil toestaan of gewoon dat hele certificaat wil opslaan in je trust list. Tegenwoordig krijg je inderdaad een halve horror film op je scherm te zien in sommige browsers.
Dat is geen probleem in het SSL systeem, maar gewoon achterlijke implementatie van de browser bouwert.

Maar dan zou ie dat ook moeten doen met elke website die over HTTP geserveerd wordt.
Een HTTPS website met een self-signed certificaat is altijd nog stukken veiliger dan een HTTP-website zonder encryptie.

Zie laatste alinea van m'n vorige post

[MadEgg]

Ik ben het met je eens dat het SSL certificaten systeem an sich niet een CA verplicht, en dat het in die zin daar dus ook niet aan ligt, maar aan de browsers.

Echter, als die koppeling er nooit geweest was hadden ze het waarschijnlijk ook niet zo in browser ingebakken...

In ieder geval moedig ik diensten die gratis certificaten verstrekken voor domeinen nadat je aangetoond hebt daadwerkelijk beheer over dat domein te hebben ten zeerste aan, dat haalt in ieder geval weer een deel van het vervelende commerciële randje eraf.

[WhatsappHack]

Ik ben het met je eens dat het SSL certificaten systeem an sich niet een CA verplicht, en dat het in die zin daar dus ook niet aan ligt, maar aan de browsers.

Echter, als die koppeling er nooit geweest was hadden ze het waarschijnlijk ook niet zo in browser ingebakken...

Maar het CA systeem is ook belangrijk voor SSL.
Wat had je in gedachten als alternatief om te verifieren of een SSL wel geldig is of niet?

De browsers hebben 't enkel zeer zwaar overdreven en "in your face" gebracht. (Hoewel dat bij sommige mensen wellicht for the best is...), maar de koppeling tussen SSL en CA vind ik wel belangrijk.
Ik ben dan ook wel benieuwd wat je als alternatief een goed plan zou vinden. Je moet toch een partij vertrouwen om de certificaten te valideren...

[mhkool]

EIgenlijk moeten er twee balkjes/vakjes komen die groen kunnen worden:

1e balkje voor vertrouwen: met een OV certificaat wordt het donkergroen en met een EV certificaat wordt het lichtgroen. Certificaat is niet ingetrokken.
2e balkje voor veilige verbinding: de gebruikte encryptie is 'veilig' (TLS1.2, 2048bit signature enz.). Met wellicht ook meerdere tinten groen voor acceptabele encryptie en hoogwaardige encryptie.

Daarnaast mogen browsers wat intelligenter worden en server certificaten bewaren en bij een nieuw/veranderd certificaat de gebruiker waarschuwen. Dit helpt een beetje tegen vervalsingen en verschillende soorten attacks.

[WhatsappHack]

Trouwens... Na dit nog eens gelezen te hebben, nog een vervolg vraag; want ik vind dit elkaar een beetje tegenspreken:

Een ongeldig certificaat zou wel gemeld mogen worden, maar dat hangt van je definitie van ongeldig af. Een certificaat wat überhaubt niet correct is zou ook gemeld moeten worden. Een certificaat wat self-signed is is GEEN beveiligingsprobleem [...] Een browser zou GEEN enorme foutmelding moeten geven als het een self-signed certificaat tegenkomt.

En hoe wil je dan precies gaan controleren of dat self-signed certificaat wel correct is...? Of ingetrokken, want dat zit er bij self-signed ook niet bepaald in; wie gaat dat betrouwbaar intrekken?

Je hebt geen partij om dit dubbel bij te checken in 't geval van een self-signed certificaat, in tegenstelling tot CA validated certificaten.
Die hele foutmelding komt dus enkel omdat de authenticiteit van het certificaat/de sleutels niet bevestigd kan worden... Je weet dus van tevoren helemaal niet of het certificaat "niet correct" is.

En dat is nou juist het hele probleem.



-edit- typo fix

[Reactie gewijzigd door WhatsappHack op 23 juli 2024 06:16]

[MadEgg]

Ja, en daar ga je dus weer voorbij aan mijn stelling dat de validiteit van het hele certificaat soms geen ene moer uitmaakt. Self-signed kun je wel intrekken, maar je zelf-gemaakte CA publiceert waarschijnlijk een CRL en heeft ook een OCSP-server draaien. Dus zou het niet te controleren zijn.

Maar voor de meeste websites maakt dat ook niet uit, daar gaat het puur om encryptie en niet om validatie. Er is niemand die zegt: de houder van dit certificaat is wie hij zegt dat hij is, dus er is ook geen reden om dat in te trekken. Het enige dat je weet is dat op de verbinding tussen jou en degene met wie je praat (wie dat dan ook moge zijn), er tussendoor niemand kan afluisteren. Dat de partij met wie je praat dan mogelijk jouw gegevens weer doorstuurt aan iemand anders / publiceert, is dan niet relevant. Want dat maakt voor heel veel websites niet uit.

Ik blijf erbij dat het leuk zou zijn als je de mogelijkheid zou hebben om puur en alleen encryptie zonder enige vorm van validatie te doen. Volgens jou heb je daar niets aan, maar ik zie heel veel toepassingen.

Besides, je (iemand?) had het ergens over dat je dan kunt controleren of de NSA er niet tussen zit. Die vlieger gaat natuurlijk niet op, de NSA is een van de meest invloedrijke organisaties ter wereld en als die bij een CA aankloppen en zeggen: doe mij eens een geldig ondertekend certificaat voor tweakers.net, dan krijgen ze dat heus wel. Sterker nog, het zou mij niet eens verbazen als ze zelf stiekem een CA die standaard in het lijstje van root-certfiicates zit dat bij elke browser meegeleverd wordt, wat ze dus een vrijbrief geeft om te doen wat ze willen.

Waar het met CA's op neer komt is dat een partij die ik niet ken tegen mij verklaart dat een andere partij die ik ook niet ken zegt wie hij is. Nou, dat kan dan net zo goed achterwege blijven.

Eigenlijk zou het gewoon helemaal niet uit moeten maken, behalve als je met je bank oid communiceert, waarbij je in een brief van je bank, naast je pincode bijvoorbeeld, de fingerprint van hun certificaat krijgt, zodat je deze bij het eerste bezoek aan hun website kunt controleren en als vertrouwt markeert. Op dat moment heb je een soort van two-factor-authentication de andere kant op: jij weet zeker dat de bank is wie hij zegt dat hij is.

[WhatsappHack]

Ja, en daar ga je dus weer voorbij aan mijn stelling dat de validiteit van het hele certificaat soms geen ene moer uitmaakt.

De validiteit van het certificaat maakt altijd uit. Zelfs als je het zelf wilt negeren, moet er wel gekeken worden of het klopt, omdat je niet selectief kan gaan zeggen: "deze negeer ik wel, maar deze negeer ik niet"; dat is te lastig.

Ik blijf erbij dat het leuk zou zijn als je de mogelijkheid zou hebben om puur en alleen encryptie zonder enige vorm van validatie te doen. Volgens jou heb je daar niets aan, maar ik zie heel veel toepassingen.

Jaaaaa, maar dat is ff een heel ander verhaal.
Een oplossing daarvoor is heel erg simpel.

Je kan namelijk wel bereiken wat jij wil, en dat wil ik ook trouwens: ik heb niet gezegd dat ik het niet wil , maar de manier waarop je het verteld en de argumentatie klopt naar mijn mening gewoon totaal niet.
Jij stelt dat CA's een stom model is dat we niet zo hadden moeten maken. En die argumentatie kan ik op geen enkele wijze in meegaan.
Dan stel je dat self-signed certificaten niet gecontroleerd moeten worden "omdat ze toch veiliger zijn dan non-HTTPS", maar ook daar kan ik niet in meegaan: de controle van een certificaat is altijd belangrijk!

... Het hele probleem zit hem hier totaal niet in de validatie en foutmeldingen bij een self-signed certificaat. Die zijn volkomen terecht.

Maar de oplossing is eigenlijk veel simpeler... We moeten het concept CA absoluut niet laten vallen.
Nee... wat we werkelijk moeten laten vallen, is het concept HTTP. Zo simpel, en enorm doeltreffend.
Het probleem waar jij het over hebt zit niet in self-signed certificaten, maar aan de grondslag van HTTP zelf.

Je krijgt dan:
1.) Altijd encryptie, een verbinding zonder encryptie bestaat niet meer. Je krijgt dan dus de veiligheid van een self-signed doordat er encryptie is toegepast, maar niet per definitie de controle van de keys. (Net als die bij self-signed ook niet betrouwbaar zijn.) Je slaat het authorisatie stukje dus eigenlijk een beetje over (althans: niet geheel betrouwbaar.); maar de encryptie wordt prima toegepast: waarmee de verbinding dus veiliger is dan unencrypt.
2.) Voor mensen en bedrijven die wel willen garanderen dat je verbind met wie je verbind en dat de sleutels kloppen, blijven SSL certificaten natuurlijk gewoon bestaan; en die blijven ondergebracht worden bij CA's.

Een self-signed certificaatje blijft dan foutmeldingen tonen: en dat blijft volkomen terecht.
En een valide SSL certificaat blijft een groen slotje tonen of een compleet groene browserbalk.
Maar je hebt helemaal geen certificaat nodig om standaard encryptie toe te passen, en dat is het grote verschil met de huidige situatie.

Snap je wat ik bedoel?
Dat is toch een simpele oplossing lijkt me zo. Altijd HTTPS. Geen controle van certificaat, tenzij er expliciet een certificaat wordt bijgeleverd.
De CA's houden gewoon hun bestaansrecht, en dat systeem blijft prima functioneren.

Win-win. We hebben overal encryptie, en SSL certificaten zijn er dan enkel nog voor een stuk betrouwbaardere authenticatie voor een ieder die daar voor kiest bij hun site/service/platform. (En self-signed blijft dan een probleem.)
Dan hoeven mensen ook geen SSL certificaat meer te kopen voor encryptie van normale sites e.d..
Het probleem is wel dat het iets makkelijker is om een MITM uit te voeren op deze wijze; maar dat kan met helemaal geen SSL natuurlijk even simpel of zelfs nog makkelijker: de encryptie blijft staan, en zal in veel gevallen een enorm verhoogde veiligheid bieden.

Die vlieger gaat natuurlijk niet op, de NSA is een van de meest invloedrijke organisaties ter wereld en als die bij een CA aankloppen en zeggen: doe mij eens een geldig ondertekend certificaat voor tweakers.net, dan krijgen ze dat heus wel

Bij CA's uit de USA misschien. Die uit andere landen niet heur.
Bovendien is dit moeilijker dan je denkt, omdat de CA's te vertrouwen moeten zijn.

Sterker nog, het zou mij niet eens verbazen als ze zelf stiekem een CA die standaard in het lijstje van root-certfiicates zit dat bij elke browser meegeleverd wordt, wat ze dus een vrijbrief geeft om te doen wat ze willen.

Dat zou opvallen, en dan zouden die erg snel revoked worden uit zo'n beetje alle browsers.
Je doet net alsof dat heel simpel zou zijn, maar helaas gelukkig niet. Als de NSA pretendeert andere sites te zijn via een eigen CA, dan gaat dat opvallen.
En dan zie je dus dat een CA niet te vertrouwen is. En is 't einde verhaal voor die CA.

Waar het met CA's op neer komt is dat een partij die ik niet ken tegen mij verklaart dat een andere partij die ik ook niet ken zegt wie hij is. Nou, dat kan dan net zo goed achterwege blijven.

Nee, dat is een belangrijke stap.
Dit is zo afgesproken, zo werkt het protocol. "Dat kan net zo goed achterwege blijven" is natuurlijk volslagen onzin.
Dan kan je net zo goed stellen "we kunnen net zo goed totaal geen SSL certificaten meer gebruiken".

Eigenlijk zou het gewoon helemaal niet uit moeten maken, behalve als je met je bank oid communiceert, waarbij je in een brief van je bank, naast je pincode bijvoorbeeld, de fingerprint van hun certificaat krijgt, zodat je deze bij het eerste bezoek aan hun website kunt controleren en als vertrouwt markeert. Op dat moment heb je een soort van two-factor-authentication de andere kant op: jij weet zeker dat de bank is wie hij zegt dat hij is.

Ja, dat is super gebruiksvriendelijk; makkelijk in te voeren als standaard, en vooral erg leuk voor mensen die moeite hebben met technologie...
Ook erg veilig, want dat valt natuurlijk allemaal totaal niet te spoofen ofzo. Phising friendly enzo.
Laten we het maar gewoon bij CA's houden voor nu: dat systeem werkt tenminste erg goed, behoorlijk betrouwbaar, en heel simpel in gebruik.

[Reactie gewijzigd door WhatsappHack op 23 juli 2024 06:16]

[mhkool]

Bij CA's uit de USA misschien. Die uit andere landen niet heur.
Bovendien is dit moeilijker dan je denkt, omdat de CA's te vertrouwen moeten zijn.

Je mag nooit iets uit de USA vertrouwen omdat het openbaar ministerie daar de macht heeft om geheime bevelen aan bedrijven te geven. Daaronder valt ook het bevel om de master key van hun certificaten af te geven en daarmee kunnen ze valse certificaten maken en SSL verkeer decrypten.

[Orion84]

Alleen encryptie biedt daar al voldoende meerwaarde.

Ik neig er eerder naar om te zeggen dat encryptie in deze vorm vooral een vals gevoel van veiligheid geeft, in plaats van daadwerkelijke meerwaarde.

[David Mulder]

Het voorkomt MiTM aanvallen, hoe is dat een vals gevoel? Als iemand je site weet te hacken of tenminste je domein naam weet te stelen zal inderdaad zich kunnen voordoen als jij zonder dat mensen een verschil zien (certificate pinning daar gelaten), maar een MiTM aanvaller zal dat niet kunnen.

[Orion84]

Als de certificaataanvragen niet goed gecontroleerd worden voorkomt het helemaal geen MitM aanvallen, want dan kan ik dus een cert voor Tweakers.net aanvragen en installeren op mijn rogue server om vervolgens een MitM uit te voeren en jou naar mijn rogue server te dirigeren.

Overigens heb ik net even vluchtig door die ACME specs gebladerd en het lijkt er op dat er in elk geval in die specificatie wel de nodige mechanismes zijn ingebouwd om te verifiëren dat de client die een cert aanvraagt ook daadwerkelijk in control is over het domein waarvoor het cert wordt aangevraagd. Dus wellicht waren mijn zorgen wat voorbarig. Al voorkomen dergelijke automatische checks niet dat iemand een certificaat voor rab0bank.nl registreert en daarmee mensen om de tuin leidt.

[freaky]

Dan zul je dus eerst de DNS moeten hacken want anders gaat dat je niet lukken.

En als je de webserver hacked, even er van uitgaande dat er geen SSL offloading op een load balancer zit oid, dan kun je de bestaande geldige gecontroleerde certificaten gewoon kopiëren.

Maar neig vooral naar meningen ipv ze te onderbouwen. Iedere browser importeert immers CA certificaten zonder enige vorm van controle of eisen... Laat staan dat er mensen zitten die de materie begrijpen.

Een van de eisen voor EV is overigens ook het doorlichten van de KvK e.d., en ongetwijfeld heel vreemd, maar dat doen ze bij de KvK en niet bij de aanvrager. ID bewijzen zijn ook nodig. Met alleen een telefoontje kom je niet weg. Als dat wel het geval zou zijn kun je dit bij de meeste browser bedrijven gewoon rapporteren en is het zo gedaan met hun root CA want die wordt vrij snel ongeldig verklaart dan.

En waar haal je het idee vandaan dat clear text geen probleem is omdat je een wachtwoord manager gebruikt? Als ze je wachtwoord afluisteren hebben ze het gewoon. Als je je wachtwoord wijzigt hebben ze het ook gewoon... Heel die wachtwoord manager gaat daar niets aan veranderen. Je voornaamste voordeel zit hem waarschijnlijk in het feit dat je niet op iedere site hetzelfde wachtwoord gebruikt. Op site X is je account echter nog steeds achterhaald en kunnen ze je account misbruiken.

En persoonlijk denk ik dat het kwalijker is dat SIDN je een domein als rab0bank.nl verstrekt dan dat een CA je een certificaat geeft op een domein wat je ook bezit, maar goed, dat is een andere discussie. Het wordt wat anders als ze je een EV afgeven waar instaat dat je daadwerkelijk de Rabobank bent, maar dat zie ik niet snel gebeuren.

Er zijn overigens maar enkele CA's die uberhaupt EV mogen verstrekken en die zitten hardcoded in je browser. Kunt zelf wel CA certificaten importeren, maar daar zal ie geen EV extensies van accepteren .

[iceblink]

Je hoeft de DNS niet te hacken, je hoeft alleen de client wijs te maken dat ze jouw DNS moeten gebruiken. Iets dat heel eenvoudig is bij WiFi.

[WhatsappHack]

Niet alleen bij WiFi hoor
Maar net als bij alles, staat of valt het bij de beveiliging, controles en toegang tot het netwerk an sich.

[CAPSLOCK2000]

Er is geen enkele vorm van beveiliging die helemaal dekkend is. Iedere losse maatregel kun je wegzetten als een "vals gevoel van veiligheid". Veiligheid maak je door meerdere maatregelen te combineren.

Je zou net zo goed kunnen zeggen dat op SSL vertrouwen voor identificatie een vals gevoel van veiligheid is. Hoeveel mensen weten nu echt hoe ze moeten controleren of een SSL-certificaat wel echt in de haak is. 99% van de mensen weet niet meer dan dat een slotje goed is en een rood balkje niet. Ik durf te wedden dat zelfs hier op Tweakers minder dan 10% van de bezoekers ooit kijkt wat er in een certificaat staat en nog veel minder weet hoe je die info moet controleren.

Kleine zelf-test: Weet je wat CRL en OCSP zijn?

[Reactie gewijzigd door CAPSLOCK2000 op 23 juli 2024 06:16]

[Bor]

Voor de rest is het al heel wat om te weten dat je gegevens versleuteld worden.

Daarmee schiet je je doel direct voorbij want wat heeft encryptie voor zin als jij niet weet dat de partij waarmee je denkt te communiceren ook daadwerkelijk die betreffende partij? Juist daarvoor gebruik je een 3rd party signed certificaat. Als je dat niet boeit heb je helemaal geen dergelijk certificaat nodig.

Maar ja, het ontwerp aan de basis van SSL certificaten is verkeerd gedaan, in een tijd waarin privacy nog niet zo in opspraak is als in de afgelopen jaren.

Onzin, het ontwerp is juist ontzettend goed. Waar je in de praktijk last van hebt is dat applicaties als browsers ook (root) certificaten accepteren van minder strenge instanties en sommige systemen zelf niet controleren of certificaten wellicht zijn ingetrokken. Het is niet voor niets dat aan de basis al jaren bijna niets veranderd is wat betreft opzet.

[dtech]

> Daarmee schiet je je doel direct voorbij want wat heeft encryptie voor zin als jij niet weet dat de partij waarmee je denkt te communiceren ook daadwerkelijk die betreffende partij?

Ik kan niet meer met een telefoon jouw verkeer op een openbaar wifi afluisteren, en een MiTm uitvoeren kan misschien wel met ARP poisoning e.d., maar vereist meer kunde en moeite.

Natuurlijk is encryptie+authenticatie beter, maar de hele "encryptie zonder authenticatie is zinloos" mindset is precies wat ervoor zorgt dat er moord en brand wordt geschreeuwt over een niet-geauthenticeerde SSL verbinding door de browser, terwijl een niet-geauthenticeerde niet-geencrypteerde niet-SSL verbinding een free pass krijgt.
Dit terwijl het eerste verkiesbaar is boven het tweede.

[Tribits]

Ik kan niet meer met een telefoon jouw verkeer op een openbaar wifi afluisteren, en een MiTm uitvoeren kan misschien wel met ARP poisoning e.d., maar vereist meer kunde en moeite.

Dus gewoon nog steeds onveilig, zo ingewikkeld zijn dergelijke MITM attacks echt niet. Daar zijn ook gewoon kant en klare tooltjes voor om dergelijke aanvallen uit te voeren. En hoe wil je dat aan de gemiddelde gebruiker uit gaan leggen? Het zou best wel eens veilig kunnen zijn, maar misschien ook helemaal niet?

Natuurlijk is encryptie+authenticatie beter, maar de hele "encryptie zonder authenticatie is zinloos" mindset is precies wat ervoor zorgt dat er moord en brand wordt geschreeuwt over een niet-geauthenticeerde SSL verbinding door de browser, terwijl een niet-geauthenticeerde niet-geencrypteerde niet-SSL verbinding een free pass krijgt.
Dit terwijl het eerste verkiesbaar is boven het tweede.

Een niet geauthenticeerde https verbinding is een vorm van schijnveiligheid. Ik weet niet of je dat moet verkiezen boven geen enkele veiligheid. Het voorkomt dan misschien een bepaald soort aanval, maar is nog steeds zo lek als een mandje. Voor je het weet gaan gebruikers er onterecht toch waarde aan hechten omdat er sprake is van encryptie. Dan heb ik liever http zodat ik zeker weet dat de verbinding niet veilig is of https zodat ik vrijwel zeker weet dat de verbinding wel veilig is.

[Reactie gewijzigd door Tribits op 23 juli 2024 06:16]

[Feanathiel]

Maar goed, als jij niet weet wat het certificaat is van de andere kant dan weet je eigenlijk nog niks. Je ziet dan inderdaad dat jouw data geëncrypt wordt. Maar uiteindelijk weet je nog niet of je daadwerkelijk met het goede systeem verbonden bent. Als er iemand op de lijn zit die alsnog jouw data kan decrypten, en zelf weer encrypt en weer door stuurt, dan heb je in feite nog weinig aan zo'n dergelijk certificaat. Hoe kijk jij hier tegen aan?

[MadEgg]

Dat klopt. De toepasbaarheid van SSL zonder valide CA is dus wat mij betreft ook afhankelijk van de toepassing. Voor een site als tweakers.net vind ik het afdoende.

Het interesseert mij vrij weinig of de server die reageert op mijn verzoek aan het domein tweakers.net nu van Jan, Kees of Piet is, want ik ken de crew van Tweakers.net niet persoonlijk. Bovendien kunnen zij ook vrij weinig met mijn gegevens. Je stelt altijd vertrouwen in de andere kant van een verbinding als je gebruik maakt van diens diensten, en veelal doe je dat zonder te weten wie aan de andere kant staat. Hoeveel vertrouwen je daarin steekt is afhankelijk van hoe belangrijk je communicatie is.

Het voordeel van encryptie is dat het inherent veel lastiger is om de gegevens uit te lezen voor een derde partij. Ze zouden met een vals certificaat een MitM-attack kunnen doen, inderdaad, maar daarvoor moeten ze ook de DNS hijacken. Het is allemaal mogelijk, het is allemaal al eens gebeurt, maar de drempel is zeker niet laag. Voldoende hoog voor veel toepassingen. Encryptie zou ik graag overal willen toepassen, maar het hoeft niet altijd even dichtgetimmerd te zitten.

Communicatie met je bank is een ander verhaal, daarbij wil ik wél dat de andere partij gecertificeerd is.

Het hele verhaal is bij SSH wat mij betreft veel eleganter opgelost. De eerste keer dat je verbinding maakt met een nieuwe server kun je de fingerprint beoordelen. Dit alles zonder waardeoordeel of je het wel of niet zou moeten vertrouwen. Je kunt dit dus controleren indien je het heel belangrijk vindt, maar je kunt ook aannemen dat de fingerprint hoort bij de server waar je verbinding mee maakt. Op basis van vertrouwen, wat ik net zo veel (of weinig) stel in een webserver als ik daar voor de eerste keer een website bezoek via HTTP.

Maak ik daarna nogmaals verbinding met dezelfde SSH-server en is de fingerprint gewijzigd dan krijg ik wel een dikke vette waarschuwing: hier is iets niet in de haak. En dan is het terecht. Op dat moment ga ik controleren of het klopt dat fingerprint gewijzigd is of dat er een MitM-attack aan de gang is.

Iets dergelijks zou ideaal zijn voor sites die momenteel over HTTP geserveerd worden. De eerste keer krijg je een self-signed certificaat toegestuurd. Je browser doet daar geen waarde-oordeel over maar slaat het op. Indien je een volgende keer dezelfde site bezoekt en je krijgt een ander certificaat, dan pas gaan de alarmbellen af. Dit alles natuurlijk wel voorzien van een slotje, maar geen groene adresbalk. Die groene adresbalk blijft vervolgens voorbehouden voor organisaties die gevoelige informatie behandelen en hiertoe zich laten verifiëren door een CA. En dit zou dan ook zeer nauwkeurig moeten gebeuren, waarbij CA's ook zwaar afgerekend worden op hier laconiek mee omgaan. De eerste functie van een CA zou vertrouwelijhkeid moeten zijn, en geen commercie / zo veel mogelijk dure certificaten uitreiken.

[Overv]

Voor het uitlezen van de data zonder encryptie moet de DNS ook gehijackt worden. Wat is dan nog de toegevoegde waarde van encryptie zonder verificatie?

[MadEgg]

Nee, dan volstaat een sniffer. Elke host in de route tussen jouw PC en de website waar je mee communiceert kan de communicatie afluisteren en uitlezen als er geen encryptie toegepast wordt.

[Verwijderd]

dat is niet waar want dit gaat spionage op zee kabels tegen

[Monochrome]

Encryptie is hoe dan ook een goede zaak aangezien dit andere partijen belemmert om je communicatie in te zien. Het gaat ook een steeds grotere rol spelen voor bijvoorbeeld HTTP 2.0. Hierbij maakt het geen zak uit of de partij met wie je praat wel "gecertificeerd" is.

Wait what?! Dit kan je niet vinden. In het huidige systeem zijn certificate authorities (CA's) juist cruciaal om te voorkomen dat de communicatie door derde partijen niet is in te zien.

Een partij die in de positie is om jouw communicatie te tappen heeft vrijwel altijd ook een man in the middle (mitm) positie (uitzonderingen daargelaten).

Bedenk je het volgende scenario in: jij probeert te verbinden met domein.com. Je krijgt een certificaat voorgeschoteld dat zegt "domein.com heeft public key A". Heel mooi. Jij versleutelt vervolgens je verkeer naar domein.com met public key A. Wat is dat certificaat waard als jij niet can controleren of public key A wel daadwerkelijk de public key is van domein.com? Precies: niks. Een aanvaller in een mitm positie kan die key verangen door z'n eigen key. Jij gaat dus je verkeer versleutelen met zijn key in plaats van die van domein.com. De aanvaller ontsleutelt jouw verkeer, versleutelt het opnieuw met de juiste key voor domein.com en stuurt het door. Resultaat: je verkeer wordt alsnog getapt, encryptie of niet. Het is dus volledig terecht dat je grote rode schermen te zien krijgt als je een niet-vertrouwd SSL certificaat voorgeschoteld krijgt.

In het geval van een gesigned SSL certificaat krijg je heel simpel gezegd het volgende voorgeschoteld: "domein.com heeft public key A, zegt certificate authority X". Het is digitaal ondertekend door certificate authority X, wat betekent dat elke aanpassing aan het certificaat ervoor zorgt dat het certificaat ongeldig wordt. Jij kan het certificaat verifieren omdat certificate authority X wordt vertrouwd door je browser. En we weten (hopen) dat certificate authority X altijd netjes eerst vaststelt dat een bepaalde public key wel hoort bij een domein alvorens het certificaat te ondertekenen.

Voor communicatie met mijn bank verwacht ik een SSL EV certificaat, met bedrijfsnaam de groene balk. Hiervoor zou de bevestiging van de certificaathouder zeer nauwkeurig en zorgvuldig moeten plaatsvinden.

EV certificaten zijn niets anders dan een certificaat waarin, bovenop de domeinnaam, allerlei andere dingen worden vastgesteld door de certificate authority, zoals de bedrijfsnaam, het adres, enz. Extra fanciness topping dus. Een EV certificaat zorgt dus voor grofweg 0 extra veiligheid (weet de eenheid voor veiligheid zo even niet uit m'n hoofd )

OT:
Dit initiatief gaat ervoor zorgen dat er niet langer betaald hoeft te worden voor een SSL certificaat. Dat is heel goed nieuws want tot nu toe was veilig kunnen communiceren altijd een rip-off. Bovendien: hoe gezond is het dat we met z'n allen vertrouwen dat certificate authorities het geld van hun klanten weigeren als hun identiteit niet vastgesteld kan worden?

[MadEgg]

Als je op een openbaar wifi zonder HTTPS te gebruiken zit kan iedereen in de nabijheid jouw communicatie met domein.com afluisteren, daar is geen MITM-positie voor nodig.

Bovendien, als je een HTTP-verbinding opzet met domein.com, en dus geen encryptie gebruikt, heb je al helemaal geen flauw benul met wie je communiceert. Je weet in ieder geval zeker dat vrijwel iedereen mee kan lezen. Toch geeft je browser geen kik als je een HTTP-website bezoekt terwijl je grote waaschuwingen en horror-verhalen in je gezicht geduwd krijgt als je een HTTPS-website bezoekt die een self-signed certificaat heeft.

Ik claim ook nergens dat SSL EV een hogere beveiliging geeft. Het geeft wel een hogere authoriteit en dus mogelijk meer vertrouwen. Waarom? Omdat het meer gegevens bevat en je hoopt dat de CA zijn best heeft gedaan om te controleren dat die gegevens juist zijn. Dat zou de rol van een CA moeten zijn.

Een betere oplossing is iets als DNSSEC. Hierbij worden CA's samengevoegd met de beheerders van de TLD's. Je browser zou dan een lijst van TLD's kunnen hebben met bijbehorende root-certificates (ik neem aan dat dat ook zo is). Vervolgens werk je de certificate chain af totdat je bij de DNS-server van je domain of choice aankomt. Je weet zeker dat tot daar aan toe alles ondertekend en correct is, en dat er dus niemand mee heeft kunnen knoeien. Het grote voordeel is dat je zélf de certificaten voor al je subdomeinen kunt uitgeven aangezien jij de authoriteit van het hoofddomein hebt, en dat je uitsluitend zaken doet met de leverancier van je TLD of choice, die weer verklaart dat jij authoriteit hebt over jouw domein.

Op dezelfde manier zouden de public keys voor webservers ook beschikbaar gemaakt moeten worden via DNS, dan heb je in een klap alles geregeld.

[Monochrome]

Als je op een openbaar wifi zonder HTTPS te gebruiken zit kan iedereen in de nabijheid jouw communicatie met domein.com afluisteren, daar is geen MITM-positie voor nodig.

Op een openbaar wifi kan ook iedereen een mitm aanval uitvoeren. De mogelijkheid om te tappen is dus evengoed aanwezig en er is dus vrijwel geen enkele toegevoegde waarde voor het gebruik van HTTPS icm self-signed certificaten, behalve misschien voor je energie-leverancier.

Bovendien, als je een HTTP-verbinding opzet met domein.com, en dus geen encryptie gebruikt, heb je al helemaal geen flauw benul met wie je communiceert. Je weet in ieder geval zeker dat vrijwel iedereen mee kan lezen. Toch geeft je browser geen kik als je een HTTP-website bezoekt terwijl je grote waaschuwingen en horror-verhalen in je gezicht geduwd krijgt als je een HTTPS-website bezoekt die een self-signed certificaat heeft.

Hou er rekening mee dat een partij in een mitm positie een (al dan niet EV) ondertekend certificaat kan vervangen door een self-signed.

Je legt feitelijk de verantwoordelijkheid in handen van de gebruiker, die naast het checken van het slotje ook nog eens voor zichzelf na moet gaan of hij de ondertekenende partij wel vertrouwt. Dit kennisniveau kan je niet verwachten van een leek. Laten we alsjeblieft de boel niet nog complexer maken dan het al is en gewoon dit scenario uitsluiten. De prijs die je daarvoor betaalt is dat self-signed certificaten not-done zijn. Maar, zoals hierboven vastgesteld, hadden die toch al weinig tot geen meerwaarde boven geen encryptie whatsoever.

Het feit dat je browser niet zeurt als er geen plain HTTP gebruikt wordt heeft te maken met het feit dat confidentiality/integrity simpelweg geen toegevoegde waarde biedt voor sommige websites. Dat icm het feit dat certificaten tot op heden niet gratis waren.

Een betere oplossing is iets als DNSSEC. Hierbij worden CA's samengevoegd met de beheerders van de TLD's. Je browser zou dan een lijst van TLD's kunnen hebben met bijbehorende root-certificates (ik neem aan dat dat ook zo is). Vervolgens werk je de certificate chain af totdat je bij de DNS-server van je domain of choice aankomt. Je weet zeker dat tot daar aan toe alles ondertekend en correct is, en dat er dus niemand mee heeft kunnen knoeien. Het grote voordeel is dat je zélf de certificaten voor al je subdomeinen kunt uitgeven aangezien jij de authoriteit van het hoofddomein hebt, en dat je uitsluitend zaken doet met de leverancier van je TLD of choice, die weer verklaart dat jij authoriteit hebt over jouw domein.

En alle problemen die we nu hebben met CA's verplaatsen naar de DNS boom. Dat lijkt me echt niet de kant waar we op moeten willen.
Een gedistribueerd model lijkt me veel wenselijker, iets met DHT zoals Tor of een block chain zoals bitcoin. Zoiets bestaat vandaag de dag al en heet convergence.

[WhatsappHack]

Een betere oplossing is iets als DNSSEC. Hierbij worden CA's samengevoegd met de beheerders van de TLD's. Je browser zou dan een lijst van TLD's kunnen hebben met bijbehorende root-certificates (ik neem aan dat dat ook zo is). Vervolgens werk je de certificate chain af totdat je bij de DNS-server van je domain of choice aankomt. Je weet zeker dat tot daar aan toe alles ondertekend en correct is, en dat er dus niemand mee heeft kunnen knoeien. Het grote voordeel is dat je zélf de certificaten voor al je subdomeinen kunt uitgeven aangezien jij de authoriteit van het hoofddomein hebt, en dat je uitsluitend zaken doet met de leverancier van je TLD of choice, die weer verklaart dat jij authoriteit hebt over jouw domein.

De beheerder van .com is VeriSign.
VeriSign is een CA.
Zit je alsnog in 't zelfde bootje.

Maare... Zoals ik in de laatste paragraaf van deze post al aangaf: DNSSEC is absoluut niet de oplossing.

Daarnaast veroorzaakt wat jij zo noemt ook een enorme overhead en een flinke vertraging, plus meer points of failure.
Je bent dus:
1.) Niet beter af dan met CA's
2.) Hebt *nog meer* partijen te vertrouwen dan enkel de CA
3.) Revoken van een TLD wordt nogal lastig
4.) Bij een godsvermogen aan TLD's ben je nog eens afhankelijk van de root (voornamelijk ICANN)
5.) Het is sloom.

... Dan toch liever een CA.
DNSSEC misschien om te complementeren bij extra beveiliging, maar niet als algehele vervanging van CA's binnen het SSL domein.

[Reactie gewijzigd door WhatsappHack op 23 juli 2024 06:16]

[Blokker_1999]

De verificatie is evenveel waard als bij alle andere goedkope certificaten. Die zijn allemaal domain name verified. Men gaat dus alleen maar na of jij toegang hebt tot de server die achter het domein zit dat de aanvraag doet. Zo een cert is op enkele seconden te regelen.

[totaalgeenhard]

Sommige ?

Hoeveel NIET Nederlandse CA's kunnen Nederlandse documenten zoals scan van paspoort, KVK uittreksel beoordelen ?

Het is gewoon nergens gebaseerd.

[Tozz]

Dat is wel boeien. Als de identificatie en verificatie niet goed in elkaar zit dan zou ik in theorie een certificaat kunnen aanvragen voor het domeinnaam dat jij wilt bezoeken. Als ik die heb bemachtigd kan ik een MitM aanval uitvoeren zonder dat jouw browser een krimp geeft. Die denkt dan gewoon dat alles veilig is, omdat het certificaat valide is.

Het hele certificaat verhaal valt of staat met de betrouwbaarheid van de CA en het correct uitgeven van certificaten aan uitsluitend de domeinnaameigenaar (en dus niet aan derden)

[Verwijderd]

Als de identificatie en verificatie niet goed in elkaar zit dan zou ik in theorie een certificaat kunnen aanvragen voor het domeinnaam dat jij wilt bezoeken. Als ik die heb bemachtigd kan ik een MitM aanval uitvoeren zonder dat jouw browser een krimp geeft.

Als ik tweakers.net bezoek zonder SSL, en we zitten op hetzelfde netwerk (allebei op wifi in de trein bijvoorbeeld) kun jij zo mijn packets sniffen en al mijn verkeer meelezen. Maar in geval van met SSL, hoe ga jij een MitM doen?

[Orion84]

Sniffen is wat anders dan een MitM. Bij een MitM aanval heeft de aanvaller controle over het netwerk. Bijvoorbeeld door in de trein een netwerk op te zetten dat sterk lijkt op dat van de NS en het echte netwerk te verdrukken.

Jij maakt verbinding met het neppe netwerk, en wijst je browser naar Tweakers.net. De aanvaller dirigeert jouw verkeer vervolgens richting zijn eigen server die zich voordoet als Tweakers.net en hey presto, je hebt een probleem.

Het is dus wel degelijk een relevante vraag in hoeverre dit soort laagdrempelige SSL aanbieders een gevaar vormen voor de betrouwbaarheid van certificaten.

[David Mulder]

Let's encrypt verifieert wel degelijk of jij het domein beheert waar je een certificaat voor aanvraagt. Wat dus het exact zelfde niveau van verificatie is als super veel andere certificaat uitgevers. Dus voor MiTM aanvallen gaat het je weinig helpen.

[Orion84]

Vandaar ook de vraag in mijn oorspronkelijke reactie: "En wat voor identificatie en verificatie vind hier eigenlijk plaats?".

Inmiddels heb ik inderdaad in die ACME specs gevonden dat daar wel de nodige functionaliteit voor controles ingebouwd zit, dus het aanvragen van certificaten voor andermans domein lijkt inderdaad niet zomaar mogelijk.

[Verwijderd]

Sniffen is wat anders dan een MitM. Bij een MitM aanval heeft de aanvaller controle over het netwerk.

Dat snap ik. Sniffen is veel laagdrempeliger en makkelijker te doen door iedereen. Daarom vind ik niet-geauthoriseerde SSL wel degelijk een hele verbetering t.o.v. geen SSL.

Wel met je eens dat het in bepaalde situaties een schijnveiligheid kan opleveren, wanneer mensen die authorisatie totaal gaan negeren. Maar die authorisatie is nu in feite ook al zo lek als een mandje, die CA constructie slaat nergens op.

[WhatsappHack]

Wel met je eens dat het in bepaalde situaties een schijnveiligheid kan opleveren, wanneer mensen die authorisatie totaal gaan negeren.

Wat valt er te negeren aan self-signed certificaten? Die hebben niets te negeren, want ze worden helemaal niet geverifieerd door een CA.

Maar die authorisatie is nu in feite ook al zo lek als een mandje, die CA constructie slaat nergens op.

Kun je dat ook beargumenteren...?
Het werkt tot dusver ontzettend goed. Er wordt sporadisch wel eens eentje gehacked, en dan worden ook meteen alle certificaten van die toko invalidated. Makkelijk, snel, veilig; prima.

Over het algemeen werkt het prima; dus ben benieuwd waarom het volgens jou nu al zo lek als een mandje is en dat de CA constructie nergens op slaat.

[Verwijderd]

Omdat je op basis van een fake KVK uittreksel (zelf even photoshoppen) met daarin een dummy 06 nummer een certificaat geverifieerd kunt krijgen.

[WhatsappHack]

Heb je dat wel eens geprobeerd dan?
Of heb je er een andere bron voor van iemand die dat gelukt is?

Het klinkt mij puur als een theorie.
De verificatie gaat namelijk wel een tikje verder dan dat bij bijv. EV.

[CEx]

Versimpeld uitgelegd:

Door jouw SSL handshake af te vangen en op te zetten met mijn machine en vervolgens een reroute naar de echte site. Je browser gebruikt netjes SSL, maar ondertussen heb ik de private key en kan ik dus alle packets decrypten.

Je verkeer loopt dus als volgt: Jij --SSL sessie-- Ik --SSL Sessie-- Tweakers. (De 2e SSL sessie is overbodig als de server het niet uitmaakt).

[Verwijderd]

Door jouw SSL handshake af te vangen en op te zetten met mijn machine

Hoe forceer je dat? Zeker als ik wel een beetje oplet met welke wifi AP's ik connect?

[Bor]

Een rogue WIFI accesspoint opzetten is op zich niet zo lastig. Je kunt er zelfs devices voor kopen. Je kunt een SSID bijvoorbeeld in veel gevallen simpelweg klonen of overschreeuwen.

[klakkie.57th]

malware op jouw pc is volgens mij al genoeg.

[Verwijderd]

Ja duh, dan kan alles. Maar hoe krijgt iemand malware op mijn PC? Dat lukt dus niet, ik ben geen newbie die blindelings attachments opent of leukfilmpjevankatten.avi.exe bekijkt. Bovendien moet dat al een hele gerichte persoonlijke aanval zijn (met lage slagingskans), terwijl je zonder encryptie gewoon iedereens verkeer in de trein of op kantoor direct kunt afluisteren. Groot verschil.

[klakkie.57th]

Volgens mij mag je er nooit van uitgaan dat je veilig bent.
Als malware zelfs het Duits parlement, internet providers (Belgacom) en tientallen ander voorbeelden kan besmetten, waarom zou dat dan niet bij jou kunnen gebeuren.

[Verwijderd]

Met alle respect, maar "het Duits parlement" klinkt als een stelletje ambtenaren en die staan nou niet bepaald bekend om ICT-deskundigheid of tweakergehalte.

En nogmaals, gerichte persoonlijke aanval met lage slagingskans, versus portsniffer opstarten en direct alles afluisteren, is gewoon een enorm verschil.

[Mijzelf]

Als je echt in hetzelfde netwerk zit kun je een DHCP server draaien, die jouw IP als gateway geeft, en vervolgens hoef je alleen maar te wachten en de dobber in de gaten te houden.

[Blokker_1999]

Een CA moet nog altijd een beperkte controle uitvoeren. Zo zal men in de meeste gevallen bij goedkope certs gewoon nagaan of je ook effectief toegang hebt tot de server waar het domein word voor aangevraagd, en dat kan je met wat tools perfect automatiseren.

[Powermage]

Het nummer moet wel weer aan KVK of domain registry gegevens te matchen zijn natuurlijk....

[Verwijderd]

Domain kun je gewoon registreren met privacy protection, of desnoods met dezelfde (eventueel fake) naam als waarmee je je certificaat gaat registreren, want bij registrars wordt sowieso nul komma nul gecontroleerd.

En KVK? Je denkt dat zij zelf actief je gegevens in de handelsregisters van ieder land gaan controleren? Ze kunnen de site van de Nederlandse KVK niet eens lezen. Je stuurt gewoon zelf een uittreksel mee, wat je natuurlijk net zo goed kunt photoshoppen of je eigen custom naam en nummer op kunt zetten, en je komt er zo doorheen. Nogmaals, die controle bij sommige CA's is echt een farce (ook voor EV certificaten).

[Powermage]

Maargoed, wat is er nu vreemd aan dat jij voor je eigen domein een SSL certificaat kan aanvragen met je prepaid nummertje overal in gezet??

De bescherming moet zijn dat jij niet op naam van een ander persoon/bedrijf iets aanvraagt, en in de huidige voorzieningen is een call-verify iets wat gedaan word nav bedrijfsgegevens, certificate uitgifte partijen doen dit pas na een automatische of handmatige controle vanuit een bron die verifieerbaar is.

Dat jij zelf een domein kan registreren met gegevens van jou en daar een cert op kan verifieren lijkt me een prima workflow

[Wolfensteijn]

Een goede CA belt alleen naar het nummer op je KvK uittreksel. En de overige gegevens worden ook echt handmatig gecontroleerd.

Ik heb genoeg gezeik gehad met het leveren van EV SSL certificaten, omdat klanten gewoon de verkeerde gegevens aanleveren

[Verwijderd]

Een goede, daar heb je het al. Er zijn ook minder goede, maar die certificaten worden evengoed overal geaccepteerd.

En een uittreksel kun je gewoon zelf even photoshoppen, met je eigen nummer erop.

[DigitalExorcist]

Ja, maar dáár hebben we tegenweurdig internet voor. KvK zit ook op internet, en hun database is ook gewoon in te zien. Succes met photoshoppen

[3raser]

Op internet kun je alleen het KvK nummer, de bedrijfsnaam en de vestigingsplaats inzien. Voor alle overige gegevens moet je betalen. Dat uittreksel is dus prima te photoshoppen want de belangrijke gegevens zijn niet (gratis) te controleren.
Ik maak een uittreksel waarbij alle gratis gegevens kloppen en waar ik mijn eigen telefoonnummer in zet. Daar zou ik dus zonder problemen een SSL certificaat mee aan kunnen vragen.

[DigitalExorcist]

En wat ga je dan doen, uitprinten en faxen of wa?

Zullen we maar gewoon even voor de grap aannemen dat échte certificeringsinstanties (in Nederland) wél gewoon die paar centen voor het inzien van het KvK-register betalen?

[3raser]

Daar zeg je iets bij, "in Nederland".
Als je wilt frauderen dan ga je dat natuurlijk bij een provider in het buitenland doen. En dan het liefst bij een instantie waar de controle zo slecht mogelijk is.

[Verwijderd]

De gemiddelde buitenlandse CA weet niet eens wat de KVK is, laat staan dat ze de moeite nemen om zelf een uittreksel opvragen (waar je volgens mij met iDeal voor moet betalen, dus sowieso geen optie voor buitenlanders).

[DigitalExorcist]

Mag toch zeker hopen dat 06-nummers niet zomaar als 'geldig' worden verklaard. Moet minstens een vast toestel zijn dat minimaal ergens bekend is en gekoppeld is aan het KvK-nummer, toch? ..... toch??

[Verwijderd]

Nope. Buitenlandse CA's weten sowieso niet eens wat een 06 is, als je gewoon [phone] er in photoshopt zet niemand daar vraagtekens bij.

Het is "ergens bekend", ja in de KVK, wat je te zien krijgt als je zelf een (betaald) digitaal uittreksel opvraagt. Maar dat doen die certificaatboeren dus niet*. Je moet er zelf eentje meesturen

(*althans sommige, misschien andere ook wel, maar in ieder geval een aantal niet, waaronder ook "officiële" die door alle mainstream browsers en OS'en erkend worden)

[yodax]

Volgens mij gaat je browser geen groen licht, maar een grijs licht geven. Er zijn nu al partijen waar dit kan. Lets Encrypt gaat het alleen toegankelijker maken. Een grijs slotje geeft alleen aan dat het certificaat bij het domein hoort.

[clueless12]

Lijkt mij niet. Als ik het goed gelezen heb dan komen de roots gewoon in de browser en krijgen we (als ik het snap) daarmee een betrouwbare keten en dus een groen slotje. Kan iemand dit bevestigen?

[Feanathiel]

Dat is dan toch heel makkelijk te faken? Even man-in-the-middle'en en je hebt een grijs slotje. Niemand die het ziet? Normaal krijg je dan nog een groot kruis met een certificaat wat gewoon niet chain-trusted is.

[Reactie gewijzigd door Feanathiel op 23 juli 2024 06:16]

[David Mulder]

Verschil tussen grijs en groen ligt in de meeste browsers aan het 'niveau' van het certificaat. Met het hoogste niveau krijg als alles perfect juist is krijg je in Chrome de volledige naam van de organisatie in een groen blok, het laagste niveau aan de andere kant is alleen een (monochroom?) slotje, maar zelfs dat slotje vereist dat het certificaat correct en valide is.

[yodax]

Precies dit dus ja. Een groen slotje is extended validation. Dat betekend dat het certificaat meer dan alleen elektronisch gecontroleerd is.

[eborn]

Dit is dus niet waar (zie reactie daarboven). Chrome geeft ook bij domain validated domeinen een groen slotje. Bij EV certificaten komt er ook een groen balkje voor met de naam van de organisatie. Maar qua slotje is de URL exact hetzelfde.

[teek2]

Dat kan nu dus ook al makkelijk. En het gaat om de combinatie domeinnaam/ssl certificaat, niet zomaar om een certificaat natuurlijk. Als je een cert wilt voor rab0bank.nl kan dat nu ook ook dus als consument moet je al op dat soort dingen letten.
Het instellen zal misschien niet veel sneller zijn maar je hoeft nu niet elk jaar te verlengen. Ik snap niet dat je tegen makkelijker, meer encryptie voor meer mensen kan zijn.

[Q]

Het enige wat deze dienst biedt is dat gebruikers redelijk zeker zijn dat ze verbonden zijn met de site waarmee ze verbonden dachten te zijn (dns match met certificaat).

Een MitM wodt lastiger, maar veel sites die op open source frameworks draaien worden niet geupdated en vaak toch zo lek als een mandje.

Voor een gemiddelde leek is het allemaal niet te begrijpen.

[dasiro]

ik denk dat je niet volledig snapt wat de bedoeling van een certificaat is. Ze worden gebruikt om het verkeer tussen de bezoeker en de site te versleutelen zodat derde partijen er geen wijzigingen in kunnen aanbrengen. De inhoud van de site zelf heeft hier niets mee te maken. Bovendien kan je perfect zelf een CA opzetten om dit te doen, alleen is de kans heel klein dat je getrust wordt.

[MrFax]

(Voorbeeld) Oh dus een persoon mag geen eigen forum draaien voor zijn programma zodat hij/zij contact kan hebben met zijn gebruikers omdat hij niet weet hoe SSL werkt?

[Orion84]

Als jij niet weet (en niet in staat bent uit te zoeken) hoe je een SSL certificaat moet regelen en installeren dan heb ik inderdaad mijn serieuze twijfels of je wel in staat bent om de webserver en forumsoftware fatsoenlijk te beheren (incl. benodigde beveiliging). Het is ook weer geen rocket science of zo hè.

En anders zijn er volgens mij legio mogelijkheden om gebruik te maken van een dienst waarbij dergelijke zaken je (deels) uit handen genomen wordt.

[MrFax]

Maar is het ook echt nodig om forum software zonder gevoelige gegevens te beveiligen?

De enige reden waarom de meeste mensen niet weten hoe ze het moeten installeren is omdat als je er naar google'd je websites vind waar je er een vermogen voor betaald, terwijl veel open source of gratis software daar helemaal geen geld voor heeft. Dit is hier dus de oplossing voor.

[Reactie gewijzigd door MrFax op 23 juli 2024 06:16]

[Orion84]

Als je het niet nodig vindt om het te beveiligen, waarom dan die wens om SSL toe te passen?

[GNID]

Het grote verschil zit 'm er in dat die aanvraag gedaan wordt op basis van het ACME protocol (zie onderaan artikel). In essentie doet dit weinig anders dan het aanvraagproces van je CA-certificaat automatiseren (secondenwerk).

Waar je op dit moment - afhankelijk van de partij waar je het certificaat aanvraagt - een bestand op je webserver plaatst, een DNS-record aanmaakt, kopie paspoort opstuurt of anderszins om te bewijzen dat jij de eigenaar van het domein bent, handelt de ACME client hier de challenge/response af. Je krijgt dus een normaal Domain Validated certificaat. Tenminste ... als de ACME server (de certificeringsinstantie, dus) dit goedkeurt. Er wordt bv gecontroleerd of je domein op een blacklist staat.
Diezelfde ACME client kan overigens ook onderstuenen bij refresh of revoke van het certificaat

Het ACME protocol vereist aan jouw kant dus een client, die de juiste responses geeft. De volgende webservers wordfen op dit moment ondersteeud:

apache/2.x (tested and working on Ubuntu Linux)
nginx/0.8.48+ (tested and mostly working on Ubuntu Linux)
standalone (runs its own webserver to prove you control the domain)


Filmpje (vanuit clientperspectief): https://www.youtube.com/watch?v=Gas_sSB-5SU
Tekst: https://github.com/letsen...ster/draft-barnes-acme.md
Erg helder uiteengezet; inclusief onderkende aanvalsvectoren. Ik weet niet of dit de laatste versie van dit document is (want draft), maar het geeft iig een beeld.

[i-chat]

selfsigned certs ik snap echt niet hoe een weldenkende tweaker hier voorstander van kan zijn op het internet...

je krijgt dan als bezoeker 'er is een probleem met het cert maar als u "HIER" klik kunt u gewoon die leuke site bezoeken... en gebruikers zien het risco niet...

morgen echter is het niet jouw persoonlijke weblog, of je torrent site-je maar een fake rabobank site, en wat denk je dat ze doen bij een ssl error.???

selfsigned en ssl waarschuwingen daar zou je NOOIT maar dan ook ECHT NOOIT mee om mogen gaan op de manier die jij nu aanbeveelt dat is vragen om ongelukken.

in dat opzicht gaat dit ook over encriptie en niet over validate, je forumpje met phpbb heeft genieg aan slechts encriptie zodat een wifi sniffer bij de mac je wachtwoorden niet achterhaald. bovendien - met die grone balk is er al genoeg onderscheid tussen 'je bank' en de rest van het www.

[Orion84]

Ho, wacht, ik beveel nergens aan om self-signed certs te gebruiken op het internet. Ik gaf alleen aan dat het (voordat ik de ACME specs gelezen had) maar weinig voordelen leek te hebben boven self-signed.

[kwaazaar]

StartSSL bestaat toch ook al? Ook gratis. Zij verifieren enkel of je een primair email-adres van het domein hebt, zoals info@domein of admin@domein.

[maartenv]

Ideaal, eindelijk geen vieze foutmeldingen meer naar mijn synology toe en netjes mijn wachtwoorden encrypted over de lijn!

[HKLM_]

Dit is voor een synology al lang mogelijk via start SSL

http://missilehugger.com/...secure-your-synology-nas/

[.GoO]

Kan dit ook zonder domeinnaam? In het bovenste gedeelte staat dat het ook werkt voor mydomain.synology.me maar daaronder staat dat je eigenaar moet zijn van het toplevel domein.

[tijnvw]

Ik maak ook gebruik van StartSSL voor mijn Synology NAS (zie hier voor een duidelijk installatie-instructie), werkt uitstekend maar vergt inderdaad een eigen domeinnaam en is wel wat gedoe om te installeren. Ben er de eerste keer zeker een aantal uur mee bezig geweest.

Als dit makkelijker gemaakt zou kunnen worden door Let's Encrypt, sta ik vooraan in de rij!

[Yggdrasil]

Daarvoor kun je al jaren gratis terecht bij https://www.startssl.com/.

De kracht achter Let's Encrypt zit hem juist in de tooling die er omheen wordt gebouwd waardoor de aanvraag én installatie volledig automatisch kan plaatsvinden.

Gezien de snelheid waarmee Synology nieuwe features toevoegt aan hun OS, verwacht ik dat ze wel ondersteuning voor Let's Encrypt zullen inbouwen zodat je met één druk op de knop een 'echt' certificaat krijgt.

[henkjobse]

Let op: startssl is alleen voor non-commercieel gebruik, dus als je zelf een commerciele website hebt (ook al is deze nog zo klein), is startssl geen optie.

[The Zep Man]

Let op: startssl is alleen voor non-commercieel gebruik, dus als je zelf een commerciele website hebt (ook al is deze nog zo klein), is startssl geen optie.

Dat staat weliswaar in de voorwaarden, maar wordt dat ook gehandhaafd?

Ja, StartSSL certificaten zijn alleen 'domain control validated'. Als je dat niveau echter al bereikt hebt, dan ben je al binnen. Buiten een paar achterdochtige tweakers zal er niemand zijn die daadwerkelijk de waardes van het certificaat controleert om te kijken of een certificaat van https://www.jansen.domeinextensie daadwerkelijk uitgegeven is aan Jansen en niet aan iemand anders.

De gemiddelde gebruiker (de massa) kijkt niet naar een groen balkje of aan wie een certificaat is uitgegeven. Als de workflow maar niet wordt verstoord door een certificaatfoutmelding is alles goed.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 06:16]

[Qlusivenl]

Voor 10 euro heb je al een ssl certi.. voor een jaar. Daar kan je ook niet wakker van liggen..

[Verwijderd]

Hoezo? Dat is nog 2x zo duur dan de domeinnaam zelf. Niet leuk als je tientallen (of meer) domeinnamen hebt.

[klakkie.57th]

mijn huidige DNS provider http://www.eurodns.com levert volgens mij een SSL certificaat bij ieder nieuw domein.

[Verwijderd]

Is dat niet alleen 1 exemplaar voor je eerste domeinnaam? Zie https://www.eurodns.com/ssl-certificate-comparison/

Qua domeinnamen zijn ze wel weer duur: $19.67 voor een .nl domeinnaam.

Het hostingpakket van 16 dollar per maand is dan wel weer lekker geprijsd, voor "Web hosting with unlimited traffic and storage" maar ja, wat is unlimited precies? Meestal zitten daar toch ook quota op, niet geheel onterecht natuurlijk.

[Verwijderd]

Kan al vanaf 3,99 zelfs

[GH45T]

Tientje voor een certificaat, paar tientjes voor een domein, stroom voor- en afschrijving van je NAS. Zo wordt je "private cloud" opeens toch aardig duur. Ik heb zelf ook een Synology en ben ook blij met het initiatief omdat ik graag een geldig certificaat heb maar ben ook niet bereid om hier voor thuisgebruik voor te betalen.

[CAPSLOCK2000]

Voor thuisgebruik kun je ook je eigen CA opzetten. Het kost wat moeite maar voor Tweakers is het best te doen.

[neokarasu]

Paar tientjes voor een domein? Vraag me toch af waar je die dan vastlegt? Want dat is erg overpriced/overdreven. Maakt je redenatie qua kosten al weer zwakker.

Reëel gezien kom je opgeteld niet eens zo duur uit.

[Reactie gewijzigd door neokarasu op 23 juli 2024 06:16]

[Dark Angel 58]

elke jaar, nietwaar?

[wrdmarco]

www.startssl.com en je hebt hem gratis

[Eloy]

Nouja, dan moet je NAS wel een unieke hostname hebben (wereldwijd uniek)

[teek2]

Hij heeft natuurlijk een uniek ip-adres wat genoeg is.

[.oisyn]

Er zitten nogal wat restricties aan certificaten op IP-adressen. Over het algemeen wordt er vereist dat je volgens de RIPE database eigenaar bent van het ip-adres. Dergelijke certificaten zijn vaak ook alleen te verkrijgen in duurdere organizational certificates. Voor de meeste thuisgebruikers gaat dit simpelweg niet op, en is een gratis certificaat van StartSSL op een eigen domeinnaam voldoende. Maar je hebt dan dus wel een domeinnaam nodig.

[teek2]

Het gaat erom dat "een unieke hostnaam nodig hebben", nergens op slaat. Een hostnaam kies je zelf en je bent vrij hem te kiezen zoals je zelf wilt. Domeinnamen zijn altijd uniek. Dus ik snap de +1 niet, blijkbaar zijn er veel mensen die niet snappen wat er nodig is om je NAS online te hebben. Je kunt overigens ook gewoon naar je IP adres surfen een domeinnaam is alleen makkelijker te onthouden en nodig voor een certificaat (welke IP adres en hostnaam onafhankelijk is). Gratis domeinnamen kun je trouwens hier halen: http://nl.eu.org/

[.oisyn]

Het gaat erom dat "een unieke hostnaam nodig hebben", nergens op slaat

Mijn nas heet gewoon "nas" op mijn lokale netwerk. Nou heb ik een self signed certificate die ik installeer op mijn devices, maar niet alle devices ondersteunen dat.

blijkbaar zijn er veel mensen die niet snappen wat er nodig is om je NAS online te hebben

Voor dingen als Synology QuickConnect (MyDS) heb je geen IP-adres of hostname nodig.

Je kunt overigens ook gewoon naar je IP adres surfen

Volgens mij is er niemand hier die dat niet weet. De discussie ging om certificaten, en zoals ik net al uitlegde ligt een certificaat op IP-adres niet echt bepaald binnen handbereik voor de gemiddelde thuisgebruiker.

Gratis domeinnamen kun je trouwens hier halen: http://nl.eu.org/

Ik vraag me af of je ergens een certificaat voor een multilevel subdomein kunt registreren terwijl je het hoofddomein niet managed.

[ASS-Ware]

Voor dingen als Synology QuickConnect (MyDS) heb je geen IP-adres of hostname nodig.

Oh zeker wel.
Bij het maken van het QuickID geef je een hostname op waaronder je NAS bereikbaar moet zijn.

[.oisyn]

Nonsens

quote: http://blog.synology.com/?p=2283

1) Registration
When enabling the QuickConnect service, your DiskStation sends out a request to one of our relay sites (2 servers, one in the UK, one in America), and provides its internal and external IP addresses. The relay site stores this information for as long as the QuickConnect ID is valid.

2) Connection
Let’s say you’re on your way to a business trip, and want to go over your presentation slides on the way… and you use DS cloud to access them.

Upon connecting within the network, the app starts by checking the internal IP associated with the QuickConnect ID, and directly establishes the connection with your DiskStation. You can browse and open files, on your phone, directly from the Synology via the router.

However, things get interesting if you leave home, and your phone connection changes over to your 3G network:

3) Auto-switch
When DS cloud now no longer detects your DiskStation within the local network, it sends out a request to the relay server requesting a connection, in turn sending a notification to the DiskStation that a connection needs to be re-established. The DiskStation then initiates a connection with the relay site: your slides are then accessible on your phone via the relay. And if the data is quite critical, the communication can be protected by SSL.

4) Port forwarding?
All this sounds rather neat and easy, but might leave you with two questions, namely which ports are used, and how does QuickConnect get away with port forwarding when you spent a long afternoon learning how to do this?

The ports remain the same as those used by the application by default: in the case of DS cloud, it’s 6690.

As for port forwarding, it simply doesn’t happen: QuickConnect leverages the fact that outbound signals aren’t blocked by most routers. And that’s also why all throughout the process above, the DiskStation initiates the connections with the relay site, pushing data straight through the router.

Ik heb mijn hostname nooit hoeven opgeven. Is ook helemaal niet nodig voor bovenstaande procedure, want de relay server weet het externe ip-adres van de NAS. Je hoeft, zoals je kunt lezen, feitelijk ook helemaal geen ports te forwarden.

[ASS-Ware]

Nonsens

Geen nonsens, je QuickConnect ID is je hostname.

[.oisyn]

Daarnet zei je nog "bij het maken van QuickID geef je een hostname op". Nu zeg je ineens dat je QuickID je hostname is . Ook dat laatste klopt overigens niet. De hostname van mijn nas is gewoon "nas". Ik heb wel een QuickConnectID, en via <id>.quickconnect.to kun je 'm bereiken, maar je moet je beseffen dat je niet direct met je NAS praat dan maar met een relay server van Synology. Dit hele verhaal heeft bovendien weinig met certificates te maken - de relay server serveert zijn eigen certificate.

Inderdaad, via de webinterface van de relay server van Synology kan ik bij mijn nas, maar dat QuickConnectID is absoluut niet de hostname van mijn nas.

[Reactie gewijzigd door .oisyn op 23 juli 2024 06:16]

[DaaNMageDDoN]

Goed opgemerkt, scroll een stukje naar boven en er staat nog zo'n heerlijke verwarring van ".GoO ":

"Kan dit ook zonder domeinnaam? In het bovenste gedeelte staat dat het ook werkt voor mydomain.synology.me maar daaronder staat dat je eigenaar moet zijn van het toplevel domein."

TLD....juist ja dat is .me (dot-me).
En ook daar een +1...zucht.
Disclaimer: ik kan die quote waarschijnlijk netter maken, maar ben te lui om uit te zoeken hoe dat te doen terwijl ik op teek2 wil reageren.

[ASS-Ware]

Nouja, dan moet je NAS wel een unieke hostname hebben (wereldwijd uniek)

Eh, nee, de hele DNS entry moet uniek zijn.
Kijk naar naar www, dat bestaat in vele domeinnamen :-)

[Verwijderd]

Dat kan al bij startSSL

[TVH7]

Het is nu al mogelijk om een gratis SSL certificaat te bemachtigen. Dit kan je doen bij https://www.startssl.com/.
De enige reden waarom SSL certificaten zo duur zijn is puur vanwege de verzekering die erachter zit.

[Dorank]

Naast het genoemde startssl is er ook nog cacert.org, een CA op basis van een Web of Trust. Nadeel is dat de cacert.org CA niet als trusted CA wordt mee geleverd bij de CA bundels van de diverse OSen/applicaties.

[MadEgg]

En dus compleet waardeloos aangezien elke gebruiker de waarschuwing als foutmelding interpreteert en dus sites met een dergelijk certificaat nooit zal kunnen bezoeken. En je gaat gebruikers natuurlijk ook niet vragen om een custom CA-certificaat te installeren zodat het wel werkt...

[Dorank]

Waarom niet? Let's encrypt is niet anders::

We will issue the first end entity certificates under our root under tightly controlled circumstances. No cross-signature will be in place yet, so the certificates will not validate unless our root is installed in client software.

Waarom zou een normale gebruiker uberhaupt zomaar CAs moeten accepteren? Het is al jaren duidelijk dat het CA gebeuren volkomen brak is, iedere CA kan ongecontroleerd certificaten signen voor willekeurige toepassingen (rogue certificates).

[Belgar]

Als je verder leest is dat alleen tijdens de testfase tussen juli en september. In September wordt alles ge-crosssigned en werkt het gewoon in Chrome, IE, firefox, etc.

[MadEgg]

Helemaal mee eens, het CA-systeem is brak en gebaseerd op commercie en niet op veiligheid. Echter, als webmaster heb je daar geen boodschap aan, dan wil je simpelweg dat bezoekers jouw website kunnen bezoeken via HTTPS zonder dat ze om de oren geslagen worden met allerlei veiligheidswaarschuwingen.

Als Let's Encrypt ook vereist dat je zelf een certificaat installeert dan is het ook niet zo zinvol. Uit Belgar's reactie begrijp ik echter dat dit slechts tijdelijk is en dat ze op niet al te lange termijn in principe door browsers standaard geaccepteerd zullen worde.

[WhatsappHack]

Helemaal mee eens, het CA-systeem is brak en gebaseerd op commercie en niet op veiligheid.

Ik zie nu twee mensen hier die dat roepen, zonder ook maar enige redelijk argumentatie: en zonder een logisch alternatief dat werkelijk zou gaan werken.

Wat is er zo brak aan?
Je hebt een SSL certificaatje voor de prijs van een happy meal, of zelfs geheel gratis via oa voornoemde startSSL; wat ook gewoon een trusted CA is.
Dat commercieel valt me heel erg mee.

Ik zou dus toch graag de argumentatie horen en een oplossing hoe het dan *wel* zou moeten.
CA's vormen een fundamentele schakel in het hele certificaten riedeltje, en is een enorm logische opzet om bepaalde problemen inherent aan het systeem te overkomen zodat er vertrouwen wordt gecreeerd.

Hoe moet dat dan zonder CA?
Roepen dat het brak is, houdt meestal in dat er dus kennelijk een betere oplossing moet zijn. Wat is die oplossing dan?

[MadEgg]

Zoals ik al meermalen heb aangegeven, encryptie kan prima ZONDER certificaat. Gewoon met een public/private keypair. Zo gebeurt dat bij SSL ook, alleen is dan een certificaat verplicht. Dat laatste, dat zou anders kunnen.

We hebben het hier ook al over gehad elders bij dit nieuwsbericht. Een encrypted verbinding is altijd beter dan een unencrypted verbinding. Echter, browsers lijken de voorkeur te geven aan unencrypted websites, en dat is de het grote probleem. Ja, dat is een probleem wat voorkomt aan de implementatie van browsers en niet inherent aan het CA-systeem, echter, dit is wel welke kant het, onder andere dankzij CA's, naartoe gedrukt is.

De validatie van certificaten is alleen dan relevant wanneer het van groot belang is dat jij exact met wie jij versleuteld communiceert. Dit impliceert dus dat je de andere partij ook daadwerkelijk kent en vertrouwd. Dit gaat voor de meeste encrypted verbindingen niet op. Een https-verbinding met Google bijvoorbeeld, ik ken die mensen heel niet. Een self-signed certificaat zou dus prima voldoen. Het voorkomt nog steeds dat als ik in een internetcafé zit mijn mede-gebruikers mijn zoekopdrachten kunnen opsnuiven. Nee, het voorkomt dan niet dat de eigenaar van het internetcafé de DNS-response voor google aanpast en er een proxy tussenzet, maar het beperkt het aantal schakels wat je moet vertrouwen enorm.

Verder is het systeem van CA's ook nog brak dankzij de geweldige vernieuwing OCSP, waardoor je privacy weer volledig te grabbel wordt gegooid, via de standaardinstelling in elke browser. Hierbij is het juist nadelig voor je privacy als je sites met een CA-gesigneerd certificaat bezoekt aangezien je browser dan vrolijk je browse-gegevens naar de CA doorstuurt, waar zij natuurlijk geen bal mee te maken hebben. OCSP Stapling is hier dan weer een pleister voor maar zo lang dat niet verplicht is en een standaard fallback heeft naar OCSP lost dat het probleem niet op omdat het maar mondjesmaat toegepast wordt.

Een ideale oplossing is de setup van DNSSEC: publiceer de public keys van je webservers via DNS, ondertekend mbv van DNSSEC, en je bent klaar. Geen MITM meer mogelijk aangezien je browser de keys van de TLD's heeft en dus de hele chain kan controleren.

[Reactie gewijzigd door MadEgg op 23 juli 2024 06:16]

[WhatsappHack]

Zoals ik al meermalen heb aangegeven, encryptie kan prima ZONDER certificaat.

Dat ontken ik ook niet, en dat snap ik.
Maar enkel encryptie is niet het enige belangrijke.

Zoals ik al meermalen heb aangegeven, encryptie kan prima ZONDER certificaat. Gewoon met een public/private keypair. Zo gebeurt dat bij SSL ook, alleen is dan een certificaat verplicht. Dat laatste, dat zou anders kunnen.

Maar hoe dan?

Een encrypted verbinding is altijd beter dan een unencrypted verbinding

Mwah, ik snap het punt wel "het is in ieder geval encrypt"; maar dat is niet het enige dat belangrijk is.
En leuk dat het encrypt is, maar als je niet eens zeker weet of het certificaat wel te vertrouwen is en wel toebehoort aan de persoon/server met wie je wil babbelen: dan heb je toch geen garanties en kan je niets controleren? Waarom zou je dan zomaar je data overpompen...?

En daar komen we aan bij het volgende punt:

De validatie van certificaten is alleen dan relevant wanneer het van groot belang is dat jij exact met wie jij versleuteld communiceert.

Het is altijd enorm van belang. (Nouja, misschien niet op "localhost"; maar dat zijn weer van die uitzondering.)
Je wilt toch altijd weten of je wel versleuteld communiceert met wie jij wilt communiceren, en niet bijvoorbeeld met sjaakie die gezellig in 't midden is gaan zitten?? Iemand anders had 't net over de NSA; hoe controleer je of dat self-signed certificaatje dan niet door hen in 't midden er tussen is geknikkerd? Dat gaat een beetje lastig zonder CA.

1.) De CA is de partij die trusted is om te controleren of een certificaat klopt, waar moet zonder hen die controle dan uitgevoerd worden...?
2.) Je kan een self-signed certificaat wel handmatig accepteren, maar hoe weet je bij de initiele exchange dan of het wel te vertrouwen is; en dat de public key correct is?

Wat is er zo veilig aan een self-signed encrypted verbinding, als je het certificaat niet eens kan controleren?
Jaja, I know: het encrypt het verkeer; en voor lokale beveiliging is dat allemaal leuk en aardig; maar je weet nog steeds niet zeker met wie je nou eigenlijk aan 't praten bent... Dus welke garantie heb je dan? Wil je dat handmatig gaan doen, dan heb je nogal een usability probleem.

Een fundamenteel onderdeel van SSL is het kunnen vertrouwen van de verbinding. Bij self-signed is dat gewoon niet het geval.
En derhalve spuugt je browser een error uit. En ja, ik ben 't helemaal eens dat HTTP verkeer een zelfde waarschuwing moet weergeven (rood open slotje oid); maar dat is eigenlijk weer een ander probleem dat weinig te maken heeft met de CA opzet.
Om SSL te kunnen vertrouwen moet die derde partij er aan te pas komen, zo simpel is het. Zo is het gebouwd... En dat is een erg slimme opzet.

Dit impliceert dus dat je de andere partij ook daadwerkelijk kent en vertrouwd.

Absoluut niet. Het stelt enkel dat het SSL certificaat en de uitgewisselde key valide is.
Dat zegt helemaal *niets* over de betrouwbaarheid van de partij met wie je communiceert. (Alhoewel als het OV of EV is, dan weet je in ieder geval wel dat er veel moeite en geld in gepompt is.)

Dat een mailtje met de link "https://rabobank-login-herstellen.nl/login.php" egt dat ik dit heel snel moet inloggen, met een prachtig SSL certificaatje, betekend niet dat ik hen ken, betekend niet dat ik hen vertrouw, en het impliceert niets. (Trouwens, rabobank.nl zelf ken ik ook niet; ik weet niet wie die servers beheren, ik ken de bankiers niet, et cetera.)
Het enige dat de controle oplevert is dat je communiceert met wie jij wil communiceren (in dit geval een phising link ). Dat zegt dus wel dat het certificaat valide is en dat jij dus babbelt met wie je wilde bereiken; maar het garandeert op geen enkele wijze dat de partij met wie je babbelt te vertrouwen valt, je data goed behandeld, et cetera.
Natuurlijk kan je daar bij veel partijen wel vanuit gaan (eg: bank.); maar het SSL zelf wordt daar niet per definitie voor ingezet: die zorgt enkel voor de authenticatie/integrity en encryptie. De inhoud van de communicatie en wat er verder met die data gedaan wordt is je eigen probleem; doch bij legitieme en bekende sites is dat vertrouwen meestal niet misplaatst en kun je veilig je gang gaan.

Deze controle is derhalve belangrijk bij alle SSL verbindingen zodat je gewoon weet of een certificaat wel te vertrouwen is.
En als dat niet met zekerheid gesteld kan worden (self-signed): dan kan er niets anders gedaan worden dan een foutmelding te geven.
Anders kan je net zo goed alles self-signed maken, als er toch geen controle plaatsvindt en nooit foutmeldingen worden gegeven. Dat ondermijnt het hele systeem, en dan wordt een trust creeeren een behoorlijk opgave.

Ik bedoel, jij zegt bijvoorbeeld:

De validatie van certificaten is alleen dan relevant wanneer het van groot belang is dat jij exact met wie jij versleuteld communiceert

Maar hoe moet een CA, of het HTTPS protocol an sich, weten wanneer het wel en wanneer het niet van groot belang is dat je het weet...? En wie bepaalt dat eigenlijk...? De een vind bankzaken belangrijk, de ander boeit het niet. (Oei.) En de een wil zelfs met zekerheid encrypt hebben als hij/zij een post schrijft dat hij/zij vandaag een wolkje in de lucht zag! ... Ongeacht dat dit totaal niet naar die persoon te herleiden valt en er *altijd* wolken in de lucht zijn: totaal niet boeiende of gevoelige info dus.

Dus, wie bepaalt (voor ons...) wat dan wel en niet van belang is?
Moet ik dan zelf aan gaan geven wat ik wel of niet belangrijk vind? Of per keer aangeven of ik dit keer wel of niet het certificaat wil laten toetsen? Dat is niet erg user-friendly; en ook nogal een beveiligingsprobleempje...
Of mogen opeens enkel banken bijvoorbeeld een getoetst certificaat aanvragen, en andere mensen niet? Hoe zit dat?

Derhalve wordt het voor het gemak en de veiligheid altijd gecontroleerd, en dat is maar goed ook.

Dit gaat voor de meeste encrypted verbindingen niet op.

Precies, maar niet vanwege de reden die je hier boven als argumentatie geeft.

Een https-verbinding met Google bijvoorbeeld, ik ken die mensen heel niet. Een self-signed certificaat zou dus prima voldoen.

Neen, want dan weet je dus niet of je wel werkelijk encrypt met Google communiceert...
Het hele punt van CA is als derde partij op te treden zodat gevalideerd kan worden of de sleutels wel in orde zijn en het certificaat (nog) geldig is.
Het zegt niets over het wel of niet kunnen vertrouwen van de partij an sich.

Dat een site een valide SSL heeft, betekend niet dat je daarom maar zomaar je login gegevens moet overknallen oid.
Ik zie dus niet in hoe het relevant is dat jij de site die je bezoekt vertrouwt, daar gaat dat hele CA systeem totaal niet over.
Het gaat er enkel om of het certificaat en de sleutels te vertrouwen zijn; en adh daarvan kan je dus wel zeker weten dat het SSL certificaat inderdaad toebehoort aan de gene met wie jij wenst te communiceren; en derhalve heb je een valide certificaat die gevalideerd wordt door de externe third-party: de CA.

Als ik Google.com wil openen, wil ik wel zeker weten dat ik ook echt met Google.com aan het babbelen ben en dat de sleutels valide zijn.
Ik wil geen self-signed certificaat. Ik zie liever eigenlijk nergens, behalve kleine miniscule onderdelen binnen eigen infra en test omgevingen, self-signed certificaten.

De CA's zijn belangrijk, en het is een mooi systeem. Vind ik.

Het voorkomt nog steeds dat als ik in een internetcafé zit mijn mede-gebruikers mijn zoekopdrachten kunnen opsnuiven

Ja, dat doet het; maar je weet nog steeds niet zeker of je wel werkelijk met een valide SSL zit te werken die bewezen eigendom is van die partij...
Je kan niet zomaar het SSL vertrouwen. (Ja, dat kan bij HTTP verkeer ook niet; maar daar gaat het niet om. Dat is gewoon een tweede probleem, dat maakt het eerste probleem niet ongeldig. )

CA's spelen een erg belangrijke en waardevolle rol. Nee, het is niet waterdicht; maar er is eigenlijk nog niemand met een *echt* goed alternatief gekomen; dat ook nog adapted is.
Het grootste probleem is eigenlijk dat er veels teveel CA's zijn, trouwens.

Een ideale oplossing is de setup van DNSSEC: publiceer de public keys van je webservers via DNS, ondertekend mbv van DNSSEC, en je bent klaar. Geen MITM meer mogelijk aangezien je browser de keys van de TLD's heeft en dus de hele chain kan controleren.

Nee, absoluuuuuuut niet.
Bij DNSSEC vertrouw je op:
- De beheerder van de TLD's (in sommige gevallen zijn dat grappig genoeg ook de CA's ) *kuch*verisign*kuch*
- ICANN, SIDN, etc.
- Je registrar
- De beheerder van de DNS server

Je kan ook moeilijk een complete domeinextensie "untrusten". Bij een CA kan je tenminste nog de CA uit je browser donderen. Dat wordt knap lastig bij domeinnamen.
DNSSEC gaat hem niet worden.

Het enige wat wellicht enigszins boeiend is, is dit concept:
http://convergence.io/

[Reactie gewijzigd door WhatsappHack op 23 juli 2024 06:16]

[i-chat]

het hele punt is hier nu juist dat het cert systeem zoiets dat een achterlijke partijtje windows 95 servers, vervalste certs kan uitgeven voor iemand die niet eens klant bij ze is, google, mircosoft apple facebook etc.

dat hebben we een paar jaar geleden wel gezien, en na dat incident is/zijn er 1 of nuja enkele ca's geblocked maar zijn er tot op de dat van vandaag geen voorstellen om het hele systeem dusdanig op de schop te gooien en te zorgen dat malafide ca's dit soort dingen niet eens kunnen.

dat hele EV gedoe is dus een ongelofelijke wassen neus, en ik wed dat die 'vergoedingen' die ze beloven als er schade door ontstaat, ook zelden of nooit daadwerkelijk worden uitgekeerd.

en dan is er nog het punt dat deze commerciele graaiers er voor hebben gezorgt dat normaal internet niet versleuteld word verzonden, dat websites als tweakers.net in beginsel jaren lang onversleuteld zijn gebleven wanneer je inlogd op hun forum, er zijn letterlijk honderden forums waar ik wel eens ben ingelogd die geen gebruik maakte van ssl.. iets dat behoorlijk pijnlijk is. want ssl is van nature iets heel anders dan cacert, en die koppeling riekt naar oneerlijke koppelverkoop.

[MegaCookie]

Dit is toch helemaal niet nieuw? Ik heb al jaren een gratis SSL-certificaat van StartSSL. Werkt prima. Alleen voor niet-commercieel gebruik, dat wel. Voor de rest worden de SSL-certificaten ook steeds goedkoper, maar dit lijkt mij verder wel een goed initiatief. Ik hoop vooral dat dit makkelijker werkt dan StartSSL, want dat kan best omslachtig zijn.

[Jaap-Jan]

En bij StartSSL kan ik geen extra certificaten aanvragen voor subdomeinen, waardoor ik alle losse webapps (owncloud, mail, CMS) in losse directories moet serveren, in plaats van ze een losse domeinnaam te kunnen geven.

[MegaCookie]

Ik kan prima extra SSL-certificaten voor mijn subdomeinen aanvragen. Alleen moet dit één voor één en je werkt uiteindelijk met meerdere certificaten. Een makkelijke oplossing is het Wildcard-certificaat, alleen kost dat bij StartSSL ook extra geld.

[mgizmo]

Kan wel, kost je alleen een registratie aan jaarlijkse kosten. Niet per certificaat. Sterker nog je kunt gewoon een wildcard aanvragen.

[Jaap-Jan]

En straks hoef je daar dus ook geen geld meer voor te betalen.

[CyBeR]

Jawel, want Let's Encrypt gaat (iig in de eerste instantie) geen wildcard-certificaten uitgeven. Ik hoop dat ze daarop terug komen want niet in alle gevallen weet ik van tevoren m'n hostnames en dan zijn wildcards wel fijn.

[MadEgg]

Ik heb er gewoon 10 voor dezelfde domeinnaam bij StartSSL. Je kunt bij elk certificaat één subdomein opgeven, en daar wordt automatisch het domein zonder subdomein aan toegevoegd. mijndomein.nl kan ik dus met 10 domeinen serveren en elk subdomein heeft zijn eigen certificaat. Werkt prima, en aangezien ik toch al een vhost heb voor elk subdomein is het ook geen extra werk.

[eijckron]

Heb je ook 10 ip adressen of heb je https + name based vhosts werkende?
Als dat laatste het geval is hoor ik graag hoe je dit instelt.

[MadEgg]

Name-based vhosts is erg eenvoudig in Apache (ongetwijfeld ook in nginx of lighttpd, maar daar heb ik geen ervaring mee). In je diverse HTTPS VirtualHost secties (/etc/apache2/sites-enabled/mijndomein.vhost oid) voeg je de regel

ServerName <mijn.domennaam.nl>

toe et voíla, het werkt. Eventueel kun je in /etc/conf-enabled/ssl.conf ook nog SSLStrictSNIVHostCheck aanzetten om alleen SNI-capable hosts te bedienen.

De tijd van 1 IP per HTTPS-host is gelukkig al lang voorbij

[eborn]

Nu XP inderdaad niet meer officieel ondersteund wordt wel. Maar voor die tijd kon je SNI toch nog niet overal voor inzetten. Op dit moment zit je nog met oude Androids (de 2.x versies). De andere browsers zonder ondersteuning zijn eigenlijk niet meer het ondersteunen waard.

[MadEgg]

Al ruim voor EOL geen probleem. IE7 en hoger ondersteunen SNI Ondersteuning voor IE6 ben ik al heel lang geleden mee gestopt, waardeloze antieke technologie. Hetzelfde geldt voor Android 2.

[eborn]

SNI heeft ongeacht de IE versie op Windows XP nooit gewerkt:
http://blogs.msdn.com/b/i...rver-name-indication.aspx

SNI ondersteuning is pas in Vista geïntroduceerd.

[GH45T]

Werkt het nu prima of omslachtig? Want ik ben ook eens bij StartSSL bezig geweest maar die website werkte toen niet goed op mijn computer (Opera met Adblock en Ghostery) en volgens mij daardoor, is het mij niet gelukt om een certificaat aan te maken. Echter, je mailadres en/of domein wat je wil beveiligen is dan bekend en een nieuwe aanvraag was niet meer mogelijk. Helaas pindakaas dus.

Dat er gegevens vastgelegd moeten worden is helder, maar ik denk dat het zaak is om de aanvraag van een certificaat zo user-friendly mogelijk te maken. Op het installeren van een certificaat en het aanmaken van de CSR heeft de CA natuurlijk weinig invloed maar dat is dan aan de beheerder om dit te bevatten.

[MegaCookie]

Ik bedoelde dat het voor mij prima werkt, alleen ik kan mij voorstellen dat het voor nieuwe gebruikers wel moeilijk te installeren en onderhouden is. Het is niet even klik en er verchijnt een certificaat in je download folder, die je moet uploaden in een bepaalde SSL folder op je server. Nee het vereist best even wat werk om je website te valideren, je SSL-certificaat te genereren en je certificaat te installeren.

[Reactie gewijzigd door MegaCookie op 23 juli 2024 06:16]

[Verwijderd]

Precies, en dat is wat er mogelijk aan deze dienst mankeert.
Als het alsnog een omslachtig proces is, dan vragen alsnog weinig mensen een certificaat aan, of zijn ze alsnog veel geld kwijt omdat een 3e partij het voor hen gaat doen tegen betaling.

[Verwijderd]

Zeer goede zaak, ik hoop dat veel websites hierdoor eindelijk op https overgaan.

Voor mensen die zich niet realiseren waarom dit belangrijk is, ook voor sites waar geen bankgeheimen of betalingsverkeer mee gemoeid is: dit artikeltje vat het aardig samen.

[WhatsappHack]

Toch ben ik er niet van overtuigd dat SSL overal noodzakelijk is.
Net als hier op Tweakers op het gedeelte waar je de, publiek leesbare, nieuwsartikelen leest: wat moet je daar met SSL? Het enige dat het doet is overhead toevoegen.

Een publiek beschikbaar blogje van iemand over zijn/haar reis in toekietoekie land: ook niet echt boeiend om SSL te gebruiken.

Natuurlijk wordt het een ander verhaal als het bijvoorbeeld een familie fotoalbum is dat achter slot & grendel staat. Ook daar zal 't waarschijnlijk niet echt een ramp zijn als die foto's onderschept zouden worden, maar "liever niet natuurlijk, want is gewoon prive". Daar is SSL wel weer handig voor net dat beetje extra zekerheid, doch wellicht enigszins overkill... Maar als 't gratis wordt: waarom niet, inderdaad.

Maar "overal SSL", dat concept heb ik een paar keer voorbij zien komen; maar zie nog steeds 't praktisch nut er niet van in. En dat terwijl ik behoorlijk (zeer) para ben mbt beveiliging en gegevensbescherming.

[Verwijderd]

Het voorkomt ook dat inlichtingendiensten maar onbeperkt kunnen doorhaan met hun "sleepnet datamining" en alles en iedereen loggen en monitoren.

Het gaat ze gewoon geen reet aan wat ik lees, met wie ik communiceer, welke pagina's ik bezoek of wat voor foto's ik bekijk. Dat een derde überhaupt bij mijn traffic kan is in de basis al verkeerd.

Daarnaast heeft de overheid niet bepaald een solide track record m.b.t. dataveiligheid, dus zolang ze dit soort gegevens massaal kunnen blijven harvesten is het nog steeds een kwestie van tijd voordat al die troep een keer in handen van derden komt.

En wat nu volkomen onbelangrijk, onschadelijk of onbelastend kan lijken, is dat misschien over 5-10 jaar niet meer. Niemand weet wat voor veranderingen er in de markt of op het politieke toneel gaan plaatsvinden. Wat nu als je verzekeringsmaatschappij je premie opschroeft omdat je sites over wintersport hebt bezocht? Om maar een lukraak voorbeeldje te noemen (het kan nog veel erger natuurlijk).

[WhatsappHack]

Het voorkomt ook dat inlichtingendiensten maar onbeperkt kunnen doorhaan met hun "sleepnet datamining" en alles en iedereen loggen en monitoren.

Niet echt, ook met SSL wordt er nog een schat aan informatie vrijgegeven.
Als jij naar "howtobombthewhitehouse.com" (hoi NSA!) gaat die een eigen SSL heeft, dan wordt dit allemaal prima voor de TLS handshake getoond.
Het IP (source & destination) en de server hostnaam worden sowieso bekend.

Iedereen loggen en monitoren is dus nog altijd tot zekere hoogte mogelijk.
Het enige waar het je tegen beschermt is dat ze niet zomaar kunnen zien welke page op een site je precies bezoekt (doch zijn daar nog andere trucjes voor, zeker bij third party extensies.) of wat je als POST materiaal verstuurd. (Wachtwoord, post op een community, et cetera.)

En dan is er nog dataoverdracht plicht.

Dat een derde überhaupt bij mijn traffic kan is in de basis al verkeerd.

Welkom op het internet.

SSL is verre van de heilige graag tegen datamining en profile building.

[Reactie gewijzigd door WhatsappHack op 23 juli 2024 06:16]

[CyBeR]

[...]
Daarnaast, het certificaat wordt niet gecontroleerd; dus hoe weet jij wel zo zeker dat je niet werkelijk met de servers van de NSA aan 't babbelen bent?

Euh, wat? Dat controleren is de hele basis van het systeem.

[WhatsappHack]

Euh, wat? Dat controleren is de hele basis van het systeem.

Ahh correct, foutje. Ik was even in de war met mijn discussie met MadEgg in dit topic; waar we het hebben over self-signed certificaten.

Rijnaert de Vos heeft het daar niet over, althans: niet in dit gedeelte van het topic. (In andere comments van hem juist weer wel, hetzij deels indirect door de CA opmerkingen, en daar heb ik ook op gereageerd en daar zou het wel relevant zijn; wellicht vandaar extra verwarring omdat ik alle comments lees en dezelfde naam voorbij zag komen... Blijft in je geheugen hangen. )

Maar puntje bij paaltje:
in dit gedeelte van de discussie klopt wat ik zei inderdaad niet.
Derhalve heb ik die passage even uit m'n reactie gehaald.

Thanks!

[Reactie gewijzigd door WhatsappHack op 23 juli 2024 06:16]

[Verwijderd]

[Niet echt, ook met SSL wordt er nog een schat aan informatie vrijgegeven.
Als jij naar "howtobombthewhitehouse.com" (hoi NSA!) gaat die een eigen SSL heeft, dan wordt dit allemaal prima voor de TLS handshake getoond.
Het IP (source & destination) en de server hostnaam worden sowieso bekend.

Nope, alleen het IP. In sommige gevallen kun je daar de domeinnaam nog wel bij vinden door dns te reversen, maar da's niet heel betrouwbaar (en sowieso alleen van toepassing op ouderwetse servers die nog geen SNI supporten).
Maar de domeinnaam staat (net als de volledige uri) alleen in de http header, en die is in geval van SSL dus encrypted.

En dan is er nog dataoverdracht plicht.

Ja, good luck with that. In ieder geval geldt die plicht niet naar providers, mensen in de trein met een packetsniffer, en 99.9% van de gevallen waarvoor ik https prefereer boven http.

Welkom op het internet.

SSL is verre van de heilige graag tegen datamining en profile building.

Heilige graal zeker niet, maar het is (om talloze hierboven genoemde redenen) sowieso al een hele verbetering t.o.v. helemaal geen encryptie en alles gewoon plaintext communiceren (inclusief passwords en privéberichten, wat ook heel veel sites nog steeds doen).

[WhatsappHack]

Nope, alleen het IP. In sommige gevallen kun je daar de domeinnaam nog wel bij vinden door dns te reversen, maar da's niet heel betrouwbaar (en sowieso alleen van toepassing op ouderwetse servers die nog geen SNI supporten).
Maar de domeinnaam staat (net als de volledige uri) alleen in de http header, en die is in geval van SSL dus encrypted.

Ja, en DNS queries bestaan opeens niet meer en zijn niet te sniffen...?
Of wat dacht je van transparante proxies?
En het SSL certificaat zelf?

Ja, good luck with that. In ieder geval geldt die plicht niet naar providers, mensen in de trein met een packetsniffer, en 99.9% van de gevallen waarvoor ik https prefereer boven http.

Wel als ze een tap zetten.

Sure, encryptie biedt altijd een sterk verhoogde veiligheid tegen gluurders.
Maar het zwakt lang niet alles af.

Heilige graal zeker niet, maar het is (om talloze hierboven genoemde redenen) sowieso al een hele verbetering t.o.v. helemaal geen encryptie en alles gewoon plaintext communiceren (inclusief passwords en privéberichten, wat ook heel veel sites nog steeds doen).

Uiteraard, maar dat ontken ik ook niet.

[Fish]

mja ik betaal iets van 40 euro voor 5 jaar, te doen toch ..

[BlackMage]

Ben wel benieuwd hoe dat gaat met die enorme hoeveelheid goedkope/oude smartphones in omloop die geen updates (meer) krijgen. Die zullen vast moeite krijgen met deze nieuwe CA.

[Belgar]

De certificaten worden ge-crosssigned door identrust. die bestaat al 10 jaar

[jeffer]

Ondanks dat ik enorm voor ben van gratis versleuteling is dit nu (vooral de laatste tijd) iets waar hosting bedrijven nog wat aan kunnen verdienen. Op deze manier worden er behoorlijk wat inkomsten ontnomen aan hosting bedrijven.
Als je straks als hoster geen gratis ssl aanbied hoor je er niet meer bij maar je verdient er dan ook weer helemaal niks mee terwijl je toch werk heb aan de implementatie van alle Let's Encrypt software.

[Belgar]

Bekijk het van de andere kant: uiteindelijk gaat het erom, als je de sleutel eenmaal hebt, om twee bestanden te plaatsen en de server te verwijzen naar deze bestanden.

Je kunt nog steeds geld vragen voor de service van het aanvragen, maar elke hoster die mij nu geld zou vragen om mijn keys te installeren op mijn eigen domein kunnen het nu ook al vergeten.

[WhatsappHack]

Als hoster volstaat het om gratis SSL ondersteuning aan te bieden.
Er zijn maar een summier aantal hosts die zelf SSL certificaten aanbieden. Het blijft toch allemaal doorverkoop, so why bother; denken de meeste.

Zolang je als host SSL ondersteund op de servers, op een makkelijke manier, kan de klant zelf kiezen waar ze hun certificaat vandaan halen. Prima.
SSL's aanbieden is nu geen vereiste, en dat zal het ook niet worden als ze gratis zijn.

[tinus73]

Wie heeft er ervaring met https://buy.wosign.com/free/ ? Welke dit ook aanbied volgens het originele artikel? Je lijkt er wat meer mee te kunnen. Het is een Chinese provider. StartSSL is Israëlisch volgens mij. Qua veiligheid is er natuurlijk van beide wat te zeggen (nofi)

[Verwijderd]

Kun je met deze dienst ook certificaten aanmaken voor subdomains (*.sitenaam.nl)?

Dus abc.sitenaam.nl en dan ook xyz.sitenaam.nl?
Of moet je daarvoor dan 2 certificaten aanmaken?

[WhatsappHack]

Daar hebben ze Wildcard certificaten voor uitgevonden, het lijkt me toch wel dat ze die ook gaan aanbieden. Zo neen, dan zul je inderdaad meerdere certificaten moeten aanmaken per sub... Wat een beetje jammer zou zijn.