Een aanvulling op deze belangrijke post voor "de gewone computergebruiker" met betrekking tot de opmerking van BitWiper betreffende:



...mag wel zijn om er een gewoonte van te maken nooit de URL- balk te gebruiken om een webadres in te tikken maar altijd de zoekbalk van een zoekmachine (Duckduckgo, Google, etc.)
Een eventuele typefout wordt hersteld in de zoekresultaten en vandaaruit aangeklikt mag je voor 99,9% aannemen dat je wordt verbonden met wikipedia.org i.p.v. wikipedua.org

Om dit goede artikel kort aan te vullen:
Wat veel mensen niet realiseren is dat HTTPS door een kwaadwillende te omzeilen is d.m.v. een Man in the Middle (MITM) aanval waarbij de https verbinding wordt gedowngrade naar een HTTP verbinding. Schematisch ziet de aanval er zo uit:

jij <--- http ---> aanvaller <--- https ---> server

Een maatregelen die hiertegen is genomen heet Http Strict Transport Security (HSTS). HSTS zorgt ervoor dat browsers een HTTPS verbinding forceren, als er niet met HTTPS gecommuniceerd kan worden, zal de browser een foutmelding tonen die niet weg te klikken is.
Het is belangrijk dat we webdiensten aansporen om altijd HTTPS te gebruiken, maar daarbij moeten we meteen aansporen om ook gebruik te maken van HSTS.

En wat als de zoek resultaten juist de malware site eerder laten zien? Ik vind dit een best groot risico. Via advertenties worden dit soort malware sites ook nog wel eens aangeboden, wat voor normale gebruikers soms best lastig zien is.

Beste Witpiper,

In reactie op HTTPS,ik probeerde ook bij mijnbelastingdienst .nl in te loggen.
Kreeg géén beveiligde verbinding,het slotje bleef uit.Wat mag dit betekenen?
vr.gr.a.j.

Inderdaad, gebruik *nooit* een zoekmachine. Legendarisch is het voorbeeld van de site van de phisher die domweg een advertentie had geplaatst, die boven de zoekresultaten van het gephishte bedrijf stonden.

Dat is weer een ander risico.
Wat ik alleen stel is dat zoekmachines URL-typefouten - zogenaamde typosquatting - behoorlijk negeert door bovenaan op de eerste pagina te melden dat resultaten worden weergegeven voor de querry met de juiste spelling

Voor het gemak maar even Bitwipers voorbeeld: wikipedua.org

Google toont dan dit:

Ongeveer 4 resultaten
Resultaten voor wikipedia.org
Zoek in plaats daarvan naar wikipedua.org

En in het geval van Duckduckgo?
Daar worden zelfs géén resultaten weergegeven voor de typosquatting URL. behalve de mededeling dat het een 'parked domain' is.

Ik probeer alleen maar aan te geven dat typosquatting een berucht en onderkend fenomeen is dat je behoorlijk naar tevredenheid kunt voorkomen door eerst een zoekmachine te gebruiken voor de gewenste URL en vanuit de zoekresultaten bijna altijd de juiste URL krijgt aangeboden.

Ik heb slecht zicht (vandaar dat ik ook heel vaak post van mij hier moet corrigeren) en ik maak het dus redelijk vaak mee een verkeerde URL te tikken.
In de URL balk kan dat meteen gestraft worden. In een zoekmachine zelden of nooit. Mijn jarenlange ervaring met deze wijze van webpagina's laden bewijst het laatste: Ik ben via een zoekmachine nog nooit op een typosquatting URL terechtgekomen.

Gebruik in de webbrowser gewoon een favoriet of een bladwijzer voor de URLs die je meest frequent bezoekt (Crtl+D). Dan zijn eventuele typfouten in het adres nagenoeg uitgesloten.

Als de gehele EU bevolking zoekmachines gaat gebruiken om dagelijks hun favorieten "in te typen", in plaats van bladwijzers te gebruiken, dan gaat dat een astronomische en onnodige hoeveelheid energie kosten en extra CO2 uitstoot opleveren...

Inloggen op mijn.belastingdienst.nl doe je het beste vanuit de algemene site van de belastingdienst, dus https://www.belastingdienst.nl/. Daar moet je al controleren of je een slotje ziet. Met Microsoft Edge op de PC die ik nu gebruik (met Windows 10) duurde het overigens even voordat het slotje verscheen, ik heb geen idee waarom (zelf gebruik ik bijna altijd Firefox als webbrowser).

Als je daar al geen slotje krijgt, is er iets goed mis. Dat probleem moet je eerst oplossen.

Als je vervolgens rechtsboven op "Inloggen" klikt, kun je daaronder kiezen voor "Mijn Belastingdienst". Als je daarop klikt ga je naar https://mijn.belastingdienst.nl/mbd-pmb/, en ook dáár hoor je een slotje te zien.

Als je geen slotje ziet, log dan niet in! Raadpleeg iemand met verstand van zaken om vast te stellen wat er aan de hand is. Je kunt ook hier vertellen wat je precies ziet, maar op afstand zo'n probleem oplossen is vaak lastig.

Het is het zelfde als whatsapp voor leken. Die app roept ook trots dat alles versleuteld wordt. Maar de nieuwe eigenaar (de grootste data ponzi-spel bedenker tot nu toe) kan wél overal bij. Wat het gaat over zijn machine. En is al zoveel van plan dat een van de origenele makers van whatsapp is opgestapt.

In het geval van whatsapp is de encryptie enkel om te voorkomen dat "de russen", "de chinezen", "de iraniërs" of de "noord koreanen" de berichten niet meer kunnen onderscheppen. In het belang van facebook en de waarde van hun databases. Niet in het belang van de gebruiker. Ook al zo een vals groen slotje dus.

Https helpt dat niemand je verkeer tussen A en B kan onderscheppen. Dat is mooi. Blijft over dat dat geen garantie geeft dat je B kunt vertrouwen.

Beste Witpiper,
Ik had op alle sites van de overheid géén slotje,wel volledig belastingdienst.mbd-pmb..Dit gewoon van gegeven https
adres genomen. 7 sites géén beveiligde verbinding.Ik vernam onderwijl van iemand anders die had wél een beveiligde verbinding.Zeer vreemd.Baart mij zorgen ,!
vr.gr.a.j.

HTTPS voor leken? Post dat op webwereld ofzo!

Van mensen hier wordt verwacht dat ze dat snappen en/of uit de RFC kunnen halen.

Van mensen hier wordt verwacht???
Tjonge, jonge wat een diep aanmatigende houding! Brrr.
Spreek voor je eigen parochie a.u.b. en laat anderen erbuiten ja!

Die aanval werkt niet als de URL die je intikt (of kopieert en plakt) begint met "https://", en dat geldt ook voor links in pagina's of snelkoppelingen waar je op klikt (een verzoek voor https vanuit de browser kan niet "gedowngrade" worden naar http).

Bovendien is HSTS helaas niet 100% betrouwbaar, want (tenzij de site voorkomt in de lijst van predefined HSTS sites) het werkt alleen als je de site eerder (meestal binnen 1 jaar) geleden hebt bezocht met dezelfde PC/tablet/smartphone en met dezelfde browser en met hetzelfde gebruikersprofiel.

Toch is HSTS absoluut nuttig, want op TV en op papier wordt http:// c.q. http:// vaak weggelaten, en ook in veel oudere webpagina's kom je nog http:// links tegen. En een MITM kan jouw vetbinding naar ern https site vethinderen, waardoor je in de verleiding zou kunnen komen om http:// te proberen. Als jouw browser de HSTS modus eerder heeft gezien, ben je veilig voor jouw eigen "onverstandigheid": de browser zal simpelweg verzoeken voor http:// omzetten in https:// voordat er heprobeerd wordt een internetverbinding op te zetten.

Maar het is het beste om jezelf aan te leren om voor sites waarvan je weet dat ze https ondersteunen, de URL altijd met https:// te laten beginnen.

Beste Bitwiper
Zéér duidelijke uitleg,bedankt! Ook voor minder comp.techn.geleerde.
vr.gr.a.j.

Weet je dat wel zeker? Waarom zou een MITM dit niet kunnen. Je ziet alleen wel een ander certificaat,
met name aan de SHA2-fingerprint is het goed te zien omdat deze bij de kleinste wijziging heel veel gaat verschillen met wat het moet zijn. Het wordt ingewikkeld doordat de bezochte website ook legaal een nieuw certificaat kan hebben.
Verder kan DNS aangevallen zijn, zoals dat regelmatig is gebeurd door een geslaagde aanval op de modemrouter waarin
meestal een ander DNSserver (onder beheer van het geboefte) werd ingesteld.
Het komt gelukkig maar zelden of nooit voor, maar het kan wel.

Ja, 100% (behoudens bugs in browsers die ik nog niet ken).

Een MITM kan dat alleen als:
1) Hij een certificaatuitgever (die door jouw browser vertrouwd wordt) heeft kunnen overhalen om hem een certificaat voor www.security.nl te verstrekken (d.w.z. een cerificaat met daarin een publieke sleutel horend bij de private key die de MITM in z'n bezit heeft) . Een vergelijkbare situatie ontstaat als de aanvaller jouw computer heeft gehacked en een vals rootcertificaat heeft geïnstalleerd (of jou via social engineering -of via een app met dubbele agenda- heeft overgehaald om zo'n vals rootcertificaat te installeren);

2) Ofwel hij de server van www.security.nl gehackt heeft en daarbij een kopie van de private key heeft kunnen maken, en daarmee "aantoont" dat zijn computer de server van www.security.nl is;

3) Ofwel er sprake is van software bugs, of een zwak sleutelpaar waardoor de aanvaller (uitgaande van de publieke sleutel in het certificaat van www.security.nl) de private key kon uitrekenen. Nb. de verwachting is dat alle huidige sleutelparen te zwak zijn voor toekomstige kwantumcomputers, en wie weet bestaat zo'n monster in het geheim al en kan de aanvaller daar bij (al dan niet legitiem).

Los van de bovenstaande (deels realistische) scenario's, is het slagen van een https verbinding geheel onafhankelijk van DNS en IP routering! De computer waar jouw browser een TCP/IP verbinding naar poort 443 mee opzet (of dat nou de echte is of een MITM), moet over de private key beschikken horend bij het certificaat dat jouw browser net daarvoor ontving (van wie dan ook) én de domeinnaam in de URL balk moet overeenkomen met 1 van de domeinnamen in dat certificaat én jouw browser moet dat certificaat vertrouwen.

Dat "vertrouwen" is er als het ontvangen https servercertificaat direct of indirect is afgeleid van een vertrouwd rootcertificaat in jouw browser. Dat vertrouwen is dus niet iets subjectiefs als "ziet er wel goed uit", maar is gebaseerd op digitale handtekeningen - waar weer dikke (toekomstige?) kwantumcomputers voor nodig zijn om deze te vervalsen. Als dat vertrouwen er niet is, geeft jouw browser een certificaatfoutmelding.

Kortom, alleen als de aanvaller over een certificaat voor www.security.nl beschikt dat door jouw browser wordt vertrouwd, en die aanvaller over de bijbehorende private key beschikt, komt de https verbinding met die aanvaller zonder certificaatfoutmelding tot stand.

In reactie op Vandaag, 08:29 door Bitwiper :

Dan heb je het waarschijnlijk over een browser die dankzij hsts herkent hoe het certificaat er uit moet zien.
Maar dit is niet het geval als je:
- de site nog niet eerder hebt bezocht
- de periode gedurende welke de browser dit onthoudt is verstreken sinds laatste bezoek. (meestal een jaar)
- er een volledige backup is teruggezet waardoor er oude hsts informatie in de browser staat.
- je geen virusscanner hebt die dit herkent

Natuurlijk, als de versleutelde verbinding met de juiste site eenmaal is gemaakt, kom een aanvaller er normaalgesproken niet meer tussen. Maar hoe zit het als de eerste syn-request de bedoelde server al niet bereikt, maar meteen al wordt omgeleid naar een mitm-server met https (en een ander certificaat), en er staat geen hsts-informatie (meer) in je browser.
Dit is immers wat er wel eens kan gebeuren als bijv. je router is gehackt en dns-server van je router is aangepast.
Is er dan tegenwoordig standaard nog iets anders wat je beschermd? En zo ja wat is dat dan?

De volgende keer een link naar de Wikipedia pagina is voldoende.

Onzinnige post.

Anomiep noemt de pagina niet en heeft het ook over 'een volgende keer'. volgende keer? vraagt iedereen met IQ +60 zich af.
Bitwipers post is kraakhelder van toon dus waarom zou deze belangrijk bijdrage nog een keer bijgedragen moeten worden?

Maar ook denk ik: Anomiep heeft last van maagzuuroprispingen en projecteert dat op Security.nl. Net zoals kleuters ook altijd de schuldige aanwijzen als zij zich prikken aan een potplant: "Au... stomme cactus!"

Nee, HSTS heeft daar niets mee te maken.

Een HSTS header, die een webserver naar jouw browser stuurt, bevat een geldigheidsperiode (vaak is dit 1 jaar of een half jaar). Jouw browser berekent de einddatum en slaat de domeinnaam, samen met die -zeg maar- vervaldatum, op in een database (de HSTS database) onder jouw profielmap.

Elke keer als je op een link klikt die met "http://" begint, of (bijvoorbeeld) http://www.security.nl/ intikt, of slechts www.security.nl (waar browsers -normaal gesproken- http:// vóór zetten), doorzoekt jouw browser eerst de HSTS database. Als de door jou gevraagde domeinnaam daarin voorkomt, checkt de browser de bijbehorende vervaldatum. Als die nog niet is aangebroken, zal de browser een eventuele http:// vervangen door https://, of als er nog niks voor stond, https:// ervoor zetten. Pas daarna zal de browser een TCP verbinding proberen op te zetten - met poort 443 van de gevrasgde webserver (dus niet meer via http poort 80).

Met andere woorden, met HSTS draagt een webserver jouw browser op om (gedurende de gegeven periode) onder geen enkele voorwaarde via http met die server te communiceren, en dat dus uitsluitend via https te doen.

Overigens, zodra een nieuwe https verbinding tot stand is gekomen, en de webserver opnieuw een HSTS header stuurt (via de versleutelde verbinding), zal de nieuwe einddatum worden uitgerekend, en wordt de oude einddatum in de HSTS database met de nieuwe datum overschreven.

Het doel van HSTS is dat, als jouw webbrowser eenmaal een site (domeinnaam) en einddatum in de HSTS database heeft, redirects naar een andere site en "downgrade attacks" van https naar http (zoals SSLstrip) door een MITM worden voorkomen - heel zinvol als je later via een onveilig netwerk (zoals publieke WiFi) surft en op links klikt die met http:// beginnen, of te lui bent om https:// vóór bijv. www.security.nl te tikken.

Je kunt dit eenvoudig zelf testen. Mocht je er een tijdje niet geweest zijn, open dan eerst https://digid.nl/. Voeg daarna de volgende regel aan de hosts file op jouw PC toe (en sla die file op):


Dat IP-adres is van www.security.nl (vertrouw me niet, doe zelf nslookup www.security.nl). Gebruik i.p.v. "test.test" niet slechts "test" want dat heeft kennelijk een speciale betekenis, in elk geval in Firefox ("testje" of "test1" kan wel).

Die regel zorgt ervoor dat als je naar de volgende URLs surft:
(1) https://test.test/
(2) http://test.test/ (of slechts test.test)
(3) https://digid.nl/
(4) http://digid.nl/ (of slechts digid.nl)
er verbinding wordt gemaakt met poort 443 of of poort 80 van de server met IP-adres 82.94.191.109.

Er gebeurt dan het volgende:

(1) https connectie: je krijgt een certificaatfoutmelding, want het certificaat dat de server stuurt is niet geldig voor de domeinnaam "test.test" in jouw URL balk (maar wel voor www.security.nl, secure.security.nl en security.nl). Omdat er geen verbinding tot stand komt, stuurt 82.94.191.109 geen HSTS header naar jouw browser. Er zal dus geen HSTS record voor "test.test" worden toegevoegd aan jouw HSTS database (ik ga er gemakshalve vanuit dat je niet al een record voor test.test in jouw HSTS database had).

(2) http connectie: de server stuurt je met een http redirect door naar https://www.security.nl/. Een MITM had je nu ook kunnen doorsturen naar een site met malware, of een site die als twee druppels water op de bedoelde site lijkt (als digid.nl geen HSTS zou ondersteunen, zou een MITM je kunnen doorsturen naar bijv. http://mijndigid.nl/ of desgewenst https://mijndigid.nl/ - met geldig certificaat, bijv. gratis van Let's Encrypt, en dan met een slotje natuurlijk).

(3) https connectie: net als bij 1 krijg je een certificaatfoutmelding;

(4) poging tot http verbinding: in tegenstelling tot 2, krijg je hier geen http redirect naar https://www.security.nl/ (of een malware/nepsite), maar een certificaatfoutmelding. Dit komt doordat digid.nl in de HSTS database zit, waardoor de browser alleen nog maar https verbindingen met digid.nl wil maken.

Hiermee zijn 2 zaken aangetoond:
A) Als een URL begint met https:// MOET de server (ongeacht z'n IP-adres) als eerste een certificaat sturen dat geldig is voor de domeinnaam in jouw URL balk (zie 1, 3 en 4 hierboven). Pas daarna kunnen bijv. redirects plaatsvinden;

B) Als een domeinnaam in jouw HSTS database zit (met een niet verlopen einddatum) hoef je er geen https:// meer voor te zetten om veilig te zijn (jouw browser doet dat voor je, zie 4).

Echter als digid.nl NIET in jouw HSTS database zit, of je er iets meer dan 1 jaar niet geweest bent, heb je niks aan HSTS. Met een nieuw profiel begin je met een lege HSTS database, en als je dan via een onveilige verbinding (of gehacked modem) surft en niet expliciet https:// ervoor zet, loop je risico (misschien klein, maar toch). Vandaar mijn advies om altijd https:// ervoor te zetten bij sites die dat ondersteunen; da's gewoon veiliger!

PS vergeet niet om die regel weer uit je hosts file te verwijderen.

Leuk artikel over HTTPS oftewel een SSL/TLS verbinding.
De nadruk ligt hier op het laatste woord; Verbinding.

Als namelijk de onderliggende server niet goed beveiligd is dan is de encrypte verbinding tussen de client pc en betreffende server dus zinloos.

Kortom, het is dus zaak dat organisaties hun zaken goed op orde hebben en dus niet alleen een geldig certificaat.

In reactie op 23:11 door Bitwiper - Bijgewerkt: 06-06-2018, 23:43:

Maar dit is niet het geval als je:
- de site nog niet eerder hebt bezocht
- de periode gedurende welke de browser dit onthoudt is verstreken sinds laatste bezoek. (meestal een jaar)
- er een volledige backup is teruggezet waardoor er oude hsts informatie in de browser staat.
- je geen virusscanner hebt die dit herkent

1. Als je de site nog nooit eerder hebt bezocht weet je browser waarschijnlijk niet of er sprake is van hsts tenzij het default al in de browser staat maar dat zijn er betrekkelijk weinig. Je doet http en dat verandert aanvankelijk niet in https, je kan aanvankelijk al bij een MITM-server binnenkomen voordat de juiste server heeft laten weten dat deze hsts ondersteunt.
U bent in dit geval het haasje.

2. Er staat geen certificaatinformatie meer in de browser. Jij zegt: maar hij blijft automatisch https gebruiken.
U surft bijv. eens via wifi. Erachter zit een malicious beheerder of iemand in de biirt lat u binnenkomen op een rogue wifipunt.
Zelfs als er https van is gemaakt bent u dan kwetsbaar. Uw browseraanvraag voor een verbinding met een bepaald ip-adres of dns-server wordt omgeleid. De misbruiker heeft namelijk een valse https-server staan en dns-server staan. Dat kan al op een laptop. Deze valse server neemt de aanvraag van uw browser aan en kan van alle of van sommige browser aanvragen
de https verbinding starten met https want uw browser weet van niets. Weliswaar niet het juiste certificaat, maar de rest klopt en de https-verbinding wordt gestart. Als u nooit naar het certificaat kijkt en niet weet hoe het er uit moet zien bent u het haasje. De aanvaller kan met u doen wat hij wil.

3. Een backup is altijd verouderd. Stel u heeft sinds een backup nog hsts websites bezoekt, dan staan deze niet geregistreerd in de backup. Gaat u dus deze backup terugzetten, dan behandelt de browser u weer alsof u hem voor de eerste keer bezoekt, omdat er in de backup nog geen certificaatinformatie over die site was opgenomen: u bezocht deze site pas later. U loopt dus hetzelfde risico van de eerste keer, want in uw browser is de hsts-informatie van deze website waarschijnlijk niet aanwezig tenzij deze al in de default lijst met de preset van hsts websites was opgenomen.

4. Een virusscanner zou ook kunnen herkennen wanneer je fout zit als andere systemen falen, maar 100% zeker is dat niet.

In elk geval klopt het dat als de browser niet gedwongen wordt om https te gebruiken (ofwel doordat de gebruiker op een link klikt die met https:// begint, ofwel doordat de gebruiker devURL intikt en deze met https:// laat beginnen, ofwel doordat de site eerder in de HSTS database is opgenomen), en er dus http:// gebruikt wordr, dat een MITM volledige controle heeft over wat er wel en niet naar de browser wordt gestuurd.

Ik begrijp niet wat je bedoelt.

En dat is dus pertinent niet waar. Direct nadat de server een certificaat naar de browser heeft gestuurd, controleert de browser onder meer:
- of dat certificaat door een vertrouwde certificaatuitgever digitaal is ondertekend;
- of die digitale handtekening klopt;
- of het om een https servercertificaat gaat;
- of het binnen de geldigheidsperiode zit;
- of de domeinnaam in de URL balk in het certificaat terug te vinden is (als het o.a voor die specifieke domeinnaam is uitgegeven, eventueel gebruikmakend van wildcards, bijv. in *.xs4all.nl,
- of de server kan aantonen over de private key te beschikken die bij de public key in het certificaat hoort.

Als er ook maar iets van het bovenstaande verkeerd gaat, breekt de browser de verbinding af - nog voordat die verbinding versleuteld is. Dat dit zo werkt kun je eenvoudig zien met bijv. WireShark op jouw PC.

Opnieuw niet waar. Heb je het experiment gedaan dat ik voorstelde?

Dat klopt allemaal als je met een teruggezette backup of met een gloednieuwe PC naar www.security.nl of naar http://www.security.nl/ surft - dan kan een MITM genadeloos toeslaan. Maar dat kan die MITM niet als de URL met https begint.

Ik ben nog geen virusscanner tegengekomen die https server certificaten (ook bekend als SSL servercertificaten) chect. Maar dat is dan ook nergens voor nodig, browswers kunnen dat prima.

De beste suggestie daartegen: Verbind de eerste keer alleen vanaf een vertrouwde verbinding. Ga na installatie van device naar je banksite om de HSTS en/of HPKP geconfigureerd te krijgen. Als je twijfelt of je de site al hebt bezocht, wacht met bezoeken tot een vertrouwde verbinding tot stand kan komen.

Leg dat (alle) gebruikers maar eens uit...

DNSSEC eisen. En de browser standaard op 443 laten verbinden.

08-06-2018, 23:23 door Bitwiper
Tuurlijk wel. Stel we nemen de proef op de som, ik ga als MITM functioneren door de netwerkplug er bij jou uit te trekken en mijn PC er tussen te wurmen. Jij logt in bij je bank en mijn PC-software ziet de plain aanvraag om een https verbinding te starten voorbijkomen.

Mijn PC constateert: "hee, het ip-adres van een bank, ga'k lekker niet doorsturen via de router naar de bank. Ik ga gewoon lekker zelf voor bank spelen. Ik heb nepsitesoftware aan boord van die bank en dat is haast niet van echt te onderscheiden.
Hallo IP van PC van Bitwiper, request ontvangen, ik ben de bank die jij hebt aangevraagd... https goedgekeurd. Dit is mijn certificaat. Maar ja ondertussen is dit niet het echte certificaat van de bank. Nah, merkt ie toch niet tenzij hij goed oplet,
en anders hebben we pech.
Bitwiper: dit moet altijd kloppen volgens mijn theorie, ik zie een slotje dus t'zal wel goed zijn.
(hihihi hij heeft niet eens opgemerkt dat het geen EV-certificaat is. Nou allee Bitwiper. Log maar heerlijk in op mijn nepsite. En ja, mijn baas kijkt vrolijk mee met wat er allemaal voorbij komt Kassaaaaaa, daar gaan we"...

Soms is dit helemaal niet moeilijk. Achter de router gaat het bijna net zo als ervoor. En als je ergens op gratis wifi binnenkomt kanje er voor zorgen om af te dwingen dat je op mijn rogue wifi-punt binnenkomt. Vraag maar aan Brenno de Winter.
Tenzij hsts in je browser nog actief is voor die banksite. Of je virusscanner of safebrowsing van de browser ziet het in geval ze aan staan. Je kan bijv. ook een spaarbank hebben waar je alleen maar naar omziet voor de belasting aangifte. Kortom: als hsts informatie om redenen die ik eerder noemde is verdwenen, kan je eventueel op de website van een oplichter terecht komen als je niet uitkijkt. Met https beginnen maakt dit volgens mij niet onmogelijk. Want als een MITM jouw request om met https naar de bank te gaan meteen al overneemt als ware hij de bank waar je naar toe wil, dan begeef je je op glad ijs als je niet eerst het certificaat goed controleert.

Begrijp je het nu waar 'em de kneep zit?

Dat is geen goed advies, om de volgende redenen:

De bedoeling is dat HSTS https afdwingt, maar:
- Niet elke https site stuurt HSTS headers naar de browser.

- Sommige sites zijn verkeerd geconfigureerd. Ik heb bijv. verschillende sites twee headers met conflicterende informatie zien sturen, bijv. Firefox negeert ze dan.

- Vaak is er sprake van "jump"-sites, zoals example.com, die redirecten naar www.example.com. Regelmatig zie ik dan een nette HSTS header op www.example.com, maar GEEN HSTS header op de jumpsite, exanple.com. En dat is funest! Want het hele probleem is nou juist dat mensen te lui zijn om te typen en daarom slechts "example.com" invoeren. Daarmee is een SSLstrip aanval door een MITM een peuleschil: de gebruiker blijft "http://example.com/" zien, of slechts "example.com/" want dat vinden browsermakers een goed idee. Er wordt dan geen slotje getoond (wat in Chrome binnenkort ook geschrapt wordt), masr tegenwoordig wel vaak met een "geen https" waarschuwing op inlogpagina's - terwijl de domeinnaam klopt - dus waar zou je je als leek zorgen over moeten maken - je zit echt op die site.
Ondertussen kan een MITM al een verbinding hebben met www.example.com (https natuurlijk, hij is safe voor volgende MITM's op de lijn) en, nadat hij de inloggegevens van de gebruiker voorbij heeft zien komen, kan doen wat hij wil. Bij 2FA (Two Factor Authentication) heeft hij daar niet zoveel aan, maar kan tijdens de lopende sessie elke handeling uitvoeren die de gebruiker zou kunnen uitvoeren, naar keuze of de gebruiker daar wel of niet iets van ziet. De stappen zijn dan als volgt:


Dus ook al heeft de gebruiker HSTS info van www.example.com in haar browser, daar heeft zij niets aan zolang de browser dat niet heeft voor example.com en de gebruiker daar blijft tijdens de sessie.

- De geldigheidsduur van HSTS is soms slecht gekozen. Als je een site gemiddeld 1x per jaar bezoekt, zit het er dik in dat er de ene keer bijv. 363 dagen tussen de bezoeken zit, en de volgende keer 367 dagen. Helaas verlopen de meeste HSTS registraties na exact 365 dagen (terwijl een kalenderjaar gemiddeld al iets langer duurt dan 365 dagen). Maar ik heb ook wel eens HSTS info gezien met een onbegrijpelijk korte geldigheidsduur.

- Als de gebruiker van device of browser wisselt, of een device moet resetten naar factory defaults, of een Windows profiel moet verwijderen en opnieuw aanmaken, is er geen historische HSTS informatie.

- Een leek kan nergens aan zien of, als zij besluit slechts "example.com" in te tikken, er voor die site op dat moment geldige HSTS informatie voorhanden is, en weet dus niet of het een slecht idee is om lui te zijn.


HPKP: bijna niemand gebruikt dat - en terecht. Het vereenvoudigt denial of service aanvallen, een reden waarom browsers zouden moeten stoppen met het ondersteunen ervan.

Nee, leg ze nou gewoon uit dat ze altijd https://www.example.com/ moeten intikken en nooit certificaatwaarschuwingen moeten negeren. En, als ze die site vaker denken te bezoeken, daar meteen een bookmark/snelkoppeling/favoriet van moete maken en daar voortaan op klikken.

Ik zie niet hoe dat hier helpt.

DAT is pas een goede suggestie! Maar ik vrees dat wij, met dit standpunt, ruzie krijgen met heel veel http site eigenaren...

Interessant. Wat gebeurt er als deze verbindingen door de MITM worden geblokkeerd? Is dit mogelijk?
En krijg je dan een waarschuwing? Of kun je niet meer internetten?

Hoe bewijs je naar je provider een MITM verbinding? Deze zal zeggen ik weet het niet!

Internetproviders tussen jouw PC en de servers waar je verbindingen mee maakt, zijn per definitie MITMs . Daardoor is de sleepwet in Nederland mogelijk, maar er zijn ook landen waar ISP's advertenties in http verkeer injecteren.

En er zijn landen waar https verbindingen woren "opengebroken" en, gezien vanuit de browser, opnieuw worden geauthenticeerd (waarna de verbinding opnieuw wordt versleuteld) met een nep, on-the-fly gegenereerd, webservercertificaat ondertekend met een overheid-rootcertificaat - dat (meestal verplicht) vertrouwd wordt door jouw browser. De NL overheid heeft aangegeven de "Staat der Nederlanden" rootcertificaten in onze browsers (en andere wereldburgers) niet voor dit doel te zullen misbruiken. Of "nood wet breekt" en verzoekjes van andere landen in alle gevallen zullen worden geweigerd, moeten we afwachten.

Je kunt, zo vermoed ik, wel raden hoe jouw ISP reageert als je meldt niet gediend te zijn van dit soort interceptie.

Waar het hier vooral om gaat is een MITM dichter bij jouw PC. Denk aan DNS aanvallen waarbij jouw PC naar een ander IP-adres wordt gestuurd dan dat van de bedoelde server. Met aanvallen op internet routering (o.a. BGP hijacks), communiceert jouw PC wel met het bedoelde IP-adres, maar dat is -gezien vanuit jouw PC- op dat moment gekoppeld aan een heel andere server. Of denk aanvallen in (public) WiFi netwerken, of in LAN's - met tools zoals ettercap en Resolver (die de meeste Windows PC's, die voortdurend WPAD blèren, via elke gewenste "proxy" laten verbinden - daarnaast ondersteunt Resolver aanvallen op o.a. NBNS).

Aan de aanvallen beschreven in de paragraaf hierboven kunnen ISP's weinig tot niets doen.

Dat, mijn vriend, zijn de juiste vragen.

???
https://images2.persgroep.net/rcs/3m5FUzT3l4-4eDmV6-PLJkMFiyY/diocontent/73209516/_crop/593/0/1141/1142/_fill/600/600?appId=93a17a8fd81db0de025c8abd1cca1279

Pas de titel ff aan.
Die past namelijk volstrekt niet bij het stuk, de discussie, noch bij de lezersgroep die elders zwemt (op de nos site).

(en link ff naar een wikipedia statement die jouw statement staaft, dat is er namelijk nog niet)

Er bestaat toch "https Everywhere"?
Waarom wordt daar in dit kader niets over gezegd?

En ik ben niet te spreken over de ontkennende en negerende reactie van Bitwiper over de kwestie dat https (zonder hsts informatie in de browser over die site) gewoon kan worden omgeleid net als iedere https-verbinding die men start.

https://www.owasp.org/index.php/Man-in-the-middle_attack:

Mooi stukje, daar niet van, zet er even wat tegenover


SSL en andere emmertjes digi-water naar de zee dragen als nationale sport

Voorbeeldje
Nuon energieleverancier.
Bekend onder https://www.nuon.nl/

Goed controleren?
Okay, het is groen dus dat is inderdaad okay
Slotje https://www.nuon.nl/ geeft antwoord op Owner "N.V. Nuon Energy"
Het is wel niet in het Nederlands maar het zal wel goed zijn, even geen zin om de kvk te controleren of er niet toevallig twee verschillende zijn, Nuon Energie en Nuon Energy, maar het zou kunnen (bij wat kleinere bedrijven wellicht).

Eind goed al goed?
Nou nee.

Email
Wat nou als je een email krijgt van dat bedrijf?
Ze stuurt namelijk emails onder nuon.com
Punt com??
Even kijken dan op het web of die website wel bestaat, https://www.nuon.com/
Inderdaad.

Slotje https://www.nuon.com/ geeft antwoord op Owner "This website does not supply ownership information."
Certificaat dan, CN common name "ssl473702.cloudflaressl.com"
O dat ziet er wel heel raar uit, dat is vast een NEPserver!!!
Gauw wegklikken en de computer scannen met de virusscanner.

De niet leek weet dat cloudflare ook halve https diensten levert, dat hebben we al eens eerder hier op deze website geconstateerd, https tot aan cloudflare, dan een vage mitm en vanaf daar mag Justus het weten hoe de verbinding eruit ziet.

Maar de leek?
Ja, of nee, die loopt nu vast.
'Gelukkig' kijkt de leek niet zover maar daarmee heeft de controle eigenlijk ook haar nut verloren, slechte controle is immers niets waard.

Subdomeinendansjes
Als ik dan toch maar die email van die nepserver.com met Cloudflare vertrouw en doe wat in de mail staat, namelijk meterstanden invullen door een link aan te klikken, krijgen we het volgende probleem.
Veel overheids websites, banken websites en commerciele websites maken er een potje van op dit punt.

Kijk maar.
Nuon.nl, uhnee Nuon.Com vraagt meterstanden in te vullen onder de volgende link

https://nuon.pti.nl/ecard/nuon.php?data=hdyejsleik4willekeurigealfabettenaantekenslang

Zit de leek nu op een website van Nuon?
Ja denkt de leek want er staat toch Nuon in de link (ojee...) eh in de url, wel twee keer!

Hoe zat dat ook alweer met die domeinen?
Nuon.nl, nuon.com en dus ook nuon.php ?
Even zoeken, typtyp,.. nuon.php ,.. oh "Unable to connect, browser can't establish a connection to the server at nuon.php."

Ahaa! Hebbes, weerrr een nepserver!??

O wacht ik zie nog .nl staan met pti ervoor.
Pti?
Pti.nl ?
Even intikken, hee een groen slotje, maarreh, Pincode Telenet B.v. ??
Owner "Pincode Telenet B.V."is geen Nuon.
Het is wel paarsig maar het geel ontbreekt, nee dit is echt een ander bedrijf.

En nu? on? ..
Hoe dan?
Ik snap er niets van als leek!!!
Als ik als leek ga controleren wordt het hopeloos ingewikkeld!

En als ik als leek zoals vele andere leken standaard via google een url opzoek loopik ook nog eens de kans vele andere nuons tegen te komen.
Want wat een eindeloze mogelijkheden aan domein extensies naast.nl en naast .com
https://en.wikipedia.org/wiki/List_of_Internet_top-level_domains#ICANN-era_generic_top-level_domains
Van nuon.sucks geloof ik wel dat een leek ook wel denkt dat niet goed kan zijn.
Maar deze, deze https://www.nuon.net/ had heel goed gekund, of org of biz, etc etc.

Sommigen (de meesten) leveren nog geen pagina op die op de Nuon website lijkt.
Maar eigenlijk maakt het niet uit als er maar ergens nuon in de url staat dan is het goed, dat heb je immers zelf van nuon geleerd.
Helemaal goed?
Nee, dus en het is eigenlijk verbazingwekkend dat er nog zoveel goed gaat!
Want van de leek kan je het niet kwalijk nemen dat die er geen ene jota van snapt!

Elke browser een eigen kleurtje en gedraging
En dan hebben we het nog niet eens over de verschillende kleuren slotjes in de verschillende browsers, wel of geen slotjes weergave, de waarschuwingen of juist geen waarschuwingen of binnen kort dus geen zichtbaar slotje en dan ook nog dat met dat www. en soms ook ww2. ..

De browsermakers, de certificaatverstrekkers, cloudboeren als cloudflare, domeinnaambeheer ICANN en vooral de bedrijven en overheden zelf met het gehussel van domeinen onder verschillende extensies, onder verschillende namen en totaal niet te begrijpen gehannes met subdomeinen en ondoorzichtige doorverwijzingen naar andere bedrijven maken het voor de LEEK ten ene male een hopeloze zaak.

Abolute controle is absolute kolder!
Goed opletten is dus eigenlijk lulkoek als je niet daadwerkelijk begrijpt wat er allemaal aan soorten mogelijkheden voorbijkomt.
De standaard leek snapt dat niet, en het is ze niet kwalijk te nemen, ze doet dus ook geen controle, in de praktijk niet en ook niet in theorie want als je niet weet hoe je moet controleren heeft het ook uiteindelijk maar matig zin.

Oja gemiste basis vraag aan de leek, http(s) ?
Vvraag aan honderd mensen wat http betekent, ehh.
En Https staat voorrr ... http-slotje?
Waar staat het slotje voor?
Hoe zit dat dan met de kleuren? Welke heb je dan?

Slotjessprookjes
Ons is verteld dat we op het slotje moeten letten maar het slaat dus eigenlijk vrijwel nergens op omdat het .. .. omdat er vele andere aanvalsvectoren zijn en dat letten op dat slotje inderdaad bepaald geen garanties geeft (op de verkeerde websites).

Niet NOSgenoemd maar ook heel kwalijk : Bovendien doen bedrijven zelf er ook nog eens ALLES aan om op de home pagina de aandacht volledig weg te trekken van die urlbar die op een smartfoon al helemaal nauwelijks leesbaar is.

Oplossing voor deze hopeloze zaak?
Standaardisering, maar de markt houdt niet van standaarden, dat is namelijk niet zo onderscheidend en verkoopaantrekkelijk.

Dus, dan maar 1 keer de belangrijke domeinen als juiste favoriet opslaan in je browser en hopen dat het goedgaat.

Een andere oplossing is een app per functie, voor internetbankieren, voor overheidszaken, ..
Maar dan heb je weer een ander probleem, namelijk dat je volstrekt niet meer kan controleren wat die bedrijven van je systeem graaien!
Op je computer houdt je advertenties tegen en trackers tegen, in de app kunnen ze behoorlijk ongecontroleerd hun gang gaan, tenzij de smartfoon-os fabrikant dat niet okee vindt.

Zweedse wateren stromen overal
Nuon is tegenwoordig trouwens zweeds, mooi woord dat waterval op zijn zweeds, vele soorten spellingsmogelijkheden en vele extensies beschikbaar.

Maar gelukkig, gelukkig voor alle boefjes heeft nuon het supermakkelijk voor ons gemaakt, als er maar ergens Nuon in de url staat is het goed!
Linkje klikken maarrr!!
Nuon.vulmaarinanythinggoes.nl/ecard/nuon.php?data=hdyejsleik4willekeurigealfabettenaantekenslang

Begin dan ook niet meer over het probleem achter / voor het toetsenbord als je als industrie er een rommeltje van maakt voor de klant!


Nuon is natuurlijk maar 1 voorbeeld, bedrijven doen dit ook standaard met bijvoorbeeld enquetes etc etc.
De gemiddelde leek heeft echt geen flauw benul waar die allemaal naar toe gestuurd wordt en denkt vaak op de site van een bedrijf te zitten terwijl dat echt niet zo is, en maar absoluut kijken naar het slotje en of de naam ergens genoemd wordt.

Ja dat bestaat. Sterker, die plugin zit (samen met o.a. NoScript) al jaren in mijn browser. Maar het is niet zaligmakend en ik ken verder niemand die het gebruikt. Precies daarom worden lapmiddelen als HSTS bedacht - en slecht of helemaal niet geïmplementeerd (mogelijk meer daarover later vanavond).

Dat ik zou negeren begrijp ik niet. Ik geef wellicht niet iedere Anoniem antwoord (en trollen negeer ik normaal gesproken zeker), want ik kan ze niet uit elkaar houden - noch weet ik of het om dezelfde persoon gaat die meerdere reacties plaatst.

Maar wat je mij niet kunt verwijten is dat ik topics die ik plaats op deze site verwaarloos; ik probeer heel serieus vragen te beantwoorden en kritiek met argumenten te pareren.

Wat heel goed kan is dat ik iets niet goed begrepen heb en/of verkeerd uitleg; ik ben ook maar een mens. Ik laat me graag overtuigen van mijn ongelijk, want daar leer ik zelf van en dan vertel ik ook geen onwaarheden als ik hier iets post. Maar je zult wel met overtuigende argumenten moeten komen. En over smaken valt niet te twisten.

Dat klopt voor 100% en ontken ik ook nergens.

Alleen lijk jij te denken dat HSTS een soort heilige graal is die MITM attacks kan voorkomen, maar dat is gewoon niet zo. Het enige dat HSTS doet, als het werkt in jouw situatie voor een specifieke site, is "http://" of een ontbrekend protocol voorvoegsel, vervangen door "https://" voordat jouw browser een TCP verbinding opzet.

Als de aanvaller over de private key van de server beschikt, kan hij jouw sessie ook op de server zelf afkijken of gegevens op die server wijzigen voordat jij ze te zien krijgt. Dat is geen scenario dat https kan mitigeren (HSTS trouwens ook niet) en neem ik dus niet mee in deze discussie.

Het gevaar van onterecht uitgegeven certificaten is aanzienlijk. Ik heb dat dan ook benoemd. Maar ook dat is een probleem dat niet eenvoudig oplosbaar is, en ook hier helpt HSTS niet.

Deze discussie draait erom dat iemand niet door heeft dat hij via http ongemerkt verbinding heeft met een heel andere server dan bedoeld, versus dat die persoon via https behoorlijk zeker verbinding heeft met de bedoelde server en anders een certificaatfoutmelding krijgt.

Er bestaat helaas geen realistische technische oplossing (ook HSTS helpt hier niet) voor mensen die certificaatfoutmeldingen negeren; er zijn nou eenmaal situaties waarin je geen andere keuze hebt, maar dan moet je wel goed weten wat je doet. Als jij een gebouw binnenloopt waar ING op de gevel staat, en terwijl iemand roept "dat is geen ING filiaal, het zijn oplichters!" daar toch de cash dagopbrengst van jouw marktkraam afgeeft, wat ben je dan?

Als je meent dat ik niks snap van HSTS en het heel anders werkt, zie ik jouw goed onderbouwde argumenten (met overtuigende bronvermeldingen) graag tegemoet.

Bitwiper, het zou een spraakverwarring kunnen zijn. Maar ik meende eerder toch steeds te horen dat je denkt dat het onmogelijk is dat een https verbinding wordt gekaapt door een MITM. "als er maar https voor staat" dan kan dat niet fout gaan las ik bij jou.
Ik heb hier eerder 4 omstandigheden genoemd waarin hsts fout kan gaan, en ook al zou er dan wel https voor staan
dan nog kan een MITM de verbinding aan het begin gewoon kapen en klopt alleen het certificaat niet. (verschilt van de echte site)

Dat heb ik willen zeggen, maar daar hoorde ik jou tegen in gaan en tenslotte hoorde ik geen reactie meer.
De pagina van OWASP bewijst dat het wel kan, ongeveer net zoals ik jou voorspiegelde.
Owasp laat de MITM tegelijk een verbinding met de echte server leggen, dat kan natuurlijk ook, en dan kan de MITM ertussen de gegevens bekijken of manipuleren.
Ik had het voorbeeld gebruikt waarbij je kan worden verbonden met een look-a-like site en dat kan evengoed.
Zonder dat je over de private key van het certificaat van de echte site beschikt kan dit.
Dat is wat OWASP wil vertellen. En als je dan niet goed op je certificaat let dan kan je er in tuinen
als om één of andere reden je browser geen hsts informatie van de bezochte site meer heeft. (ik had er 4 genoemd)

Ik kreeg bij zoeken op Google geen HTTPS van Mijn Belastingdienst.nl te zien.andere sites wel HTTPS. Ook die van Mijn Overheid.nl was HTTPS.Dus specifiek mijn Belastingdienst.nl géén HTTPS.
Op een forum kaarte ik het direct aan en iemand anders had wél een HTTPS verbinding met Mijn Belastingdienst.nl.
Kan dat dus ,ik géén HTTPS verbinding en een ander wel op de zelfde zoekopdracht?

Ik weet niet op welke 4 omstandigheden je doelt en begrijp ook niet waarom je steeds HSTS erbijhaalt (want daar gaat in de praktijk veel bij mis, zie https://www.security.nl/posting/566101/NL%3A+veel+brakke+https+sites).

Als je in de URL balk van jouw browser https://www.security.nl/ intikt, gevolgd door Enter, dan kan m.i. het volgende gebeuren:

A) De voorpagina van de echte www.security.nl verschijnt;

B) Je ziet een foutmelding dat een verbinding niet mogelijk is (bijv. omdat de server down is of omdat jouw internetverbinding eruit ligt;

C) Je krijgt een cerificaatfoutmelding, in dit geval om een andere reden dan dat de domeinnaam in het certificaat niet "www.security.nl" is (zie daarvoor E) - maar bijv. omdat het certificaat is verlopen (of jouw PC dat denkt omdat de systeem-datum en tijd fout staan op jouw PC), omdat het certificaat een onveilige hashfunctie en/of een te korte RSA public key bevat, het certificaat door de uitgever is ingetrokken (revoked), het certificaat wel geldig is maar niet expliciet bedoeld is om te worden ingezet als https server certificaat, na een crash van de server een oude backup is teruggezet met daarin de private key horende bij het vorige certificaat, de server OCSP stapling gebruikt en daarin onjuiste informatie meestuurt, jij jouw browser op verplichte OCSP/CRL checks hebt ingesteld en de OCSP/CRL server niet (bijtijds) antwoordt of onjuist antwoordt, de server uitsluitendend andere cipher suites ondersteunt dan waar jouw browser mee overweg kan etcetera. Het zou ook kunnen dat de server een intermediate certificaat niet meestuurt (dat jij toevallig nog niet in de "SSL cache" van jouw browser hebt, of dat dit certificaat ongeldig/ingetrokken is. Her zou ook kunnen dat de maker van jouw browser (of besturingssysteem) het benodigde rootcertificaat niet meer vertrouwt, of dat jij zelf van minstens één van de betrokken certificaten hebt aangegeven ze niet meer te vertrouwen. En vermoedelijk is deze lijst nog niet compleet;

D) Iemand met toegang tot de verbinding luistert die af met een zogenaamde netwerksniffer (bijv. tcpdump of WireShark) en slaat alle uitgewisselde netwerkpakketjes (grotendeels met versleutelde inhoud) op in een bestand dat gewoonlijk een capture file wordt genoemd. Als de "afluisteraar" op enig moment in de toekomst de versleuteling weet te kraken, of de voor het decrypten noodzakekijke sleutels in handen krijgt, is het aspect "vertrouwelijkheid" geschonden, maar niet de "integriteit" van de informatie die jij met de webserver hebt uitgewisseld;

E) Je krijgt een certificaatfoutmelding omdat geen van de domeinnamen in het certificaat (d.w.z. waar het certificaat voor is uitgegeven) overeenkomt met de domeinnaam in de URL balk van jouw browser, nl. "www.security.nl";

F) Jouw browser krijgt, zonder foutmeldingen of waarschuwingen, een verbinding met een andere fysieke https server dan die van de echte www.security.nl, nl. de computer van een aanvaller. Die aanvaller kan jou dan laten zijn wat hij wil. Als die aanvaller vanuit zijn PC zelf een verbinding opzet met de echte https://www.security.nl/ en de gegevens die jij naar de nepsite stuurt, doorzet naar de echte www.security.nl - en vice versa - is sprake van een geslaagde MITM aanval:
In dit scenario kan de aanvaller jou maar zijn keuze informatie laten uitwisselen met de echte www.security.nl en/of met zijn computer. Nadat hij jouw login gegevens (indien jij inlogt) heeft ontvangen (en desgewenst heeft doorgezet naar de echte security.nl), kan de aanvaller -zonder dat jij hier iets van ziet- alles doen op security.nl wat jij kunt. Dus inclusief jouw wachtwoord wijzigen en wellicht (weet ik niet zeker) ook jouw email-adres, zodat jij niet meer kunt inloggen en ook jouw wachtwoord niet meer kunt resetten.

Relevant voor onze discussie zijn mijns inziens uitsluitend E en F, ben je het daarmee eens?
Of ken je wellicht nog andere scenario's die ik in bovenstaande opsomming over het hoofd zie?

Ik wil je daar graag mee helpen, maar dan heb ik de exacte domeinnaam nodig waarbij jij geen slotje te zien krijgt. "Mijn Belastingdienst.nl" is geen geldige domeinnaam, want in domeinnamen mogen geen spaties zitten.

Hoe luidt de domeinnaam precies?

De reactie van Anoniem hierboven,beginnend met tekst>in dit scenario<Dit is wat mij al jaren ,lees al jaren gebeurt!!Ik zit bij de beste provider van Nederland!!!!Maar wil ik inloggen bij Mijn belastingdienst.nl is wederom mijn inlogcode niet meer bruikbaar.Moet een nieuwe aanvragen.krijg bevestiging op site uw aanvraag is gedaan,maar komt geen nieuwe digid (interventie(opgestuurd.weer aanvragen,dit is mijn al twee keer gebeurt.Bestel ik sloopafvalbak op mijn adres ,krijg no-repley bevestiging,alles exact,wordt afval bak 4 huizen verder gebracht,chauffeur liet opdracht zien,HUISNUMMER GEWIJZIDG!Chauffeur internet in vrachtauto op display gezien.
Heb ik géén melding van gekregen!Dit speelt al jaren.Doe ik zakelijke transacties/mailverkeer,komt mail niet aan,naar verzender gegaan,en opnieuw naar twee mailadressen laten sturen,GEEN MAIL ontvangen,vrijdag middag.Ook niet in alle boxen.Provider gebeld,kon mij niet helpen,vreemd.MAANDAG MORGEN MAIL IN SPAMBOX!!.

Mijn Belastingdienst.nl moet standaard https geven maar deed dat niet,gaf www.mijn belastingdienst.Maandag middag gaf hij weer wel https.mijn belastingdienst.nl. Maar mijn ervaringen als hierboven doen mij het ergste vermoeden.
Ik Googelde óók regelmatig (Interesse) op dat huis als hierboven(4 huizen verder).Hoe betrouwbaar is mijn internet verbinding bij de beste provider van Nederland?
Vriendelijke groet,

Zoals boven ook aangehaald, kan de site "Mijn Belastingdienst.nl" niet bestaan.


Ook de site "www.mijn belastingdienst.Maandag" kan niet bestaan. Maandag is geen toplevel domein. En mocht je "www.mijn belastingdienst.nl" bedoelen, dan bestaat die site ook niet.

Je kunt wel bij de beste provider zitten maar als je met verdeelde domeinnamen werkt, kunnen zij er ook geen kant mee op.

"mijn.belastingdienst.nl" geeft gewoon een https verbinding, ook al probeer je met http in te loggen.

Edit: Zulke belangrijke sites als deze, moet je de url nooit door de browser laten aanvullen. Doe dit bij voorkeur via een goed bevonden bookmark.

Ik blijf vinden dat de fingerprint van het certificaat vergelijken met wat het hoort te zijn, de meest robuuste controle is.
Het andere heeft af en toe al eens gefaald, zelfs een EV-certificaat voor een financieel bedrijf kon men gewoon aanschaffen zonder veel risico te lopen:
https://www.security.nl/posting/542799/Onderzoeker+demonstreert+probleem+met+EV+SSL-certificaten

Veel controle-mechanismen zijn vooral theoretisch en hangt er mede van af of anderen hun werk goed doen, maar 2 certificaten met dezelfde fingerprint als je bank en die door je browser wordt vertrouwd, dát is meest onwaarschijnlijk.

Maar naast het "kraken" van het certificaat is een andere methode om dat te bereiken: het toevoegen van een
nieuwe vertrouwde certificaat autoriteit in de browser en het maken van een certificaat door die autoriteit voor
het gewenste domein. Omdat www.security.nl geen DANE record heeft zal een dergelijk certificaat van een
andere uitgever gewoon door de browser vertrouwd worden. Dit is een makke in het oorspronkelijke certificaat trust
systeem: iedere uitgever die jouw browser vertrouwt can certificaten uitgeven voor alle domeinen, er is geen koppeling
van domein naar uitgever dus als er ERGENS een rotte appel is (of een lokaal toegevoegde uitgever) dan zijn de
rapen gaar.

In mijn geval verzocht ik om https mijn belastingdienst.nl en kreeg géén beveiligde verbinding,het is een overheids site.
Er zijn in mijn optiek maar enkele die mijn bovenstaande situatie ,bezorging 4 huizen verder, wachtwoorden onbruikbaar enz,enz die kunnen interveniëren in een internet verbinding of medewerking verlenen aan.
vriendelijke groet,

Een browser vertrouwd geen certificaten. Een browser vertrouwd certificaatuitgevers.
Als het je lukt om bij een door browsers vertrouwde certificaatuitgever een certificaat te bestellen op naam van www.security.nl
kan men dit gebruiken voor een MITM aanval. Ik zei net (19:55 door Anoniem) dat dit zelfs bij een "superveilig" EV-certificaat al eens is gebeurd, gelukkig als test en niet door iemand met kwade bedoelingen.

Dan nog kun je je afvragen hoeveel nono's erin trappen als er een levensgrote waarschuwing komt met de tekst
"u wilt waarschijnlijk naar mijn.ing.nl en niet naar mijn lNG.nl" o.i.d.
Mensen kunnen in de war raken van domeinnamen die erg op elkaar lijken en per ongeluk doorgaan op de verkeerde url.

Let gewoon op de fingerprint van de URL, er is zelfs een bank die je adviseert dit te doen al kun je kritiek hebben op de manier waarop.

Ja duh. Als een aanvaller een rootvertificaat aan jouw browser kan toevoegen, waaron zou zij dan überhaupt nog de moeite nemen om MITM aanvallen op jouw verbindingen uit te voeren? Maar goed, het is een mogelijkheid - en dat schreef ik eerder ook al, in dezelfde bijdrage notabene:

Zucht. Dat was een vereenvoudigde samenvatting. Daarboven, in dezelfde bijdrage, schreef ik onder meer:
Klopt. En ook dat schreef ik al, zie de quote van mijn eigen tekst hierboven (ik hoop dat 2x herhalen genoeg is voor je).

Ja. En daarom schreef ik:
Overigens heeft dit niets met https te maken; het geldt net zo goed voor http - maar ook voor bijv. ftp, e-mail adressen en telefoonummers - 1 cijfer fout en je kunt zomaar iemand anders aan de lijn krijgen!

Ik heb geen idee wat de fingerprint van een URL is (iemand?) maar wellicht is het een goed idee als domeinnamen van redundante karakters worden voorzien (net als bij IBAN-nummers) zodat de browser je kan helpen om tikfouten, en dus typosquatting- te voorkomen.

Ja. En daarom schreef ik:
Hohoho, het gaat niet alleen over zelf geen tikfouten maken.
Een Man In The Middle kan een certificaat hebben waarin de domein "tikfout" met opzet is gemaakt.
De gebruiker krijgt dan wel een levensgrote waarschuwing in zijn scherm, maar hij kan nog steeds zo stom zijn om voor de verkeerde website te kiezen als de twee domeinnamen (de echte en de valse) erg op elkaar lijken.

Ja murw geworden van al die theorie waar ik in de praktijk geen last van krijg.
Zou leuk zijn: fingerprint van een url, bijv een simpele hash al was het maar MD5.
Dat gaat bijvoorbeeld mijn.ing.nl en mijn lNG.nl feilloos uit elkaar houden.

Maar een haas is geen konijn, en daarom: de vingers staan blijkbaar wel eens los van het brein en typen dan de verkeerde woorden. Zo ook daar. Had natuurlijk moeten zijn: fingerprint van certificaat. (niet van de URL)
Verder even in de context van daarnet 19:01 door Anoniem.
En daarbij heeft https://www.grc.com/fingerprint ook nog iets obscuurs te vertellen over wat er mis kan gaan.


Dan hebben we tegenwoordig ook nog DNS CAA, en dat is betrekkelijk nieuw vergeleken bij hsts.
Ik zou het wel leuk vinden als je daar iets over hebt uit te leggen als u wilt alstublieftdankuwel.
Doe wat mij betreft als je dit honoreert maar onder "DNS CAA voor slimmeriken" dan lees ik het eerder. ;)
(maar je hoeft het natuurlijk niet alleen voor mij te doen, ik denk dat er genoeg andere geïnteresseerden zijn)

Dan ben je wel heel dom...

Maar, wat ik niet wist (wellicht vergeten was), uit https://www.security.nl/posting/566101/NL%3A+veel+brakke+https+sites#posting566145:
Dat heb ik getest met Firefox (ESR) en inderdaad: de gebruiker kan de foutmelding niet wegklikken en toch naar de nepsite gaan! Voorwaarde is natuurlijk wel dat de HSTS header, niet te lang geleden, is ontvangen door de browser van de betreffende site - en van alle eventuele "springplanksites". Dus wel een handig bijkomend voordeel van HSTS!

Handmatig fingerprints van certificaten bijhouden lijkt mij ondoenlijk en niet realistisch. Daar zullen vast wel plug-ins voor bestaan, maar ook dan zit je met het probleem dat certificaten regelmatig verlopen. Wat doe je als je ontdekt dat een fingerprint niet meer klopt? En hoe weet je zeker dat het eerste certificaat dat je zag daadwerkelijk van de betreffende site is?

Het is knap lastig om je tegen "state actors" te beschermen, net zo goed als dat je met een goed slot op je voordeur, niet voorkomt dat iemand met een sjofel door jouw muur rijdt. Ik vertrouw mijn eigen PC's, smartphones e.d. zeker niet voor 100%, terwijl ik redelijk denk te weten wat ik doe. Als de overheid malware op jouw device(s) wil planten moet je van goede huize komen wil je dat opmerken. De gemiddelde computergebruiker (en vooral daaronder) is kansloos. Mijn doel is in elk geval gewone gebruikers helpen beschermen tegen ongerichte aanvallen (journalisten zoals Thomas Erdbrink in Teheran beschermen is echt een ander verhaal).

Daar weet ik nog nauwelijks wat van, maar wel dat het ook risico's met zich meebrengt. Stel je had net voor de Diginotar affaire aangeven uitsluitend certficaten van Diginotar te zullen gebruiken? Of, minder lang geleden, uitsluitend van Symantec/Verisign? Zorg dat je niet op slechts 1 paard wedt!

Dank voor jouw reacties overigens, soms reageer ik wat kort door de bocht maar stel het zeer op prijs om het vuur aan de schenen gelegd te krijgen en/of te worden aangevuld/gecorrigeerd. Zeer leerzaam allemaal!

Doe nou niet alsof "typosquatting mede in een certificaat" geen enkel probleem is.

Google Chrome:
Hoeveel zouden hier (in een sporadisch geval waarin men dit tegenkomt) toch doorgaan en het detailverschil niet opmerken?
"Nuh. mijn.Ing.nl is toch goed met een hoofdletter i?.... Is een bedrijfsnaam, zal best wel met een hoofdletter zijn."
(niet doorhebbende dat het hier niet gaat om een hoofdletter i (I) maar om een kleine letter L (l) die er precies hetzelfde uitziet...) En voor Firefox hebben we volgens mij default nog steeds het punycode probleem:
https://www.security.nl/posting/511152/Browsers+kwetsbaar+voor+phishingaanval+via+unicode-domein
Tenzij je zelf even in about:config network.IDN_show_punycode op true zet.

Jou eerdere reactie toen iemand dit hier ook aandroeg:
;)

Nee, niet van elke site maar wel van de gevoeligste sites waarin je financiële transacties en belangrijke login informatie of privee informatie verstrekt, zoals je bank, Digid e.d.
Ik het er een klein scriptje voor geschreven om automatisch een fingerprint veld op te laten komen dat mij eraan herinnert dat ik even copy-paste van de certificaat fingerprint moet doen en dan opslaan en afsluiten. Vervolgens laat ik ze vergelijken met wat ik vast in een bestand heb gezet en wordt een vergelijking gemaakt of het daar gelijk aan is of niet.
Hij hoort hetzelfde te zijn, behalve meestal één keer per jaar wanneer de site een nieuw certificaat krijgt.
Dan verifieer je even of dat goed zou kunnen kloppen, en vervolgens wijzig je de oude fingerprint met de nieuwe in het vaste bestand, en kun je weer een jaar vooruit.

Gaat het over die dingen? 'k Zal het nog wel eens ergens vernemen.

Ik heb de hele thread nog eens nagelezen en zag dat ik de volgende bijdrage eerder gemist heb (waarschijnlijk doordat deze door de moderator is vrijgegeven en dus verschenen na mijn bijdrage van 10-06-2018, 07:43). Mogelijk is deze van de anoniem die ervan overtuigd lijkt dat MITM aanvallen bij https een eitje zijn, wat echt niet zo is. Dus alsnog een reactie.

Zo werkt het echt niet. Alleen als:
- jij mij een certificaat stuurt dat is ondertekend door een certificaatuitgever die door mijn webbrowser (en dus door mij) wordt vertrouwd,
- en als de domeinnaam in de URL-balk van mijn browser overeenkomt met 1 van de domeinnamen in het certificaat,
- en als jij aantoont te beschikken over de private key behorende bij de public key in het certificaat,
- en er aan nog een heel stel voorwaarden wordt voldaan die niet relevant zijn in deze discussie:
zal mijn browser geen browservenstervullende certificaatfoutmelding tonen (die ik echt niet zou negeren).

En als ik wel een certificaatfoutmelding krijg, terwijl mijn browser HSTS informatie van de betreffende site in haar HSTS database heeft, kan ik die waarschuwing niet eens negeren; in dat geval kan ik dus geen https verbinding maken met jouw PC die zich voordoet als mijn bank.

Om mijn browser te kunnen foppen zul je dus moeten zirgen dat ik geen certificaatfoutmelding te zien krijg. En dat kan alleen indien jij:
1) ofwel de private key van mijn bank weet te stelen (hopelijk kansloos),
2) ofwel de private key van mijn bank weet te berekenen uit de public key in het certificaat (succes ermee),
3) ofwel een certificaatuitgever zo gek krijgt dat deze een certificaat-aanvraag door jou voor mijn bank honoreert (niet kansloos met een Let's Encrypt certificaat - mits je bij de DNS registrar van mijn bank het IP-adres van de webserver van mijn bank weet te wijzigen in dat van jouw PC, of middels een BGP hijack IP netwerkverkeer bestemd voor mijn bank tijdelijk naar jouw PC weet te routeren. Niet kansloos dus, maar ook geen peuleschil),
4) ofwel mij een phishing mail stuurt die eruit ziet alsof deze van mijn bank komt, bijvoorbeeld met het dringende verzoek om onmiddelijk mijn saldo te checken op http://rabobank.nl/. Zodra ik namelijk op laatstgenoemde link klik, kan jouw PC mij elke gewenste site laten zien, desgewenst met slotje.

Maarre... ik zit niet bij de Rabobank maar bij Triodos; de link http://triodos.nl/ zou mijn browser door https://triodos.nl/ vervangen nog voordat er ook maar een bit over het netwerk gaat (Triodos heeft HSTS wel goed geconfigureerd - in tegenstelling tot de Rabobank; zie https://www.security.nl/posting/566101/NL%3A+veel+brakke+https+sites).

En, als ik al op links in e-mails klik, check ik eerst zorvuldig waar die naartoe gaan. Sterker, van e-mails met links erin bekijk ik de headers om vast te stellen vanaf welk IP adres ze zijn verzonden, en met whois check ik van wie dat IP-adres is. Kortom, forget it.

Terug naar punt 3: hier heb je, vernoed ik, de grootste kans van slagen om https://www.triodos.nl/ met slotje in mijn browser te krijgen. Maar helaas: ik weet dat Triodos een EV certificaat hoort te hebben. Hoewel je hier wellicht velen mee kunt foppen, hou je mij er niet mee voor de mal. Tenzij je een EV-certificaat voor Triodos weet te bemachtigen. Maar de kans dat iemand dat lukt, die ook een MITM aanval kan uitvoeren, schat ik in als verwaarloosbaar klein. Ik ga dan ook echt geen certificaten bekijken of fingerprints (cryptografische hashes over het certificaat, meestal de ASN.1 variant).

Conclusie: jouw aanval gaat niet slagen. Zelfs niet (relatief eenvoudig) als jij (i.p.v. mijn gebruikelijke DNS servers) DNS requests van mijn PC met valse replies weet te beantwoorden. Maar ook niet (een stuk lastiger) met jouw PC fysiek tussen mijn PC en mijn router - waarbij je, naast vervalste DNS antwoorden, ook al het andere netwerkverkeer kunt afvangen en/of wijzigen - maar (gelukkig) niet onopgemerkt elke gewenste https verbinding kunt openbreken.

Als je me niet gelooft, voer dan het experiment uit dat ik hierboven (https://www.security.nl/posting/564452/https+voor+leken#posting564942) beschreef. En/of google naar bijv. https mitm howto en lees die artikelen aandachtig. Ik beloof niet dat ze allemaal kloppen (want er lopen meer "overtuigden" rond zoals jij), maar als je jouw verstand gebruikt moet je hieruit kunnen opmaken dat het klopt wat ik schrijf (tenzij je zit te trollen natuurlijk, maar dat geloof ik niet).

Testosteron enzo
jongens, jongens
Dit gaat toch niet meer over de inhoud maar over ingedrukte tenen en koste wat het kost gelijk willen hebben.
Uitzonderlijk antwoord met een uitzonderlijk argument over uitzonderlijk gedrag.
Te uniek in vergelijking tot dagelijkse praktijk om relevant te zijn en daarmee ook in ontkennende/ontkrachtende zin.

Daarbij komt nog, it-ers maken ook fouten en it-ers zijn absoluut ook ontvankelijk voor phishing, ook aangetoond, zoek er maar op.
Dus,
IT-phishing mop: twee t!3ten in een digitale envelop (bingo!) #
Maar als ze (of hij) met die mooie stem aan de lijn hangt doen die it-ers ook alles voor haar en vergeten ze heel even die andere best practices.
Dat is nou eenmaal de aard van het herenbeestje (kijk maar hoeveel reacties een forumpost krijgt bij een meisjesnaampseudoniem en hoe de mannetjes hun toontje wijzigen), natuur gaat voor ook bij jou.

# Nature calling en jij kijkt echt niet naar het slotje als er wat anders leuks voorbij komt, aanpak breed bekend.
https://www.theguardian.com/uk-news/2018/mar/19/cambridge-analytica-execs-boast-dirty-tricks-honey-traps-elections
https://medium.com/@w1nnersclub/cambridge-analytica-admits-ukranian-prostitutes-it-uses-could-be-from-elsewhere-e1a72836c096
Nog meer succesvolle phishing met behulp van moeder en natuur
https://www.youtube.com/watch?v=lc7scxvKQOo
Nope, zelfvertrouwen is geen goede garantie dat het niet kan gebeuren.

Overigens, supporten wel alle soorten browsers hsts?
Banken supporten in ieder geval niet alle soorten browsers, en als het werkt is het niet gezegd dat het ook werkt (abnamro schijnt soms nog java versie 6 voor functionaliteit te vereisen, tel uit je security winst).

Inderdaad. Iemand zegt dat hij mijn verbinding met mijn bank kan MITM-en, en ik weerleg dat.
Dus, where the fuck bemoei jij je mee, betweter?

Zie: https://caniuse.com/#feat=stricttransportsecurity

Juist! Juist!
Nu beginnen we elkaar te begrijpen. Voor een MITM is dat een peuleschil hoor. Maar om een MITM te kunnen wórden hangt er nog wel vanaf welke gewoonten jij er op na houdt, zoals bijv. ga je wel eens bankieren via een openaar wifipunt en is er dan toevallig een dergelijke kaper in de buurt die je verbinding kaapt zonder dat jij het merkt, en ook hotels in het buitenland houden er niet de beste internet-security gewoonten op na.

Jij zei eerst wat anders he. Eerst antwoorde je:
En toen zei ik nog eens:
en je antwoord:
Snap je dat ik daar kriegel van werd? Snap je dat ik dan nog eens een verhaaltje ga vertellen over Bitwiper aanvallen met een MITM proef? Want je zei maar niet dat je goed zou opletten of het certificaat klopte.

Dus mooi dat je dat nu eindelijk door hebt, en heel gezond dat je daar dan toch op je certificaat let of het wel EV is,
hoewel dat ook al eens is misgegaan toen een onbevoegde een EV-certificaat kon krijgen voor een bestaande bank o.i.d.

Wat je volgens mij eventueel nog meer zou kunnen doen is de Let's Encrypt en voor mijn part Comodo-certificaatuitgevers uit je browser trust list mieteren mocht je in risicovolle omgevingen banktransacties of andere provacygevoelige dingen doen. Dan wordt het een stuk lastiger voor een MITM. Hij kan normaalgesproken dan alleen nog look-alike certificaten proberen waarmee jij een joekel van een waarschuwing in je beeld krijgt. Jij trapt daar dan vast niet in, maar laten we niet proberen voor alle andere mensen te spreken, aangezien Owasp liet weten:
En helaas we hoeven maar om ons heen te zien en de geschiedenis na te gaan:
onbegrip over een dreiging die op til is, heeft mensen vaak genoeg tot verkeerde keuzes gebracht, zoals negeren.

(verder niks met testosteron te maken, in ieder geval niet bij mij, maar met de waarheid boven tafel willen brengen)

Ik heb toch echt in nagenoeg elke bijdrage aangegeven dat de voorwaarde is dat je alle certificaatuitgevers in jouw browser (en/of besturingssysteem) vertrouwt. Waarmee ik bedoel dat ze niet onterecht certificaten uitgeven (certificate signing requests van o.a. een uniek serienummer en een digitale handtekening te voorzien waarmee het een geldig https server certificaat wordt):

En hoewel ik DV certificaten (waaronder die van Let's Encrypt) vaak genoeg -in elk geval in eerdere threads- speelgoedcertificaten heb genoemd, is een DV certificaat verkrijgen voor een bestaande domeinnaam (van een ander) helemaal geen peuleschil zoals jij stelt. Toon jij maar eens aan dat je een geldig certificaat voor mijn bank, triodos.nl, - met bijbehorende private key natuurlijk - in handen kunt krijgen! Als jou dat lukt zal ik schrijven dat jij gelijk had en ik niet, en als je een EV certificaat plus private key voor triodos.nl in handen kunt krijgen, krijg je een hele mooie fles wijn van mij en publiekelijke excuses.

Ik stel het op prijs als je begint met vertellen hoe je dit aan denkt te gaan pakken, maar je kunt me natuurlijk ook verassen met een geldig certificaat (onderaan een certificate chain leidend tot een rootcertificaat dat in de meeste browsers zit), natuurlijk met de bijbehorende private key.

Nb. het is inderdaad relatief een peuleschil om een certificaat in handen te krijgen voor een domeinnaam die lijkt op triodos.nl, zoals bijvoorbeeld triodos.ni, trlodos.nl, triiodos.nl, tniodos.nl, tri.odos.nl, tripdos.nl, triobos.nl, triodos.nl.co, triodosbank.nl, secure_triodos.nl, triodosssl.nl etc. - maar daar hebben we het hier niet over! Immers op het moment dat jouw PC tussen mijn PC en mijn router in zit, en ik op de bookmark in mijn browser wijzend naar https://triodos.nl/ klik, zul jij toch echt met een geldig certificaat voor triodos.nl op de proppen moeten komen. Want certificaatwaarschuwingen negeer ik niet. En al zou ik dat willen, dat kan ik niet door HSTS info voor Triodos.nl in de HSTS database in mijn browser.

Succes!

Ik herhaal: niet kansloos met let's encrypt certificaat zei jij zelf Botwiper.

Dan DNS: het gaat over een MITM! Die speelt zijn eigen DNS wel hoor. En ook welk ip adres zijn nepserver heeft,
bijv. hetzelfde ip-adres als van Triodos bank? En je komt niet meer bij, maar die nepserver adverteert dus geen DNS
want is niet verbonden met het DNS systeem! Hehe, is dat lachen.

En ja HSTS maakt deze aanval een stuk doorzichtiger, maar we hadden het in de eerste plaats over https
en daar ging het op dat moment over.
Verder staat Triodos.nl niet in de HSTS preload lijst, dus bij situaties dat het Triodos- domein nog onbekend is voor je browser m.b.t. HSTS ben je kwetsbaar voor MITM.

Als ik je één tip mag geven t.a.v. security is het dit: wees niet hoogmoedig. maar blijf alert.
Je weet namelijk nooit hoe een koe een haas vangt.

Een MITM aanvaller hoeft zich niet direct tussen de PC van het slachtoffer en de echte server(s) te bevinden. Dat kan wel, bijv. door op het terras voor een kroeg o.i.d. een WiFi accesspoint op te tuigen dat zich voordoet als het echte accesspoint van die kroeg (of andere accesspoints waar de devices van anderen op dat terras naar zoeken).

Maar, tenzij je iemand volgt, en die persoon toevallig op zo'n terras gaat zitten en van de onbeveiligde WiFi gebruik maakt, zijn gerichte aanvallen nauwelijks tot niet uitvoerbaar.

Gezien het grote aantal kwetsbaarheden in SOHO (Small Office Home Office, MKB en thuisgebruikers) modem/routers, en het kleine aantal mensen dat dergelijke apparaten patcht (als er al updates voor verschijnen), is wellicht het grootste MITM risico op Internet het type aanval waarbij jouw PC of draagbaar device gedwongen wordt gebruik te maken van een of meer kwaadaardige DNS servers.

Als je mijn Fritz!Box zou kunnen hacken (wat ik niet uitsluit) en de daarop ingestelde DNS servers zou kunnen wijzigen, zou je mijn PC een IP-adres van een server in jouw bezit kunnen teruggeven op het moment dat ik met mijn browser naar https://www.triodos.nl/ ga. Daarbij boeit het niet of die server van jou in Brazilië, Texas, Rusland of Nederland staat: op het moment dat jouw nepserver een deel van het verkeer van mijn PC met de echte servers van Triodos uitwisselt, is ook sprake van een MITM aanval. Bijkomend voordeel voor criminelen: zij hoeven niet fysiek in de buurt van hun slachtoffers te zitten!

Echter, een MITM aanval tussen een server en een thuisgebruiker (fysieke aanval of anders) gaat jou niet helpen om een DV-certificaat (met bijpassende private key in jouw bezit) in handen te krijgen.

Inderdaad niet kansloos, maar niet eenvoudig. Waarom probeer je het niet, zoals ik in mijn vorige bijdrage voorstelde? Ik ben benieuwd!

Ten eerste hoeft het niet gericht te zijn. Het kan ook best toeval zijn.
Ten tweede maakt men vaak gebruik van een speciale hardware zoals deze:
https://www.wifipineapple.com/

Eerder ook al een aantal keren hier in het nieuws geweest,
https://www.security.nl/posting/40814/WiFi-netwerken+afluisteren+met+een+ananas
https://www.security.nl/posting/40906/Netwerken+hacken+met+zelfgemaakte+WiFi-ananas
https://www.security.nl/posting/449399/Nieuwe+Pineapple+voor+wifi-hacking+aangekondigd

Ook de "Pi" kan er wat van:
https://www.security.nl/posting/41568/Raspberry+Pi+omgetoverd+tot+krachtige+WiFi-hacker

Kijk, als alles normaal verloopt zoals het hoort gaat het niet fout. Maar daar kan je niet 100% op vertrouwen.
Er komen ook situaties voor waar het stiekem niet gaat zoals het hoort, en dan zou het mis kunnen gaan.
Dat bedoel ik als ik zeg: je weet nooit hoe een koe een haas vangt.
Ook als je een keer moe bent en niet goed oplet kan het fout gaan.

Daarom geef ik de voorkeur aan robuuste controles als semi-automatische certificaat fingerprint-controle bij enkele belangrijke sites.
Daarnaast voorkomt een uitwendig netwerkfilter dat niet zomaar overal verbinding mee zou kunnen worden gemaakt.
Er zijn bij mij minstens 2 lagen van security, en dat is volgens mij hoe het hoort: niet op één systeem vertrouwen.
In feite vertrouw je met https en hsts nogal op je browser. In mijn ogen maar 1 level van security.
Wel een redelijk sterk level, maar nog steeds hebben ze bij elke nieuwe versie van de browser weer nieuwe kwetsbaarheden gevonden die af en toe nog steeds vuurrood zijn.