Gebruik je de DNS van je router ?

Je kunt dan evt. problemen omzeilen door in je netwerk settings apart de openDNS te gebruiken (8.8.8.8 bijvoorbeeld).

Let wel : deze DNS servers gaan steeds meer 1024 versleutelde sites blocken omdat het 2048 zou moeten worden, of omdat certificaten verlopen zijn..

Certificaat van Opendns is tot 23-12-2015 geldig; er is niets mis mee. Misschien een instelling op je modem/router?

Stel je surft naar https://www.security.nl/. Als je dan een certificaatfoutmelding te zien krijgt, en het blijkt om een certificaat van opendns.com te gaan, dan betekent dit dat OpenDNS gelogen heeft over het IP-adres van www.security.nl. In plaats van het verwachte IP-adres, heeft OpenDNS jouw PC het IP-adres van een webserver van OpenDNS gegeven. Vertouwende op DNS bouwt jouw webbrowser een verbinding op met een onjuist IP-adres.

Jouw webbrowser geeft vervolgens een certificaatfoutmelding omdat de domainname in de URL balk van jouw webbrowser (nog steeds www.security.nl) niet overeenkomt met de domainname in het ontvangen certificaat (*.opendns.com). Deze foutmelding is volkomen terecht: het enige dat jij weet is dat jouw browser een versleutelde verbinding heeft met een webserver van OpenDNS. De bedoelde verbinding met www.security.nl wordt dus onderschept.

Vermoedelijk werkt die OpenDNS webserver als een proxy server, d.w.z. dat die OpenDNS webserver op zijn beurt, als client, een verbinding opzet met www.security.nl. Waarschijnlijk is ook dat een https verbinding, maar dat weet jij niet. Ook weet jij niet of er misschien nog meer proxy servers tussen zitten.

En belangrijker, alle informatie die je op dat moment uitwisselt met www.security.nl (of mijn.ing.nl etc.) is in elk geval niet versleuteld op die webserver van OpenDNS, en mogelijk gaat er daarna ook vanalles mis.

Nb. de bedoeling van https is dat je, in de eerste plaats, zeker weet dat jouw webbrowser met een webserver met een specifieke domainname communiceert, en in de tweede plaats, dat de gehele verbinding (van jouw webbrowser tot de bedoelde webserver) versleuteld is.

Waarom zou OpenDNS dit doen? Mogelijkheden die ik kan bedenken:
- OpenDNS zou kwaadaardig kunnen zijn en jou bespioneren/informatie stelen;
- OpenDNS zou zo, ook in https verbindingen, advertenties kunnen injecteren;
- Jij hebt zelf ingesteld dat de betreffende site geblokkeerd moet worden;
- OpenDNS denkt dat er sprake is van malware op die site en blokkeert deze daarom (op deze manier);
- OpenDNS twijfelt over de site en wil met je meekijken om te zien of er sprake is van malware.

Het argument van NedFox, dat OpenDNS op deze manier sites met certificaten met 1024bit RSA sleutels zou blokkeren, kan ik mij niet voorstellen (overtuig me maar met een concreet voorbeeld). Zo lek zijn 1024bit certs nou ook weer niet (er worden nog steeds 1024bit rootcertificaten gebruikt, die vormen een veel interessantere prooi voor aanvallers dan servercertificaten).

Betekend dit dat ik beter de DNS-Servers van de provider kan gebruiken?
Er komt wel een hangslot in de browser te staan, als ik op doorgaan klik bij die foutmelding.
En bij de bank staat ook: 'ING BANK N.V.'
Is dat hangslot dan eigenlijk niet geldig, en word er geen versleuteling toegepast?
Want bij de sitenaam staat in dat certificaat gewoon 'mijn.ing.nl'.
Ik heb dit probleem alleen als ik op een geblokkeerde website kom.

Bedankt voor jullie reacties.

M.v.g. Becky.

Erik van Straten weet precies hoe het werkt. Dank voor dit college. ;-)

Nee, OpenDNS doet niet aan onderscheppen van SSL versleuteld verkeer.
Het probleem is dat OpenDNS DNS responses hijacked; d.w.z. als een domein niet bestaat zou je normaliter een NXDOMAIN response moeten krijgen (waarop je browser dan vlot een witte pagina zal geven).
OpenDNS geeft daarintegen in zulke gevallen een antwoord met IP van henzelf, die leidt naar een pagina met advertenties (hun verdienmodel).
Echter, dit gebeurt dus ook bij een reverse hostname lookup voor een IP:
probeer het zelf maar uit: stel bij shop.domein.iets verschijnt jouw probleem, en shop.domein.iets verwijst naar bijv. 193.34.198.53, dan moet het antwoord van het PTR record (= reverse DNS) voor 53.198.34.193.in-addr.arpa overeenkomstig "shop.domein.iets" antwoorden.
De error zoals jij weergeeft toont een gebrek daaraan, waarop je browser vervolgens protesteerd.


Wellicht bedoel je "via" je router? Want Becky schrijft duidelijk:

8.8.8.8 != OpenDNS
Maar is inderdaad een beter alternatief; doet GEEN NXDOMAIN hijacking, doet geen datamining (aldus meerdere uitspraken van staff ik ik live gehoord heb), en doet DNSSEC validatie.

Da's een onzin zin. DNS servers blokkeren om te beginnen niet. Ze geven wellicht geen antwoord. Maar dat ligt aan de authoritive DNS van het domein (danwel de reverse hostname IP daarvan) waar het certificaat voor bedoeld is.
Nog meer onzin: een DNS server doet geen validatie van een eventueel SSL protocol dat ergens zou kunnen plaatstvinden.
Jouw (IMHO bizarre) stelling zou betekenen dat als op :443 een verlopen cert zit, dat :80 niet meer bereikbaar wordt omdat een DNS server zou blokkeren.

Hoewel Google aangeeft SHA2 certificaten te willen pushen, is het onwaarschijnlijk dat ze hun Public DNS in zullen zetten als filter.
De macht die dat platform hen in handen geeft moet je verantwoordelijkheid gebruiken.
Ik heb hun DNS dan nog nooit daarop op kunnen betrappen, maar mocht je een voorbeeld van het tegendeel hebben, dan ben ik uiterst nieuwsgierig.

OpenDNS dns servers zijn :
- 208.67.222.222
- 208.67.220.220

8.8.8.8 is Google

Pascal - BalefireHQ

Google Public DNS servers zijn:
8.8.8.8
8.8.4.4

Een DNS server gaat toch geen certificaten bekijken? Achter elke poort kan er wel een ander certificaat zitten. b.v. voor websites, smtp verkeer, imap server etc.steeds een ander certificaat.

Ik gebruik OpenDNS al een paar jaar op een paar PC's en sinds een jaar staat hij zelfs op mijn router. Ik heb nog nooit een advertentie gezien op hun pagina.
Bovendien kun je het 'hijack' gedrag zelf instellen als je een account aanmaakt. Ik heb die NXDOMAIN functie weer aangezet, zodat ik wel een witte pagina krijgt. Allen bij een geblokkeerde pagina zie je hun pagina, maar die kun je ook customizen met eigen tekst en logos.

Ik snap het nu.
Ik zal even kijken of ik OpenDNS blijf gebruiken, of dat ik alleen OpenDNS instel in de Gasten router.

Bedankt voor jullie reacties.

Als je, bij het bezoeken van bekende sites als https://mijn.ing.nl/, een certificaatfoutmelding krijgt en er sprake is van een certificaat voor *.opendns.com, dan deugt dit voor geen meter. Het ligt voor de hand om daar opendns de schuld voor te geven, maar misschien is er iets anders aan de hand dat ook anderen zou kunnen overkomen (die wellicht niet zo alert zijn als jij).

Ik begrijp je niet. Ik neem aan dat "mijn.ing.nl" niet een geblokkeerde website is, toch noem je deze in dit verband.

Drie vragen:

1) Welke webbrowser gebruik je, en welke versie?

2) Hoe ga je precies naar mijn.ing.nl? Heb je bijvoorbeeld (zoals aangeraden) een snelkoppeling/bookmark/favoriet in jouw webbrowser voor https://mijn.ing.nl/internetbankieren/SesamLoginServlet, of heb je Google als startpagina en zoek je naar mijn.ing.nl o.i.d.?

3) Komt het daadwerkelijk voor dat als je de ING internetbankieren pagina opent (zoals beantwoord bij vraag 2), je eerst een waarschuwing over een *.opendns.com certificaat te zien krijgt?

OpenDNS heeft een mechaniek (al uitgebreid besproken) om requests voor niet bestaande hostnames af te vangen en je dan een webpagina te tonen vanaf een van hun eigen servers. Je kan ergens bij OpenDNS instellen dat je dat niet wilt, maar dat vereist het aanmaken van een account daar en ik geloof het IPadres van je thuisverbinding invullen.

OpenDNS is een van de "gratis" DNSservers die op het hele internet werken. Google heeft ook zo'n dienst. Wat "beter" is, hangt helemaal af van wat jij belangrijk vindt. Snelheid, privacy en afhankelijkheid van bepaalde partijen zijn per mogelijkheid verschillend.

Je kunt op allerlei manieren een "slot in de browserbalk" krijgen. Met oudere versies van IE kan het zelfs door een favicon mee te sturen. Dat is (daarom) al lang niet meer iets waar je blind op moet vertrouwen. Er van uitgaande dat het slot wel "echt" is, betekent dat niets meer dan dat de verbinding tussen jou en de server aan de andere kant op een of andere manier versleuteld is. Dat betekent niet dat de partij aan de andere kant diegene is die jij denkt dat het is, of dat de versleuteling niet te kraken is. Om dat zeker te weten zal je het certificaat moeten onderzoeken en kijken welke versleutlingsmethode er wordt gebruikt om de verbinding feitelijk op te zetten.

Ik zal het even duidelijker uitleggen:

Ik gebruik verschillende browsers. Internet Explorer op Windows 8, Mozilla Firefox op Windows 7, Browsers op Android, Safari op de iPod, en op alle apparaten krijg ik zo nu en dan een melding dat het Servercertificaat niet overeenkomt met de website naam. En als ik dan op 'Certificaat weergeven' klik, dan staat er bij naam van certificaat: *opendns.com. Maar de sitenaam is dan https://google.nl. Als ik dan op doorgaan klik, dan word de browserbalk in IE rood. Deze balk verdwijnt dan weer super snel en dan komt er gewoon een wit slot te staan. Als ik dan op dat slot klik, dan staat er: ' Geotrust Global CA heeft deze website geïdentificeerd als: www.google.nl. De verbinding met de server is versleuteld.'
Dit komt bij ING gelukkig niet zo vaak voor. Ik voer dan gewoon in de adresbalk: https://mijn.ing.nl/
Dan komt dezelfde certificaat fout tevoorschijn. Maar niet zo vaak.
Als ik dan bij de ING op doorgaan klik, dan word de balk weer rood maar weer snel word de balk groen met de naam van ING.

Op school gebruiken we blijkbaar op het openbaar wifinetwerk ook OpenDNS. Hier komt dit probleem niet voor.
Misschien dat de school gaan account heeft bij OpenDNS, en dat ze gewoon de servers gebruiken zonder blokkades, maar ik vind het een beetje heel vreemd dat ik dat probleem thuis heb, en niet op school.
Ik heb het via een Ethernetkabel geprobeerd, misschien dat het aan de wifirouter ligt, maar hetzelfde probleem blijft bestaan.
Ik heb wel een account bij opendns, met verschillende blokkades.

Als je tijdelijk een certificaat ziet met *opendns.com,
dan heb je even een beveiligde verbinding opgebouwd met een opendns.com server.
Het kan zijn dat ook het DNS-verkeer met de opendns-servers heel speciaal via een gecertificeerde beveiligde https loopt.
Gebruik je misschien dnscrypt?
Mvg, cluc-cluc

Ik heb hier ook last van gehad. Ik heb mijn router opnieuw geflashed met DD-WRT, waarmee het probleem opgelost was. Echter na enkele dagen had ik er weer last van. Daarnaast was mijn internet traag. Ik heb vervolgens mijn router getest op de NSA backdoor. Deze bleek daarin te zitten. Deze geeft nl. root toegang tot de router. Je kan deze eenvoudig testen.
Ik had hiervoor een tooltje van sourceforge, maar weet de naam niet.
Hier heb ik nog een link voor verdere informatie:
http://www.ghacks.net/2014/01/06/find-router-listening-backdoor-port-32764/

Mijn router wordt niet meer ondersteunt door dd-wrt, waardoor ik terug gegaan ben naar de originele firmware. Deze had at probleem niet.

Ik begin een vermoeden te krijgen:
Je kunt op verschillende apparaten de DNS-server instellen: allereerst in het modem,
dan in een eventuele router en als laatste in de internetverbinding van het OS.
Als je in al die apparaten een en hetzelfde ip-nummer invult, dan gaat alles goed,
het systeem kan geen kant op.
Maar wat nu, als ieder onderdeel van de keten een ander ip-nummer ingegeven krijgt,
welk apparaat heeft dan de bepalende/doorslaggevende factor?
Het modem zal graag naar de DNS van de provider gaan, zo staat het standaard ingesteld.

In alle posten van becky wordt geen ip-nummer vermeld, noch waar, en in welk apparaat,
het ip-nummer is ingegeven.
07-10-2014, 23:57 door NedFox meldt: openDNS te gebruiken (8.8.8.8 bijvoorbeeld)
08-10-2014, 10:51 door Anoniem: verduidelijkt voor het eerst het verschil tussen OpenDNS
en de DNS van Google dmv vermelden ip-nummers.
08-10-2014, 14:21 door Anoniem: vermeldt nog eens de juiste public dns-servers van Google.
Dan meldt becky 09-10-2014 12:12:
Ik gebruik verschillende browsers. Internet Explorer op Windows 8, Mozilla Firefox op
Windows 7, Browsers op Android, Safari op de iPod. Dus 4 verschillende OS-sen.
En verderop: En als ik dan op 'Certificaat weergeven' klik, dan staat er bij naam van
certificaat: *opendns.com. Maar de sitenaam is dan https://google.nl. Als ik dan op
doorgaan klik, dan word de browserbalk in IE rood. Deze balk verdwijnt dan weer super
snel en dan komt er gewoon een wit slot te staan. Als ik dan op dat slot klik, dan
staat er: ' Geotrust Global CA heeft deze website geïdentificeerd als: www.google.nl.
De verbinding met de server is versleuteld.'
Op school gebruiken we blijkbaar op het openbaar wifinetwerk ook OpenDNS.
Hier komt dit probleem niet voor.

Hieruit maak ik op, dat becky -op dat moment- de dns-servers van Google gebruikt en
niet die van de (zeg maar) "echte" OpenDNS. Ik weet niet, of dat de bedoeling is.
OpenDNS is heel wat anders als opendns.
Ik denk, dat er binnen de hele verbindingsketen thuis verschillende apparaten
verschillende dns-servers zijn opgegeven, waardoor het systeem -soms- in de soep loopt.

Vraag aan becky: waar heb je welk ip-nummer in welk apparaat ingegeven?

En voor de duidelijkheid: om zonder dns naar mijn-ing gaan doe je door in een schoon
tabblad het ip-nummer 145.221.194.139 (niets meer of minder!) in te geven in de adresbalk.
Je gaat dan in 1 keer naar https://mijn.ing.nl/internetbankieren/SesamLoginServlet

Er is ook een dergelijk probleem bekend doordat bepaalde websites worden geblokkeerd door OpenDNS.
(dat is, afhankelijk van je abonnement, nu eenmaal de service van OpenDNS:
dat reclame, onveilige websites e.d. dus worden geblokkeerd)

Het probleem hoeft niet per se direct te worden veroorzaakt door een website die je zelf hebt ingetikt.
Want de website die je bezoekt kan op de achtergrond automatisch doorlinken naar andere websites.
Bijvoorbeeld voor het bijhouden van statistieken. (bijvoorbeeld ssl.google-analytics.com)
En juist zo'n automatische "doorlinkwebsite" zou dus door OpenDNS voor de veiligheid geblokkeerd kunnen worden.
Als zoiets gebeurt, probeert OpenDNS je te verbinden met zijn "blokkeerpagina" .
Maar die blokkeerpagina is een bericht van opendns.com, en dat stemt dan niet overeen met wat het had moeten zijn
als de pagina niet geblokkeerd werd. Vandaar de foutmelding.

Hier wordt een mogelijke oplossing voor dat probleem gegeven:
https://support.opendns.com/entries/42398824-Adding-Exceptions-for-opendns-com-Certificates
(de suggestie van anoniem 16:12 is ook niet verkeerd om te controleren, en een probleem met je router is ook niet volledig uit te sluiten, maar als het slechts af en toe optreedt bij exact steeds dezelfde websites, dan geef ik je meer kans dat dit dus het probleem is)
mvg, cluc-cluc.

Dit is maar ten dele waar; in de eerste instantie gebruik je dan geen DNS, maar de webserver daar doet niets anders dan tegen je browser zeggen 'ga naar https://mijn.ing.nl/internetbankieren/SesamLoginServlet'. Vervolgens doet je browser dat en gebruik je alsnog de DNS entry voor mijn.ing.nl. En maar goed ook anders werkt het zeker niet, dan krijg je ten eerste weer een certificaatfout, en als je al zo moedig bent om daardoorheen te klikken blijkt dat de webserver de opgevraagde hostname checkt en weigert je de bankierpagina te laten zien.

Ik heb de DNS in de Sitecom & Cisco router ingesteld op: 208.67.222.222 en 208.67.220.220.
8.8.8.8 is van Google, niet van OpenDNS. De website van OpenDNS is: opendns.com.
Dit is niet de Google Public DNS...

Zoals net in dit bericht aangegeven te hebben, heb ik de DNS servers van OpenDNS ingesteld in de Router. Niet op het apparaat zelf.
Ik zal het netwerk eventjes proberen uit te leggen.
Beneden hebben we een Glasvezelmodem van Vodafone. Daaraan hangt een Sitecom router. Daaraan hangt weer een Sitecom router die naar boven loopt, en aan die Sitecom router hangt weer een Cisco-Linksys router voor Gast gebruik.
In de eerste router is OpenDNS niet ingesteld, omdat dit niet kan. Sitecom routers bieden namelijk niet de optie om de DNS te wijzigen. Alleen kan dit door een Static IP Adres in te stellen. De tweede sitecom router kon dit wel, omdat de interne IP Adressen niet zomaar wijzigen. De eerste Sitecom router heeft als ip-adres: 192.168.0.1. De tweede 172.160.220.250. En de derde router heeft als IP adres: 123.166.240.160.
Op de tweede en de derde router is die OpenDNS ingesteld, de eerste niet.
Het probleem bevind zich denk ik toch bij OpenDNS, en niet in de netwerk instellingen.
Maar ik kan het fout hebben.

Ik ben Anoniem van 09-10-2014 16:12.
Ik ben even zo brutaal geweest om 123.166.240.160 door de molen te halen, want ik vond dat een vreemd nummer.
http://www.ip-adress.com/whois/123.166.240.160 blijkt een adres in China te zijn. Kan dit de fout veroorzaken?
De 2 andere genoemde ip-nummers zijn in ieder geval interne ip-nummers en correct.
Hoe kan je checken, welke DNS-server je werkelijk gebruikt? Is daar ook een website voor?

Dank aan Anoniem 19:33 voor het verbeteren van mijn stelling. Ik ga er van uit, dat als ik een 'kaal' ip-nummer ingeef,
dat de browser dan direct naar dat adres gaat. Wat er intern bij ING wordt uitgespookt met mijn vraag, kon ik in eerste instantie niet achterhalen.

En de term "open resolver" is duidelijke terminalogie.
En Google's open resolver heet in het echt: "Google Public DNS".

becky is wat mij betreft nog net niet duidelijk genoeg.
Als 123.166.240.160 een lokaal IP-adres is van die derde router (gateway?), dan is dit normaalgesproken geen probleem.
Het lijkt me wel een probleem als het werkelijk een DNS-server instelling zou zijn.
(tenzij het juist de bedoeling is om dit IP-adres als een DNS-server in China aan te spreken)

Omdat becky de IP's in één adem noemt met 192.168.0.1 (meestal het LAN IP-adres van een router) zou het misschien
kunnen dat becky per vergissing LAN IP-adressen van de routers heeft genoemd i.p.v. DNS IP-adressen?
Dus vraag aan becky: weet je zeker dat je in bericht 09-10-2014, 19:35 DNS-instellingen van de routers hebt verstrekt? Hiervoor moet je inloggen op de betreffende router, en meestal kijken bij "WAN -instellingen".

Wat ik me ook afvraag, is waarom je geen DNS-servers zou kunnen instellen op de eerste Sitecom router.
Wat voor model router is dit dan? En relevant kan ook zijn of je bovendien gebruik maakt van "Sitecom Cloud Security",
die in de nieuwere modellen routers standaard is ingebakken bij routers van Sitecom?
En heb je dit al bekeken: https://forums.opendns.com/comments.php?DiscussionID=1265

Overigens ben ik benieuwd of de tip van 09-10-2014, 17:38 met behulp van
https://support.opendns.com/entries/42398824-Adding-Exceptions-for-opendns-com-Certificates
het oorspronkelijke probleem inmiddels misschien zelfs al heeft verholpen?
Mvg, cluc-cluc.

Het advies van OpenDNS om hun certificaat voor andere sites te vertrouwen is GEVAARLIJK!

Nou ja, misschien niet voor "internetbadguys.com" maar wel voor de ook genoemde "twitter.com, facebook.com, etc". En zeker voor banksites is dit ronduit onacceptabel!

In elk geval in Firefox (en Safari, maar die gebruik ik niet) is het helemaal onverstandig om te doen wat OpenDNS adviseert, namelijk:

NIET DOEN!

Stel je surft naar https://www.snsbank.nl/ en krijgt de certificaatwaarschuwing. Als je dan doet wat OpenDNS adviseert (als dat kan, zie punt 3 hieronder), kan OpenDNS in elk geval die sessie meekijken. Als je het vinkje voor "Permanently store this exception" laat staat, kan OpenDNS, elke volgende keer dat je bij SNS internetbankiert, meekijken zonder dat je daar een waarschuwing voor krijgt!

Ik heb wat onderzoek gedaan naar hoe Firefox (v32.0.3) hiermee omgaat. Hierbij heb ik geen gebruik gemaakt van OpenDNS, maar van een op mijn eigen PC geïnstalleerde Apache en tijdelijke aanpassingen van de hosts file.

1) Het is gelukkig niet zo dat als je voor een enkele site (zoals genoemde "internetbadguys.com") een uitzondering maakt, dus voor die site ook het certificaat *.opendns.com accepteert, dit meteen voor alle sites geldt waarbij OpenDNS de verbinding kaapt en het opendns.com certificaat aanbiedt. Je zult dus voor elke site waarbij dat gebeurt een waarschuwing krijgen (en desgewenst de uitzondering accepteren, al dan niet permament). M.a.w. als je OpenDNS toetstaat mee te kijken in de verbinding met https://en.wikipedia.org/, zul je wel een waarschuwing krijgen als je daarna (voor het eerst) https://www.snsbank.nl/ bezoekt.

2) Een niet-permanente uitzondering (geen vinkje voor "Permanently store this exception") blijft van kracht zolang Firefox blijft draaien. Als er nog een ander venster van Firefox openstaat, en je verbreekt de verbinding met een site waar je een tijdlijke uitzondering voor gemaakt hebt, en je zet die verbinding vervolgens opnieuw op, dan krijg je geen waarschuwing.

3) HSTS (HTTP Strict Transport Security): als je eerder (niet te lang geleden) met succes een https website bezocht die gebruik maakt van HSTS, zoals bijv. https://www.security.nl/ en https://mijn.ing.nl/, dan lijk je daar geen uitzondering voor te kunnen maken (in elk geval in de experimenten die ik uitvoerde lukte dat niet); in het waarschuwingsscherm toont Firefox (Engelstalig) dan eenvoudig niet de klikbare regel "I understand the Risks". Echter, zelfs hiervoor biedt OpenDNS -naar verluidt- een workaround aan in https://support.opendns.com/entries/42404534-Bypassing-HSTS-Certificate-Error-Cannot-connect-to-the-real-. In mijn tests (voor mijn.ing.nl en www.security.nl) werkte dat gelukkig niet, maar alleen al het advies om HSTS te bypassen vind ik ronduit schandalig!

Nb. het Resetten van jouw Firefox instellingen ("Reset Firefox..." in about:support) verwijdert wel eerder opgeslagen HSTS informatie. Nog radicaler, het wissen van de map "Mozilla" in c:\Users\<jouw naam>\AppData\Roaming\ doet dat ook (Firefox slaat HSTS gegevens op in permissions.sqlite).

Helaas maken nog niet alle banksites gebruik van HSTS, bijv. https://www.snsbank.nl/ doet dit nog niet, die is dus makkelijk te kapen door OpenDNS. Griezelig! Het zou mij niet verbazen als jouw bank niet alle schade vergoedt als jouw bankrekening geplunderd wordt en ze erachter komen dat je OpenDNS hebt toegstaan mee te kijken.

4) Permanente uitzonderingen slaat Firefox kennelijk op in een tekstfile genaamd "cert_override.txt" in jouw persoonlijke profile map (meestal iets van C:\Users\<jouw naam>\AppData\Roaming\Mozilla\Firefox\Profiles\<random>\). Nb. Firefox ondersteunt dit soort uitzonderingen voor websites met self-signed certificaten, maar helaas ook voor sites waarbij de domainname in het certificaat niet overeenkomt met die in de URL balk. OpenDNS.com profiteert van dat laatste.

5) Een uitzondering betekent niet dat het echte certificaat niet meer geaccepteerd wordt: voor geen van beide krijg je dan een waarschuwing. Je kunt dus niet eenvoudig zien of OpenDNS ertussen ziet of niet - tenzij de echte website een EV certificaat gebruikt met de bekende groene kleur als gevolg. Aangezien je geen EV certificaat voor wildcard domainnames als *.opendns.com zou moeten kunnen krijgen, ga ik ervan uit dat *.opendns.com nooit een EV certificaat zal hebben.

Conclusie: kijk uit met OpenDNS! Hoewel ze het misschien goed bedoelen (jou helpen beschermen tegen https sites die malware verspreiden), vind ik dat dit doel de middelen absoluut niet heiligt!

@Erik:
In de eerste plaats erg bedankt voor de uitgebreide informatie, maar ik waag het toch om een paar dingen op te merken.

Nou ja, het kan gevaarlijk zijn als je niet weet wat je doet, en niet precies weet wat er aan de hand is.
Firefox informeert en adviseert immers nadat je hebt gekozen voor de optie "I understand the risks" :

"If you understand what's going on, you can tell Firefox to start trusting this site's identification.
Even if you trust the site, this error could mean that someone is tampering with your connection.
Don't add an exception unless you know there's a good reason why this site doesn't use trusted identification."

Maar als je weet dat OpenDNS een vertrouwde partij is, en als het er heel erg naar riekt dat je die certificaatfoutmelding krijgt vanwege een blokkering van een bepaalde website, zodat OpenDNS jou om die reden naar hun "blockpage" probeert door te sturen om je hiervoor te waarschuwen (waardoor dus een "certificaat mismatch" ontstaat, omdat dit niet de website is waar je oorspronkelijk naar toe wilde gaan...) dan is het risico wat mij betreft acceptabel.
Het is niet voor niets dat Firefox de mogelijkheid biedt voor het maken van zo'n "exception".

Voor wat betreft het HSTS-verhaal van OpenDNS: hier geeft OpenDNS aan (in een situatie waarbij jij bij OpenDNS bijvoorbeeld facebook hebt geblokkeerd, en graag de "blockpage" van OpenDNS wilt zien als jouw systeem toch een DNS-request voor facebook genereert): "Please be aware that the warnings do not apply to this case because OpenDNS blocking has intentionally redirected you to the block page instead of facebook.com."
Kortom: als je weet wat je aan het doen bent, en naar alle waarschijnlijkheid met een vertrouwde partij hebt te maken,
dan hoef je niet meteen in paniek te raken van die Firefox "I understand the risk" -risicowaarschuwingen.
Ik geef toe dat je bij deze procedure oude hsts-informatie in je browser waarschijnlijk even kwijt raakt, en het is een minpunt dat OpenDNS hier niets over zegt. Maar herstelt de gewiste hsts-informatie zich niet bij de eerstvolgende keer dat je de betreffende hsts-website(s) weer bezoekt?

En hoe OpenDNS volgens jou hierdoor opeens mee zou kunnen kijken met bijv. bankzaken, begrijp ik niet goed.
Als je met private acties als bankzaken bezig bent, dan moet je imho vlak voordat je inlogt altijd de informatie achter het slotje controleren of je op dat moment wel echt met je bank verbonden bent. De groene kleur is al een eerste indicatie dat je waarschijnlijk goed zit. Maar het zorgvuldigst doe je dit door de zgn. "fingerprint" van het certificaat te controleren. Die mag niet opeens anders zijn dan gewoonlijk (registreer het!) tenzij het oude certificaat van de bank was verlopen, en er een nieuw certificaat voor in de plaats is gekomen.

Als OpenDNS er als "man in the middle" tussen zou zitten, dan zou je het certificaat van OpenDNS ook nog moeten zien op het moment dat je lijkt te zijn aanbeland bij de website van de bank, en niet alleen maar bij hun blockpage.
Maar zit er op dat moment een geldig certificaat van de bank achter het "slotje", dan is alles toch in orde?
Hoe zou OpenDNS dit dan af moeten luisteren? Ik zie het niet.

Conclusie: natuurlijk bestaat er altijd wel ergens enig risico, maar ik zou me niet onmiddellijk grote zorgen maken.
(als ik over straat fiets, loop ik ook enig risico. Bijvoorbeeld dat ik wordt aangereden. Maar ik doe het lekker toch...)
Uiteindelijk is het misschien maar net wat iemand het belangrijkste vindt:
1. Het tonen van een blockpage van OpenDNS die jou vertelt naar welke "badguy" je vanaf een bepaalde website die jij
hebt ingetikt wordt doorgesluisd, maar dan misschien iets meer moeite doen om zekerheid te krijgen d.m.v. wat extra certificaatcontrole of je inderdaad veilig bent verbonden met je bank,
of:
2. Juist niet weten naar welke "badguys" een website jou eventueel probeert door te sluizen
maar er voor jezelf mogelijk iets gemakkelijker/sneller/zekerder van zijn dat je veilig (hsts) bent verbonden met je bank.
Mvg, cluc-cluc

P.S.: in reactie op je opmerking t.a.v. missende HSTS bij www.snsbank.nl: weet je dit wel zeker, Erik?
Weliswaar is het zo dat je www.snsbank.nl met het onbeveiligde http kunt bezoeken,
(en daarom klopt het dus wel dat bijv. ssllabs.com geen hsts aangeeft voor deze banksite).
Maar als je vervolgens doorklikt naar de inlogpagina voor internetbankieren, dan verandert je browser automatisch
van http naar https. Het is dus niet mogelijk om met http in te loggen bij snsbank.
Ook niet als je de url van de inlogpagina met de hand intikt. En dat lijkt mij op het eerste gezicht nogal "HSTS".

Graag gedaan, en prima natuurlijk - discussie houdt scherp! Ik ga echter niet in 100% van wat je schrijft, het is zo al veel te lang. Mocht ik onvriendelijk overkomen tegen jou hieronder, dat is niet mijn bedoeling. Ik vind het alleen echt niet kunnen wat OpenDNS doet. Dat ze known malware sites blokkeren okay, maar dat ze jou redirecten naar hun server(s) bij facebook, twitter en zelfs banksites en jou vervolgens permanent hun certificaat laten vertrouwen, vind ik absoluut onacceptabel.

Mijn bezwaren hierbij zijn:

1) Open deur na jouw opmerking: de meeste mensen hebben geen flauw benul hoe https werkt en wat certificaten precies inhouden, en hebben dus geen idee wat de consequenties zijn van vertrouwen (of importeren) van een vreemd certificaat, zeker als dat permanent is. Menselijk is echter: ik wil naar die site! Why the f*** werkt het niet? Tik tik tik Google: opendns certificate error -> bovenste hit: "Adding Exceptions for *.opendns.com Certificates : OpenDNS".

2) OpenDNS vertelt je in hun pagina's, voor zover ik kon vinden, niets over wat de consequenties zijn van het vertrouwen van hun certificaat en welke risico's je daarmee loopt. Sterker, het is vooral een "trust us, you can trust us" verhaal... Uit https://support.opendns.com/entries/42398824-Adding-Exceptions-for-opendns-com-Certificates:
3) En voor de mensen die wel snappen wat het vertrouwen van een certificaat van derden betekent: weten zij of de beheerders van OpenDNS te vertrouwen zijn? Weten zij hoe goed OpenDNS haar servers tegen indringers beschermt? Hoe zijn hun private key(s) beschermt? Of zij beveiligingsincidenten aan jou zullen melden? Wat is het verdienmodel van OpenDNS? Nb. ik vraag me af of Firefox revocation checks doet op certificaten die je vertrouwt zoals OpenDNS aangeeft dat je moet doen.

Misschien begrijp ik Becky (08-10-2014, 07:26) verkeerd, maar ik heb nog nooit gehoord dat mijn.ing.nl malware verspreidde. Ik zie niet waarom OpenDNS de verbinding met banksites zou moeten kapen. Okay, stel dat er een vermoeden is van malware op zo'n site, dat zul je een certificaat van openDNS moeten accepteren om de reden van blokkeren te lezen. Rest de vraag: waarom moet je dat vertrouwen permanent maken?

Denkt jouw bank daar ook zo over? Vergelijkbaar (derde partij tussen jou en de bank): http://www.afas.nl/nieuwsbericht/procederen-wint-van-innoveren.

Van wat ik erover kan vinden is deze mogelijkheid vooral gemaakt om de volgende situaties niet te blokkeren:
- Self-signed certificaten
- Certificaten uitgegeven door een niet vertrouwde CA (bijv. https://www.nlnetlabs.nl/)
- Certificaten van onjuist geconfigureerde sites evt. met self-signed certificate (bijv. https://gpg4win.org/)

Niet als OpenDNS dat niet wil.


Er zijn veel problemen met het huidige model van CA's en certificaten. Echter, als de URL begint met https://, de domainname klopt en een slotje op de juiste plaats getoond wordt, is de kans dat je op een nepsite zit enorm klein. D.w.z. totdat je vreemde certificaten permanent gaat vertrouwen en/of importeert. Uit https://www.ing.nl/de-ing/veilig-bankieren/veilig-internetbankieren/veilige-verbinding-met-mijn-ing/index.aspx:
Als 20% van de internetters tot hier leest zou ik het al heel mooi vinden; je kunt m.i. niet van mensen verwachten dat ze in certificaten gaan kijken. Dat een groene balk er niet is zegt kennelijk ook niets (en ik heb op m'n todo lijstje staan om zelf een keer een EV-certificaat te maken om te kijken of je die ook kunt "vertrouwen" in Firefox).

Als je het *.opendns.com certificaat hebt vertrouwd in Firefox voldoet een verbinding via een OpenDNS server aan de bovenstaande criteria. En, niet ondenkbaar, op het moment dat OpenDNS (of een tweede MitM zogenaamd namens OpenDNS) je vertelt dat je, speciaal voor jouw bankverbinding, ook een "mijn.ing.nl" certificaat moet vertrouwen, is het eind zoek (risico op social engineering is veel te groot).

Ik ben behoorlijk paranoïde maar ik ga echt geen fingerprints van certificaten controleren. Stel bij mijn.ing.nl krijg je ineens een nieuw certificaat voorgeschoteld; als ik jou nu niet zou vertellen dat bedoeld certificaat op 2014-10-31 verloopt, had jij dat dan geweten? Bovendien, als je ziet hoeveel certificaten er in omloop zijn voor bijv. *.google.com (zie https://ssl-tools.net/certificates/18tn156-google-com#0bb9ee841a) en *.microsoft.com, dan valt daar geen pijl op te trekken - banken zouden ook meerdere certificaten kunnen inzetten.

In de beschrijvingen van Becky en anderen zie ik niets over een blockpage. Je lijkt te worden doorgestuurd naar de bedoelde site, maar voor hetzelfde geld blijft OpenDNS als een proxy werken.

Als dat zo is, is alles in orde. Maar als je dat niet controleert, of afgaat op wat OpenDNS zegt (this is by design), dan is het helemaal niet in orde en kan OpenDNS al het netwerkverkeer afluisteren.

HSTS wordt geregeld door http headers die de server naar jouw browser stuurt en geldt voor de exacte domain name, en desgewenst ook voor subdomains middels het attribuut "IncludeSubDomains" (zie https://tools.ietf.org/html/rfc6797). Als SNS voor www.snsbank.nl naast https ook http permanent wil ondersteunen is HSTS onmogelijk, maar dan zouden ze nog steeds een mijn.snsbank.nl kunnen maken die m.b.v. HSTS het gebruik van https afdwingt.

Dat is een redirect die, an sich, niets met HSTS te maken heeft.

Jawel hoor, zodra ik bij OpenDNS ben aangenomen en onbeperkte toegang heb tot hun infra, is het een koud kunstje voor mij om jou, met in de URL balk van jouw webbrowser http://www.snsbank.nl/mijnsns/, de SNS inlogpagina te tonen ;)

Nee joh, da's onbetrouwbare meuk...
(http://www.theregister.co.uk/2014/10/13/something_ate_googles_8888_at_about_eight_in_asias_evening/)

Jazeker, een correct werkend, niet gemanipuleerd/gekaapt DNS-systeem is cruciaal,
ongeacht of dat nu OpenDNS, google's DNS of welke andere DNS-server dan ook is.
Missschien toch maar weer een lokale hosts file voor de belangrijkste sites? ;-)

Dit doen ze volgens mij alleen wanneer jij er zélf voor hebt gekozen om deze sites via OpenDNS te blokkeren.
Bij een abonnement kun je volgens mij bij OpenDNS opgeven welke sites (en/of standaard pakketten van sites?) je wilt filteren. Facebook stond/staat er om bekend dat ze elk graantje informatie proberen op te pikken, zelfs als je daar geen account hebt. Je zou ze eens de kots (oeps...) kost moeten geven die de communicatie met facebook voor de zekerheid hebben geblokkeerd.

Banksites blokkeert men meestal niet. Maar sommige banken gaan in zee met derde partijen die zijn doorgelinkt op hun website. En zo'n derde partij kan dus wél als onwenselijk geblokkeerd zijn in jouw persoonlijke OpenDNS filterinstellingen.
En als je iets als "link prefetching" aan hebt staan in je browser, dan probeert deze al op voorhand al die links te bezoeken en in je browsercache te laden, zonder dat je er ooit zelf actief op geklikt hebt.

Het ligt voor de hand, dat zodra er een DNS-request van jouw systeem aankomt bij zo'n OpenDNS server, dat deze DNS-server dan niet gaat antwoorden met het IP-adres van de betreffende geblokkeerde site, maar met het IP-adres van hun "blokkeerpagina". Die blokkeerpagina informeert jou dan dat je systeem een door jou bij OpenDNS opgegeven geblokkeerde website probeerde te bezoeken.

Dit is mijn theorie over het probleem:
onder https kan zo'n blokkeerbericht van OpenDNS jou niet zomaar bereiken, want hun certificaat komt immers niet
overeen met de naam van de website die je had ingetikt. De enige mogelijkheid om dat bericht onder https te kunnen zien, is het OpenDNS-certificaat te vertrouwen, zodat je browser het accepteert voor die site. Dat is toch niet zo moeilijk?
Maar het is niet verplicht: als je OpenDNS niet vertrouwt, kun je het ook laten. Maar dan zie je bij https dus geen melding
meer over welke website er werd geblokkeerd. In plaats daarvan gebeurt er dan waarschijnlijk zoiets als becky waarneemt.
(zie ook 08-10-2014, 07:26 door becky - "Ik heb dit probleem alleen als ik op een geblokkeerde website kom."
Nu snap je misschien beter wat ze daar waarschijnlijk mee bedoelde, Erik!)

Ik snap verder je zorgen wel, en het streven naar eenvoud voor digibeten. Maar zoals je elders in een ander kader
eens aangaf: gebruikers ontkomen er niet aan om "iets" van certificaten te weten.
Men zou op zijn minst de naam van de website kunnen controleren. Maar "ing" lijkt bijv. wel heel erg op "lng".
Voordat je het weet heb je dus een nepcertificaat vertrouwd van "mijn.lng.nl" in plaats van "mijn.ing.nl".
Daarom gaat mijn voorkeur uit naar controle van de sha1 fingerprint/vingerafdruk.
Zo'n lokaal berekende sha1-hash van alle informatie van het certificaat is niet zomaar te spoofen,
en zelfs de kleinste afwijking in het certificaat valt onmiddellijk op in de fingerprint.
Dat is nu eenmaal de eigenschap van sha: dat een minieme wijziging van de input een totaal andere uitkomst geeft.
Ook de verloopdatum staat altijd in het certificaat, dus je weet wanneer het gaat veranderen. No problem.
Ik zag dat bijv. SNSbank hun vingerafdruk vermeldt op hun inlogpagina bij "hoe controleer ik of het certificaat echt is".
Valt wel wat op af te dingen om dit zo door te geven, maar bewijst in ieder geval dat ik niet de enige ben die het zo controleert. Alleen de allereerste keer dat je een banksite bezoekt weet je inderdaad niets. Bij het allereerste bezoek van een banksite weet je niet zeker of alles wel klopt, want je kan niets controleren. Maar dat geldt ook voor HSTS! (is het de eerste keer een valse site, dan helpt HSTS je helaas niet, en ook elke eerste keer nadat de HSTS-periode geëxpireerd is)

Mijn uitgangspunt is daarom, dat je
altijd de informatie achter het "slotje" controleert of je wel echt met je bank verbonden bent.
Dit slotje zie je alleen bij https-verbindingen, en dat sluit uit dat je op het onveilige http aan het communiceren bent.
(en een goeie browser gaat er over mekkeren als https later opeens http wordt)
Als je bij inloggen het certificaat van de bank ziet, dan heb je aan die voorwaarde van de bank voldaan.
En waar verbiedt de bank dat ik OpenDNS niet óók mag vertrouwen?
Stel je voor zeg... [ironie] dan kun je ook wel denken dat de virusscanner op je PC malware bevat
die op de achtergrond je banksessie manipuleert of doorseint. Dat ding update volautomatisch!
Hartstikke gevaarlijk. Is zulke malware er vandaag niet in verscholen, dan misschien morgen wel...
Of dat die virusscanner het aanvalsoppervlak van je PC vergroot, en dat daardoor een badguy bij je banksessie kan. Waarom zou ik de makers van de virusscanner vertrouwen?[/ironie]
Theoretisch is er heus van alles mogelijk hoor, ik ontken niets! Begrijp me niet verkeerd.
Maar in de praktijk loopt men niet zo gauw in zeven sloten tegelijk.
Dit zeg ik niet om gemakzucht aan te moedigen alsof er nooit iets zou kunnen gebeuren,
maar om enigszins nuchter en proportioneel te blijven.
Mvg, cluc-cluc

Nog even enkele kleine puntjes van kritiek (hopelijk blijf ik hierbij vriendelijk tegen mijzelf) :
Niet helemaal waar.
De expiratiedatum van een certificaat van een website kun je eventueel van tevoren opzoeken via www.ssllabs.com.
De vingerafdruk van een certificaat van een website kun je eventueel van tevoren opzoeken via www.grc.com/fingerprints

Tenzij de website is opgenomen in de "preloaded list voor HSTS" van je browser. Dan helpt het direct.
Zie https://www.security.nl/posting/38699/Firefox+krijgt+lijst+met+niet+af+te+luisteren+websites
Maar vooralsnog zie ik geen bekende Nederlandse banken in die lijst staan.
Zie: http://src.chromium.org/viewvc/chrome/trunk/src/net/http/transport_security_state_static.json

Momenteel is (afhankelijk van de bank) een HSTS-periode van een half jaar tot een jaar gebruikelijk. Dus best wel lang.
Een bank kan expiratie voorkomen door bij ieder bezoek binnen die HSTS-periode de resterende tijdsduur weer op te hogen. In hoeverre dit ook altijd daadwerkelijk gebeurt, heb ik zo snel geen zicht op. Maar het zou goed kunnen dat men
in de praktijk vrijwel geen last heeft van dit probleem.

Verder heeft Erik van Straten hierboven ontdekt dat je HSTS-entries verdwijnen bij bepaalde acties:
Als ik het goed begrijp, houdt dit in, dat je na zo'n actie de eerstvolgende keer dat je zo'n HSTS website weer benadert
even niet door HSTS bent beschermd. Dus hierna extra opletten dat je de eerstvolgende keer echt "https intikt in je browser, en niet http (zonder "s"). (dat deed je waarschijnlijk toch al, want dit is iets wat de banken standaard vereisen)
Kortom: HSTS kan helpen als je deze eis van de bank per ongeluk vergeet. Maar is dus geen garantie om een ssl-strippende MITM onder alle omstandigheden te weren. M.a.w.: vertrouw ook weer niet teveel op HSTS.

@Erik van Straten:
Een koud kunstje...hmm, juist ja.
Maar lukt die striptease ook nog als ik mijn verbinding met zo'n bank start met https en met een geldig certificaat van de bank achter mijn slotje, en zonder dat ik er verder iets van zou kunnen merken dat jij ertussen zit?...
Mvg, cluc-cluc

@cluc-cluc, in tegenstelling tot bij een Poodle aanval door een cybercrimineel (zie https://www.security.nl/posting/405457/SSLv3+%22Poodle%22+lek+voor+leken) spelen bij OpenDNS twee zaken:

1) Als jij OpenDNS om het IP-adres van mijn.ing.nl vraagt kunnen zij met een adres naar hun eigen keuze antwoorden. OpenDNS zegt zelf dat dit een adres van een van hun servers kan zijn! Normaal gesproken is daarmee nog geen aanval op https mogelijk, tenzij die OpenDNS server als MitM het netwerkverkeer doorzet naar de bank en de hierboven beschreven Poodle aanval uitvoert (en dat kan alleen indien zowel de browser als de webserver SSLv3 ondersteunen). In dat geval krijg je gewoon het EV certificaat van ING, een slotje, een groene balk etcetera te zien. ECHTER: dit is geen realistisch scenario, want OpenDNS heeft iets veel "slimmers" bedacht - zie punt 2.

2) OpenDNS vraagt jou om hun *.opendns.com certificaat te vertrouwen als je een https site van een derde partij bezoekt, en OpenDNS -om de een of andere reden- heeft besloten jouw webbrowser naar hun server te sturen in plaats van de door jou bedoelde. Sterker, OpenDNS vraagt jou dat vertrouwen permanent te maken in Firefox en Safari. OpenDNS noemt zelf Facebook en Twitter als voorbeelden van sites die zij via hun server(s) kunnen routeren. Indien zij zo'n MitM aanval uitvoeren op het moment dat jij naar jouw Facebook pagina gaat, heeft de OpenDNS server een versleutelde verbinding met Facebook, en jouw webbrowser heeft een geheel andere versleutelde verbinding met de OpenDNS server. Op die OpenDNS server is de informatie onversleuteld, zodat bijv. OpenDNS beheerders jouw wachtwoord kunnen afkijken. De URL in de URL balk van jouw webbrowser begint met https://www.facebook.com/ en er is een slotje zichtbaar. Als OpenDNS voor haar server een EV certificaat zou aanvragen (dat kan niet voor wildcard "*" domainnames, maar wel bijv. voor mitm.opendns.com), zou jij ook een groene balk zien. Als je op dat slotje klikt, zie je een certificaat voor *.opendns.com (niet voor Facebook). Maar waarom zou je je daar zorgen over maken? In https://support.opendns.com/entries/42398824-Adding-Exceptions-for-opendns-com-Certificates leggen ze haarfijn uit dat dit de bedoeling is en dat je hen kunt vertrouwen: Met deze constructie kan OpenDNS meekijken bij verbindingen tussen jouw webbrowser en Facebook, en wellicht ook met jouw bank.

Uit jouw reacties begrijp ik heel goed dat jij dit nooit zult laten gebeuren. Als jij, met https://mijn.ing.nl/ (of https://www.facebook/com/) in de URL balk, op het slotje klikt en een ander certificaat ziet dan van mijn.ing.nl (of www.facebook.com), gaan bij jou alle alarmbellen af. Maar gebeurt dat ook bij mensen als Becky? Ik denk het niet...
Aanvulling: correctie, bij Becky gingen ook alarmbellen af, want Becky begon dit topic als TS hierboven (sorry Becky)!

Maar bij hoeveel andere OpenDNS gebruikers klikken op slotjes en bekijken certificaten? En bij hoeveel van hen gaan vervolgens alarmbellen af? OpenDNS is wellicht een prima DNS provider, maar ze moeten je niet vragen om permanent hun certificaat te vertrouwen voor sites als Facebook, Twitter en mogelijk jouw bank, ook al lijken ze nog zo betrouwbaar.

In reactie op 22:41 door Erik van Straten:

Het punt waar ik tegenaan hik, is het idee dat OpenDNS misbruik zou maken van het vertrouwen.
OpenDNS draait al een tijdje mee, is een florerend bedrijf en een prima werkgever als ik de berichten op internet mag geloven, en profileert zich als: "a cloud-delivered network security service that delivers automated protection against advanced attacks for any device, anywhere."

Daarom vergeleek ik OpenDNS met een virusscanner op je PC, waarmee men in theorie ook ondeugdelijke dingen op je PC zou kunnen uitspoken en spioneren en manipuleren. Je proeft wel: vroeg of laat komt zoiets natuurlijk altijd uit.
En dan is het vrijwel zeker definitief einde oefening voor de fabrikant van de betreffende virusscanner.

Zo is het imho ook met OpenDNS: je hebt helemaal gelijk dat er in theorie met het geschonken vertrouwen dingen zouden kunnen worden uitgespookt die niet door de beugel kunnen. Net als bij een virusscanner op je PC, of wat voor geïnstalleerde software dan ook. Maar ze zullen door de mand vallen als er iets echt niet deugd, want er zijn genoeg mensen die zoiets wél detecteren. En dan zijn die medewerkers hun baan kwijt.
Dus waarom zou men bij OpenDNS zo'n risico nemen?

Het scenario van de SSLv3-kwetsbaarheid was toen deze discussie van start ging nog niet bekend, en is een
toevallige bijkomstigheid. Ik zie OpenDNS er ook niet voor aan, om opeens iedereen die sslv3 nog gebruikt stiekem af te tappen. Bovendien kan OpenDNS de security.nl -lezers al geen sslv3 meer afdwingen, want iedereen heeft natuurlijk inmiddels het advies van jouw opgevolgd om sslv3 uit te zetten. ;-)

Verder is het volgens mij redelijk eenvoudig om het kwaadaardige scenario dat je voorspiegelt te controleren:
het mag niet zo zijn dat je browser een *.opendns.com certificaat weergeeft achter het slotje terwijl de inlogpagina van de bank voor je neus staat of tijdens de telebankiersessie. Er mag alleen een *.opendns.com certificaat worden weergegeven achter het slotje als er een melding (over een geblokkeerde site) op je scherm komt van OpenDNS, of je als je bewust
de bedoeling hebt om met een opendns.com website te communiceren.

Tonen van geblokkeerde sites gaat automatisch. Men zal er echt niet één iemand uitpikken die afwijkend wordt behandeld. Of je moet wel hééééééél bijzonder zijn, en het is van hogerhand opgelegd. Maar dat is uitzonderlijk.

Er zijn misschien legio mensen die niet zo op die certificaten letten. Maar ook genoeg mensen die dit wél snappen. Maar niemand heeft tot nu toe rondgebazuind dat het 100% zeker foute boel is. Het zou breed in het nieuws zijn uitgemeten.

Daarom geloof ik niet zo snel dat er zich zo'n kwaadaardig voorval voor zou doen, of voor zou gáán doen bij becky's computer. Maar eerder dat de "schijnbare anomalie" iets tamelijk onschuldigs is. (wel jammer dat we niets meer van becky hebben gehoord).
Ik zat net te bedenken dat ook het gebruik van "dynamische IP-adressen" tot problemen kan leiden.
Alle DNS-services verlopen immers via het IP-adres, en de persoonlijke filterservices zijn gerelateerd aan dat IP-adres.
Wijzigt je IP-adres, dan ben je alle gemaakte persoonlijke filterinstellingen bij OpenDNS kwijt.
Ook dit zou eventueel een probleem bij becky kunnen zijn. Het schijnt dat je wel dynamic IP in combinatie met OpenDNS kunt gebruiken, maar dan zul je DDNS-software moeten installeren.

Neemt niet weg dat ik het persoonlijk nou ook weer niet echt ideaal vindt om *.opendns.com permanent te vertrouwen. Onoverkomelijk is het voor mij niet, maar ik zou het alleen accepteren als er voldoende voordelen tegenover staan.

Afijn, iedereen dient de dingen bij dit soort zaken voor zichzelf te overwegen en uit te balanceren,
of de voordelen wel opwegen tegen de nadelen, eventueel betere alternatieven, etc.
De keuze hangt ook heel erg van ieders persoonlijke wezen en de persoonlijke situatie af.
Mvg, cluc-cluc

Ik heb een tijdje problemen gehad met de zekering van de 230V-huisgroep, waar ook een van onze PC's op draaide. Die PC gaf onder Firefox regelmatig allerlei certificaat-fouten bij verschillende sites. Uiteindelijk bleek de oorzaak heel eenvoudig. Het batterijtje op het moederboard van de PC was leeg. Daardoor werd bij stroomuitval de klok niet bijgehouden. Na een herstart duurde het even voordat de systeemklok was gesynchroniseerd, en in die periode kwamen de foutmeldingen. Dus mijn tip: vervang de batterij in je PC of laptop, synchroniseer de systeemklok en kijk of het probleem dan weg is. Succes! Henny.

Hoewel ik een link naar grc.com gezien heb was deze niet gericht naar https://www.grc.com/dns/dns.htm
Via deze pagina is het makkeljik te testen welke DNS servers je gebruikt en hoe makkelijk deze servers voor de gek te houden zijn. OpenDNS is sterk aan te raden gezien de resultaten via deze pagina.