Hoezo gebruikersnamen en wachtwoorden? Die gegevens zijn bij de meeste apps versleuteld (en zeker de bekende Facebook, twitter, etc.). Wat de onderzoekers voorbij zagen komen was waarschijnlijk de namen van de devices zoals 'Iphone-van-Pietje' maar die zou je op een beveiligde verbinding ook langs zien komen. Het enige probleem is dat veel websites (zoals div. nieuws sites) geen https gebruiken en je dus zou kunnen zien wat voor onderwerpen gelezen worden.

Dit snap ik niet. Zowel Gmail als Facebook gebruiken HSTS waardoor al het verkeer gecrypt is (er vind geen handshake meer plaats over plain HTTP). Wat valt er voor een MitM access point dan af te vangen? Zelfs WhatsApp is tegenwoordig end-to-end gecrypt, device updates zijn gesigned en Google search loopt ook over TLS.
Of willen ze hiermee aantonen dat een device direct verbinding maakt met een access point indien de naam overeenkomt met een AP waarmee deze eerder connectie heeft gehad? Want dat is een oud en bekend probleem.
Of bedoelen ze dat je uit de AP namen veel informatie kunt halen? Want een toestel waarvan de WiFi aan staat zal constant zijn bekende WiFi AP namen broadcasten en uit die SSIDs kun je veel informatie afleiden, zoals waar de gebruiker werkt, waar hij woont en waar hij vaak komt.

Jij begrijpt niet hoe een Evil Twin werkt

Een hacker geeft in veel gevallen niets om https versleuteling als hij een MitM aanval kan uitvoeren.
apps uitgesloten omdat daar soms een certificaat check ingebouwd zit.

maar de bewering dat het niet kan is, zeker in het geval van een evil accesspoint, onjuist

Kortom, gebruik bij free WiFi altijd een VPN

En jij (in tegenstelling tot Anoniem van 18-05-2016, 10:39) begrijpt niet hoe HSTS werkt. Iets dat juist om deze reden zo belangrijk is.
Alhoewel jij (en Anoniem van 18-05-2016, 11:10) niet de enigen zijn die dat niet begrijpen [1].

[1] https://www.security.nl/posting/471195/#posting471206

@Erik: in mijn ogen is HPKP zelfs nog een tandje beter, omdat je daarmee - in tegenstelling tot HSTS - ook voorkomt dat een aanvaller een *ander* TLS certificaat injecteert in de connectie. Want HSTS stelt alleen dat er *altijd* over HTTPS gecommuniceerd moet worden, maar niet met specifiek welke certificaten (welke, want bij HPKP heb je doorgaans twee certificaten, 1 actief en 1 als backup indien de eerste moet worden gerevoked).

ik zie dat je zelf het verschil tussen de gmail app en https://gmail.com verward.
Ano 11:10 heeft namelijk een punt.

en de eerste die hier onder beweert dat een evil-twin, een nep wifi of een man in the middle geen kwaad kan nodig ik uit om bij de starbucks een drankje met me te doen. moet je wel je tablet of laptop mee nemen.

Daar heb je gelijk in, ik zal de laatste zijn om te beweren dat je geen gevoelige informatie kunt verzamelen (helaas lijkt http://trainwatch.u0d.de/ uit de lucht te zijn).

Maar de gebruikelijk SSLStrip werkt niet als een site (op correcte wijze) HSTS gebruikt en de bezoeker die site eerder heeft bezocht (om precies te zijn, minder dan het aantal seconden dan de HSTS header specificeerde tijdens het laatste bezoek). Vandaar het pleidooi van velen (waaronder van mij) voor HSTS, juist omdat MITM zo simpel is bij WiFi.

Je kunt, als aanvaller, niet zomaar elk willekeurig certificaat injecteren:
- de domainname erin moet overeenkomen met wat de gebruiker heeft aangevraagd, -en-
- de browser moet het certificaat vertrouwen op basis van een pre-loaded rootcertificaat.
Natuurlijk zul je sommige gebruikers voor de gek kunnen houden met een certificaatfoutmelding, maar verstandige gebruikers trappen daar (hopelijk) niet meer in (zo ja dan houdt alles op).

Als ik met een netjes onderthouden PC https://www.security.nl/ open, moet jij van heel goede huize komen wil jij mijn browser een nepcertificaat voor die site voorschotelen dat door mijn browser wordt vertrouwd.

Ik ben huiverig voor HPKP omdat het middel wel eens erger zou kunnen zijn dan de kwaal. Zoals je schrijft is het betrekkelijk eenvoudig om jezelf hiermee te DoS-en, namelijk als je geen gepubliceerd backup-keypair hebt.

Ik zie twee grote risico's bij HPKP:
1) Het ligt teveel voor de hand om niet, voorafgaand aan elke certificaataanvraag, een nieuw sleutelpaar te genereren. De levensduur van certificaten hoort onder meer beperkt te zijn juist omdat er een risico is op lekken van de private key en/of refactoren daarvan.

2) Dilemma: waar laat je de private key van het backup-certificaat?
- Als deze zich in een bestandje naast de ingebruik zijnde private key bevindt, en je server wordt gehackt (of heeft een heartbleed-like lek), wat doe je dan: beide revoken of fingers crossed?
- Als je die backup private key ergens anders laat "slingeren", wie kunnen daar dan allemaal bij? Weet je deze bijtijds te vinden (en weet je het wachtwoord ervan dan nog) zodra je je primaire keypair moet intrekken?

HSTS, met name indien je preload voor elkaar hebt, is een stuk veiliger - vooral voor jouw eigen site(s).