'Gebruik tweetrapsauthenticatie en vpn bij publieke wifi-hotspots'

Volgens F-Secure-productmanager Janne Pirttilahti is wifi nog steeds onveilig. Kwaadwillenden kunnen een rogue access point eenvoudig op een bestaande wifi-hotspot laten lijken om verkeer van gebruikers te onderscheppen. Een vpn zou in de meeste gevallen voldoende bescherming bieden.

Dit liet Janne Pirttilahti aan Tweakers weten in een interview op de Wi-Fi NOW-conferentie, die dinsdag van start is gegaan in Amsterdam. Een vpn zou voldoende bescherming bieden aangezien er een beveiligde verbinding tot stand wordt gebracht die gebruikmaakt van encryptie. Daardoor is het voor een kwaadwillende vele malen moeilijker om verkeer af te luisteren. Hoe eenvoudig het is om onversleuteld verkeer te onderscheppen demonstreerde Pirttilahti in een live hacking session.

Hierbij zette hij een rogue access point op die zich voordeed als een bestaande publieke hotspot. Hiervoor is alleen een laptop en een wifi-dongle nodig, 'hoe goedkoper hoe beter'. Vervolgens stuurde hij een signaal naar de publieke hotspot om de verbindingen van alle huidige gebruikers te verbreken. Omdat hij de kracht van zijn eigen access point hoger had ingesteld dan die van de publieke hotspot, kozen de apparaten van de meeste gebruikers de sterkere hotspot om automatisch opnieuw verbinding te maken. Nadat de gebruikers eenmaal verbonden waren kon Pirttilahti inzicht krijgen in het internetverkeer. Dit demonstreerde hij door op een tablet naar afbeeldingen te zoeken die op zijn laptop stuk voor stuk werden onderschept. Hetzelfde zou mogelijk zijn met ander verkeer, waaronder in sommige gevallen wachtwoorden en gebruikersnamen.

Het probleem van een vpn hangt volgens Pirttilahti samen met het feit dat het voor de gemiddelde gebruiker vaak te ingewikkeld is om deze in te stellen. Het zou volgens hem eigenlijk met een druk op een knop mogelijk moeten zijn. Een ander probleem is dat de gebruiker de aanbieder van een vpn dient te vertrouwen. Al het internetverkeer wordt immers via de servers van de vpn-aanbieder omgeleid. Veel aanbieders claimen dat zij geen logboeken bijhouden van dit verkeer. Het is voor de gebruiker echter onmogelijk een dergelijke claim te verifiëren. Ook hier moet weer van vertrouwen worden uitgegaan. Er zijn in Nederland isp's die gratis een vpn aanbieden bij het gebruik van hotspots, bijvoorbeeld KPN.

Op de vraag hoe gebruikers zich het beste kunnen beschermen antwoordde Pirttilahti dat voor een thuisnetwerk wpa2 met een lang wachtwoord zonder bestaande woorden nog steeds voldoende is. Voor dagelijks wifi-gebruik stelt hij dat een vpn en waar mogelijk tweetrapsauthenticatie voor de gemiddelde gebruiker voldoende bescherming biedt. "Gezond verstand helpt je ook een heel eind op weg", voegde hij daaraan nog toe.

Reacties (111)

[Verwijderd]

Ik mag toch hopen dat iedereen inmiddels wel weet dat als je met een "publiek" accespoint verbind je verbinding afgeluisterd kan worden en extra gevoelig bent voor "man in the middle" attacks.

Vaak is dat helemaal niet zo'n probleem: Facebook, whatsapp, en zeker bank applicaties hebben daar een ssl encryptie laag overheen. Je browser gaat vanzelf "piepen" als je niet daadwerkelijk met facebook, whatsapp of de bank verbind.

[magnifor]

http://www.thoughtcrime.org/software/sslstrip/

Ik zou daar niet zo zeker van zijn. Lees ook dit artikel maar door:

https://decorrespondent.n...netwerk/25988820-b2a600e1

Facebook wachtwoorden en dergelijken waren eenvoudig te onderscheppen.

[The Zep Man]

Facebook wachtwoorden en dergelijken waren eenvoudig te onderscheppen.

Een aanval van zes (!) jaar oud. In de tussentijd is HSTS (zie mijn eerdere reactie) gemeengoed geworden, en wordt dat inmiddels door Facebook geïmplementeerd. Praktisch alle browsers ondersteunen HSTS. Ook staat Facebook in de meegeleverde lijst van Chrome, die ook gebruikt wordt door IE, Firefox, etc..

Ik schrijf Facebook, maar veel andere sites (en het worden er steeds meer) hebben het geïmplementeerd. Met Google's motivatie om toch maar TLS aan te gaan bieden in plaats van een onbeveiligde site om zo hoger in hun zoekresultaten te komen, in combinatie met dat het steeds toegankelijker wordt om TLS te implementeren (zie Let's Encrypt) lost dit probleem zich vanzelf op.

Wat natuurlijk wel toegepast kan worden via een onbeveiligd access point zonder VPN naar een veilig 'thuis' is dat de gebruiker gephished kan worden. Passief logingegevens stelen wordt echter steeds lastiger.

[Reactie gewijzigd door The Zep Man op 25 juli 2024 02:36]

[vali]

Zoals ik al eerder melde moet je niet blind van uitgaan dat iedere website het toepast. Hier heb je een website waar je het kan testen en met een snelle test passen de volgende websites het niet toe:

Icloud.com
Digid.nl (wat een verrassing)
outlook.com
facebook.com (half)
gmail.com

ect.ect.

HSTS is al tijd geleden aangekondigd, maar zolang websites het maar heel langzaam implementeren moeten de normale gebruikers op een andere manier worden geïnformeerd of ze veilig zijn of niet.

[Reactie gewijzigd door vali op 25 juli 2024 02:36]

[magnifor]

Aanvallen zoals beschreven in het artikel van De Correspondent waren in 2014 nog uit te voeren met het zes jaar oude SSLstrip . Ook Facebook was toen kwetsbaar.

Overigens is HSTS ook niet waterdicht: https://www.blackhat.com/...Transport-Security-wp.pdf

VIII. CONCLUSION
We have reviewed how the major desktop operating systems
work regarding its time synchronization and we have
found that, on certain systems and under certain circumstances,
an NTP MitM attack is possible and it could be used in order
to force HSTS policies to expire. We have developed a NTP
MitM tool, called Delorean, that could be used to perform the
proposed attacks.

[vali]

Dat had ik ook gelezen inderdaad. Ze verzinnen altijd wel een manier om het te omzeilen.

[Douweegbertje]

Kijk, en dit is juist nu zo leuk. Je doet net alsof het de normaalste zaak van de wereld is dat mensen dit weten, terwijl juist ook een https verbinding helemaal niet veilig hoeft te zijn. Dit kan net zo goed (en makkelijk) te omzeilen zijn als een normale http verbinding. Vooral als je op een public hotspot zit.

Hell, je hoeft niet eens perse te verbinden met je bank, ik kan je gewoon een pagina serveren die er 1 op 1 op lijkt en jij ziet het verschil niet.

Dus ja, het is maar net hoeveel kennis iemand over het onderwerp heeft en blijkbaar ben je 'iets' beter dan de gemiddelde gebruiker maar alsnog zou je in een hack kunnen trappen. Uiteindelijk moet je gewoon verwachten dat de gemiddelde gebruiker geen kennis heeft en moeten "wij" techies eens met oplossingen komen die voor de gebruiker, gebruiksvriendelijk en veilig is.

[The Zep Man]

Kijk, en dit is juist nu zo leuk. Je doet net alsof het de normaalste zaak van de wereld is dat mensen dit weten, terwijl juist ook een https verbinding helemaal niet veilig hoeft te zijn. Dit kan net zo goed (en makkelijk) te omzeilen zijn als een normale http verbinding. Vooral als je op een public hotspot zit.

Lees eens iets over HTTP Strict Transport Security. Je browser accepteert geen onbeveiligde verbinding wanneer het weet dat het voor een specifieke site geen onbeveiligde verbindingen geaccepteerd mogen worden. Dit wordt uit twee bronnen gehaald:

1. Een lijst in de browser, beheerd door de ontwikkelaars.
2. Een HTTP header bij het eerste bezoek van de site.

Een beveiligde verbinding als onveilige verbinding aanbieden is dus mogelijk (1) wanneer de site niet in de lijst van de browser staat en (2) als de gebruiker de site over een onbeveiligde verbinding voor het eerst bezoekt. In elke andere situatie zal de browser simpelweg weigeren om een verbinding te maken.

Met andere woorden: een klassieke 'sslstrip' aanval is onwaarschijnlijk, mits de betreffende site maar HSTS geïmplementeerd heeft.

[Reactie gewijzigd door The Zep Man op 25 juli 2024 02:36]

[DaaNMageDDoN]

En (3) de gebruiker niet opmerkt dat er geen groene balk bovenin verschijnt. (Toch?) En dat terwijl die voor de eerste keer wil inloggen bij die dienst waarvan wordt verwacht dat het zijn zaakjes goed in orde zou hebben.
Dat is niet iets wat veel mensen in de gaten houden, maar ik denk wel steeds meer. In deze context misschien ook wel een beetje van hetzelfde, maar dan op een andere laag (unencrypted wifi/vpn VS http/https).
Misschien mogen we ook van browsers verwachten dat er gewaarschuwd wordt indien er ingelogd gaat worden over een onbeveiligde verbinding. Ik meen dat IE waarschuwd(e) wanneer er mixed content in beeld staat, maar hoe zit dat tegenwoordig met onze browsers?

[Thc_Nbl]

en (4)
Als mensen wel een ssl certificaat hebben, maar de server belabert configureren, heb je nog steeds niets aan je certificaat.

Daarom raad ik ook een ieder aan om even via www.ssllabs.com hun ssl website te testen.
Wat ik tegen kom ik... echt om te huilen, zo slecht...

[The Zep Man]

En (3) de gebruiker niet opmerkt dat er geen groene balk bovenin verschijnt.

Die groene balk (Extended Validation) bewijst alleen dat de betreffende partij meer geld heeft neergelegd voor het certificaat. Het heeft geen toegevoegde waarde. Gebruikers letten er niet op.

Misschien mogen we ook van browsers verwachten dat er gewaarschuwd wordt indien er ingelogd gaat worden over een onbeveiligde verbinding. Ik meen dat IE waarschuwd(e) wanneer er mixed content in beeld staat, maar hoe zit dat tegenwoordig met onze browsers?

Misschien mogen we gewoon eens verwachten dat het niet aan de gebruiker is om te controleren of diens verbinding beveiligd is? Het is 2015, en er zijn zat (gratis of betaalbare) manieren om website van SSL/TLS te voorzien.

[cobis taba]

Het is gewoon niet waar dat een EV certifcaat geen enkele toegevoegde waarde heeft. Uit jouw eigen bron:

"EV certificates are validated against both the Baseline Requirements and the Extended Validation requirements, which place additional requirements on how authorities vet companies. These include manual checks of all the domain names requested by the applicant, checks against official government sources, checks against independent information sources, and phone calls to the company to confirm the position of the applicant. If the certificate is accepted, the government-registered serial number of the business and well as the physical address are stored in the EV certificate."

Of je dat voldoende vind en of je dat (veel) beter vind kun je zeker bediscussiëren, maar dat het geen enkele toegevoegde waarde zou hebben is natuurlijk niet waar.

[vali]

Lees eens iets over HTTP Strict Transport Security. Je browser accepteert geen onbeveiligde verbinding wanneer het weet dat het voor een specifieke site geen onbeveiligde verbindingen geaccepteerd mogen worden. Dit wordt uit twee bronnen gehaald:

Was laatste nog onderzocht dat bijna geen enkele belangrijke websites zoals banken dit totaal niet toepassen. Het heeft dus geen zin om op zo'n techniek te vertrouwen. Kan het artikel ff niet meer vinden.

[The Zep Man]

[...]

Was laatste nog onderzocht dat bijna geen enkele belangrijke websites zoals banken dit totaal niet toepassen.

Bron?

Je kan het prima zelf onderzoeken in plaats van klakkeloos maar iets te roepen. Bijvoorbeeld ABN-AMRO, ING en Rabobank hebben HSTS geïmplementeerd. PayPal, Google en Facebook implementeren het, om nog een paar niet onbelangrijke sites te noemen.

Dit kan je prima zelf testen met iets als Live HTTP Headers. En al ben je te lui/verwend om zelf onderzoek uit te voeren, kan je ook op deze niet uitputtende lijst kijken welke sites allemaal HSTS ondersteuning aanbieden.

[Reactie gewijzigd door The Zep Man op 25 juli 2024 02:36]

[vali]

Zoals ik melde kan ik de bron niet meer vinden. Wel staat hier een en ander beschreven en dat kwam ook uit de tijd dat vele website dies jij opnoemde geen HSTS hadden geïmplementeerd. Ook is er niet zo gek lang geleden (ook rond 2014) een onderzoek gedaan hiernaar om dit bij de banken aan te kaarten.

Wil alleen duidelijk maken dat men niet alleen op zo'n techniek vertrouwen en helemaal niet met een addon die door een onbekende developer is geschreven. Je gezonde verstand gebruiken heb je veel meer aan. Iedereen kan bekijken of er https verkeer gaande is en daarbij van waar de certificaat vandaan komt. Daar heb ik geen addon voor nodig (die overigens ook half supported wordt)

[Reactie gewijzigd door vali op 25 juli 2024 02:36]

[WhatsappHack]

Iedereen kan bekijken of er https verkeer gaande is

Nou... Nou... Nee.
Meer dan de helft van de bevolking weet waarschijnlijk niet eens wat uberhaupt het verschil is tussen http en https. Als je het vraagt krijg je soms "Euh... Ja, die s!!! :)" als antwoord. Zelfs "beveiligde verbinding" staan mensen je soms aan te gapen met zo'n blik van "jamaar dat is toch altijd veilig?".

Vanuit een Tweaker perspectief, en zeker als je wat verstand van zaken hebt, is het allemaal rete simpel, stelt het geen hol voor en is het zo gebeurd om even wat controles uit te voeren; maar voor het merendeel van de (non-technische) mensen is het regelrechte voodoo, waar je als je er te lang over moet denken alleen maar hoofdpijn van krijgt en dus eigenlijk waarschijnlijk gewoon een uitvinding van Satan zelf is.

... Dan is een addon die goed te boek staat toch wel een pré.
Iets is beter dan niets.

[vali]

Een browser geeft weer of er https of http verkeer is. Ga mij niet vertellen dat een niet it-er weet of bij zijn bank een groene balk wordt weergegeven en/of een slotje naast de browser wordt weergegeven. Mochten ze dat niet weten dan moet de overheid hier (en dat doen ze al) meer over informeren.

Een addon is leuk, maar die blijft geschreven door een developer die je maar moet vertrouwen. De gene die The Zep Man als voorbeeld nam krijgt nou niet hele goede cijfers. Moet je daar dan maar op vertrouwen? Ik doe liever mijn gezonde verstand.

[Douweegbertje]

Ik hoef niets te lezen, ik snap wel het één en ander van netwerken en hacken

Stap eens af dat zoiets dom simpels als 'https' of 'ssl' of weet ik veel wat de garantie zou zijn dat je veilig bent. Ik reageer nu toevallig op jou, maar het is voor iedereen die reageerde om te vertellen dat het allemaal niet mogelijk is (inbreken bij iemand die over https gaat etc.):

Één van de zwakke punten hier is het open netwerk echter zijn er zoveel manieren om misbruik te maken van een systeem of service. Ik ga gewoon een rare vergelijking maken, maar in essentie is het hetzelfde alleen op een niet-technisch niveau:

Het condoom;
Dit is voor relatief veilige seks. Daar is iedereen het wel redelijk over eens.
Wat nu als je hem over je hoofd heen trekt in plaats van de daadwerkelijk bedoelde plaats? Het condoom is even veilig alleen je bent zelf niet veilig bezig. Dat is al één punt.
Wat nu als jij zegt tegen je partner dat je hem om hebt, terwijl dit niet zo is? Dat is al punt twee. Eventueel komt de andere partij er achter, maar dat is weer afhankelijk van een aantal factoren.
Nu zijn er gewoon nog heel wat variaties te maken, maar het is gewoon een -feit- dat https/ssl gewoon best veilig is, alleen het gebruik ervan biedt letterlijk 0 komma 0 garantie dat je ook daadwerkelijk beveiligd bent.

[Verwijderd]

"maar het is gewoon een -feit- dat https/ssl gewoon best veilig is, alleen het gebruik ervan biedt letterlijk 0 komma 0 garantie dat je ook daadwerkelijk beveiligd bent."

Eens, maar dat is thuis ook zo, bedraad of niet bedraad.

[djexplo]

De content via een HTTPS verbinding is helemaal niet zo eenvoudig te onderscheppen. Dit is alleen mogelijk als met een fake SSL-certicate. Maar zo'n fake SSL-certifcaat word door je browser geblokkeerd zolang deze alleen "veilige Certificate Authorities" accepteerd.

Bepaalde virus-scanner s zoals ESET kunnen SSL filteren, door zich zelf als veilige Certicate-authority in je browser toe tevoegen.

Maar als man-in-the-middle kan je natuurlijk wel een re-direct doen naar een eigen domein met bijna de zelfde naam b.v. https://[e-mail] , of stiekem switchen van HTTP naar HTTPS. Maar HTTP zal je bank b.v. niet accepteren, en een ander adres in de adres-balk kan de gebruiker ook opvallen.

[looc]

Er zijn andere practische manieren waarop je https kunt onderscheppen:
Persoon A vraagt voor internetbankieren https://example.com
Aanvaller maakt een beveiligde verbinding met https://example.com

De website wordt met http doorverstuurd naar Persoon A. Die krijgt geen certificaat melding omdat er simpelweg geen https wordt gebruikt.
Vult Persoon A zijn gegevens in, dan heeft de aanvaller jackpot

[Reactie gewijzigd door looc op 25 juli 2024 02:36]

[vali]

Ik heb dit met een klein project op school opgezet en kan je vertellen dat het niet werkt met de meeste banken. Zo werkt het bv niet bij ing.nl of abn-ambro. Overigens is het opzetten van een rogue accespoint is veel gemakkelijker dan in dit artikel wordt geschets.

Jam met een goedkope wifii stick alle wifi punten in je omgeving en zet vervolgens een nieuwe accespoint op (met exact dezelfde SSID en channel). Gebruikers loggen automatisch in op je website (om geloofwaardiger over te komen kun je het beste de website van een kpn of ns na bouwen). Zijn tools om een website redelijk goed te rippen en zolang het visueel bijna identiek is en het (fake) inlogscherm gewoon werkt, logt gros van de mensen toch wel in.

Websites waarvan https certificaat gestript kon worden zijn (tot hoeveer ik getest had)
Facebook.com
gmail.com
outlook.com
digid
ASN bank
icloud.com
sharepoint website (van mijn opleiding)

Schikbarend genoeg zag ik ook medestudenten van mijn opleiding inloggen op mijn rogue accespoint toen ik tijdelijk een test had uitgevoerd in de etensruimte (uiteraard logde ik inloggegevens niet of keek ik mee waar ze heen browsde)). Ook al was het enkele jaren geleden, vond het laatste toch wel het meest schrikbarende.

[Reactie gewijzigd door vali op 25 juli 2024 02:36]

[PolarBear]

Ook al was het enkele jaren geleden, vond het laatste toch wel het meest schrikbarende.

Het risico wordt met HTST, public key pinning en certificate pinning door tools als EMET of in de browsers in ieder geval beperkt. Maar dat vereist wel kennis en kunde aan beide kanten.

[vali]

Oww het is zeker op te lossen (de technieken bestaan al zeer lange tijd), maar dat wilt niet zeggen dat je bij de gewone gebruiker flink wat informatie kan achterhalen. Zeker maildiensten zoals kpnmail ect maken niet gebruik van two-way-authenticatie. Dit kan iemand weer voor andere doeleinde gebruiken.

[Reactie gewijzigd door vali op 25 juli 2024 02:36]

[cracking cloud]

Maar wat voor meerwaarde heeft 2-factor authentication nog als ik al jouw verkeer (incl cookies) kan zien? Dan kan ik toch nog steeds jouw sessie spoofen?

[vali]

Tools die vaak gebruikt worden en uitgebreid beschreven worden op het internet voor scriptkiddies werken vaak niet als 2-factor authentication aan staat.

[SPee]

Maar als de client ook de DNS server gebruikt die door de Access Point wordt opgegeven, dan wordt het wel een stuk makkelijker om het verkeer naar de "evil twin" te sturen ipv naar de echte server. Zonder dat de gebruiker het ook doorheeft (nl. echte namen).
Veelal wordt die DNS ook met DHCP meegestuurd.

[jaapzb]

en een ander adres in de adres-balk kan de gebruiker ook opvallen.

Kan, maar zal ook heel vaak niet zo zijn.

Er zijn genoeg mensen die niet eens weten hoe de adresbalk werkt, en gewoon op hun homepagina google zoeken naar "facebook.com" en daar vervolgens op het eerste resultaat klikken.

[kaaas]

Het is helemaal niet zo duur om een geldig ssl certificate aan te schaffen.

[zenlord]

Met gemiddelden ben je echter niets. Als er 1 kwaadwillende hacker is die absoluut 'slimmer' is dan alle gebruikers ter wereld, dan is iedereen kwetsbaar. Ga er dus maar van uit dat er wel altijd iemand slimmer zal zijn dan jij.

[Iblies]

Jij begint al over https, terwijl het gros niet eens weet hoe een url te beginnen en waar het eigenlijk voor staat.

Zo kan een url prima met FTP beginnen en op een intranet kunnen ook andere regels gelden.

Rijbewijs en bijscholen.

[xleeuwx]

Verder kan het zo zijn dat het kwaad al is geschiet als je op een pagina komt. Je kan namelijk makkelijk een pagina serveren die iets installeert op de pc van de client (bijvoorbeeld de pagina accepteer onze voorwaarden pagina).

Wanneer de pc van de client dan weer thuis is heb je bijvoorbeeld een keylogger of erger geïnstalleerd die alles netjes registreert wat jij doet, bijvoorbeeld:
- paypal login
- bank login (kan je het minst mee)
- Creditcard betalingen (altijd leuk)
- Facebook login (van sommige mensen kan het leuk zijn)

Misschien gebeurt er op de openbare wifi dus niet direct iets maar kan dus ook later veel ellende bezorgen.

[Reactie gewijzigd door xleeuwx op 25 juli 2024 02:36]

[Verwijderd]

"Je doet net alsof het de normaalste zaak van de wereld is dat mensen dit weten, terwijl juist ook een https verbinding helemaal niet veilig hoeft te zijn. Dit kan net zo goed (en makkelijk) te omzeilen zijn als een normale http verbinding. Vooral als je op een public hotspot zit. "

Wat maakt dat jij denkt dat het met een bekabelde verbinding of via de wifi van jou thuis niet kan gebeuren?
Het is natuurlijk onzin dat https het net zo makkelijk te omzeilen is als een normale http verbinding. Je device controleert namelijk de authenticiteit van de https server en piept als hij niet trusted is.
Natuurlijk kan je proberen de gebruiker voor de gek te houden door een fake pagina te serveren. Wordt al best moeilijk als mensen hun bank app gebruiken. (uiteraard is ook dat theoretisch mogelijk, maar dat is best veel moeite en duur om een willekeurig persoon te pakken)

[cracking cloud]

De blog van Troy Hunt is een hele goede bron van info als je geïnteresseerd bent in dit onderwerp.

[EvilItSelf]

Tenzij je als man in de middle het certificaat faked. Het is tenslotte een man in the middle aanval.

[Verwijderd]

maar je browser of bank app controleert het certificaat toch op authenticiteit? Dan moet je als man in de middle in het bezit zijn van een trusted certificaat en de laatste keer dat dat mis ging was bij de diginotar affaire waarna alle browser middels updates weer hersteld zijn.

[EvilItSelf]

Een trusted certificate moet geverifieerd worden, maar als alle verbindingen over een corrupt WiFi punt lopen kan alles nagebootst worden. De bank denkt dat hij sleutels uitgewisseld heeft met jou en jouw browser denkt dat er sleutels uitgewisseld zijn met de bank. Terwijl beide partijen contact hebben met de man in the middle. Ook jou certificaat verificatie gaat goed, omdat jouw computer denkt dat hij de geldigheid van het certificaat klopt. En dat alles terwijl de man in the middle alles kan lezen wat er langs komt.

[Verwijderd]

"maar als alle verbindingen over een corrupt WiFi punt lopen kan alles nagebootst worden"

Welnee, het certificaat wordt niet via het net gecontroleerd, hij wordt gecontroleerd tegen de lijst die je browser heeft. Als je dat wil faken moet je eerst een browser (of app) update forceren, maar neem aan dat ook die update de update server controleert.

Uiteraard zijn er allerhande vulnerabilities, maar de man in the middle is wel redelijk ondervangen.. zou mooi wezen: Ook thuis kan er natuurlijk zo een mitm attack gedaan worden bij je provider, in iran, china of rusland is dat gewoon de overheid.

Check diginotar nog eens.. daar zit de echte zwakheid. Als je een root certificaat hebt kun je vrolijk al het verkeer faken zonder dat de client het door heeft. Maar dat heeft niet zo veel met open wifi te maken, als je dat kunt, kun je ook bij de telcos mitm spelen.

[CAPSLOCK2000]

Vaak is dat helemaal niet zo'n probleem: Facebook, whatsapp, en zeker bank applicaties hebben daar een ssl encryptie laag overheen. Je browser gaat vanzelf "piepen" als je niet daadwerkelijk met facebook, whatsapp of de bank verbind.

Vervolgens klikt iedereen op "accept" en klaagt een beetje over de cookiewet (die er niks mee te maken heeft). Van de ene kant is het natuurlijk je eigen verantwoordelijkheid maar van de andere kant weten we dat de meeste mensen die verantwoordelijkheid niet nemen. De browsers hebben niet voor niets steeds dwingendere waarschuwingsschermen toegevoegd. Het helpt helaas maar weinig.

[WhatsappHack]

Die waarschuwingsschermen zijn ook weer een probleem an sich.
Ze kunnen soms problemen veroorzaken.

Een expired of self-signed certificaatje bijvoorbeeld, daar krijg je in sommige browsers een groot rood scherm met "BRENG ME TERUG NAAR DE VEILIGHEID!!1!", alsof er zojuist een atoombom is ontploft midden in je woonkamer; en die browser heeft dat eventjes voor je opgelost.

Het probleem is echter dat bij een aardig aantal (interne) websites, en dan heb ik het dus niet over de bank oid, dit nog best eens wil gebeuren. Het bizarre effect is dan dat je, en dit is slechts een voorbeeldje hoor , op "Login" klikt terwijl je op http zit. De browser stuurt je naar de http versie van een of ander script, en die redirect eenmalig naar SSL. Vervolgens blijkt het certificaat expired of self-signed te zijn... En stuurt die browser je terug naar de HTTP variant *zonder* enige encryptie; en vraagt je doodleuk om daar dan maar in te loggen.
Dat is gewoon leip.

Een self-signed certificaat en/of expired certifcaat, daar ontbreekt het aan de trust. Je kan niet verifieren bij een CA of de boel wel klopt. Maar de verbinding wordt alsnog wel degelijk encrypted, en zal dus in de meeste gevallen nog altijd een heel stuk veiliger zijn dan de HTTP versie van de page waar je gegevens submit.
Bij een bank moet je natuurlijk nooit het risico nemen, en de ***** met een bank die vergeet z'n certificaten te verlengen overigens, maar bij veel huis-, tuin- en keukensites is het in principe vaak prima te harden; zeker indien het om expired gaat ipv self-signed.

Waar ik dan ook op hoop is dat er snel wordt gesleuteld om het HTTP protocol zo rap mogelijk om te zetten dat deze _altijd_ TLS gebruikt, zonder uitzondering. Wat wij nu als normaal HTTP verkeer beschouwen, zou dan alsnog versleuteld verkeer zijn.

"Maar dan kunnen we niet controleren of we wel babbelen met wie we willen babbelen!".
Dat klopt, maar dat kan nu ook niet via reguliere unencrypted HTTP. Daar kan je het én niet controleren, én gaat het in plain-text over the internets heen. Maar daar zijn dan alsnog de SSL certificaten voor; die zijn niet opeens waardeloos ofzo, zelfs niet als al het verkeer automagisch al encrypt wordt. De "encryption is implemented on protocol level" oplossing vervangt de SSL certificaten niet, maar zorgt er wel voor dat er uberhaupt geen plain-text communicatie meer plaatsvindt over het HTTP protocol heen... En dat zou toch wel heel erg fijn zijn!
En de mensen die wel graag alsnog die trust willen hebben en zeker willen weten met wie ze babbelen (dat zijn dus gewoon nog steeds exact dezelfde mensen/bedrijven): die nemen gewoon alsnog een SSL certificaat voor het groene slotje/de groene balk.

Dat er anno 2015 nog steeds geen standaard encryptie in het protocol zit is eigenlijk gewoon godsgeklaagd. Ik weet dat er aan gewerkt werd/wordt, maar het duurt allemaal veel te lang naar mijn mening.

[Reactie gewijzigd door WhatsappHack op 25 juli 2024 02:36]

[CAPSLOCK2000]

HTTP2 doet dat en dat is klaar voor productie. Je kan het vandaag nog uitrollen. De rest van de wereld zal nog wel wat langer nodig hebben maar wie wil kan er mee beginnen en het voortouw nemen.

[VonFoX]

Dat weten wij tweakers ja. Mijn moeder weet dat niet.

[Dorank]

Zelfs de kennis van tweakers lijkt me aan de matige kant. Immers de demonstratie met een rogue accesspoint is volkomen overbodig indien het om een open(onbeveiligt) netwerk gaat. Waarom zou je de extra moeite nemen als je alleen maar wilt inzien? Voor het bekijken van opgevraagde URLs(images) of sessie cookies is dat al voldoende.

[Typhone]

Maar gaat moeder als het mis gaat schreeuwen tegen het systeem of tegen de (het gebrek aan) voorlichting van de gevaren? De meeste mensen beginnen meteen te roeptoeteren en zijn niet zelfkritisch. Mijn pa komt ook regelmatig aan met die Kassa/Vara tips waar je met gezond boerenverstand normaal nooit problemen mee zou hebben.

[Olaf van der Spek]

Ik mag toch hopen dat iedereen inmiddels wel weet

Ik had eigenlijk gehoopt dat vooral Tweakers eindelijk eens zouden begrijpen dat NIET iedereen dat weet. Sterker nog, dat bijna niemand (>99%) dat weet.

[Whatts]

Los van de vraag of SSL over een onbeveiligde WiFi wel of niet veilig is: ik zie inderdaad niets nieuws in dit artikel.
Dit was al jaren gekend (door tweakers en IT'ers), en wie het nog niet wist, zal dit artikel waarschijnlijk ook nooit onder ogen krijgen.

[Sir Guinhill]

Die SSL laag is weinig waard als de aanbieder van die "rogue acces point" ook met DNS een man in the middle aanval uitvoert.

[akooijman]

'Iedereen' heeft geen idee waar je het over hebt.
Ik vul een wachtwoord in, *dus* is het veilig. Dat is het veiligheidsbesef van 'iedereen' die niet op tweakers woont

[tERRiON]

Ik ben zelf geen ontwikkelaar maar het moet toch mogelijk zijn om een app te bouwen die als VPN-client én als firewall werkt?

Het idee waar ik zelf al een hele tijd mee loop lijkt me vrij simpel:
Zodra je de app start, worden alle uitgaande verbindingen geblokkeerd, m.u.v. het verkeer dat nodig is om een VPN-verbinding op te zetten. Wanneer de verbinding daadwerkelijk is opgezet, wordt al het verkeer over de VPN-verbinding gerouteerd.

In de praktijk betekent het dan dat je de app start voordat je verbindt met de publieke Wifi. Zodra daar de eentjes en nulletjes beginnen te lopen, wordt de VPN-verbinding opgezet en zodra die 'up' is, werken alle overige apps weer. En daarnaast lijkt het me heel goed mogelijk om een app te bouwen die dit automatisch afhandelt op het moment dat je probeert verbinding te maken met een onbeveiligde Wifi-verbinding.

Of gaat iemand me nu vertellen dat zoiets dergelijks al bestaat?

[Keypunchie]

Toch gewoon VPN-functionaliteit in bvb. iOS? https://support.apple.com/en-us/HT201550

De uitdaging is niet de client, maar juist de server. Wie vertrouw je vervolgens met al jouw data? VPN diensten online is altijd maar de vraag of je ze kunt vertrouwen. Bedrijfs-VPN's hebben vaak restricties die het voor je prive-doeleinden niet goed bruikbaar maken (daarnaast, het is aan te raden werk en prive gescheiden te houden)

Op dat onderwerp doorgaand: wat zijn eigenlijk betaalbare en redelijk gebruiksvriendelijke oplossingen om thuis zelf een VPN-server te draaien?

[GekkePrutser]

De VPN in iOS laat wel degelijk wat 'lekken' via de wifi voordat de VPN up is. En dat is best veel omdat alles gelijk gaat lopen checken zodra je verbinding maakt (email, push notificaties enz).

Een tijdje geleden waren er problemen met de always-on VPN die mijn werk gebruikt. Als ik dan WiFi aan/uit zette dan had ik heel even verbinding (net genoeg om een pagina te laden of mail op te halen) maar dan viel het weg. Bleek dat de VPN server zelf een probleem had, de verbinding werd wel opgezet maar hij routeerde het verkeer niet. Maar die eerste paar seconden had ik dus wel verbinding omdat hij gewoon via de wifi routeert terwijl je VPN nog niet up is. Dat is wel jammer.

Vroeger met Symbian Series 60 kon je per applicatie instellen over welke verbinding iets kon: Bijv. email altijd over 3G of over VPN, maar de browser over WiFi indien aanwezig. En dan probeerde hij het dus echt alleen via de gekozen verbindingen. Het is jammer dat dat soort functionaliteit op moderne smartphones ontbreekt.

[Reactie gewijzigd door GekkePrutser op 25 juli 2024 02:36]

[Armin]

De VPN in iOS laat wel degelijk wat 'lekken' via de wifi voordat de VPN up

Ondersteund iOS9 geen 'always on VPN'?

Ik weet dat Windows Phone het sinds 8.1 Update 2 ondersteund, en iOS was altijd juist iets verder qua VPN dan Microsoft. Dus het zou me negatief verbazen als dat inmiddels niet zo is.

Maar ik laat me graag informeren (want weet het oprecht niet).

UPDATE: Het zit in het OS sinds iOS8, maar moet handmatig aangezet worden via een "configuration profile" of via de "mobile device management server".

[Reactie gewijzigd door Armin op 25 juli 2024 02:36]

[GekkePrutser]

Klopt het zit er wel in, maar het 'lekt' dus wel verkeer in de momenten voor de VPN up is. Want echt always on is het niet, als je switched van IP bijvoorbeeld, bij het verbinden met een nieuw wifi netwerk dan moet hij het opnieuw opbouwen.

Het zat er trouwens al in een veel eerdere iOS versie in, op dezelfde manier.

[Armin]

bij het verbinden met een nieuw wifi netwerk dan moet hij het opnieuw opbouwen.

Het zat er trouwens al in een veel eerdere iOS versie in, op dezelfde manier..

Nee, jij verwart nu twee zaken. Bij klassieke 'always' en 'on-demand' VPN heb je lekken bij het aangaan (en dus ook wisselen) van een verbinding. Er is dan een kleine kans (hoe groot is afhankelijk van de snelheid van verbinding maken) dat een aantal paketjes over de gewone WiFi gaan ipv de VPN tunnel over die WiFi simpelweg omdat de VPN nog niet klaar is, wanneer die pakketjes al staan te trappellen het internet op te gaan ...

Echter 'always on' VPN (niet verwarren met de 'always route alles' voorkomt dat. iOS ondersteunt die modus sinds iOS8. The OS houd dan alle pakketjes tegen tijdens het maken van de verbinding zodat er geen lekken optreedt.

[GekkePrutser]

Aha, ja ik wist niet van die nieuwe modus. Bedankt!

Ik heb het even opgezocht en inderdaad mijn werk gebruikt de on-demand optie. Ik zie trouwens best veel lekken, op het moment dat ik met een WiFi verbind, knalt gelijk alles het internet op om email te checken, voordat de VPN draait. Gelukkig gebruik ik gesignde certificaten zelfs voor mijn prive email.

Even een ander vraagje: Hoe werkt dat dan met captive portals op publieke wifi? Die werken dan helemaal niet neem ik aan? Of heeft dat automatische schermpje dat naar boven komt tijdens het verbinden een uitzondering op de VPN?

[Armin]

Goede vraag.

Er zijn een aantal trucs trucs. Enderzijds is er een whitelist van bekende SSID's die captive portals zijn. Men laat dan de browser toe.

Verder kunnen apps die whitelist aanpassen. Denk aan de HotSpot app van jouw provider.

Tenslotte is er een generieke truc die die de meeste portals/OS-en gebruiken, het niet blokkeren van een aantal speciale requests. Apple bijvoorbeeld probeert adres [http://www.apple.com/library/test/success.html] te benaderen. Als dat niet lukt neemt men aan dat het een Captive Network Portal is. Ik geloof dat men ook een speciale user-agent gebruikt zodat de request herkenbaar is. Microsoft heeft ook iets soortgelijks.

Echter dat is evident inderdaad niet 100% fool-proof. Zeker ook omdat sommige WiFi portals dan weer proberen hier omheen te werken (met soms goede bedoelingen).

[ThinkPad]

Met OpenVPN for Android kan ik wel het verkeer laten pauzeren als de VPN wegvalt. Maar zodra het toestel (voorafgaand aan opstarten VPN-verbinding) verbinding maakt met een netwerk, dan zal hij gelijk verkeer laten stromen.

Misschien dat ik eerst de VPN kan starten en daarna pas verbinding maken met het netwerk, moet ik eens proberen.

Via Tasker laat ik OpenVPN automatisch een verbinding maken als er verbinding met een bepaald WiFi-netwerk wordt gemaakt (andersom kan ook: VPN bij alle netwerken, behalve netwerk XYZ). Overigens kun je het lekken van je VPN-tunnel goed testen met www.dnsleaktest.com

[Reactie gewijzigd door ThinkPad op 25 juli 2024 02:36]

[SPee]

Er zijn routers te koop met ingebouwde VPN server.
Dus hoef je geen zorgen meer te maken of je een bedrijf kan vertrouwen.

[Keypunchie]

Heb je een resource waar ik wat van dat soort routers kan vergelijken? Aan welk prijspunt moet ik denken? (misschien meer een forumtopic, maar nu we het er toch over hebben).

[Armin]

+1, ik houd me ook aanbevolen.

Let ook op:

- protocol. PPTP (zoals bijvoorbeeld KPN VPN gebruikt) is weinig zinvol en OpenVPN werkt op veel clients niet native.
- updates. Geen updates maakt dat je VPN server zelf waarschijnlijk gehacked gaat worden. Vele thuis-consumenten NAS systemen zijn notoir in dit opzicht.

Ikzelf ben nog steeds op zoek naar een goede betaalbare oplossing (anders dan bedrijfmatig, want die zijn er maar zijn duur).

Ik blijf dus voorlopig met online diensten aan de gang bij gebrek aan gevonden beter.

[SPee]

Nee, er is niet echt een filter op "vpn server" bij het zoeken naar routers (ook niet in de pw).
Wat ik wel heb gevonden: De DD WRT firmware heeft ondersteuning voor vpn server. Dus de routers die ondersteund worden zouden dat kunnen.
Verder zijn er een paar merken die dat ook in hun router in hebben gebouwd. Je moet dat uit hun documentatie destilleren of het enkel als client of ook als server geldt. Ik heb nu een Asus, waar volgens mij vrij veel van hun routers ook als server gebruikt kunnen worden.
Maar dit is niet echt een veelgevraagde optie, dus die staat vrij laag in de lijst met features. Als het al wordt vermeldt.

[tERRiON]

Ik ben ook geen iOS-kenner ( ) maar blokkeert de iOS VPN-client alle uitgaande verbindingen op het moment dat je verbinding probeert te maken? Het risico zit 'em er namelijk in dat je toch gegevens 'lekt' op het moment dat de Wifi-verbinding tot stand gekomen is maar de VPN-verbinding nog niet opgebouwd is.

[cavey]

Hey Keypunchie,

Ik draai zelf OpenVPN EN Softether VPN. OpenVPN is wel een hele bekende, maar je zit dan wel enigszins vast aan de client. Ook kan je niet al je verkeer erover heen knallen met bijv. iOS (want het is geen native vpn implementatie voor iOS voorzover ik weet). Op mobiele devices kan je vast zitten aan of udp of alleen tcp ondersteuning.

Het werkt wel handig op m'n werkmachine, zodat ik m'n NFS-shares van thuis kan mounten (muziek streamen), zonder dat al m'n netwerk verkeer over de VPN lijn gaat, en ik dus niet bij servers en dat soort dingen kan op het netwerk.

Softether VPN, http://www.softether.org/, is een goede, en gratis VPN server. Ondersteunt diverse protocollen (ipsec/l2tp, openvpn), je kan de boel extra beveiligen met SSL certificaten, ondersteunt Radius authenticatie en nog meer leuke dingen.

Deze heb ik draaien voor m'n iOS en Android devices, laptops, computers, eigenlijk alles wat ik maar een L2TP verbinding ondersteunt. In combi met radius authenticatie is de boel heel makkelijk in te stellen. Dit heb ik dan ook voor m'n ouders gedaan op hun iOS devices, uitgelegd hoe het werkt en ik heb netjes hun logins voorbij zien komen vanaf public hotspots in het buitenland. "Als je via een public hotspot gaat: zet je vpn aan! Is misschien wat trager, maar al je data wordt wel versleuteld door de lucht gegooid".

Met iOS kan je een toggle zetten bij de vpn configuratie of al het verkeer er overheen moet gaan. Default aanzetten is erg handig

Bijkomend voordeel: Ik kan nu wel vanuit het buitenland, of vanuit de trein, TV kijken via de app die m'n kabel provider geeft. VPN opzetten, app opstarten, gaan

tl;dr: OpenVPN gratis, nadeel imho: je hebt de app nodig, en configureren is wat... hellish

Softether: native VPN support in iOS en Android, voor de rest is alles serverside te configureren. app-loos, native vpn \o/

[Reactie gewijzigd door cavey op 25 juli 2024 02:36]

[Yggdrasil]

Echt makkelijk is het niet maar OpenVPN is een veelgebruikte VPN server die op vrijwel elk platform beschikbaar is, in veel routers ingebouwd zit (of je koopt een Raspberry Pi) en als veilig wordt beschouwed. Er zijn veel handleidingen te vinden over het inrichten. Ik draai dit bijv. met mijn Asus RT-AC66U router en kan verbinden met mijn iPhone, iPad en laptop.

[Typhone]

Exact zo niet maar Little Snitch (OSX) lijkt er een beetje op.

[Neurd]

Met tasker op android heb ik het zo ingesteld dat mijn VPN client standaard verbinding maakt wanneer ik met een Wi-Fi verbindt TENZIJ het mijn eigen netwerk is.
Dus ja, het bestaat en ik heb er geen omkijken naar.

[Verwijderd]

VPN clients die ik gebruikt heb in het verleden, werkten al zo. (Ben de namen even kwijt)

Zodra je verbinding had met je VPN merkte je dat je gewone internet niet meer zo snel was. Die ging dan door de VPN verbinding naar de internet verbinding van het kantoor.

[Typhone]

De beste oplossing is natuurlijk nog altijd om er helemaal geen gebruik van te maken als je bezorgd bent om eventuele veiligheid. Ik connect voor zover ik weet nooit met openbare WiFi hotspots. Überhaupt ga ik in hotels en dergelijke nooit zonder VPN online en ook voor mijn werk hebben we de beschikking over een zeer goede VPN-cliënt.

Ik verbaas me ook altijd hoeveel mensen op een vliegveld vrolijk hun saldo gaan checken of nog even wat bankzaken of persoonlijke gegevens gaan regelen. Al weet ik niet hoe goed dat wel/niet afgeschermd is.

[Reactie gewijzigd door Typhone op 25 juli 2024 02:36]

[Robbaman]

Mag toch overigens wel hopen dat de software van je bank (app of website) WEL gebruik maakt van een TLS verbinding... dan gaat het bovenstaande verhaal sowieso al niet meer op.

[GrooV]

Je kan met MITM een ander veilig certificaat generen wat gewoon door browsers wordt geaccepteerd.

De app moet voorzien zijn van certificate pinning om alleen het juiste certificaat van de bank te accepteren. Zie https://www.owasp.org/ind...te_and_Public_Key_Pinning

[Arietje]

Al kan dat alleen in het geval dat een CA als diginotar gehackt is.

[Armin]

En de browser/app daarna géén revocatie check doet.

Ofwel in de praktijk kan dat met een MITM aanval dus gewoonweg niet.

[Fermion]

Het is af te raden, maar je saldo controleren zoals met je ABN-AMRO app zou feitelijk niet uit mogen maken waar jij je saldo controleert, ik ga ervan uit dat ABN-AMRO het verkeer maximaal heeft beveiligd.

Ik zou mij pas zorgen maken wanneer ABN-AMRO het afkeurt om je saldo op openbare WiFi's te controleren. Dan zou er iets niet goed zitten.

[GrooV]

Online bankier app's hebben accepteren alleen het certificaat van hun eigen bank. Dit is dus wel veilig aangezien je dat niet kan faken met een ander veilig certificaat.

Zie https://www.owasp.org/ind...te_and_Public_Key_Pinning

[Reactie gewijzigd door GrooV op 25 juli 2024 02:36]

[Armin]

Online bankier app's hebben accepteren alleen het certificaat van hun eigen bank

Dat zou inderdaad moeten, doch is niet altijd zo.

Veel bankier apps bleken recentelijk zelfs nog juist géén check te doen, en dus niet alleen het eigen of zelfs andere geldige (doch vervalsde), maar soms ook self-signed certifciaten te accepteren.

Mede kotm dit omdat de SDK's van Apple en Android standaard geen controles doen. Enkel de SDK van Windows Phone doet standaard een check. De app maker moet dus expliciet een check inprogrameren.

[BugBoy]

De beste oplossing om geen verkeersongeluk te krijgen is thuis te blijven. Ik vind het altijd een beetje makkelijk gezegd om iets maar niet te doen. Onderweg is het vaak heel handig om toch het e.e.a. te kunnen doen. Vanwege de erg hoge roamingkosten (vooral buiten de EU) is een publiek of hotel WIFI vaak de enige (betaalbare) optie.

Voor belangrijke zaken, zoals het regelen van je bankzaken, heb je meestal toch al een two-factor authenticatie (random-reader, tan-codes, ...). Andere belangrijke diensten werken meestal wel via SSL (zoals email). Niet zomaar alle waarschuwingen wegdrukken werkt al prima.

Overigens gebruik ik zelf een RaspberryPi die in de meterkast hangt en een OpenVPN server draait. Daarmee kan ik van buiten altijd naar mijn lokale netwerk. Die kan ik inschakelen vanaf mijn mobiel, zodat de communicatie tussen mijn telefoon een thuis beveiligd is. Ook al het externe verkeer gaat dan via die VPN tunnel. In de praktijk doe ik dat overigens vrijwel nooit

[GrooV]

Laat me raden, je OpenVPN server heeft een zelf gesigneerd certificaat. Niet 100% veilig dus

[Stoney3K]

Wel veilig, alleen niet 'idiot-proof'. Je zal met de hand moeten verifiëren of de fingerprint van het certificaat dat je binnen krijgt hetzelfde is als het certificaat wat je hebt gegenereerd. Is dat niet zo dan is er kans op een MITM-aanval.

Voor iemand die klakkeloos op 'verbinden' drukt is het niet geschikt, maar iemand die genoeg kennis heeft om zo'n server op te zetten en dus weet dat het om een eigen certificaat gaat, kan er rekening mee houden.

[Armin]

Je zal met de hand moeten verifiëren of de fingerprint van het certificaat dat je binnen krijgt hetzelfde is als het certificaat wat je hebt gegenereerd.

Dat doet normaal de VPN software toch voor je? Je moet eenmalig je self-signed certifciaat/CA certifciaat importeren op alle clients en server (details afhankelijk van welk VPN protocol je gebruikt), maar daarna doet men zelf een check.

Self-sigend of niet stelt je enkel in staat zaken als revocatie te doen, of te voorkomen dat je op elke client handmatig certificaten moet importeren. Maar qua athenticatie/encryptie/signing is er geen wezelijk verschil.

Of begrijp ik je punt nu niet?

[Brousant]

Wat is daar minder veilig aan dan?

[BugBoy]

Dat is helemaal veilig, want dat certificaat wordt expliciet vertrouwd op mijn toestel. Alleen van apparatuur van derden is het inderdaad niet veilig. Maar de vraag is of je sowieso al gebruik daarvan wilt maken als je paranoia bent...

En ook al is het niet 100% veilig, dan is het nog altijd heel wat veiliger dan zonder VPN wat te doen. Hiervoor is altijd nog een MITM attack voor nodig in plaats van eenvoudig te sniffen.

[Reactie gewijzigd door BugBoy op 25 juli 2024 02:36]

[Keypunchie]

Ik verbaas me ook altijd hoeveel mensen op een vliegveld vrolijk hun saldo gaan checken of nog even wat bankzaken of persoonlijke gegevens gaan regelen. Al weet ik niet hoe goed dat wel/niet afgeschermd is.

De websites van banken hebben al goede bescherming, maar daar ben je nog doorgaans kwetsbaar voor een "man-in-the-browser" attack. Het voordeel van de apps is juist dat deze helemaal kunnen zijn dichtgetimmerd, inclusief gesigneerde code.

Vanuit hun zorgplicht en het feit dat de bank doorgaans op moet draaien voor kosten van online fraude, hebben zij de boel behoorlijk goed qua beveiliging.

Inclusief sessies die automatisch time-outen als je task-switch, het uitschakelen van screenshot-mogelijkheden (android) en allemaal van dat soort trucs.

Er moet ergens een afweging zijn tussen veiligheid en functionaliteit. Juist onderweg (vliegveld/trein) kan het handig zijn om je saldo te weten (ga je naar een duur restaurant, of wordt het een hamburger), of om nog even geld over te maken van de ene naar de andere rekening (het wordt hoe dan ook dat dure restaurant ;-) ).

[-AD]

http verkeer kan als ik het correct heb gewoon uitgelezen worden op deze manier (zonder vpn) als mensen op jouw acces point ingelogd zijn. Hoe zit dit met https dan?

[Verwijderd]

Alleen in het geval dat het rogue accespoint zich voordoet als de site die je wil bezoeken. Maar in dat geval gaat je browser klagen dat het certificaat niet klopt.

[Verwijderd]

Niet per sé, je browser gaat klagen (enge waarschuwingspagina's) op het moment dat het certificaat niet klopt. Als de site onversleuteld wordt geserveerd blijft hij kalm, en kun je alleen aan het ontbreken van een slotje zien dat de verbinding niet beveiligd is.
Een leuke workaround van Moxie Marlinspike een tijdje geleden was het instellen van een slotje als favicon

mocht er iemand een uurtje over hebben en geïnteresseerd zijn in hoe software werkt die het HTTPS verkeerd downgrade naar HTTP: Moxie heeft op BlackHat 2009 een talk gegeven over zijn software SSLStrip.
http://www.thoughtcrime.org/software/sslstrip/

edit: een oplossing hiertegen vanuit de gebruikers kant is o.a. wat Google tegenwoordig doet: http pagina's als onveilig markeren en hopen dat de gebruiker het opmerkt. Softwarematig wordt er aan HSTS (certificate pinning) gewerkt, waardoor de browser zelfs nepcertificaten van overheidsinstanties kan ontdekken. Google heeft dit onder andere al een keer gebruikt om een man in the middle aanval van de Turkse overheid op GMail op te merken, die een eigen valide certificaat hadden laten maken voor gmail

[Reactie gewijzigd door Verwijderd op 25 juli 2024 02:36]

[hackerhater]

Ligt eraan.
Het is voor sites mogelijk aan te geven dat ze altijd over https benaderd moeten worden.
Als je browser dat eenmaal weet weigert ie een http verbinding.

[Yggdrasil]

HSTS en Certificate Pinning zijn niet hetzelfde.

Met HSTS kan een site via HTTP headers aan de browser aangeven dat deze altijd via HTTPS bezocht moet worden. Als de bezoeker dus éénmaal de site bezocht heeft via een betrouwbare verbinding dan zal voor toekomstige bezoeken SSL worden vereist.

Certificate Pinning vergelijkt het van de website ontvangen certificaat met een lijst met een ingebouwde lijst van vertrouwde certificaten (dus niet die van de CA's, maar van de sites zelf). Hierdoor kunnen bijv. man-in-the-middle verbindingen gedetecteerd worden, bijv. van een firewall die SSL verkeer kan ontsleutelen door een eigen CA-certificaat te installeren op je PC. In dat geval is de verbinding immers wel versleuteld, met een geldige SSL chain, dus zou de gebruiker normaal gesproken niet merken dat er iemand meeluistert.

[daft_dutch]

Browser gaat niet klagen want men stript gewoon het gehele SSL verkeer weg. zodat er plane http aan de browser geserveerd wordt. Daar piept een browser dus noooooit over.
Dus de gebruiker moet zelf zien dat de site niet naar een https variant gaat.
En dat checkt men niet zo snel.

En als via het rogue netwerk de gebruiker iets download en uitvoert ben je helemaal ver van huis want dan kunnen frauduleuze certificaten gewoon geïmporteerd zijn in het systeem waarna gebruikers het certificaat goed moeten inspecteren om te zien dat het niet een goed certificaat is. Veel succes gewenst voor de normale computer gebruiker.

[Reactie gewijzigd door daft_dutch op 25 juli 2024 02:36]

[Snow_King]

Dat gaat dus niet. Als de browser een verbinding naar poort 443 op zet kan het access point niet iets als SSL-stripping doen.

SSL-stripping kan alleen als de browser in eerste instantie al via HTTP verbond waarna er normaliter een redirect naar HTTPS plaats vind.

Dan kan je die redirect ondervangen en gewoon HTTP serveren.

Mijn mail App op mijn iPhone verbinding standaard via SSL naar mijn IMAP. Dat kan je niet strippen of een man in the middle attach op uitvoeren. De telefoon gaat direct klagen dat het certificaat niet klopt.

[daft_dutch]

Men gaat naar http://facebook.nl dat verwijst normaal door naar https://facebook.nl
maar dat wordt gestript tot http://facebook.nl

Alleen als men Expliciet SSL verwacht (zoals jou iphone)
Maar dat gebeurt niet expliciet door de normale gebruiker. Als men dat namelijk altijd deed zou deze hele dicussie dit hele tweaker post. en al dat gezeur over onveilig netwerken helemaal niet bestaan!!

Daarbij is jou SSL IMAP verbinding hard gekoppeld aan een certificaat of ben je gewoon het bokje als je telefoon een keer een fout certificaat geinecteert krijgt?

voor echte veiligheid. gebruik SSH om een dynamische SOCK proxy te tunnelen. Is teminste een beetje beschermt tegen valse certificaten

[Reactie gewijzigd door daft_dutch op 25 juli 2024 02:36]

[Snow_King]

Ja, maar mijn punt was vooral dat SSL-stripper niet kan zodra er eenmaal een HTTPS verzoek komt vanuit de browser.

Veel browsers onthouden bijv dat ze al een keer SSL hebben gedaan naar een site en zullen het daarna ook weer doen.

Zie ook: https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security

HTTP Strict Transport Security (HSTS) is a web security policy mechanism which helps to protect secure HTTPS websites against downgrade attacks and cookie hijacking. It allows web servers to declare that web browsers (or other complying user agents) should only interact with it using secure HTTPS connections,[1] and never via the insecure HTTP protocol

[daft_dutch]

dat doe je toch een dns spoofing dat je van facebook naar
facebook met Cyrillic karakters inplaats van normale latin karacters
en dan denk de browser dat het een nieuwe site is waar nog nooit een https verbinding naar toe is geweest. Of een ander soort typosquatting.

zie ook: https://en.wikipedia.org/wiki/IDN_homograph_attack

[Reactie gewijzigd door daft_dutch op 25 juli 2024 02:36]

[Yggdrasil]

Precies. Als de eerste request naar de HTTP versie van een site gaat (bijv. omdat men facebook.com in de adresbalk van een browser typt) dan kan d.m.v. DNS spoofing en een redirect worden voorkomen dat er een HTTPS verbinding wordt opgezet. Daarom is HSTS zo belangrijk om normale gebruikers te beschermen. Hierdoor zal de de browser, als eenmaal de betreffende site bezocht is over een vertrouwde verbinding, onthouden dat deze alleen maar via HTTPS bezocht mag worden.

[himlims_]

ervanuit gegaan dat $user zijn systeem/software update [..]

[Armin]

http verkeer kan als ik het correct heb gewoon uitgelezen worden op deze manier (zonder vpn) als mensen op jouw acces point ingelogd zijn. Hoe zit dit met https dan?

Enkel als er geen wachtwoord is. Ofwel het hebben avne en WiFi met heel groot het wachtwoord op de muur geschreven is veiliger dan echt 'open'. Is er namelijk een wachtwoord, wordt elke sessie (elke gebruiker) appart versleuteld en kunnen individuele gebruikers elkaars data niet zien.

HTTPS is verder zowieso veilig. Immers dat protocol is speciale bedoeld om anderen die toegang tot jouw bits hebben, toch te verhinderen de onderliggende informatie te zien.

[DeTeraarist]

Jammer dat er specifiek over publieke hotspots wordt gesproken, terwijl je buurman net zo goed jouw SSID kan imiteren.

[VonFoX]

Dan moet buurman wel mijn WPA2 key weten. Anders connecten mijn apparaten niet.

[DeTeraarist]

Nee. De hotspot kan gewoon elke sleutel die het aangeboden krijgt goedkeuren Sterker nog, de meeste apparaten klagen niet als er in ene niet om authenticatie wordt gevraagd, die verbinden gewoon.

[Anonyymm]

VPN opzetten voor de normale gebruiker is idd doorgaans een brug te ver. En waarschijnlijk is dit een advies met een eigen product (https://www.f-secure.com/en/web/home_global/home) op komst. Ziet er overigens wel goed uit. Ik denk dat er ook best meer postbus51 spotjes, oid, mogen komen om meer te attenderen op gevaar van bijvoorbeeld bankieren via een openbare (onbeveiligde) wifi verbinding.

Ik vind het altijd wel bijzonder dat (korte) ingewikkelde wachtwoorden veiliger worden beschouwd dan een lang wachtwoord met bestaande woorden. En dat veiliheidsexperts dat ook aanraden terwijl je zelden een advies leest voor gebruik van veel woorden achter elkaar.

Een mooi plaatje uit 2011 beschrijft de "Troubador" en de "Correct horse" methode:
- Tr0ub4dor&3 - 28 bits entropy (3 dagen als er 1000 keer per seconde gegokt kan worden).
- correcthorsebatterijstaple - 44 bits entropy (550 jaar als er 1000 keer per seconde gegokt kan worden).

Laatste is ook nog eens makkelijker te onthouden. Het volgende zinnetje is mij altijd bijgebleven: "Security at the expense of usability comes at the expense of security".

[Verwijderd]

https://xkcd.com/936/

[robbinwehl]

Wat zien ze onder '' Een vpn zou in de meeste gevallen voldoende bescherming bieden. '' ?
Wanneer er bijvoorbeeld PPTP als encrypte gebruikt word is het met een kleine extra handeling alsnog te ontsleutelen.

[ASS-Ware]

Wat zien ze onder '' Een vpn zou in de meeste gevallen voldoende bescherming bieden. '' ?
Wanneer er bijvoorbeeld PPTP als encrypte gebruikt word is het met een kleine extra handeling alsnog te ontsleutelen.

Dan gebruik je L2TP/IPSec.
PPTP is allang niet meer veilig, inderdaad.

[robbinwehl]

Inderdaad, en zolang je geen preshared keys gebruikt is dat een heel stuk veiliger.

[cazzer22]

In Blackberry OS 10 zit een instellingsmogelijkheid om direct na het accepteren van een wifi verbinding een vpn verbinding te starten vóórdat er mail of iets binnengehaald wordt. Dit lijkt mij een wenselijke instelling vooral voor publieke wifi hotspots. Helaas heeft iOS9 zo'n instelling niet, android vermoedelijk ook niet.

[Pikkemans]

Google is al bezig met het intergreren van een eigen VPN oplossing in Android. Zodra een gebruiker aanmeld via een open wifi netwerk dan zal er automatisch een VPN tunnel opgezet worden via Google. Dat het dan via Google gaat mag je zeker iets van vinden maar het is beter omdat het vanuit het OS word meegeleverd zodat de massa minder risico loopt om door echte criminelen te worden bestolen van gegevens.

bron: http://www.tomshardware.c...lipop-free-vpn,28745.html

[Yoshee]

is het gebruik van bv de ING app, op IOS, niet beter ipv de site zelf te gebruiken om aan te melden?