Ik houd er alleen niet van dat een script root rechten nodig heeft om allerlei bestanden te kopieren naar voor mij onbekende plekken. Software op mijn servers komt er alleen op via de package manager van het systeem, anders niet.

Ik werd gebeld door iemand die zich uitgaf als medewerker van een niet nader te noemen geheime dienst (kan best een zware cybercrimineel geweest zijn die zich voordeed als) met de vraag: gegeven bestaande https websites (DNS is dan wat lastiger), hoe kunnen wij verkeer daarmee aftappen - gebruik makend van Let's Encrypt?

Omdat ik niemand voordeel wil geven publiceer ik mijn antwoord ook maar hier.

Dat hangt ervan af. Als u toegang heeft tot een router (of bijv. onderzeese kabel die u opensnijdt en er een bridge-achtig device tussenplaatst), die zich bevindt tussen de server van Let's Encrypt en de webserver die u af wilt luisteren, is het een eitje om zo'n certificaat te krijgen.

Idioot maar illustratief voorbeeld: stel u bent de NSA en wilt verkeer tussen Nederlanders en digid.nl aftappen. U boft want die Let's Encrypt server staat toevallig (?) in de USA! (Maar ook als u van de Turkse geheime dienst bent en verkeer van "ruimdenkende" Turken met een https server van een niet-regerende politieke partij wilt kunnen afluisteren, vindt u vast wel een geschikt tappunt tussen die webserver en Let's Encrypt).

(1) Regel toegang tot een router die zich ergens tussen de Let's Encrypt server en de Digid.nl server bevindt (veel internet backbone routers hebben sowieso achterdeurtjes voor allerlei partijen - met vaak zwakke wachtwoorden of onbedoelde kwetsbaarheden). Zorg ervoor dat het bedoelde Let's Encrypt verkeer daadwerkelijk door "uw" router wordt geleid (bijv. middels BGP trucs, desnoods via DDoS aanvallen op alternatieve-route-routers of websites "daarachter").

(2) Hang daar een tijdelijke webserver aan. Configureer de router zo dat verkeer tussen de te spoofen webserver (digid.nl) en Let's Encrypt naar uw webserver wordt geleid. Uw webserver geeft u natuurlijk het IP-adres van de te spoofen webserver, zodat Let's Encrypt deze niet kan onderscheiden van de echte server.

(3) Hetzelfde als (3) in mijn eerste bijdrage. U heeft nu een certificaat voor digid.nl (met de bijbehorende private key in uw bezit) dat er in de browsers van bezoekers precies hetzelfde uitziet als de echte digid.nl (tot gebruikers het certificaat zelf inspecteren en geen PKI overheid zien, maar dat doet/snapt toch geen normaal mens).

(4) Vervolgens zult u een MitM aanval moeten uitvoeren op de gebruikers die u wilt aftappen. Toegang tot een router zo dicht mogelijk in de buurt van de echte digid.nl verdient de voorkeur, daar bereikt u de meeste gebruikers mee. In het geval van individuele gebruikers kunt u natuurlijk ook de ISP dwingen tot medewerking, of de modem-router van de gebruiker hacken en van aangepaste DNS-server instellingen voorzien (modem-routers zonder backdoor zijn schaars). Zodra de gebruiker naar digid.nl surft, laat u uw DNS server het IP adres van uw neppe digid.nl server retourneren.

(5) Enjoy.

P.S. @ Logius: wordt het geen tijd dat digid.nl een EV-cert krijgt? Desnoods niet PKI-Overheid?

Is er ook maar IETS waardoor dit voordat letsencrypt bestond niet mogelijk zou zijn?

Je kunt beter niet jouw e-mail adres op een forum publiceren, want dat leidt tot heel veel spam. Ik raad je aan bovenstaande bijdragen te editten en jouw e-mail adres te verwijderen (ik heb het genoteerd - mocht dat nog nodig zijn).

M.b.t. jouw vraag: waar gaat die over en waarom stel je die niet op dit forum?

@Erik: Wat je beschrijf is niet zo zeer een probleem van LE maar een probleem met alle DV certificaten.
Tuurlijk heeft een grote uitbreiding van het aantal DV certificaten effect op de betrouwbaarheid van HTTPS in het algemeen maar het grote voordeel zit hem in een afname van het aantal geintjes wat nu wordt uitgehaald met HTTP:
Baidu’s traffic hijacked to DDoS GitHub.com
http://insight-labs.org/?p=1682
Hotspots AT&T injecteren advertenties in wifi-verkeer
https://www.security.nl/posting/441059/Hotspots+AT%26T+injecteren+advertenties+in+wifi-verkeer
Israeli Firm Strong-Arms Indian Techie for Exposing Suspicious Code
http://thewire.in/2015/06/09/israeli-firm-strong-arms-indian-techie-for-exposing-suspicious-code-3528/
A network error routed traffic for the UK's nuclear weapons agency through Russian telecom
http://www.theverge.com/2015/3/13/8208413/uk-nuclear-weapons-russia-traffic-redirect

Ik snap jullie argumenten niet.
het spoofen van websites kan ook -en het is zelfs gemakkelijker- zonder letsencrypt.

mitm attacks zijn eenvoudiger uit te voeren zonder letsencrypt. Voor die sites die meer willen dan eenvoudige en gratis versleuteling en beschermd willen zijn tegen mitm attacks zijn er EV certificaten.

het mitm argument gaat verder voorbij aan het feit dat er wel degelijk checks worden uitgevoerd ter controle of de server (en domein) waar het certificaat voor wordt aangevraagd wel juist is, zie https://letsencrypt.org/howitworks/technology/

Ergo, letsencrypt maakt het zeer sterk eenvoudiger om http verkeer te versleutelen en dat is alleen maar goed. ik ga het zeker gebruiken als alternatief voor sslstart en cacert.

Ik zeg overigens niet dat SSL/TLS en het hele systeem van CA's en certificaat uitgifte _veilig_ is. ga er maar van uit dat de grote CA's samen werken met de NSA en dat het voor hen niet moeilijk is om willekeurig welke https site na te bootsen.

Het maakt niet zoveel uit, iedere organisatie die een root CA beheerd kan potentieel een mit
uitvoeren. Er is vrijwel niemand die voor iedere secure verbinding zelf controleert of de certificate chain is zoals je deze verwacht. Hierop is het systeem nl niet op gebaseerd. Het systeem is gebaseerd op vertrouwen in de CAs. Wanneer je dit niet hebt, kunnje net zo goed niet over een certificate based kanaal verbinden.

Nee. Als je een willekeurige CA hacked (zoals destijds DigiNotar) kun je elk certificaat aanmaken dat je wilt.

De eenvoudigste manier tot nu toe was een commercieel DV (Domain Validated) certificaat. Ook die zijn waardeloos.

Echter, Let's Encrypt maakt het misbruikers nog eenvoudiger:
- Geen e-mail verkeer, dus minder traceability
- Geen money-trail
- Werkt meteen.

https://login.utwente.nl/ (130.89.150.175) gebruikt een DV certificaat;
https://login.utvvente.nl/ (149.202.136.79) gebruikt een Let's Encrypt certificaat (uitgegeven afgelopen zaterdag).

Off topic: interessant is dat de phishing site TLS goed geconfigureerd heeft, terwijl de echte site, op z'n zachtst gezegd, "beter kan" (Grade F: Poodle, RC4, alleen TLS 1.0, SHA1 certs: https://www.ssllabs.com/ssltest/analyze.html?d=login.utwente.nl).

Conclusie: gratis zorgt ervoor dat een hele nieuwe groep serieuze gebruikers, maar ook "grappenmakers" (het kost toch niks) - die wel degelijk phishen, zich op Let's Encrypt storten. Zie de groeiende lijst op https://crt.sh/?Identity=%25&iCAID=7395.

Dit kan ook allemaal zonder Let's Encrypt.
Waardeloze toevoeging voor het forum als u het mij vraagt.

Had je ook gewoon met een gratis geen money-trail certificaat van cacert of startssl kunnen doen. En hoeveel is die tracebility via e-mail waard als je de mailbox host op die phishing server?. Ok ik geef je Werkt meteen, bij de door mij aangedragen ca's duurt het een uurtje.

Iedereen die ook maar het geringste idee heeft dat een ssl certificaat (de eigenaar van) een server betrouwbaar maakt dient onmiddellijk beter te worden voorgelicht.

Certificaten uitgegeven door CAcert worden standaard niet vertrouwd door browsers, en het is nog maar de vraag of je van startssl.com een gratis certificaat voor https://login.utvvente.nl/ kunt krijgen (volgens https://www.startssl.com/policy.pdf pagina 16 vindt een check plaats op misleidende domainnames en verwarren van w met v v is een bekende phishing techniek).

Niets, maar niet op elke gehackte server kun je zomaar een mailserver-service installeren. Bij Let's Encrypt heb je die hele mailbox niet nodig - simpeler dus.

Uit https://blog.mozilla.org/security/2015/11/03/updated-firefox-security-indicators-2/: Je mag beginnen bij deze meneer.

Echter, de discussie in deze thread gaat niet over de betrouwbaarheid van een webserver of diens beheerder, maar over de betrouwbaarheid waarmee een willekeurige bezoeker de identiteit van een webserver kan vaststellen.

Gegeven een gebruiker die de domainname kent en controleert (in de URL-balk), vind ik het een vereiste dat die gebruiker zeker weet dat er geen MitM aanval plaats kan vinden (encryptie is zinloos als je niet precies weet met wie je praat). Validatie, die volledig afhankelijk is van de betrouwbaarheid van DNS en/of routering, is dan echt onvoldoende (waarvoor ik eerder in deze thread argumenten heb aangedragen).

En, als je phishing serieus wilt bestrijden (dus klinkt-als domainnames, andere TLD's etc. o.a. in e-mails), is de essentie van een servercertificaat dat een bezoeker, die een specifieke domainname nog nooit bezocht heeft (of niet vaak bezoekt), op basis van dat certificaat ook betrouwbaar kan vaststellen van welke organisatie die webserver is (toegegeven, de betrouwbaarheid van CA' s is een vereiste en moet beter, maar het concept "Notaris" gebruiken we al heel lang en beschouwen we als een onmisbare trusted third party bij allerlei transacties zoals het kopen van een huis).

Interessant is dat https://blog.mozilla.org/ een "gewoon" certificaat gebruikt (qua betrouwbaarheid tussen DV en EV in), terwijl Firefox het verschil met een DV certificaat niet meteen laat zien. Pas als je het certificaat oproept en inspecteert zie je (naast "CN=blog.mozilla.org") onder Subject: "O=Mozilla Foundation, L=Mountain View, ST=California, C=US". Let's Encrypt certificaten hebben slechts een "CN=" veld onder Subject.

Commerciële DV certificaten waren al een heel slecht idee, Let's Encrypt maakt het nog erger.

Nog enkele voorbeelden, vandaag geregistreerd: dl.dropboxusercontent.com.verygood.site, www.nnedre.com.verygood.site en static1.squarespace.com.verygood.site. En, eveneens vandaag geregistreerd: trendhoppersale.nl - is dit nu wel of niet van dezelfde organisatie als trendhopper.nl?

Kijk, nou komen we bij elkaar :-)


Ons verschil van inzicht zit erin dat ik een dv certificaat niet beschouw als teken van de betrouwbaarheid van een website of de identiteit van de server waar deze op draait, het zegt me alleen maar dat de verbinding tussen mijn browser en het systeem waar ik verbinding mee maak versleuteld is. Dat mensen ten onrechte wijsgemaakt wordt dat het meer is dan dat, is het echte probleem. Foutieve aannames dienen gecorrigeerd te worden, het proberen te voorkomen van de effecten van foutieve aannames is geen structurele oplossing.Daar kan ik weinig tegen inbrengen. Maar wellicht is het beter dat nu echt duidelijk wordt hoe veel/weinig waarde dv certificaten hebben. Let's Encrypt is niet de oorzaak van het probleem het maakt het probleem alleen zichtbaarder. De oplossing moet bij de oorzaak van het probleem worden gezocht.

Een combinatie van HSTS en Public Key Pinning met DANE zou al heel wat verbetering brengen, dan hebben aanvallen op de routering cq MITM in de meeste gevallen geen zin meer.

Je kunt ook public key pinning doen met Firefox en Chrome zonder DNSSEC:

https://developer.mozilla.org/en-US/docs/Web/Security/Public_Key_Pinning

(dit werkt voor frequente bezoekers van een website)

____

Over DV-certs, als antwoord op post van Erik van Straten.

Ik zie hoe dan ook niet het probleem met gratis DV-certs.

Als je beheer hebt over domein naam kun je al makkelijk niet gratis certificaat met false creditcard bestellen.

Een servercertificaat heeft echt niets te maken met of een verbinding tussen browser en server wel of niet versleuteld is (en als die verbinding versleuteld is, zegt zo'n certificaat niets over de kwaliteit daarvan).

De enige en indirecte relatie die tussen een certificaat en versleuteling van de verbinding kan bestaan, is als de (symmetrische) sleutel voor encryptie van de verbinding, door de browser met de public key uit het certificaat wordt versleuteld om deze veilig (via de op dat moment nog niet versleutelde verbinding met de server) naar de server te kunnen sturen; dit is bijv. een RSA key exchange.

Echter, als ik me niet vergis, configureert de Let's Encrypt client webservers zodanig dat deze de voorkeur geven aan Diffie-Hellmann key exchange; niets uit het certificaat heeft daarbij ook maar iets met de verbinding te maken. Het enige doel van het servercertificaat is dan authenticatie van de server.

Die authenticatie hoort ervoor te zorgen dat jij een MitM aanval kunt detecteren. Echter, met Let's Encrypt kan een aanvaller zo'n servercertificaat verkrijgen door een MitM aanval uit te voeren tijdens het aanvragen van het certificaat, waarna die aanvaller zich eenvoudig kan voordoen als de echte server. Een Let's Encrypt certificaat beschermt dus niet tegen MitM aanvallen en is daarmee net zo "waardevol" als een self-signed servercertificaat.