Let's Encrypt! Hoeveel vertrouwen hebben jullie?

[Plopeye]

Ik wil eens een topic starten om eens te peilen en vooral ook om mensen eens aan het denken te zetten.

Mijn stelling wat betreft Lets Encrypt:

Ze zijn het vertrouwen niet waard want de uitgifte bevat te weinig controle's. Er is ook al gebleken dat er SSL certificaten aan malvertising site's zijn uitgegeven. Lets Encrypt haalt in mijn ogen het hele fundament van SSL onderuit, namelijk vertrouwen...

Ik zit er aan te denken om het root certificaat van Lets Encrypt in de organisatie waar ik werk als niet vertrouwd aan te merken.

[Trucker Her]

Plopeye schreef op dinsdag 15 maart 2016 @ 13:31:
Ik wil eens een topic starten om eens te peilen en vooral ook om mensen eens aan het denken te zetten.

Mijn stelling wat betreft Lets Encrypt:

Ze zijn het vertrouwen niet waard want de uitgifte bevat te weinig controle's. Er is ook al gebleken dat er SSL certificaten aan malvertising site's zijn uitgegeven. Lets Encrypt haalt in mijn ogen het hele fundament van SSL onderuit, namelijk vertrouwen...

Ik zit er aan te denken om het root certificaat van Lets Encrypt in de organisatie waar ik werk als niet vertrouwd aan te merken.

Grotendeels heb ik dit gevoel ook. Het is leuk natuurlijk om je verkeer gratis encrypted over het net te sturen (en vaak ook gewenst!) maar wanneer je niet weet bij wie dat uit komt, heb je er op het gebied van vertrouwen nog niks aan.

Wel is het zo dat ik dan alsnog de meerwaarde zie van een beveiligde verbinding via Lets Encrypt certificaten. Tijdens normaal HTTP verkeer kan je ook de ontvanger niet verifiëren. Én is je verkeer te onderscheppen. Met een certificaatje van Let's Encrypt & https, is dat nog steeds het zelfde geval, alleen is dan je verkeer niet meer te onderscheppen.

Dus het is wat mij betreft een beetje meten met twee maatstaven. Enerzijds vind ik het een vooruitgang, want je verkeer is minder gemakkelijk te onderscheppen. Anderzijds het kan "vals" vertrouwen opwekken.

Just my 2cts

[xleeuwx]

Dan zou ik heel snel alle andere certificaten ook maar Deactiveren... Stel je voor dat iemand een certificaat aanschaft en deze misbruikt .

Je kan heel simpel nu met een anonieme PayPal een SSL certificaat aanschaffen en dus heb je nog steeds het "vertrouwen" geschaad.

Echter gaat een SSL Certificaat helemaal niet om vertrouwen !!!

Een SSL Certificaat gaat er om dat de server een beveiligde verbinding versleutelt met een certificaat en deze wordt ondertekenend door Lets Encrypt / Comodo of enige andere Certificaat instantie (CA).

Trucker Her schreef op dinsdag 15 maart 2016 @ 13:36:
[...]

Wel is het zo dat ik dan alsnog de meerwaarde zie van een beveiligde verbinding via Lets Encrypt certificaten. Tijdens normaal HTTP verkeer kan je ook de ontvanger niet verifiëren. Én is je verkeer te onderscheppen. Met een certificaatje van Let's Encrypt & https, is dat nog steeds het zelfde geval, alleen is dan je verkeer niet meer te onderschepp

Dit is dus ook waar het fout gaat.... dat iedereen het volgende zegt: http is onveilig maar https is niet te onderscheppen.... fout

Als jij op bijv. een openbare hotspot zit en iemand vind het leuk om daar voor dhcp / dns server te gaan spelen, die vervolgens jou netjes een IP geeft en jou een DNS server voorschotelt dan kan hij het verkeer naar de bank bijvoorbeeld via zijn server versturen en dus rustig mee kijken.
Hij hoeft alleen een https certificaat hier aan te hangen en jij ziet een mooi groen slotje, nogmaals dit is makkelijker te doen met Lets Encrypt maar ook een certificaat aanvragen bij bijvoorbeeld comodo kan dan nog steeds (stuk moeilijker, maar niet onmogelijk).

[ Voor 52% gewijzigd door xleeuwx op 15-03-2016 13:42 . Reden: openbare hotspot toegevoegd ]

[Bor]

xleeuwx schreef op dinsdag 15 maart 2016 @ 13:36:
Echter gaat een SSL Certificaat helemaal niet om vertrouwen !!!

Een SSL Certificaat gaat er om dat de server een beveiligde verbinding versleutelt met een certificaat en deze wordt ondertekenend door Lets Encrypt / Comodo of enige andere Certificaat instantie.

Eh nee, hier sla je de plank compleet mis!

Het certificaten systeem is juist geheel opgezet rond vertrouwen. Zonder certicaten kun je immers ook prima encryptie toepassen. Het is juist het certificaat wat het vertrouwen moet onderschrijven. Door een certificaat terug te herleiden naar een vertrouwde root Certification Authority (CA) kun je er in het certificaten landschap vanuit gaan dat een certificaat ook daadwerkelijk hoort bij degene die jouw het certificaat aanbiedt. Hiervoor horen er controles uitgevoerd te worden voor de uitgifte van een certificaat die overeen horen te komen met het doel waarvoor het certificaat gebruikt gaat worden. Vertrouwen is de hoesteen van een certificaten infrastructuur.

Een verbinding wordt overigens ook niet versleuteld met een certificaat maar met een key(pair). Het certificaat dient hierin alleen om vertrouwen te scheppen over de identiteit van de communicatiepartner(s).

[ Voor 8% gewijzigd door Bor op 15-03-2016 13:45 ]

[xleeuwx]

Bor schreef op dinsdag 15 maart 2016 @ 13:43:
[...]


Eh nee, hier sla je de plank compleet mis!

Het certificaten systeem is juist geheel opgezet rond vertrouwen. Zonder certicaten kun je immers ook prima encryptie toepassen. Het is juist het certificaat wat het vertrouwen moet onderschrijven. Door een certificaat terug te herleiden naar een vertrouwde root Certification Authority (CA) kun je er in het certificaten landschap vanuit gaan dat een certificaat ook daadwerkelijk hoort bij degene die jouw het certificaat aanbiedt. Hiervoor horen er controles uitgevoerd te worden voor de uitgifte van een certificaat die overeen horen te komen met het doel waarvoor het certificaat gebruikt gaat worden. Vertrouwen is de hoesteen van een certificaten infrastructuur.

Een verbinding wordt overigens ook niet versleuteld met een certificaat maar met een keypair. Het certificaat dient hierin alleen om vertrouwen te scheppen over de identiteit van de communicatiepartner(s).

Dus jij wilt zeggen dat een certificaat wat een groen slotje laat zien per definitie veilig is ?

[Bor]

xleeuwx schreef op dinsdag 15 maart 2016 @ 13:46:
[...]


Dus jij wilt zeggen dat een certificaat wat een groen slotje laat zien per definitie veilig is ?

Nee juist niet. Dat stel ik ook nergens toch en dat is juist het punt want de topicstarter ook probeert aan te geven. Je slaat de plank volledig mis.

[ Voor 4% gewijzigd door Bor op 15-03-2016 13:47 ]

[xleeuwx]

Bor schreef op dinsdag 15 maart 2016 @ 13:47:
[...]


Nee juist niet. Dat stel ik ook nergens toch en dat is juist het punt want de topicstarter ook probeert aan te geven. Je slaat de plank volledig mis.

Wat ik probeer duidelijk te maken is dat een certificaat niet per definitie veilig hoeft te betekenen. Misschien heb ik mijn uitleg niet helemaal duidelijk maar om dus volledig Lets Encrypt als onveilig te defineren dat vind ik beetje ver gaan, een Comodo certificaat kan ook heel goed onveilig zijn.

[Ypho]

Een groene slotje zegt uiteraard niets over veiligheid, maar in hoeverre je de identiteit van een website kunt vertrouwen. Bij een groen slotje mag je er van uit gaan, dat er genoeg validatie is gedaan om de identiteit van de website te bevestigen (dat je echt met de ING Bank NV bent verbonden ipv een louche partij).

Ik weet niet precies welke validatie Let's Encrypt uitvoert, maar ik neem aan dat er toch wel gecontroleerd wordt of de aanvrager echt de eigenaar is van het domein (via mail/file/dns validatie). In dat geval is de validatie gelijk aan een DV van een random andere partij, en is er qua vertrouwen niet veel verschil lijkt me.

[_JGC_]

Let's encrypt is gewoon een domain validation certificatenboer. Als jij controle hebt over de DNS of webserver waar een domein naar verwijst kan je hierop een certificaat aanvragen. Dit kan bij Let's Encrypt, maar ook bij StartSSL en diverse andere certificaatboeren zoals Comodo. Enige verschil met Let's Encrypt is dat je dit volledig kunt automatiseren met hun client en dat het gratis is.
Let's Encrypt zal nooit een groen slotje geven, want ze leveren geen EV certificaten.

Enige reden waarom ik geen gebruik maak van Let's Encrypt is omdat je bijna verplicht wordt om de client te gebruiken. Ik bestel over het algemeen domain validation certificaten bij Comodo omdat je voor een paar euro een certificaat voor 3 jaar kunt kopen en daarmee is de kous af. Bij Let's Encrypt zijn certificaten maar 3 maanden geldig en doet de client auto-renew voor je. Als de client je platform niet ondersteunt ben je elke 3 maanden druk bezig om je certificaten te verversen.

[Trucker Her]

xleeuwx schreef op dinsdag 15 maart 2016 @ 13:50:
[...]


Wat ik probeer duidelijk te maken is dat een certificaat niet per definitie veilig hoeft te betekenen. Misschien heb ik mijn uitleg niet helemaal duidelijk maar om dus volledig Lets Encrypt als onveilig te defineren dat vind ik beetje ver gaan, een Comodo certificaat kan ook heel goed onveilig zijn.

Als je nou 2 regels verder in m'n bericht ook gequote had; daar zie je dat ik zei minder gemakkelijk te onderscheppen.

Daarnaast heb je wel deels gelijk, maar zoals ik ook in mijn post aan geef, het zijn 2 verschillende maatstaven daarbij.

Je kan inderdaad leuk een man-in-the-middle attack proberen uit te voeren op een publieke hotspot. Maar dan zal je ook de gebruiker een certificaat moeten voeren wat vertrouwd wordt door hun client. Dus iets als LetsEncrypt of een Comodo/ander CA certje.
Het probleem daarmee is dat door de controles die erop zitten je zit met de e-mail & overige verificatiemethodes. Wanneer je daar niet aan kan voldoen, heb je niet een gepast certificaat.

Vandaar dus ook van de TS; komt de veiligheid niet in het geding doordat daardoor de authenticiteit van de server/aanbieder niet goed wordt geverifieerd?

Ja. Je hebt dus een https verbinding, je verkeer is versleuteld. Ja. Daaraan is te sjoemelen. Maar dat gaat weer hand in hand met de controles op certificaten en de aanvraag.

[Jester-NL]

xleeuwx schreef op dinsdag 15 maart 2016 @ 13:36:
(...)

Echter gaat een SSL Certificaat helemaal niet om vertrouwen !!!

Een SSL Certificaat gaat er om dat de server een beveiligde verbinding versleutelt met een certificaat en deze wordt ondertekenend door Lets Encrypt / Comodo of enige andere Certificaat instantie (CA).
(...)

Juist wel... Dat is de stelling die de TS deponeert, en ook waar certificaten juist om draaien (en waarom het ene type certificaat duurder is dan het andere type... of de ene leverancier ten opzichte van de andere).
In principe is er geen verschil tussen een zelf-signed ceretificaat, en een (duur) certificaat van bijvoorbeeld een Symantec, dat niet alleen een slotje weergeeft, maar ook de adresbalk een ander kleurtje geeft en de bedrijfsnaam toevoegd.
Punt is: de maker(s) van jou en mijn OS en browser(s) hebben met elkaar afgesproken dat (bijvoorbeeld) Symantec standaard wel wordt vertrouwd, en xleeuwx.nl niet.
Dat houdt in dat we met zijn allen probleemloos een site met een Symantec-certificaat kunnen bezoeken (zonder dat je browser onmiddellijk in de stress schiet over het certificaat op die site) en dat het bezoeken van xleeuwx.nl met een self-signed certificaat wel een waarschuwing laat zien over het certificaat op de site.
Vertrouwen...

Voor wat betreft mijn vertrouwen in Let's encrypt... Tja...
Sowieso vindt ik eigenlijk dat een DV-certificaat an sich al een wassen neus is... en dan maakt het in wezen niets uit of dat certificaat nu gratis is, of dat je er een paar tientjes tegenaan gooit. De basis is hetzelfde: als je een mail op het domein kunt ontvangen ben je klaar. En dan maakt het niet echt uit of dat domein tweakers.net is, of paypal-helpdesk-nederland.tk (alhoewel die tweede waarschijnlijk bij de grotere CA's een alarmbelletje zal laten rinkelen).
Dat gezegd hebbende, is het niet verkeerd dat er een club is als let's encrypt. Het geeft mij namelijk best een fijn gevoel dat ik mijn webmail op mijn eigen domein nu versleuteld kan benaderen. All in all maken ze SSL net wat toegankelijker...
Het lijkt me ook dat het voor de Symantecs en de Comodos uiteindelijk een uitkomst is... want let's encrypt is redeljk basic in haar producten... wil je meer, dan moet je er uiteindelijk toch (elders) geld voor neerleggen.

[Plopeye]

Wat Lets Encrypt wel mogelijk maat is een zogeheten fast flux actie met vertrouwde certificaten.
Als je een botnet van gehackte webservers via SSL malware wil laten aanbieden, dan kan je dat via de API helemaal voorbereiden en uitvoeren. Malware via een SSL duikt onder inline scanners door en kan op die manier scanning gateways ontduiken.

Moet je dat doen met betaalde certificaten dan is een actie om elke botnet node te voorzien van een vertrouwd SSL certificaat 1 een hels karwei en 2 ineens toch wel een dure hobby.

Daarom vind ik dat het vertrouwen van Lets Encrypt certificaten toch lager zou moeten zijn dan een betaald DV certificaat.

De mogelijkheid van bovenstaand geschetste situatie is voor mij zelfs reden voor vertrouwen 0,0.

Ook is de vraag hoe onafhankelijk je kan zijn met zo'n waslijst aan sponsoren en hun belangen?
Platinum $ 350K per jaar, Gold $ 150K per jaar...

https://letsencrypt.org/sponsors/

[Lye]

xleeuwx schreef op dinsdag 15 maart 2016 @ 13:36:
Dit is dus ook waar het fout gaat.... dat iedereen het volgende zegt: http is onveilig maar https is niet te onderscheppen.... fout

Als jij op bijv. een openbare hotspot zit en iemand vind het leuk om daar voor dhcp / dns server te gaan spelen, die vervolgens jou netjes een IP geeft en jou een DNS server voorschotelt dan kan hij het verkeer naar de bank bijvoorbeeld via zijn server versturen en dus rustig mee kijken.
Hij hoeft alleen een https certificaat hier aan te hangen en jij ziet een mooi groen slotje, nogmaals dit is makkelijker te doen met Lets Encrypt maar ook een certificaat aanvragen bij bijvoorbeeld comodo kan dan nog steeds (stuk moeilijker, maar niet onmogelijk).

Waar anderen je er eerder al op hebben gewezen dat certificaten juist om vertrouwen gaan zal ik je voorbeeld nog eens even aanpakken.

Openbare hotspots zijn inderdaad een ideale plek voor man-in-the-middle attacks, echter is je voorbeeld incorrect.
Je kunt niet zomaar "even een HTTPS certificaat aan een website" hangen en je website dan voor laten doen als een andere website. Dit komt omdat een SSL certificaat domein gebonden is. Als jij jezelf voor wilt doen als de ING moet je dus ook een certificaat hebben die geldig is voor ing.nl. Jij zult nooit een "groen slotje" serveren zonder een certificaat dat geldig is voor ing.nl. Ook zul jij nooit een certificaat kunnen krijgen voor dit domein zonder de eigenaar te zijn van dit domein, tenzij de website of de CA een fout maakt.

Als jij via een openbare hotspot naar ing.nl gaat en je ziet een groen slotje en de naam van de bank kun je er vrijwel zeker van zijn dat dit altijd de daadwerkelijke bank is en dat het verkeer tussen jullie versleuteld is (natuurlijk is het te onderscheppen, alleen het is niet te ontcijferen).

Plopeye schreef op dinsdag 15 maart 2016 @ 21:45:
Wat Lets Encrypt wel mogelijk maat is een zogeheten fast flux actie met vertrouwde certificaten.
Als je een botnet van gehackte webservers via SSL malware wil laten aanbieden, dan kan je dat via de API helemaal voorbereiden en uitvoeren. Malware via een SSL duikt onder inline scanners door en kan op die manier scanning gateways ontduiken.

Moet je dat doen met betaalde certificaten dan is een actie om elke botnet node te voorzien van een vertrouwd SSL certificaat 1 een hels karwei en 2 ineens toch wel een dure hobby.

Hoe fast flux goed toepasbaar is door gratis certificaten ben ik nog niet helemaal achter. Voor zover ik weet maakt fast flux gebruik van het extreem snel veranderen van DNS records. SSL certificaten maken helemaal geen gebruik van DNS records en zijn, zoals eerder genoemd, domeinnaam gebonden, waardoor het niet uitmaakt of er nou 1 webserver of 20000 bots achter hangen.. Als ik hierbij iets over het hoofd zie, please enlighten me

Desalniettemin ben ik het wel eens met je opmerking dat Let's Encrypt certificaten minder betrouwbaar zijn dan standaard DV certificaten. Echter vind ik het geen reden om ze daarom compleet af te zweren. Let's Encrypt certificaten zijn ideaal voor persoonlijke websites, zeer kleine communities en dergelijke. Hoewel hier ook een certificaat van een paar tientjes aan gehangen kan worden, gaat het vooral om de eenvoud. Ik durf te wedden dat zonder Let's Encrypt deze domeinen geen certificaat zullen krijgen, met alle gevolgen van dien.

Voor mijn persoonlijke website maak ik ook gebruik van een Let's Encrypt certificaat, echter zou ik voor een bedrijf toch minimaal voor een betaald DV certificaat gaan.

[F_J_K]

Lye schreef op woensdag 16 maart 2016 @ 01:38:

Hoe fast flux goed toepasbaar is door gratis certificaten ben ik nog niet helemaal achter. Voor zover ik weet maakt fast flux gebruik van het extreem snel veranderen van DNS records. SSL certificaten maken helemaal geen gebruik van DNS records en zijn, zoals eerder genoemd, domeinnaam gebonden, waardoor het niet uitmaakt of er nou 1 webserver of 20000 bots achter hangen.. Als ik hierbij iets over het hoofd zie, please enlighten me

Gokje:
1) man in the middle bij cert-auth -> bestaande domeinnaam naar nieuw IP
2) vraag snel een gratis cert aan voor domeinnaam via dat IP
3) man in the middle vanaf publiek hotspot -> bestaande domeinnaam naar nieuw IP
4) ?
5) profit!

Maar die stap 1 is wat minder makkelijk dan stap 3...

Desalniettemin ben ik het wel eens met je opmerking dat Let's Encrypt certificaten minder betrouwbaar zijn dan standaard DV certificaten. Echter vind ik het geen reden om ze daarom compleet af te zweren. Let's Encrypt certificaten zijn ideaal voor persoonlijke websites, zeer kleine communities en dergelijke. Hoewel hier ook een certificaat van een paar tientjes aan gehangen kan worden, gaat het vooral om de eenvoud. Ik durf te wedden dat zonder Let's Encrypt deze domeinen geen certificaat zullen krijgen, met alle gevolgen van dien.

[Firefly III]

Tot nu toe lees ik toch vooral emotie en weinig techniek. De argumenten tegen certificaten gebaseerd op domeinvalidatie gaan voor elke certificatenboer op.

Wat de sponsoren te maken hebben met de (on)afhankelijkheid is me ook een raadsel. Juist omdat het er zoveel zijn. Tenzij je een concrete aanvalsmethode kan bedenken waarmee Let's Encrypt gecompromitteerd kan worden door een financiële sponsor is dat ook gewoon onderbuikgevoel.

Verder is het gebruik van SSL voor spam, malware en andere nare ongein zo oud als SSL zelf, en een fatsoenlijke scanner is daar allang voor toegerust.

Mijn betaalde certificaten werden even summier gecontroleerd als die van LE.

Maar ik ben benieuwd of er nog goede argumenten komen tegen LE, behalve dan "wat de boer niet kent, dat vreet-ie niet".

[Plopeye]

Vertrouwen is ook een emotie en weinig techniek toch? Je kan met de techniek enkel een weerspiegeling maken van het vertrouwen dat je wilt uitstralen.

Een fatsoenlijke scanner? Die dus een man in the middle doet om SSL verkeer te kunnen scannen? Naast de vele rekenkracht die het kost (Decrytion/Encrytion) is dit ethisch ook wel op het randje eigenlijk.

[matty___]

Je kunt ook prima self signed aanmaken alleen begint je brouwers dan te zeuren. Dat probleem heb je niet met Lets Encrypt.

[Firefly III]

Plopeye schreef op woensdag 16 maart 2016 @ 08:33:
Vertrouwen is ook een emotie en weinig techniek toch? Je kan met de techniek enkel een weerspiegeling maken van het vertrouwen dat je wilt uitstralen.

Een fatsoenlijke scanner? Die dus een man in the middle doet om SSL verkeer te kunnen scannen? Naast de vele rekenkracht die het kost (Decrytion/Encrytion) is dit ethisch ook wel op het randje eigenlijk.

Ja ja. Maar geen goed argument verder dus? Want dat mis ik wel. Het is nu gewoon een beetje mekkeren op LE, zonder concrete argumenten die voor of tegen ze spreken. Leuk hoor, dat techniek een weerspiegeling is van het vertrouwen dat je wilt uitstralen (jij bent vast een manager ).

Als je malware wil voorkomen zul je de pagina's die het aanbieden moeten scannen zodra mensen ze bezoeken (en dus eventueel blokkeren). Dat kan niet als het SSL verkeer is. Tenzij je via een proxy-achtige constructie de SSL verbinding opzet vanaf je scanner, en vanaf daar de gegevens weer doorsluist naar de gebruiker. De gebruiker kan je een fake certificaat geven (uitgegeven door de scanner) waardoor de gebruiker gewoon een SSL verbinding heeft. Die heeft daar een root-certificaat uitgegeven door de scanner voor nodig. Dat is vaste prik in grote organisaties, niks bijzonders aan. Wat betreft de ethiek: juist in een omgeving waar malafide partijen zich proberen te verschuilen achter SSL kan je het niet maken om zulke pagina's niet te scannen. Tenzij je elke week een cryptolocker wilt.

[ Voor 0% gewijzigd door Firefly III op 16-03-2016 10:49 . Reden: Smiley ]

[ANdrode]

Plopeye schreef op dinsdag 15 maart 2016 @ 21:45:
Moet je dat doen met betaalde certificaten dan is een actie om elke botnet node te voorzien van een vertrouwd SSL certificaat 1 een hels karwei en 2 ineens toch wel een dure hobby.

Er waren al gratis certificaten te krijgen (startssl). Het uitgifte proces kon je al scripten – in mijn ogen een middagje werk.

Let's Encrypt implementeert DV. De veiligheid is dus equivalent aan alle andere DV certificaten .

Als je SSL wilt kan je ook cloudflare als proxy gebruiken of een wildcard certificaat gebruiken dat meegeleverd wordt met software [3].

De mogelijkheid van bovenstaand geschetste situatie is voor mij zelfs reden voor vertrouwen 0,0.

Je wilt blacklisten op basis van sentiment, niet op basis van feiten.

Als je het echt veiliger wilt maken denk ik dat je dan betere CA's kan blacklisten die eerder verkeerde certificaten heeft gesigned [1] of CA's die nog steeds via een oud root certificaat, dat veel cross-signatures heeft, SHA1 certificaten uitgeven [2].

[1]: Comodo
[2]: 2: Symantec/Verisign
[3]: Bepaalde software levert een wildcard certificaat mee om mixed-content waarschuwingen te voorkomen.

[ Voor 3% gewijzigd door ANdrode op 16-03-2016 09:26 ]

[Bor]

matty___ schreef op woensdag 16 maart 2016 @ 08:49:
Je kunt ook prima self signed aanmaken alleen begint je brouwers dan te zeuren. Dat probleem heb je niet met Lets Encrypt.

Daar kom je juist op het stukje vertrouwen. Een self signed certificaat werkt an sich prima maar wordt doorgaans niet vertrouwd door een ander. Dat is ook de reden dat een browser een waarschuwing geeft. Juist door gebruik te maken van een bekende / vertrouwde root CA wordt duidelijk gemaakt dat een certificaat te vertrouwen is. Wanneer je erg weinig tot geen validatie doet is schaad je dat vertrouwen eigenlijk een beetje. Immers ziet een doorsnede eindgebruiker in zijn browser geen verschil tussen een certificaat dat onder strenge voorwaarden en na strenge controle is uitgegeven en een certificaat dat is uitgegeven nadat je amper bewijs hebt geleverd dat het aangevraagde certificaat daadwerkelijk bij iets in jouw beheer of bezit hoort.

Een van de redenen van de beperkte controle die wordt uitgevoerd bij veel certificaatboeren is dat de prijzen onder druk staan en men vooral snel wil kunnen leveren. In het geval van Let's encrypt (misschien is dit een verkeerde naam en had het initiatief Let's Trust moeten heten) is een certificaat zelfs gratis terwijl het opzetten en onderhouden van een echt veilige Public Key Infrastructure (PKI) een zeer kostbare zaak is. Daar gaat de schoen vroeg of laat wringen.

[azerty]

Plopeye schreef op dinsdag 15 maart 2016 @ 13:31:
Ik wil eens een topic starten om eens te peilen en vooral ook om mensen eens aan het denken te zetten.

Mijn stelling wat betreft Lets Encrypt:

Ze zijn het vertrouwen niet waard want de uitgifte bevat te weinig controle's. Er is ook al gebleken dat er SSL certificaten aan malvertising site's zijn uitgegeven. Lets Encrypt haalt in mijn ogen het hele fundament van SSL onderuit, namelijk vertrouwen...

En als jij een cert koopt voor 8€/jaar (enkel email validatie) is het plots wel onmogelijk om een cert uit te reiken aan malvertising sites?

[matty___]

Bor schreef op woensdag 16 maart 2016 @ 09:24:
[...]

Een van de redenen van de beperkte controle die wordt uitgevoerd bij veel certificaatboeren is dat de prijzen onder druk staan en men vooral snel wil kunnen leveren. In het geval van Let's encrypt (misschien is dit een verkeerde naam en had het initiatief Let's Trust moeten heten) is een certificaat zelfs gratis terwijl het opzetten en onderhouden van een echt veilige Public Key Infrastructure (PKI) een zeer kostbare zaak is. Daar gaat de schoen vroeg of laat wringen.

Wordt het niet door Google oid gefinancierd?

https://letsencrypt.org/sponsors/

[ Voor 3% gewijzigd door matty___ op 16-03-2016 09:30 ]

[Lye]

matty___ schreef op woensdag 16 maart 2016 @ 09:29:
[...]

Wordt het niet door Google oid gefinancierd?

Het wordt gefinancierd door sponsors, waaronder Chrome, Mozilla en Facebook.
Edit: Dat zag je zelf dus ook al

[ Voor 6% gewijzigd door Lye op 16-03-2016 09:31 ]

[ANdrode]

matty___ schreef op woensdag 16 maart 2016 @ 09:29:
[...]
Wordt het niet door Google oid gefinancierd?

Mozilla, Google, Akamai, EFF, Facebook, etc....

Let's Encrypt zorgt er voor dat de privacy van heel veel gebruikers een stuk beter geborgd wordt/SSL bereikbaar wordt. Hierdoor kunnen de browser vendors er nu aan vasthouden dat HTTP2 alleen over SSL geïmplementeerd wordt.

Browsers zijn volgens mij aan het experimenteren met de SSL indicator. DV, OV en EV zien er anders uit als je goed kijkt.

Geen referer header bij HTTPS. Best ironisch dat ik dit typ op tweakers.net, dat enkel de login pagina over HTTP aanbied...

[ Voor 10% gewijzigd door ANdrode op 16-03-2016 09:36 ]

[Bor]

matty___ schreef op woensdag 16 maart 2016 @ 09:29:
[...]

Wordt het niet door Google oid gefinancierd?

https://letsencrypt.org/sponsors/

Let's Encrypt is afhankelijk van sponsors maar dat doet niet af aan mijn argument. Ook met sponsors zal er bezuinigd moeten worden hoogstwaarschijnlijk. Dit geldt niet alleen voor Let's Encrypt maar voor elke low budget certificaatinstantie.

Het opzetten en onderhouden van een PKI kan redelijk simpel en snel / low budget maar wanneer je dit betrouwbaar en echt veilig wilt doen wordt dit zo opeens totaal anders. Denk aan dure fysieke beveiliging, zeer regelmatige audits, hoog beschikbare high performance infrastructuur, hardware security modules, screening van personen en ga maar door (dit is nog maar het topje van de ijsberg).

[Plopeye]

azerty schreef op woensdag 16 maart 2016 @ 09:27:
[...]


En als jij een cert koopt voor 8€/jaar (enkel email validatie) is het plots wel onmogelijk om een cert uit te reiken aan malvertising sites?

Als je 20.000 botnet nodes van een SSL cert wil voorzien dan wordt het met 20.000 x 8 euro wel een dure hobby...

En dit is nou net de drempel die Lets Encrypt nu weggenomen heeft...

[Nakebod]

_JGC_ schreef op dinsdag 15 maart 2016 @ 14:04:
Let's Encrypt zal nooit een groen slotje geven, want ze leveren geen EV certificaten.

Dan zal ik wel een speciale Let's Encrypt client hebben, want veel groener kan mijn slotje niet.
Als in, mijn betaalde PositiveSSL EV DV cert van een paar euro per jaar ziet er hetzelfde uit.

Wat mij betreft is een betaald SSL certificaat net zo veilig/onveilig als een gratis certificaat. Betalen voor een certificaat maakt het niet ineens veiliger.

[Bor]

azerty schreef op woensdag 16 maart 2016 @ 09:27:
[...]


En als jij een cert koopt voor 8€/jaar (enkel email validatie) is het plots wel onmogelijk om een cert uit te reiken aan malvertising sites?

Ik denk dat dit gedeeltelijk irrelevant is. De vraag van de TS komt wellicht boven omdat Let's Encrypt gratis certificaten aanbiedt maar dit kun je natuurlijk gemakkelijk veel breder trekken.

[Jester-NL]

Bor schreef op woensdag 16 maart 2016 @ 09:51:
[...]


Ik denk dat dit gedeeltelijk irrelevant is. De vraag van de TS komt wellicht boven omdat Let's Encrypt gratis certificaten aanbiedt maar dit kun je natuurlijk gemakkelijk veel breder trekken.

Hoe breed wil je het trekken? Ik lees net dat Symantec ook aan de gratis certificaten gaat...

[azerty]

Plopeye schreef op woensdag 16 maart 2016 @ 09:46:
[...]


Als je 20.000 botnet nodes van een SSL cert wil voorzien dan wordt het met 20.000 x 8 euro wel een dure hobby...

En dit is nou net de drempel die Lets Encrypt nu weggenomen heeft...

Absoluut niet. Je had al gratis certificaten (scripbaar) via onder meer StartSSL, cloudflare, wosign, ... De drempel was er al niet meer. En trouwens, waarom zou je überhaupt elke node van een certificaat voorzien? Zet ze allemaal onder 1 domein, koop een wildcard cert en voor pak 'em beet 80€ ben je ook klaar.

[azerty]

Nakebod schreef op woensdag 16 maart 2016 @ 09:47:
[...]

Dan zal ik wel een speciale Let's Encrypt client hebben, want veel groener kan mijn slotje niet.
Als in, mijn betaalde PositiveSSL EV cert van een paar euro per jaar ziet er hetzelfde uit.

Wat mij betreft is een betaald SSL certificaat net zo veilig/onveilig als een gratis certificaat. Betalen voor een certificaat maakt het niet ineens veiliger.

In Firefox is het bij mij toch zo dat een DV certificaat enkel een groen slotje geeft, waar een EV de naam van het bedrijf erbij vermeld.



PS: als je dit niet kunt zien... Pech, moet je LE maar vertrouwen

[ANdrode]

Bor schreef op woensdag 16 maart 2016 @ 09:40:
[...]
Het opzetten en onderhouden van een PKI kan redelijk simpel en snel / low budget maar wanneer je dit betrouwbaar en echt veilig wilt doen wordt dit zo opeens totaal anders. Denk aan dure fysieke beveiliging, zeer regelmatige audits, hoog beschikbare high performance infrastructuur, hardware security modules, screening van personen en ga maar door (dit is nog maar het topje van de ijsberg).

De kwaliteit daarvan borg je toch met audits? LE voldoet daaraan, net zoals alle andere CA's.

[Nakebod]

azerty schreef op woensdag 16 maart 2016 @ 10:01:
[...]


In Firefox is het bij mij toch zo dat een DV certificaat enkel een groen slotje geeft, waar een EV de naam van het bedrijf erbij vermeld.

[afbeelding]

PS: als je dit niet kunt zien... Pech, moet je LE maar vertrouwen

Maakte net stiekem de fout door EV te schrijven waar ik DV bedoelde
Maar het ging om het groene slotje, welke volgens _JGC_ bij Let's Encrypt er niet zou zijn.

Tenzij hij bedoelde dat de naam niet weergegeven wordt. En dat is zoals verwacht, gezien Let's Encrypt dus geen EV doet.
Vooralsnog hebben ze geen plannen daarvoor. Maar misschien dat dat in de toekomst wel komt als betaalde optie, om ook inkomsten naast de sponsoren te halen.

[begintmeta]

ANdrode schreef op woensdag 16 maart 2016 @ 09:24:
...
Je wilt blacklisten op basis van sentiment, niet op basis van feiten.

Als je het echt veiliger wilt maken denk ik dat je dan betere CA's kan blacklisten die eerder verkeerde certificaten heeft gesigned \[1] of CA's die nog steeds via een oud root certificaat, dat veel cross-signatures heeft, SHA1 certificaten uitgeven \[2].

\[1]: Comodo
\[2]: 2: Symantec/Verisign
\[3]: Bepaalde software levert een wildcard certificaat mee om mixed-content waarschuwingen te voorkomen.

Ik denk daarnaast dat naast gebruikers wellicht ook aanbieders van bijvoorbeeld browsers of operating systems eventueel wat selectiever zouden mogen zijn in het includeren van bepaalde CAs.

Wat betreft Let's Encrypt: je moet altijd nagaan of de site waar je mee verbonden bent inderdaad de site is die hij pretendeert te zijn, of het nu abn amro met een Symantec ev-certificaat is, letsencrypt met een IdenTrust certificaat of je eigen servertje met een self-signed of ander certificaat. Het mooiste werkt dat natuurlijk als je het certificaat, niet de CA in een eigen whitelist hebt staan, maar dat is uiteraard praktisch niet te doen (behoudens voor eigen servers), daarom moet je ook diverse andere factoren in je afweging betrekken (hoe betrouwbaar acht je de dns-gegevens in het netwerk bijvoorbeeld). Wie de CA die een certificaat van een bepaald domein/ip heeft gecertificeerd, is in zoverre van belang als dat je wil weten hoe makkelijk het is een certificaat voor een 'vreemd domein'' te verkrijgen, ik weet simpelweg niet of dat bij Let's Encrypt of Symantec nou zo veel makkelijker of moeilijker is dan het bijvoorbeeld bij Diginotar was.

[ Voor 9% gewijzigd door begintmeta op 16-03-2016 10:20 ]

[ANdrode]

begintmeta schreef op woensdag 16 maart 2016 @ 10:14:
[...]
Ik denk daarnaast dat naast gebruikers wellicht ook aanbieders van bijvoorbeeld browsers of operating systems eventueel wat selectiever zouden mogen zijn in het includeren van bepaalde CAs.

Ja . En er moeten stricte regels zijn over sub-CA's en cross-signing.

Elk CA certificaat kan namelijk weer sub-CA's maken, zolang er maar een pad naar een trust anchor is. Een aantal jaar geleden waren er volgens het EFF SSL observatory project 650 organisatie's die een CA certificaat hadden die door Microsoft of Mozilla vertrouwd werden.

[Plopeye]

Als je dan dit weer leest: http://www.networkworld.c...te-from-lets-encrypt.html

en dan met name:

It is possible to revoke digital certificates. However, Let's Encrypt had decided as policy not to revoke certificates. In October, the organization explained that certification authorities (CAs) are not equipped to police content.

Zet bij mij wel weer vraagtekens...

[begintmeta]

Plopeye schreef op woensdag 16 maart 2016 @ 10:20:
Als je dan dit weer leest: http://www.networkworld.c...te-from-lets-encrypt.html

en dan met name:

It is possible to revoke digital certificates. However, Let's Encrypt had decided as policy not to revoke certificates. In October, the organization explained that certification authorities (CAs) are not equipped to police content.

Zet bij mij wel weer vraagtekens...

Je kan eigen letsencrypt certificaten vziw wel revoken, de keuze van letsencrypt om geen certificaten door tweeden of derden te laten revoken, kan je in zekere zin, zoals letsencrypt betoogt, wel verdedigen denk ik.

[azerty]

Plopeye schreef op woensdag 16 maart 2016 @ 10:20:
Als je dan dit weer leest: http://www.networkworld.c...te-from-lets-encrypt.html

en dan met name:

It is possible to revoke digital certificates. However, Let's Encrypt had decided as policy not to revoke certificates. In October, the organization explained that certification authorities (CAs) are not equipped to police content.

Zet bij mij wel weer vraagtekens...

Omdat een certificaat (op dit moment) maar een levensduur van 90 dagen heeft, is het dus niet nodig om een CRL bij te houden. Het kan ook goed zijn dat die levensduur nog verder naar beneden gaat als de automatisering op alle vlakken vlot verloopt.

een CRL moeten bijhouden is een dure zaak (vandaar dat het bijv. bij StartSSL geld kost om een certificate te revoken), dus door de lifetime van een cert zodanig in te perken dat het een minimale impact heeft als de keys gestolen zouden worden, kan die kost vermeden worden...

[begintmeta]

azerty schreef op woensdag 16 maart 2016 @ 10:24:
[...]


Omdat een certificaat (op dit moment) maar een levensduur van 90 dagen heeft, is het dus niet nodig om een CRL bij te houden. ...
... dus door de lifetime van een cert zodanig in te perken dat het een minimale impact heeft als de keys gestolen zouden worden, ...

Daar ben ik het niet mee eens, en vziw kan je een gecompromitteerd certificaat ook gewoon terugtrekken.

[ Voor 22% gewijzigd door begintmeta op 16-03-2016 10:32 ]

[azerty]

begintmeta schreef op woensdag 16 maart 2016 @ 10:26:
[...]

Daar ben ik het niet mee eens, en vziw kan je een gecompromiteerd certificaat ook gewoon terugtrekken.

I stand corrected, het is idd wel mogelijk om te revoken:

quote: https://letsencrypt.org/getting-started/

letsencrypt revoke --cert-path example-cert.pem

[_JGC_]

Nakebod schreef op woensdag 16 maart 2016 @ 10:13:
[...]

Maakte net stiekem de fout door EV te schrijven waar ik DV bedoelde
Maar het ging om het groene slotje, welke volgens _JGC_ bij Let's Encrypt er niet zou zijn.

Tenzij hij bedoelde dat de naam niet weergegeven wordt. En dat is zoals verwacht, gezien Let's Encrypt dus geen EV doet.
Vooralsnog hebben ze geen plannen daarvoor. Maar misschien dat dat in de toekomst wel komt als betaalde optie, om ook inkomsten naast de sponsoren te halen.

Ik bedoelde idd de groene balk, het slotje bij Firefox en Chrome is standaard groen ongeacht het soort certificaat, zolang er maar SHA256 of beter wordt gebruikt, het domein klopt met het certificaat en er geen bronnen worden geladen die niet over een kloppende HTTPS verbinding komen.

[ANdrode]

azerty schreef op woensdag 16 maart 2016 @ 10:24:
[...]
Omdat een certificaat (op dit moment) maar een levensduur van 90 dagen heeft, is het dus niet nodig om een CRL bij te houden. Het kan ook goed zijn dat die levensduur nog verder naar beneden gaat als de automatisering op alle vlakken vlot verloopt.

Let's Encrypt heeft wel een OCSP responder.

Helaas zijn OCSP en CRL geen oplossing voor het probleem van revocation. Als de check mislukt dan geeft/gaf de browser namelijk geen foutmelding. Dit ging mis bij Diginotar.

OCSP/CRL's zorgen er voor dat een CA het certificaat van een niet betalende klant kan blokkeren, niet voor veiligheid tijdens een MITM aanval .

LE publiceert ook 'certificate transparency' informatie voor hun certificaten. Daardoor kan je in een publieke lijst zoeken of er voor jouw domein een certificaat is gepubliceerd.

Als alle CA's die voor al hun certificaten zouden doen (c.f. alleen voor EV) dan kan je als website eigenaar controleren of er een certificaat onterecht is uitgegeven.

[ Voor 6% gewijzigd door ANdrode op 16-03-2016 10:32 ]

[Bor]

azerty schreef op woensdag 16 maart 2016 @ 10:24:
[...]


Omdat een certificaat (op dit moment) maar een levensduur van 90 dagen heeft, is het dus niet nodig om een CRL bij te houden. Het kan ook goed zijn dat die levensduur nog verder naar beneden gaat als de automatisering op alle vlakken vlot verloopt.

Fout! De geldigheidsduur van een certificaat heeft echt niets te maken met het feit dat certificate revocation nodig is. Indirect geef je hiermee aan dat het niet uit maakt of het betreffende certificaat (of eigenlijk de keypair) gecompromitteerd is of niet.

Jester-NL schreef op woensdag 16 maart 2016 @ 09:53:
[...]

Hoe breed wil je het trekken? Ik lees net dat Symantec ook aan de gratis certificaten gaat...

Dat is vrij makkelijk te beantwoorden; je kunt je afvragen of een trustmodel als we gebruiken rond certificaten uberhaubt wel zin heeft wanneer er geen tot weinig controle wordt uitgevoerd alvorens een certificaat wordt uitgegeven.

ANdrode schreef op woensdag 16 maart 2016 @ 10:32:
[...]


Let's Encrypt heeft wel een OCSP responder.

Helaas zijn OCSP en CRL geen oplossing voor het probleem van revocation. Als de check mislukt dan geeft/gaf de browser namelijk geen foutmelding.

Dit ligt iets genuanceerder. Een CRL en OCSP zijn absoluut oplossingen voor het probleem van revocation. Het probleem zit hem niet in het publiceren van revocation informatie maar bij de browsers (en andere software zelf). Daar is immers de beslissing genomen om geen waarschuwing te geven wanneer een certificaat ingetrokken blijkt. Het komt ook veelvuldig voor dat software helemaal niet controleert op ingetrokken certificaten.

ANdrode schreef op woensdag 16 maart 2016 @ 10:07:
[...]


De kwaliteit daarvan borg je toch met audits? LE voldoet daaraan, net zoals alle andere CA's.

In beperkte mate kun je dat borgen met audits inderdaad. De praktijk is helaas dat audits vrijwel altijd maar een beperkt deel van de infrastructuur en de naleving van procedures (en vaak niet eens de procedures op zich in zijn totaliteit) controleren.

[ Voor 64% gewijzigd door Bor op 16-03-2016 10:40 ]

[hackerhater]

Let's ecrypt doet aan domain validation. Ik weet zelf niet hoe ze het implementeren, maar ik vermoed dat je oa de keuze hebt voor een paar email-adressen (admin@, postmaster@, etc),
Als je de toegang hebt tot die email-adressen/ze kan aanmaken lijkt me het toch logisch dat je controle hebt over dat specifieke domein?

Ik heb pas voor mijn werkgever de certs moeten vernieuwen. De cert-boer stuurde de bevestigingsmailtjes allemaal naar admin@[domain]. Met de DirectAdmin administrator login kon ik ze uitlezen en bevestigen.
Ik wil niet veel zeggen, maar met die login kan ik alles doen met de sites wat ik wil......

[Bor]

hackerhater schreef op woensdag 16 maart 2016 @ 10:47:
Let's ecrypt doet aan domain validation. Ik weet zelf niet hoe ze het implementeren, maar ik vermoed dat je oa de keuze hebt voor een paar email-adressen (admin@, postmaster@, etc),
Als je de toegang hebt tot die email-adressen/ze kan aanmaken lijkt me het toch logisch dat je controle hebt over dat specifieke domein?

Nee die conclusie is te voorbarig. Zeker gezien standaard mailverkeer (smtp) niet beveiligd is. Het is mogelijk om e-mail gedurende de transmissie te onderscheppen zoals je ongetwijfeld weet. Daarbij is een e-mail adres geen naar een persoon terug te herleiden authenticatiemiddel. Het is daar simpelweg niet voor geschikt.

[Lye]

hackerhater schreef op woensdag 16 maart 2016 @ 10:47:
Let's ecrypt doet aan domain validation. Ik weet zelf niet hoe ze het implementeren, maar ik vermoed dat je oa de keuze hebt voor een paar email-adressen (admin@, postmaster@, etc),
Als je de toegang hebt tot die email-adressen/ze kan aanmaken lijkt me het toch logisch dat je controle hebt over dat specifieke domein?

Ik heb pas voor mijn werkgever de certs moeten vernieuwen. De cert-boer stuurde de bevestigingsmailtjes allemaal naar admin@[domain]. Met de DirectAdmin administrator login kon ik ze uitlezen en bevestigen.
Ik wil niet veel zeggen, maar met die login kan ik alles doen met de sites wat ik wil......

LE gebruikt geen email voor validatie. Ze gebruiken een client op de server die of een tijdelijke webserver opzet waarna er verbinding wordt gemaakt met de LE servers, of validatie via bestanden in een publieke map op de webserver. Mogelijk zijn er nog meer validatiemethoden, ik heb ze echter nog nooit gebruikt

[azerty]

hackerhater schreef op woensdag 16 maart 2016 @ 10:47:
Let's ecrypt doet aan domain validation. Ik weet zelf niet hoe ze het implementeren, maar ik vermoed dat je oa de keuze hebt voor een paar email-adressen (admin@, postmaster@, etc),
Als je de toegang hebt tot die email-adressen/ze kan aanmaken lijkt me het toch logisch dat je controle hebt over dat specifieke domein?

LE maakt gebruik van het ACME protocol (https://github.com/ietf-wg-acme/acme/), welke onder meer (zoals door Lype vermeld) werkt via een webserver. DNS kan ook geloof ik.

quote: https://github.com/ietf-w...r/draft-ietf-acme-acme.md

For example, if the client requests a domain name, the server might challenge the client to provision a record in the DNS under that name, or to provision a file on a web server referenced by an A or AAAA record under that name. The server would then query the DNS for the record in question, or send an HTTP request for the file. If the client provisioned the DNS or the web server as expected, then the server considers the client authorized for the domain name.

[ Voor 31% gewijzigd door azerty op 16-03-2016 10:58 ]

[ANdrode]

Bor schreef op woensdag 16 maart 2016 @ 10:32:
[...]
Dit ligt iets genuanceerder. Een CRL en OCSP zijn absoluut oplossingen voor het probleem van revocation. Het probleem zit hem niet in het publiceren van revocation informatie maar bij de browsers (en andere software zelf). Daar is immers de beslissing genomen om geen waarschuwing te geven wanneer een certificaat ingetrokken blijkt. Het komt ook veelvuldig voor dat software helemaal niet controleert op ingetrokken certificaten.

Dit is offtopic, want LE ondersteunt wel revocation/OCSP.


Ik sloeg wat nuance's over. Historisch gezien waren OCSP responders vaak niet bereikbaar en was het niet mogelijk om OCSP responses mee te sturen in de SSL handshake.

Het probleem zit er in dat verplichte OCSP checks een single point of failure voor al deze certificaten introduceert. Als er iets mis gaat (downtime van OCSP responder/niet bereikbaar door firewall/proxy) zijn sites onbereikbaar.

Tegelijkertijd zijn OCSP responses tot tien dagen geldig. Na revocation kunnen ze dus nog tien dagen meegestuurd worden d.m.v. stapling.

In mijn ogen is dat geen goed revocation mechanisme.

Bor schreef op woensdag 16 maart 2016 @ 10:32:
[...]
In beperkte mate kun je dat borgen met audits inderdaad. De praktijk is helaas dat audits vrijwel altijd maar een beperkt deel van de infrastructuur en de naleving van procedures (en vaak niet eens de procedures op zich in zijn totaliteit) controleren.

En bij andere CA's weet je ook niet wat de processen zijn. Het zijn commerciële bedrijven en ik noemde eerder al wat voorbeelden van waar het bij concurrentie mis ging.

Dan is LE toch 'net zo goed' als alle andere DV certificaten?

Binnen het trust model van web-PKI is LE equivalent aan alle andere DV certificaten. Je moet een DV/OV certificaat alleen niet zien als iets waardoor je zeker weet met wie je verbind. Je weet alleen vrij zeker dat niemand anders kan meelezen.

EV certificaten bieden écht wat zekerheid – maar je wint meer zekerheid voor herhalende bezoekers met pinning, bijvoorbeeld met Public-Key-Pins headers.

[begintmeta]

Bor schreef op woensdag 16 maart 2016 @ 10:50:
...
Nee die conclusie is te voorbarig. Zeker gezien standaard mailverkeer (smtp) niet beveiligd is. Het is mogelijk om e-mail gedurende de transmissie te onderscheppen zoals je ongetwijfeld weet.

Die zwakte is enigszins te omzeilen door aanvullen de inhoud van de mail via een beveiligd kanaal te moeten terugkoppelen. Daarnaast zijn er zoals is aangegeven ook andere methoden denkbaar natuurlijk.

Daarbij is een e-mail adres geen naar een persoon terug te herleiden authenticatiemiddel. Het is daar simpelweg niet voor geschikt.

Maar het (DV-)certificaat hoeft ook niet naar een persoon te herleiden zijn, alleen naar een domeinnaam.

[ Voor 5% gewijzigd door begintmeta op 16-03-2016 10:55 ]

[hackerhater]

Bor schreef op woensdag 16 maart 2016 @ 10:50:
Nee die conclusie is te voorbarig. Zeker gezien standaard mailverkeer (smtp) niet beveiligd is. Het is mogelijk om e-mail gedurende de transmissie te onderscheppen zoals je ongetwijfeld weet. Daarbij is een e-mail adres geen naar een persoon terug te herleiden authenticatiemiddel. Het is daar simpelweg niet voor geschikt.

Nou? Als ik naar de logs van onze servers kijk is zeker 90% van de server2server SMTP tegenwoordig versleuteld.

Het gaat er ook niet om of je de persoon bent die je zegt te zijn, maar of je beheerders-toegang tot dat domein hebt. Als je de DNS kan wijzigen/bestanden op de site kan zetten/aan de admin-mailadressen kan wordt aangenomen dat je er controle over hebt.

LE gebruikt geen email voor validatie. Ze gebruiken een client op de server die of een tijdelijke webserver opzet waarna er verbinding wordt gemaakt met de LE servers, of validatie via bestanden in een publieke map op de webserver. Mogelijk zijn er nog meer validatiemethoden, ik heb ze echter nog nooit gebruikt

Stil. Dat vereist nog altijd toegang tot de betreffende webserver

[Plopeye]

Stil. Dat vereist nog altijd toegang tot de betreffende webserver

Niet zo moeilijk met alle lekke wordpress en joomla installaties om maar een voorbeeld te geven...

[hackerhater]

Plopeye schreef op woensdag 16 maart 2016 @ 11:09:
Niet zo moeilijk met alle lekke wordpress en joomla installaties om maar een voorbeeld te geven...

Tjah als je geen verstand van sites hebt, moet je iemand inhuren die het voor je bij houd.
Als je site gehacked wordt heb je wel grotere problemen dan iemand een SSL-cert op je domeinnaam aan vraagt.

[Bor]

ANdrode schreef op woensdag 16 maart 2016 @ 10:52:
[...]


Dit is offtopic, want LE ondersteunt wel revocation/OCSP.

Hier is niets offtopic aan gezien ik reageer op de algemene stelling dat CRL's en OCSP gene oplossing bieden voor het probleem.

hackerhater schreef op woensdag 16 maart 2016 @ 11:14:
[...]


Tjah als je geen verstand van sites hebt, moet je iemand inhuren die het voor je bij houd.
Als je site gehacked wordt heb je wel grotere problemen dan iemand een SSL-cert op je domeinnaam aan vraagt.

Dit is een dooddoener. Alle software bevat fouten, ook als je zaken goed inricht en bijhoudt. Natuurlijk hebben bepaalde pakketten een zekere reputatie maar in feite loop je altijd risico. Bovendien bepaald een eventueel groter probleem niet of een ander issue zoals het aanvragen van een certificaat op iemand anders' domeinnaam wel of geen probleem is. Totaal irrelevant dus.

[Firefly III]

Ja maar ho even, wat dan? Dan heb je een SSL certificaat voor een site met een brakke Joomla / Wordpress installatie. Er vanuit gaande dat het je inderdaad lukt om precies de URL te bakken zoals het ACME protocol hem voorschrijft, en je alle honderd andere problemen weet te overkomen die daar ook nog bij kunnen kijken.

Deze aanvalsmethode is niet zo makkelijk als we voor dit voorbeeld graag voordoen.

Maar stel dat dat lukt. En dan? Heb je zijn site veiliger gemaakt door er een SSL certificaat voor aan te vragen. Wat kan je daar dan mee? Wat is je concrete plan of attack?

[Orion84]

JCE schreef op woensdag 16 maart 2016 @ 11:20:
Ja maar ho even, wat dan? Dan heb je een SSL certificaat voor een site met een brakke Joomla / Wordpress installatie. Er vanuit gaande dat het je inderdaad lukt om precies de URL te bakken zoals het ACME protocol hem voorschrijft, en je alle honderd andere problemen weet te overkomen die daar ook nog bij kunnen kijken.

Deze aanvalsmethode is niet zo makkelijk als we voor dit voorbeeld graag voordoen.

Maar stel dat dat lukt. En dan? Heb je zijn site veiliger gemaakt door er een SSL certificaat voor aan te vragen. Wat kan je daar dan mee? Wat is je concrete plan of attack?

Op een rogue access point, of via DNS spoofing etc. nietsvermoedende bezoekers van die site omleiden naar een kwaadaardige phishing / malware site (die dankzij het certificaat wel vertrouwd overkomt). Omdat jij het certificaat hebt aangevraagd beschik jij als aanvaller dus over het bijbehorende sleutelpaar en kan je je in communicatie voordoen als de website in kwestie.

[hackerhater]

Orion84 schreef op woensdag 16 maart 2016 @ 11:27:
Op een rogue access point, of via DNS spoofing etc. nietsvermoedende bezoekers van die site omleiden naar een kwaadaardige phishing / malware site (die dankzij het certificaat wel vertrouwd overkomt). Omdat jij het certificaat hebt aangevraagd beschik jij als aanvaller dus over het bijbehorende sleutelpaar en kan je je in communicatie voordoen als de website in kwestie.

Het kan ja, maar als je een site al tot code-niveau kan hacken, wat houd je dan tegen om niet de site zelf te besmetten en zo info te onderscheppen?
Waarom dan zo moeilijk doen met valse certificaten als je al volledige toegang hebt?

[Bor]

JCE schreef op woensdag 16 maart 2016 @ 11:20:
Ja maar ho even, wat dan? Dan heb je een SSL certificaat voor een site met een brakke Joomla / Wordpress installatie.

Daarom stel ik ook duidelijk dat alle software fouten bevatten die mogelijk ge-exploit kunnen worden. Je moet het breder zien dan alleen iemands "hobby" joomla projectje (en ook dat kan van grote waarde voor iemand zijn).

Maar stel dat dat lukt. En dan? Heb je zijn site veiliger gemaakt door er een SSL certificaat voor aan te vragen. Wat kan je daar dan mee? Wat is je concrete plan of attack?

Een certificaat is niet alleen om encryptie van de verbinding mogelijk te maken maar ook om de athenticiteit van een website aan te tonen; communiceer ik wel met de webserver waar ik denk mee te communiceren. Afhankelijk van de website waarvoor je een malafide certificaat aan zou kunnen vragen kun je hier heel interessante dingen mee doen.

hackerhater schreef op woensdag 16 maart 2016 @ 11:30:
[...]


Het kan ja, maar als je een site al tot code-niveau kan hacken, wat houd je dan tegen om niet de site zelf te besmetten en zo info te onderscheppen?
Waarom dan zo moeilijk doen met valse certificaten als je al volledige toegang hebt?

Daar heb je wellicht wat aan totdat de site opnieuw wordt ingericht of totdat men jouw hack ontdekt. Een certificaat behorende bij jouw eigen gemaakte keypair kan zo veel interessanter zijn, zeker wanneer er niet op revocation wordt gecontroleerd.

[ Voor 23% gewijzigd door Bor op 16-03-2016 11:34 ]

[hackerhater]

Bor zie wat ik net zei :

Het kan ja, maar als je een site al tot code-niveau kan hacken, wat houd je dan tegen om niet de site zelf te besmetten en zo info te onderscheppen?

Als je op een brakke site dat kan doen heb je al volledige controle over die website en is die site niet meer te vertrouwen. Of er een SSL-cert voor staat of niet!

[Orion84]

hackerhater schreef op woensdag 16 maart 2016 @ 11:30:
[...]


Het kan ja, maar als je een site al tot code-niveau kan hacken, wat houd je dan tegen om niet de site zelf te besmetten en zo info te onderscheppen?
Waarom dan zo moeilijk doen met valse certificaten als je al volledige toegang hebt?

Omdat je, zodra je dat certificaat eenmaal hebt, de aanval kan voortzetten compleet buiten die site om en dus veel minder risico loopt om ontdekt te worden en veel vrijer bent in wat je allemaal er mee kan doen.

Gewoon de gehackte site misbruiken kan inderdaad zeker ook, maar er zijn best wel redenen te bedenken waarom het interessant kan zijn om een certificaat te verkrijgen voor andermans site.

[ Voor 3% gewijzigd door Orion84 op 16-03-2016 11:36 ]

[hackerhater]

Dat kan zeker, maar dat verwacht je eerder bij grotere sites a la ing en die draaien niet op troep als wordpress.
Maar dit gevaar geld voor elke cert-boer die DV-certificaten uit deelt, niet puur voor Let's Encrypt.
Daarom zou ik voor de grotere sites ook EV-certificaten adviseren & een IT-afdeling die constant de sites in de gaten houd dat dit niet kan gebeuren.

[Bor]

hackerhater schreef op woensdag 16 maart 2016 @ 11:33:
Bor zie wat ik net zei :

[...]


Als je op een brakke site dat kan doen heb je al volledige controle over die website en is die site niet meer te vertrouwen. Of er een SSL-cert voor staat of niet!

Je kijkt veel te beperkt. Zodra je het certificaat hebt kun je dit exploiten buiten de betreffende site om, ongeacht of de betreffende site gepatched of opnieuw ingericht is op een later moment.

[ Voor 6% gewijzigd door Bor op 16-03-2016 11:38 ]

[Orion84]

hackerhater schreef op woensdag 16 maart 2016 @ 11:37:
Dat kan zeker, maar dat verwacht je eerder bij grotere sites a la ing en die draaien niet op troep als wordpress.
Maar dit gevaar geld voor elke cert-boer die DV-certificaten uit deelt, niet puur voor Let's Encrypt.
Daarom zou ik voor de grotere sites ook EV-certificaten adviseren & een IT-afdeling die constant de sites in de gaten houd dat dit niet kan gebeuren.

Klopt, ik reageerde ook met name op JCE in "Let's Encrypt! Hoeveel vertrouwen hebben jullie?" hè, die zich afvroeg wat je met zo'n rogue certificaat kan.

Dat in de praktijk lang niet elke random wordpress site even interessant is om er de identiteit van te kapen (want dat is wat je uiteindelijk doet), dat ben ik wel met je eens. Maar het blijft een risico met automatisch uitgegeven DV certificaten, dat de controle in sommige gevallen te omzeilen is als je tot op zekere hoogte 'binnen' bent bij de slachtoffer site.

En dat is inderdaad precies de reden dat je voor belangrijkere zaken EV certificaten wilt gebruiken. Het vervelende is natuurlijk wel dat het voor de gebruiker niet altijd even helder is wat het verschil is en wanneer het wel en niet te vertrouwen is.

[ANdrode]

Bor schreef op woensdag 16 maart 2016 @ 11:32:
[...]
Daar heb je wellicht wat aan totdat de site opnieuw wordt ingericht of totdat men jouw hack ontdekt. Een certificaat behorende bij jouw eigen gemaakte keypair kan zo veel interessanter zijn, zeker wanneer er niet op revocation wordt gecontroleerd.

Ok dan gaan we ff door over revocation in het algemeen

Als je de netwerk positie voor een MITM hebt dan kan je ook de revocation checks blokkeren. Mozilla haar documentatie geeft aan dat "OCSP responders are not yet reliable enough for us to do hard fail".

Wij leven dus in een wereld waar revocation niet werkt.
Wat zijn mitigations:

• Het zichtbaar maken dat er een certificaat geissued is, certificate transparency
• Kort gebruik van een private key (90d, 1y, 2y, ...)
• Meer zekerheid bij certificaten

Ik vind dat LE hierin een proces heeft dat de status quo op twee van deze punten verbeterd. De ACME client genereert elke keer een nieuwe private key en de certificaten worden gelogd.

Het goedkoop maken van certificaten door middel van het automatiseren van het uitgifte proces van certificaten zorgt voor privacy voor veel mensen.

Door betere validatie bieden EV certificaten zekerheid over de identiteit van de aanvrager van het certificaat. Als je daarna ook technische middelen gebruikt, door bijvoorbeeld met een header aan te geven dat je altijd een EV more green = better CA - G3 certificaat gebruikt, dan kan een aanvaller, met een mis-issued cert van een willekeurige andere CA, niets tegen terugkomende bezoekers.

Helaas blijven de social engineering aanvallen over. Niemand beschermd mij als ik op https://mijn.ing.nl klik.

[ Voor 0% gewijzigd door ANdrode op 16-03-2016 12:16 . Reden: Provocerende CA naam was niet nodig :X ]

[Bor]

ANdrode schreef op woensdag 16 maart 2016 @ 12:15:
[...]
Wij leven dus in een wereld waar revocation niet werkt.
Wat zijn mitigations:
[list]
• Het zichtbaar maken dat er een certificaat geissued is, certificate transparency

Zonder online verificatie is dit evenveel waard als een CRL denk ik. Immers, wanneer je daar ook niet hard op failed blijft een handmatige controle van een lijst met certificaten over.

• Kort gebruik van een private key (90d, 1y, 2y, ...)

Dit beperkt alleen het risico maar haalt het risico niet weg. Zeker niet als je 1y of 2y als kort gebruik bestempeld.

Het goedkoop maken van certificaten door middel van het automatiseren van het uitgifte proces van certificaten zorgt voor privacy voor veel mensen.

Privacy is een groot goed. Bij certificaten draait het echter om vertrouwen. Je wilt met een certificaat de authenticiteit aantonen maar hanteert in dit geval alleen een zeer beperkt aantal (zwakke?) en geautomatiseerde controles. Het een gaat niet goed samen met het ander.

Dat er betere validatie mogelijk is (bv bij EV certificaten) is een bekend gegeven. Het probleem is echter dat een doorsnede consument / gebruiker het verschil niet kan zien: "Een slotje is immers veilig toch?"

Dit is overigens geen nadeel van Let's Encrypt in het algemeen maar van de huidige implementatie van PKI en het steeds verder afzwakken van de vereisten om een certificaat te verkrijgen.

[ Voor 6% gewijzigd door Bor op 16-03-2016 12:31 ]

[ANdrode]

Bor schreef op woensdag 16 maart 2016 @ 12:30:
[...]
Zonder online verificatie is dit evenveel waard als een CRL denk ik. Immers, wanneer je daar ook niet hard op failed blijft een handmatige controle van een lijst met certificaten over.

Ook zonder online verificatie kan je als eigenaar van een domein zien dat er ongeautoriseerd een certificaat is uitgegeven.

De browsers willen naar online verificatie toe. Chrome doet dit EV certificaten. Voor zover ik weet doen enkel LE en sinds kort Symantec aan CT voor niet-EV certificaten.

Symantec had "als test" een paar EV google.com certificaten gemaakt. Ik denk dat Google hierna een beetje boos was...

Dit beperkt alleen het risico maar haalt het risico niet weg. Zeker niet als je 1y of 2y als kort gebruik bestempeld.

Ik vind één of twee jaar al heel erg lang. Het is wel korter dan eerst (3-5 jaar).
Met marginale kosten per certificaat en een handmatig uitgifte proces zijn kortdurende certificaten niet aantrekkelijk. Met het geautomatiseerde proces voor DV wél.

Privacy is een groot goed. Bij certificaten draait het echter om vertrouwen. Je wilt met een certificaat de authenticiteit aantonen maar hanteert in dit geval alleen een zeer beperkt aantal (zwakke?) en geautomatiseerde controles. Het een gaat niet goed samen met het ander.

Toch hebben DV certificaten een toegevoegde waarde. De aanvrager van het certificaat had rond het moment van aanvragen controle over de site/email/DNS van de domeinnaam.

Hiermee bescherm je tegen "die hacker die ook op wifi in de trein" zit. Of "de host waar je heen gaat omdat er een malicious DNS server op jouw router is ingesteld".

Ik vind dat een groter risico dan dat de gevallen waarin er onterecht een certificaat wordt uitgegeven.

Dat er betere validatie mogelijk is (bv bij EV certificaten) is een bekend gegeven. Het probleem is echter dat een doorsnede consument / gebruiker het verschil niet kan zien: "Een slotje is immers veilig toch?"

Dit is overigens geen nadeel van Let's Encrypt in het algemeen maar van de huidige implementatie van PKI en het steeds verder afzwakken van de vereisten om een certificaat te verkrijgen.

Dat is inderdaad een UI probleem. Dit kan nog veel beter en browsers zijn hier actief mee bezig.


Firefox Security Indicators

[Thc_Nbl]

Ik vind lets encrypt een prima toevoeging, wat ik eigenlijk hier nergens iets over zie of hoor.
Het maakt niet uit wat voor certificaat of instantie je gebruikt, gezien XX% van de mensen hun webservers bar slecht configureren en dat zelfde geld ook voor mail servers.
Als iedereen nu daar eens mee begint, met zich conformeren aan de internet standaarden.

het is b.v. belachelijk dat in dit voorbeeld.
https://www.digid.nl
of
https://digid.nl

2 verschillende configuraties draaien, waarbij de "digid.nl" een minder goed geconfigureerde server heeft staan, terwijl we daar op inloggen.

ander voorbeeld. rabobank mail configuratie, ja, ze gebruiken SPF, maar wordt niet afgedwongen. (~ivp - )
gevolg, spammers mogen hun naam misbruiken, echt zo wordt de boel de naar de kl.te geholpen.

dus, al met al, leuk certificaten, maar zonder goede configuratie erachter heeft het weinig zin.

paar sites om zelf eens even te kijken hoe je het gedaan hebt.
https://www.htbridge.com/ssl/
https://www.ssllabs.com/

Wat ik met die "malware" dingen veel gevaarlijkere vind..
Gevirtualiseerde malware, dat is pas een probleem aan het worden..

[Bor]

ANdrode schreef op woensdag 16 maart 2016 @ 12:53:
[...]

Ook zonder online verificatie kan je als eigenaar van een domein zien dat er ongeautoriseerd een certificaat is uitgegeven.

Wat zou je in dat geval willen doen? Er van uitgaande dat het certificaat al is uitgegeven heb je een groot probleem wanneer software niet op revocation controleert. Het certificaat blijft dan immers min of meer geldig tot zijn geldigheidstermijn is verstreken.

Ik vind één of twee jaar al heel erg lang. Het is wel korter dan eerst (3-5 jaar).

Helemaal eens

[begintmeta]

Bor schreef op woensdag 16 maart 2016 @ 13:26:
...
Wat zou je in dat geval willen doen? ...

Ervoor zorgen dat de softwareleveranciers het bewuste (intermediate)CA-certificaat niet meer includeren natuurlijk

[Bor]

begintmeta schreef op woensdag 16 maart 2016 @ 13:39:
[...]

Ervoor zorgen dat de softwareleveranciers het bewuste (intermediate)CA-certificaat niet meer includeren natuurlijk

In hoeverre is dat een oplossing voor een enkel foutief uitgegeven end user certificaat of bijvoorbeeld een key compromise?

[ANdrode]

Bor schreef op woensdag 16 maart 2016 @ 13:26:
[...]
Wat zou je in dat geval willen doen? Er van uitgaande dat het certificaat al is uitgegeven heb je een groot probleem wanneer software niet op revocation controleert. Het certificaat blijft dan immers min of meer geldig tot zijn geldigheidstermijn is verstreken.

In een scenario waar geen kwaadwillende aanvaller is werkt OCSP gelukkig wel (key compromise).

Als een CA verkeerde certificaten uitgeeft dan moet de organisatie aan zijn auditors en aan de browsers wat er mis is gegaan. Bij Symantec zie je dat Google nu extra eisen stelt.

Wanneer een incident veroorzaakt wordt door een fout in het systeem dan is publiek bespreken de oplossing. Als een CA geen goede uitleg heeft dan moet je hem verwijderen uit de root store en actief blacklisten...

[Muggie]

Hetgeen me het meeste opvalt aan LE is dat om de initiële goedkeuring en het automatische proces van vernieuwen van certificaten goed te laten werken poort 80 richting je webserver open moet staan en dat is volgens mij juist iets wat je niet wilt. Of kan iemand me een stukje documentatie wijzen waarin staat dat dat geen vereiste is, ik kan het niet vinden.

[begintmeta]

Zou je de 'standalone-procedure' misschien kunnen scripten?

[Bor]

hackerhater schreef op woensdag 16 maart 2016 @ 10:54:
[...]


Nou? Als ik naar de logs van onze servers kijk is zeker 90% van de server2server SMTP tegenwoordig versleuteld.

En heb je het dan over server to server binnen de eigen organisatie of ook daarbuiten (gezien het op internet nog altijd clear text smtp is wat de klok slaat)?

[hackerhater]

Bor schreef op woensdag 23 maart 2016 @ 13:16:

En heb je het dan over server to server binnen de eigen organisatie of ook daarbuiten (gezien het op internet nog altijd clear text smtp is wat de klok slaat)?

Naar buiten toe natuurlijk. De grote partijen (google, MS, etc) doen ondertussen aan encryptie waardoor een groot deel van de onze email versleuteld wordt.

[CyBeR]

Bor schreef op woensdag 23 maart 2016 @ 13:16:
[...]


En heb je het dan over server to server binnen de eigen organisatie of ook daarbuiten (gezien het op internet nog altijd clear text smtp is wat de klok slaat)?

Op internet gaat 't grootste deel tegenwoordig ook via TLS. Echter is dat wel oppertunistic TLS waarbij zulke dingen als de geldigheid niet geverifieerd worden. (Het alternatief is namelijk inderdaad plaintext afleveren wat sowieso als slechter geldt dan TLS met verificatiefouten.)

[Bor]

CyBeR schreef op woensdag 23 maart 2016 @ 17:07:
[...]


Op internet gaat 't grootste deel tegenwoordig ook via TLS. Echter is dat wel oppertunistic TLS waarbij zulke dingen als de geldigheid niet geverifieerd worden. (Het alternatief is namelijk inderdaad plaintext afleveren wat sowieso als slechter geldt dan TLS met verificatiefouten.)

Dat er gebruik wordt gemaakt van TLS is bekend maar in de praktijk lijkt het nog niet zo hard te gaan. Google geeft bijvoorbeeld aan dat "83 procent van uitgaande en 69 procent van inkomende Gmail-berichten is versleuteld". Dat gaat nog niet zo hard dus.

Bron; nieuws: Internetbedrijven willen e-mailbeveiliging via smtp verbeteren

[begintmeta]

Uiteindelijk zou u2u-versleuteling natuurlijk ook het beste zijn (behalve voor de metadata, maar dat probleem wordt ook door s2s tls of routeobfuscatie natuurlijk niet helemaal opgelost (/is vrijwel niet volledig op te lossen)) Voor dnnsec en dane is het sowieso hoogste tijd, andere maatregelen zijn ook prima, maar liggende zaken implementeren is ook wat waard.

[CyBeR]

Bor schreef op donderdag 24 maart 2016 @ 10:34:
[...]


Dat er gebruik wordt gemaakt van TLS is bekend maar in de praktijk lijkt het nog niet zo hard te gaan. Google geeft bijvoorbeeld aan dat "83 procent van uitgaande en 69 procent van inkomende Gmail-berichten is versleuteld". Dat gaat nog niet zo hard dus.

Bron; nieuws: Internetbedrijven willen e-mailbeveiliging via smtp verbeteren

Euh, meer dan 80 en net geen 70 procent is toch ruim "het grootste deel" of niet soms?

[begintmeta]

Bor schreef op donderdag 24 maart 2016 @ 10:34:
..."83 procent van uitgaande en 69 procent van inkomende Gmail-berichten is versleuteld". Dat gaat nog niet zo hard dus. ...

Ik ben trouwens ook benieuwd hoeveel berichten Google nooit verlaten. Maakt google intern ook van versleuteling gebruik?

[Bor]

CyBeR schreef op donderdag 24 maart 2016 @ 11:09:
[...]


Euh, meer dan 80 en net geen 70 procent is toch ruim "het grootste deel" of niet soms?

Het is een goed begin maar security wise is nog geen 70% ruim beneden pijl, zeker wanneer je er vanuit gaat dat het niet in alle gevallen om echt volledige native TLS implementaties gaat maar om starttls (vatbaar voor o.a. downgrade aanvallen). Er is nog veel te verbeteren op dit vlak.

[CyBeR]

Het gaat zelfs in geen enkel geval om TLS-on-connect. De enige manier om dit te doen is STARTTLS, tenzij je geen mail wilt ontvangen.

Zoals ik al zei 't is opportunistic. Er is (nog) geen manier om aan te geven dat je TLS verplicht.

[ Voor 27% gewijzigd door CyBeR op 24-03-2016 12:19 ]

[Bor]

Kortom, van beperkte waarde en niet breed genoeg geïmplementeerd.Het is hooguit een stap in de goede richting maar we zijn er nog (lang) niet.

[thepeppi]

Naar mijn idee zijn de goedkope certs uberhaupt niet veilig genoeg en ik denk dat er zat mensen op deze aardkloot rondlopen die deze zelf kunnen fabriceren.
Zolang er geen persoonlijke identificatie aan een cert zit lijkt het mij ten alle tijden een frauduleus gevaar in zich te hebben.

Daarintegen is het natuurlijk wel zo dat gegevens niet meer door elke willekeurige scriptkid kan worden onderschept en misbruikt worden.

Dus mijn antwoord op de vraag is tweezijdig

• betrouwbaar omdat het alsnog gecodeerd verzonden wordt
• tegelijkertijd gevoelig zoals elke goedkope cert voor fraude en misbruik

Gebruik ik het op mijn server?
Ja

[Mocro_Pimp®]

Ze zijn het vertrouwen niet waard want de uitgifte bevat te weinig controle's. Er is ook al gebleken dat er SSL certificaten aan malvertising site's zijn uitgegeven. Lets Encrypt haalt in mijn ogen het hele fundament van SSL onderuit, namelijk vertrouwen...

Wat offtopic, je hebt het over vertrouwen in LetsEncrypt wegens weinig controle, maar wat denk je hiervan:

Ik stond net op het punt om een SSL certificaat bij TransIP te bestellen. Een oer Hollands bedrijf. Nederlandse regelgeving m.b.t. dataopslag etc. Ik ben er helemaal fan van.

Maar dan, bij het afrekenen, kom ik dit tegen:

Ik ga akkoord met de algemene voorwaarden van Comodo en accepteer dat de gegevens in het certificaat buiten de Europese Unie worden verwerkt.

Ho, ho, ho. Alle alarmbellen begonnen te rinkelen in mijn hoofd. Is dat wel verstandig?

De Amerikanen hebben de Patriot act waarmee zij al het buitenlands verkeer mogen afluisteren.

Met SSL versleutelde data ben je dan veilig, zou je denken?
Besef dat de inlichtingendiensten ook de SSL-certificaat kunnen bemachtigen van deze Amerikaanse partijen. Daarmee is in feite het vertrouwen gebroken.

Data en encryptiesleutels zijn beiden namelijk door dezelfde partij (de VS-overheid) te bemachtigen, en dus te ontsleutelen.

(en daarmee het halve www)

[_JGC_]

Je draait door. Je genereert een CSR en een sleutel. De sleutel houd je zelf en deel je met niemand, de CSR gaat naar de CA die daarmee een certificaat uitgeeft.

[begintmeta]

_JGC_ schreef op zaterdag 30 december 2017 @ 08:12:
Je draait door. Je genereert een CSR en een sleutel. De sleutel houd je zelf en deel je met niemand, de CSR gaat naar de CA die daarmee een certificaat uitgeeft.

Ik denk dat het er meer om gaat dat de achterliggende sleutels in de keten (van de CAs) kunnen worden gebruikt om zich voor te doen als de partij waarmee men contact legt (men kan zijn eigen sleutel als zijnde voor de bepaalde website van derden laten verificeren (a la diginotar)). Dat is door certificate pinning en dergelijke zaken wel wat te mitigeren, maar uiteindelijk is altijd vertrouwen nodig als je niet via een veilig kanaal rechtstreeks sleutels kan uitwisselen.

[ Voor 7% gewijzigd door begintmeta op 30-12-2017 10:30 ]

[_JGC_]

MitM met een certificaat van een corrupte CA kan altijd, maar feit dat Comodo een Amerikaans bedrijf is betekent niet dat ze op afroep je SSL communicatie kunnen ontsleutelen.

[Jester-NL]

Mocro_Pimp® schreef op zaterdag 30 december 2017 @ 01:45:
[...]

Wat offtopic, je hebt het over vertrouwen in LetsEncrypt wegens weinig controle, maar wat denk je hiervan:

Ik stond net op het punt om een SSL certificaat bij TransIP te bestellen. Een oer Hollands bedrijf. Nederlandse regelgeving m.b.t. dataopslag etc. Ik ben er helemaal fan van.

Maar dan, bij het afrekenen, kom ik dit tegen:

Ik ga akkoord met de algemene voorwaarden van Comodo en accepteer dat de gegevens in het certificaat buiten de Europese Unie worden verwerkt.
(snip)

Ehrm... Lees nou nog eens goed wat er staat: de gegevens in het certificaat (in het geval van een DV dus je e-mailadres (dat sowieso of op de site moet staan, of in de whois vindbaar), bij een EV wat meer informatie, allemaal noodzakelijk om het certificaat goed uit te geven) worden buiten de EU verwerkt.
Dat is an sich niet gek, want er moet een certificaat worden gemaakt waar die gegevens in verwerkt staan. En Comodo is nu eenmaal én een Amerikaans bedrijf én de club die over het algemeen zijn certificaten tegen de vriendelijkste prijjzen wegzet.

Wil je er zeker van zijn dat die data niet naar buiten de EU gaan, dan zul je een ander certificaat moeten kiezen. En niet op TransIP mopperen, maar op je eigen oer-Hollandse keus voor het goedkoopste certificaat. Certificaatverstrekkers als Globalsign (Belgisch, zij het tegenwoordig in Japanse handen) of Certum (Pools) zijn de eerste clubs waar ik aan denk. Prijzen zijn dan natuurlijk wel wat anders dan TransIP kan bieden, en omdat het niet (meer) via hun API kan, zal er hoe dan ook handwerk bij komen kijken.

Overigens ben ik redelijk bekend met de SSL-markt, en verwacht ik eerlijk gezegd dat het overgrote deel van de aanvraag in Nederland wordt verwerkt... maar dat neemt natuurlijk niet weg dat het certificaat an sich gewoon een Amerikaans product is en blijft

[Mocro_Pimp®]

Jester-NL schreef op zaterdag 30 december 2017 @ 12:47:
[...]
Ehrm... Lees nou nog eens goed wat er staat: de gegevens in het certificaat (in het geval van een DV dus je e-mailadres (dat sowieso of op de site moet staan, of in de whois vindbaar), bij een EV wat meer informatie, allemaal noodzakelijk om het certificaat goed uit te geven) worden buiten de EU verwerkt.
Dat is an sich niet gek, want er moet een certificaat worden gemaakt waar die gegevens in verwerkt staan. En Comodo is nu eenmaal én een Amerikaans bedrijf én de club die over het algemeen zijn certificaten tegen de vriendelijkste prijjzen wegzet.

Wil je er zeker van zijn dat die data niet naar buiten de EU gaan, dan zul je een ander certificaat moeten kiezen. En niet op TransIP mopperen, maar op je eigen oer-Hollandse keus voor het goedkoopste certificaat. Certificaatverstrekkers als Globalsign (Belgisch, zij het tegenwoordig in Japanse handen) of Certum (Pools) zijn de eerste clubs waar ik aan denk. Prijzen zijn dan natuurlijk wel wat anders dan TransIP kan bieden, en omdat het niet (meer) via hun API kan, zal er hoe dan ook handwerk bij komen kijken.

Overigens ben ik redelijk bekend met de SSL-markt, en verwacht ik eerlijk gezegd dat het overgrote deel van de aanvraag in Nederland wordt verwerkt... maar dat neemt natuurlijk niet weg dat het certificaat an sich gewoon een Amerikaans product is en blijft

Waar het mij om gaat is niet de publiciteit van de mijn openbare gegevens, maar het feit dat de encryptiesleutel onder de Patriot act zijn te bemachtigen door de overheid aldaar. Zelfs de uitgever van het certificaat kan tegen een dergelijk oproep niet in beroep en moet erover zwijgen. Zulk nieuws is al vaak langsgekomen op Tweakers.

[begintmeta]

_JGC_ schreef op zaterdag 30 december 2017 @ 10:42:
MitM met een certificaat van een corrupte CA kan altijd, maar feit dat Comodo een Amerikaans bedrijf is betekent niet dat ze op afroep je SSL communicatie kunnen ontsleutelen.

Nee, wel dat je waakzaam moet blijven dat het certificaat inderdaad hoort bij degene bij wie het hoort. Een CA heeft geen waarde meer als je er niet op kan vertrouwen, als je waakzaam moet blijven ben je uiteindelijk je eigen CA.

Mocro_Pimp® schreef op zaterdag 30 december 2017 @ 17:13:
... het feit dat de encryptiesleutel onder de Patriot act zijn te bemachtigen door de overheid aldaar. ...

Maar dat is niet zo, eventueel zijn wel de signing keys van de CA te bemachtigen, maar de encryptiesleutel zelf hoef je niet zomaar uit handen te geven, en daarover beschikt de CA ook niet.

[Mocro_Pimp®]

[...]

Maar dat is niet zo, eventueel zijn wel de signing keys van de CA te bemachtigen, maar de encryptiesleutel zelf hoef je niet zomaar uit handen te geven, en daarover beschikt de CA ook niet.

Weet je misschien een plek waar ik meer hierover kan lezen?

[begintmeta]

Mocro_Pimp® schreef op zaterdag 30 december 2017 @ 18:24:
Weet je misschien een plek waar ik meer hierover kan lezen?

Zoals _JGC_ ook al aangaf: je maakt een CSR voor de sleutel die je wil gebruiken, de onderliggende private key maak en hou je in eigen beheer. Meer info moet niet lastig te vinden zijn, normaalgesproken heeft de CA informatie over hoe je een CSR moet indienen (comodo bijvoorbeeld), en ook verder (bijvoorbeeld in combinatie met openssl en dergelijke sleutelwoorden) zal het niet lastig zijn informatie te vinden.

[ Voor 13% gewijzigd door begintmeta op 30-12-2017 18:54 ]

[Jester-NL]

Comodo heeft, na je aanvraag, jou CSR, het certificaat signing request. Dat is een afgeleide van je private key, maar niet de private key zelf.
Die private key bestaat alleen op de server waar jij de CSR hebt aangemaakt (en eventueel de systemen waar jij die privte key naartoe exporteert).
De CA heeft nooit de private key (tenzij jij die aan ze overhandigd, in welk geval een goeie CA je zal vertellen een nieuwe CSR aan te maken en de private key zelf te bewaren)

Met andere woorden, er is met willekeurig welke amerikaanse wet niet aan een decryptie van je certificaat te komen. Doet Comodo daar wel aan, dan is dat een achterdeur in hun software, niet jouw CSR, en kunnen ze gevoegelijk hun hele toko sluiten, want ze belazeren het vertrouwen van hun klanten.

Nogmaals, genoemde disclaimer heeft te maken met de gegevens die jij als klant moet achterlaten en doorgeven en totaal niets met de werking van het certificaat.

Je zou voor een begin over heo SSL werkt hier eens naar kunnen kijken: https://www.websecurity.s...o-SSL-certificates_WP.pdf

offtopic:
@Mocro_Pimp®: Wat me nu een beetje ontgaat, is waarom je een topic over Let's Encrypt (in zijn algemeenheid) hebt gekickt met een vraag die helemaal niet gaat over LE, maar over het bestelproces van een niet-gerelateerde CA.

[ Voor 9% gewijzigd door Jester-NL op 31-12-2017 10:27 ]

[iisschots]

Ik stel voor wil je hier verder over spreken je een nieuw topic opent