Onderzoekers: patronen in https-verkeer verraden bezochte pagina's

Onderzoekers zijn erin geslaagd om met een betrouwbaarheid van 89 procent vast te stellen welke pagina's iemand via https heeft bezocht. Daarvoor moet wel het https-verkeer worden onderschept. Nog niet eerder zijn onderzoekers erin geslaagd https-verkeer zo nauwkeurig te analyseren.

Een man in the middle, die het verkeer van een internetgebruiker onderschept, is normaliter niet in staat om te zien welke pagina's over https worden bezocht. Enkel de domeinnaam waarmee verbinding wordt gemaakt, is zichtbaar. De get-request zelf, waarin de opgevraagde pagina is opgenomen, wordt over ssl/tls verstuurd. Er kunnen echter nog steeds patronen in het versleutelde internetverkeer worden waargenomen.

Onderzoekers van Berkeley en Intel hebben ontdekt dat in bepaalde gevallen zelfs met 89 procent zekerheid kan worden vastgesteld welke pagina's zijn opgevraagd. Tot nu toe was dat 60 procent. Daarvoor moet een aanvaller wel een aantal stappen ondernemen. Ten eerste moet hij het internetverkeer onderscheppen. Daarnaast moeten minimaal vijfhonderd pagina's van een bepaalde domeinnaam door de aanvaller zelf zijn bezocht en geanalyseerd voordat een indicatie van een bezochte pagina kan worden gegeven. Dat lukte de onderzoekers onder meer bij een Amerikaanse burgerrechtenorganisatie, een aantal banken en een organisatie voor abortus.

De onderzoekers tekenen aan dat bezochte pagina's indicaties kunnen geven van iemands seksuele voorkeuren, financiële situatie en medische problemen. Onder meer werkgevers, die immers de internetverbinding van hun medewerkers beheren, zouden daarvan misbruik kunnen maken, stellen de onderzoekers. Hetzelfde geldt voor spionerende overheden.

Een verdediging tegen de aanval zou kunnen zijn om ip-packets in bepaalde gevallen door midden te delen, of door padding toe te passen, waarbij willekeurige waarden aan een pakket worden toegevoegd. Dat laatste wordt vaker gedaan in cryptografie, om te voorkomen dat twee identieke berichten die dezelfde versleuteling gebruiken, aan elkaar kunnen worden gekoppeld.

Reacties (44)

[tofus]

Bekend probleem bij encryptie; Als je (deel) van de patronen van de source-tekst kent, wordt het decrypten ordes van grote makkelijker. Zo is het beroemde/beruchte 'Enigma'-cipher ook ten onder gegaan.

Als je echt veilig wilt communiceren, zul je flinke hoeveelheden 'ruis' aan je communicatie moeten toevoegen. En waarschijnlijk quantum-cryptografie moeten gebruiken.

[Jace / TBL]

Bekend probleem bij encryptie; Als je (deel) van de patronen van de source-tekst kent, wordt het decrypten ordes van grote makkelijker. Zo is het beroemde/beruchte 'Enigma'-cipher ook ten onder gegaan.

Als je echt veilig wilt communiceren, zul je flinke hoeveelheden 'ruis' aan je communicatie moeten toevoegen. En waarschijnlijk quantum-cryptografie moeten gebruiken.

Dit is alleen een issue bij beroerde encryptie-algoritmen, of een beroerde cipher mode (zoals ECB waarbij twee gelijke blokken van n bits in de input data, ook tot twee gelijke blokken van n bits in de encrypted output leiden).

Aan data encrypted met AES met een fatsoenlijke block mode (liefst XTS of CTR) valt niets te detecteren. Daar heeft quantum-cryptografie verder niets mee te maken.

[tofus]

Aan data encrypted met AES met een fatsoenlijke block mode (liefst XTS of CTR) valt niets te detecteren.

Daarom heeft de NSA ook een batterij mathematici in dienst met die als taakomschrijving 'crypto-analyticus' hebben. Die analyseren alleen communicatie versleuteld met 'beroerde' algoritmes...of...wacht....misschien toch niet...

Overigens, https gebruikt in de meeste implementaties gewoon AES voor de blockstream. En waar gaat dit artikel nu juist over? Juist. HTTPS.

Alleen de key-exchange zelf (tijdens de TLS/SSL handshake) gaat via een assymetrisch cipher, doorgaans RSA of DSA, ook zeker niet bepaald de 'beroerste' zou ik zeggen.

Daar heeft quantum-cryptografie verder niets mee te maken.

Dat zei ik toch ook niet? Feit blijft iig dat als je zo veilig mogelijk wilt communiceren, dat quantumcryptografie op dit moment wellicht je beste optie is.

[Reactie gewijzigd door tofus op 24 juli 2024 06:14]

[Jace / TBL]

Die analyseren volgens jouw dus alleen communicatie versleuteld met 'beroerde' algoritmes?

Nee, die brengen ook meta data in beeld, en allerlei andere fratsen waar dit artikel ook over gaat.

Wat jij stelde (delen van input bekend = makkelijker de output decrypten) is in het algemeen gewoon niet waar. Grappenmaker.

En mits voldoende sterke (en onbekende key), denk ik inderdaad dat er ook voor een "batterij mathematici" bij de NSA niets aan AES-encrypted data valt te kraken. De kwetsbaarheden in https zitten hem (in geval van gebruik van AES) niet in AES zelf, maar inderdaad in het uitwisselen van de key. Op die asymmetrische algo's die daarvoor gebruikt worden valt het een en ander aan te merken.

[Armin]

delen van input bekend = makkelijker de output decrypten

Volgens mij praten jullie langs elkaar heen.

Het is encryptie 101 dat als je een deel van de input weet, decryptie makkelijker is. Niet voor niets worden bij toetsen en audits van encryptie-protocollen en technieken ook altijd gekeken, naar is het ook bestand tegen aanvallers die een deel van de input kennen.

Immers dat soort zaken zijn heel veel voorkomend. Als ik bij ING.nl telebankieren ga is 90+% van de data voor het inloggen identiek aan wat jij krijgt als je naar die website gaat om in te loggen.

Echter dat is niet waar het in dit artikel om gaat. War het hier om gaat is meta-data. Dus ook zonder dat ik iets kan decrypten kan ik informatie krijgen. Immers het opvragen en verzenden van informatie gaat in golven.
Voorbeeld: Bij ING.nl vraag je eerst de pagina op waardoor een grote golf van data de PC op komt, dan log je in waar er een klein stukje hun kant op gaat van ruwweg vaste omvang, en dan krijg je je account pagina wat ook ruwweg een vaste omvang heeft. En individuele functies zullen ook bepaalde karakeristieken hebben. Wil je dat tegengaan zou je al grote hoeveelheden ruis beide kanten op moeten sturen.

Maar de vraag is ook of dat nodig is. Als ik ING.nl bezoek of GMail weet de meeluisteraar toch al wat ik aan het doen ben. In veel gevallen is het de inhoud die ik wil beschermen en niet zozeer de activiteit. Bij andere zaken zoals zoeken is het wellicht een ander verhaal, maar daar is het vinden van karakteristieken juist weer lastig.

[MBV]

Dit is nuttig wanneer je een HTTPS-site gebruikt als proxy, of als er meerdere websites geserveerd worden op 1 IP-adres.

[Jace / TBL]

Het is encryptie 101 dat als je een deel van de input weet, decryptie makkelijker is. Niet voor niets worden bij toetsen en audits van encryptie-protocollen en technieken ook altijd gekeken, naar is het ook bestand tegen aanvallers die een deel van de input kennen.

Volgens mij gaat die vlieger niet op bij bijvoorbeeld AES met een cipher mode waar ieder block met een onafhankelijke key wordt encrypted (zoals in ieder geval CTR, en ik geloof ook XTS al weet ik dat niet 100% zeker).

Echter dat is niet waar het in dit artikel om gaat. War het hier om gaat is meta-data. Dus ook zonder dat ik iets kan decrypten kan ik informatie krijgen.

Inderdaad. Ik reageerde slechts op tofus' bewering "als je (deel) van de patronen van de source-tekst kent, wordt het decrypten ordes van grote makkelijker" maar dat is (a) niet algemeen waar (soms wel, niet altijd) en (b) hier niet van toepassing, men decrypt niets. En daar ging het artikel ook inderdaad niet over, tofus begon over het makkelijker kunnen decrypten van dingen, maar het 'veiligheidslek' in dit artikel zit hem in hele andere zaken.

[Armin]

Volgens mij gaat die vlieger niet op bij bijvoorbeeld AES met een cipher mode waar ieder block met een onafhankelijke key wordt encrypted

Die vlieger gaat altijd op!

Maar ik ben nu flauw, want jouw reactie lezend volgens mij zijn we het gewoon eens. Waar jij op doelt is dat bij het opzetten van AES er inderdaad expliciete maatregelen genomen zijn om te beschermen tegen bekendheid. van delen van de input. En dan heb je geheel gelijk.

Dat is dus waar ik op doelde. Het is per definitie makkelijker om een reeks bytes X te decrypten als je een deel al kent. Meer informatie is altijd beter voor een aanvaller. Een goed encryptie-protocol zoals AES heeft dus ook beschermingen daar tegen.

Maar dan nog is het nog steeds makkelijker in relatieve zin. Om die reden zijn er toepassingen waar alvorens encryptie toe te passen, nog een extra randomise-algorithme gebruikt wordt. Bij later ontdekte zwakheden van protocollen, zijn de eerste aanvallen namelijk heel vaak gebaseerd op juist het weten van bepaalde input.

Microsoft Bitlocker encryptie van harddisks doet dat bijvoorbeeld ook. Op dit moment is dat niet nodig aangezien er inderdaad geen volledige aanval tegen AES bestaat, maar mocht er op een bepaald moment een aanval mogelijk zijn gebaseerd op 'bekende input' is het fijn dat Microsoft een extra laag ingebouwd hebben voor de zekerheid.

[tofus]

De kwetsbaarheden in https zitten hem (in geval van gebruik van AES) niet in AES zelf, maar inderdaad in het uitwisselen van de key.

Hoe kom je daar nu weer bij? Het artikel gaat duidelijk over de GET-requests m.b.t. de bezochte domeinen/URI's, alsmede eventuele patronen in de HTTP response-data (zoals bijv. iemands seksuele voorkeuren, financiële situatie of medische problemen). Uit het artikel: "De get-request zelf, waarin de opgevraagde pagina is opgenomen, wordt over ssl/tls verstuurd. [..]" Het gaat dus weldegelijk om de data die is versleuteld met AES (de GET request), en niet om de key-exchanges. Heb je het artikel uberhaupt wel gelezen? Of vond je dat niet eens meer nodig?

Op die asymmetrische algo's die daarvoor gebruikt worden valt het een en ander aan te merken.

Nog meer klinklare onzin. Assymetrische ciphers zijn doorgaans vele ordes van grootte veiliger en robuuster dan symmetrische block-ciphers. En ook vele ordes van grootte complexer en CPU-intensiever. Vandaar dat ze alleen voor de key-exchange worden gebruikt, want anders wordt de implementatie te complex en de data-transfer te duur m.b.t. benodigde rekenkracht. De daadwerkelijke HTTP protocol-(meta)data (zoals de GET-requests en de response-data waar het artikel het over heeft) wordt gewoon met AES versleuteld, en dat is vele malen 'zwakker' dan met een assymetrische cipher. Maar ook vele malen 'praktischer'.

Bijna alles wat je beweert laat zien dat je wellicht de crypto-klok hebt horen luiden, maar geen benul hebt waar de crypto-klepel hangt.

[Reactie gewijzigd door tofus op 24 juli 2024 06:14]

[Jace / TBL]

Hoe kom je daar nu weer bij? Het artikel gaat duidelijk over de GET-requests m.b.t. de bezochte domeinen/URI's, alsmede eventuele patronen in de HTTP response-data (zoals bijv. iemands seksuele voorkeuren, financiële situatie of medische problemen). Uit het artikel: "De get-request zelf, waarin de opgevraagde pagina is opgenomen, wordt over ssl/tls verstuurd. [..]" Het gaat dus weldegelijk om de data die is versleuteld met AES (de GET request), en niet om de key-exchanges. Heb je het artikel uberhaupt wel gelezen? Of vond je dat niet eens meer nodig?

Ik reageerde op jouw commentaar ("wordt het decrypten ordes van grote makkelijker"), niet op het artikel. Ik stelde nergens dat die onderzoekers iets konden decrypten (noch aan de asymmetrische key exchange, noch aan de encrypted data zelf). De onderzoekers zelf ook niet trouwens, of heb je de paper waar het artikel naar verwijst niet gelezen? Daarin zie je namelijk dat men vooral uit meta-data en statistische analyse dingen kan afleiden over de GET requests, zonder dat men die GET-requests daadwerkelijk kan decrypten.

Ik zeg wel (en dat was in reactie op jouw geraaskal over NSA mathematici en symmetrische vs asymmetrische encryptie) dat eventuele cryptografische kwetsbaarheden in SSL/TLS hem zitten in de key exchange. Zoals RSA waarbij servers op een gegeven moment grotere keys moesten gaan gebruiken om nog veilig te zijn, of een randomgenerator bevatte met speciale 'NSA parameters' (DUA_EC_PRNG). En niet in AES. Verder is mijn voorspelling (maar dat is vooral mijn intuïtie als wiskundige) dat de afhankelijkheid van priemfactorisatie in RSA eerder tot kwetsbaarheden zal leiden dan de permutatiestructuur waar AES op gebaseerd is. Niet voor niets neigt men steeds meer naar Diffie-Hellman-varianten gebaseerd op elliptische curven (ECC) in plaats van priemgetallen (RSA). Maar goed, dat wordt wat offtopic hier.

Nog meer klinklare onzin. Assymetrische ciphers zijn doorgaans vele ordes van grootte veiliger en robuuster dan symmetrische block-ciphers. En ook vele ordes van grootte complexer en CPU-intensiever. Vandaar dat ze alleen voor de key-exchange worden gebruikt, want anders wordt de implementatie te complex en de data-transfer te duur m.b.t. benodigde rekenkracht. De daadwerkelijke HTTP protocol-(meta)data (zoals de GET-requests en de response-data waar het artikel het over heeft) wordt gewoon met AES versleuteld, en dat is vele malen 'zwakker' dan met een assymetrische cipher. Maar ook vele malen 'praktischer'.

Helaas, het is precies andersom. Symmetrische ciphers zijn veiliger dan asymmetrische ciphers met vergelijkbare key-grootte. Asymmetrische ciphers zijn (in tegenstelling tot symmetrische ciphers) bovendien sowieso niet geschikt om data van willekeurige lengte te encrypten. Dat is dus niet alleen een kwestie van 'complexer en intensiever' maar gewoon überhaupt niet veilig toepasbaar daarvoor. Daarnaast wordt de encrypted data bij asymmetrische ciphers (wederom in tegenstelling tot symmetrische ciphers) groter dan het origineel.

Symmetrische encryptie is geschikt voor het veilig en efficiënt encrypten van data (klein of groot). Asymmetrische encryptie is geschikt voor het encrypten van keys (relatief klein) en die veilig kunnen uitwisselen over een onveilig communicatiekanaal.

Bijna alles wat je beweert laat zien dat je wellicht de crypto-klok hebt horen luiden, maar geen benul hebt waar de crypto-klepel hangt.

Ik zou me voortaan even beter inlezen alvorens dit soort uitspraken te doen en jezelf voor schut te zetten.

[tofus]

Helaas, het is precies andersom. Symmetrische ciphers zijn veiliger dan asymmetrische ciphers [..]

Het is volgens mij heel simpel: Assymmetrische ciphers zijn wiskundig complexer, bieden grotere key-sizes en zijn daardoor over het algemeen veiliger dan symmetrische ciphers. Echter, juist door de extra veiligheid en complexiteit, zijn ze ook trager en daardoor onpraktischer. Daarom worden symmetrische ciphers gebruikt voor de encryptie van bulk-data, en worden assymmetrische ciphers vooral gebruikt voor het versleutelen van de meest gevoelige informatie, zoals bijv. de keys in een key-exchange voor een symmetric cipher, of het versleutelen van zeer gevoelige communicatie m.b.v. PGP/GPG, etc.

Je geleuter over 'voor dezelfde keysizes' slaat ook nergens op. AES biedt geen 2048-bit keys, en voor 256-bit RSA/DSA bestaat niet eens een implementatie. Laten we de discussie reeel proberen te houden, ok?

Ik zou me voortaan even beter inlezen alvorens dit soort uitspraken te doen en jezelf voor schut te zetten.

Tja, over voor schut zetten gesproken. Om met de wijze woorden van Yoda te spreken: "Shannon and Schneier, clearly read them you did not."

[Reactie gewijzigd door tofus op 24 juli 2024 06:14]

[Jace / TBL]

Het is volgens mij heel simpel: Assymmetrische ciphers zijn wiskundig complexer, bieden grotere key-sizes en zijn daardoor over het algemeen veiliger dan symmetrische ciphers.

Om te beginnen zijn 'wiskundig complexer' en 'grotere key sizes' niet zonder meer reden om vanzelfsprekend veiliger te zijn. Zo is RSA-512 veel zwakker dan AES-128, of zie dit voorbeeld van Bruce Schneier.
Welke keysize staat voor welke mate van beveiliging hangt sterk samen met welk algoritme je gebruikt. AES-128 is veiliger dan 3DES-168 (beide symmetrisch), en ECC-512 is veel sterker dan RSA-1024 (beide asymmetrisch). En als je symmetrisch met asymmetrisch (met name RSA) vergelijkt is het verschil doorgaans nog groter.

Je geleuter over 'voor dezelfde keysizes' slaat ook nergens op. AES biedt geen 2048-bit keys, en voor 256-bit RSA/DSA bestaat niet eens een implementatie. Laten we de discussie reeel proberen te houden, ok?

Symmetrisch omvat meer dan AES, Blowfish gaat bijvoorbeeld tot 448-bit keys en Threefish tot 1024 bit (beide van Bruce Schneier overigens). En RSA en DSA zijn überhaupt niet gelimiteerd tot een bepaalde key grootte (behoudens natuurlijk een ondergrens waarbinnen je nog zinnige data kwijt kunt). voorbeeld van RSA implementatie waar je gewoon 256-bit (of 123 of whatever) keys kunt gebruiken.

Verder ken je wellicht die overzichtjes waarin verschillende algoritmes (symmetrisch en asymmetrisch) met diverse key-groottes worden vergeleken op overeenkomstige mate van veiligheid. Zoals hier of daar (table 1). Hint: de reden dat daar geen RSA-256 bij staat is niet omdat dat niet zou bestaan. Die verschillen in key-grootte om dezelfde mate van veiligheid te krijgen, daar doelde ik op. "Symmetrische ciphers zijn veiliger dan asymmetrische ciphers met vergelijkbare key-grootte" komt ruwweg overeen met "symmetrische ciphers zijn even veilig als asymmetrische ciphers met veel grotere keys".

Tja, over voor schut zetten gesproken. Om met de wijze woorden van Yoda te spreken: "Shannon and Schneier, clearly read them you did not."

Toch wel. (FYI: Shannon nog tijdens studie wiskunde, Scheiner pas later)

[Reactie gewijzigd door Jace / TBL op 24 juli 2024 06:14]

[Sgreehder]

Quantumcryptografie is niet 'veiliger', het is alleen gelijk duidelijk als iemand heeft meegekeken.

[Leon Straathof]

Aes sterk hmm sterkte ligt zwaar onder druk door nieuwe technieken denk aan de wapenwedloop voor bitcoin mining ook een vorm van encrypty kraken. Cpu toen gpu en nu asic. En ja asics kunnen ook voor minder goede doelen worden misbruikt. Super computers ofwel dikke cpu is echt achterhaald.

[svenslootweg]

... niet echt, nee.

Bitcoin mining gaat om het (letterlijk) toepassen van brute force bij een SHA-hash. Ten eerste is dat sowieso een heel ander algoritme dan waar het hier om gaat, ten tweede is het een hash-algoritme en geen encryptie-algoritme, ten derde is het geen plaintext bruteforce (de uitkomst hoeft enkel aan bepaalde karakteristieken te voldoen, niet identiek te zijn), en ten vierde zijn ASICs algoritme-specifiek - dat is nu juist waarom ze zo efficient zijn.

Bitcoin mining, en de daarvoor gebruikte ASICs, hebben echt helemaal niets te maken met encryptie-algoritmes, en zeker niet AES.

[Jace / TBL]

bitcoin mining ook een vorm van encrypty kraken

Welnee, aan Bitcoin komt helemaal geen encryptie te pas.

Cryptografie, ja. Encryptie, nee. De beveiliging van bitcoins zit hem in ECDSA, een wiskundig algoritme om digitale handtekening te zetten. En het minen gaat om het bruteforcen van (gedeeltelijke) SHA256 hashes. Allebei iets heel anders dan encryptie, en ook niet 'kraken'.

Super computers ofwel dikke cpu is echt achterhaald.

Qua rekenkracht doen die ASICs het beter, sure. Maar ze zijn ook veel beperkter. CPUs en GPUs kunnen in principe alles, ASICs zijn specifiek gebouwd voor een bepaalde operatie (die ze dan wel heel snel kunnen). Al die Bitcoin mining ASIC hardware waar de nodige miljoenen in zijn gestoken kunnen maar één ding: SHA256 hashes berekenen.

Overigens is een volledige SHA256 hash bruteforcen (dus niet alleen de eerste zoveel digits zoals bij Bitcoin), net als AES-256 bruteforcen, vooralsnog in de verste verte niet mogelijk.

Als AES-256 al 'zwaar onder druk' zou liggen, zou dat komen door later ontdekte zwaktes of gaten in het algoritme, en niet omdat het kan worden gebruteforced. Het grootste tot nu toe bekende 'gat' reduceert de bruteforce zoekgrootte met ongeveer 2 bits: artikel. De hyperige titel ten spijt ("aes cracked" ) is dat totaal insignificant. Er zijn nog wat andere theoretische en gedeeltelijke attacks bedacht, maar daarvan is er naar mijn weten tot nu toe geen één concreet toepasbaar (bijvoorbeeld "13 van de 14 rounds van AES-256" klinkt als "bijna gekraakt" maar in de praktijk kun je daar nog steeds niets mee).

(edit) oh, spuit 11 zie ik.

[Reactie gewijzigd door Jace / TBL op 24 juli 2024 06:14]

[YopY]

Het lijkt me (ook gezien het artikel) dat als je een random string aan de aangevraagde URLs toevoegt (zoals een session ID zoals veel sites al doen), de verzamelde gegevens / patronen alweer ongeldig worden; een soort salting voor passwords.

[BRAINLESS01]

Ik denk niet dat ze zozeer kijken naar de data, maar naar de metadata. Dus hoe groot is het antwoord van de server en hoe snel kwam de server met dat antwoord? Als alle pagina's heeft op een server van verschillende groottes zijn dan kun je alleen daarmee al een goede inschatting maken van welke pagina een gebruiker opgevraagd heeft.

Je kunt daarmee nog steeds de tekst niet lezen, maar je weet wel wat de gebruiker ongeveer ziet.

[Tozz]

Nee. Het artikel stelt dat de opgevraagde pagina's bepaald kunnen worden met 89% zekerheid. Het toevoegen van een sessie ID wijzigd de opgevraagde URL (GET/POST request), maar dat zal in 9 van de 10x weinig tot geen effect hebben op de pagina die utieindelijk teruggestuurt wordt.

Er kan een minime wijziging zijn in de pagina doordat bv. een andere 'Hallo <username>' wordt geparsed, maar verder zal bijvoorbeeld een forum thread ongeaacht welke user die opvraagt nagenoeg hetzelfde zijn.

[Goderic]

Moderne encryptie is zo gemaakt dat dercrypteren onmogelijk. Zelfs als je als aanvaller kan kiezen welke data er versleuteld wordt kan hij hierdoor niet de sleutel of andere berichten achterhalen. Enkel de lengte van je bericht kan hij achterhalen als de data niet gepadded is. En soms is dat dus al genoeg.

[Joolee]

Een man in the middle, die het verkeer van een internetgebruiker onderschept, is normaliter niet in staat om te zien welke pagina's over https worden bezocht. Enkel de domeinnaam waarmee verbinding wordt gemaakt, is zichtbaar. De get-request zelf, waarin de opgevraagde pagina is opgenomen, wordt over ssl/tls verstuurd.

Zover ik weet is aan een HTTPS packet enkel het destination IP te achterhalen. Het opgevraagde domein en de opgevraagde pagina staan beide binnen de encrypted body van de request.

Dit vormt overigens een probleem voor hostingproviders omdat pas bekend is welke domeinnaam er wordt opgevraagd zodra het HTTPS package is decrypted. Om het HTTPS packet te decrypten moet het certificaat van het juiste domein bekend zijn Om die reden heeft elk domein dat https gebruikt een eigen ip adres nodig.

[Dysmael]

Er kunnen meerdere domeinen worden gehost op één IP waarbij elk domein een eigen certificaat heeft. Dat kan door de implementatie van Server Name Indication. De opgevraagde host (domeinnaam) is onderdeel van de TLS handshake en gewoon leesbaar.

Zie RFC3546 en RFC6066

• Specifically, the extensions described in this document:
  
  - Allow TLS clients to provide to the TLS server the name of the
  server they are contacting. This functionality is desirable in
  order to facilitate secure connections to servers that host
  multiple 'virtual' servers at a single underlying network address.

En zie dit topic op GoT voor wat screenshots van Wireshark die ik heb gemaakt ter onderbouwing:
http://gathering.tweakers.net/forum/list_message/41891186

[Reactie gewijzigd door Dysmael op 24 juli 2024 06:14]

[Sorcerer8472]

Als ik een verbinding maak met 167.202.214.30 dan is de kans vrij groot dat ik abnamro.nl bezoek en niet een andere bank. Ik snap niet wat het grote punt is; het IP geeft vaak meer weg. En ja, ik heb het artikel gelezen en begrijp dat dit er ook al in staat. Alleen snap ik dus niet waarom het zo bijzonder is. Wellicht mis ik toch iets.

Wat betreft patronen is het ook logisch: je hebt de website, images die hij moet laden (+ size van alles met name) en latencypatronen. Ik vind de uitkomst hiervan dus niet verrassend, maargoed, het is nu in ieder geval wetenschappelijk onderzocht en met deze uitkomsten kan wellicht wat worden gedaan. De vraag is of datgene heel nuttig is...

[Reactie gewijzigd door Sorcerer8472 op 24 juli 2024 06:14]

[TRON]

Het gaat er ook om dat men nu met enige zekerheid kan bepalen welke pagina's je hebt bezocht.

In jouw voorbeeld, bezoek je bij ABN-AMRO:
- internetbankieren?
- lening afsluiten?
- schuld sanering?
- etc.

[TheKmork]

Ik denk dat je dit in een iets ander licht moet zien. Denk bijvoorbeeld aan datingsites. Men kan sowieso al zien dat je connectie maakt met de site, maar wat men dan met deze techniek ook zou kunnen achterhalen is welke pagina's op deze site je bezoekt (ofwel in dit voorbeeld welke profielen je bekijkt).
Hoewel dit genoemde voorbeeld (naast een schending van de privacy) niet heel veel schade kan doen, zijn er ongetwijfeld wel voorbeelden te bedenken waar dit minder gewenst is.

Daarnaast moet ik wel aankaarten dat het vrij paranoïde is om, zoals in het artikel gesteld wordt, er vanuit te gaan dat je baas een hele database aan het aanleggen is met al het gedrag van alle werknemers en daar een profiel van op te stellen. Werkgevers zullen meer geïnteresseerd zijn naar welke domeinen de medewerkers gaan (om eventueel te kunnen filteren), niet naar dergelijke diepgaande specifics.

[poor Leno]

Hmtsja.. Het enige positieve gevoel wat er nu bij me opkomt, is dat er nu wat aan gedaan kan worden..

Maar ja tegen die tijd zijn we ook weer veel verder..

[Wampa1]

Ook een voordeel is dat het dus blijkbaar niet de makkelijkste handeling is om te verrichten. Het zal de echt technisch onderlegde mensen dus niet tegenhouden, maar het is niet iets wat je baas zal gaan doen in ze vrije tijd lijkt me ^^.

[Whatts]

Maar het zou bijvoorbeeld misschien wel in een proxy ingebouwd kunnen worden, waardoor de baas enkel de juiste proxy-software moet (laten) aankopen en installeren.

[migchiell]

Precies, je baas hoeft dit niet zelf te doen, die krijgt binnenkort een vlotte sales-manager over de vloer die hem de diensten van een stel handige IT-ers aanbiedt, en die geven hem gewoon een maandelijkse rapportage van de sites die zijn personeel heeft bezocht.

[Enai]

Oplossing: BYOD.

[DLGandalf]

Het is een man-in-the-middle attack, of je nou je eigen machine of een gekregen machine in het netwerk plaatst maakt dus weinig uit. Tenzij je bedoelt dat je je eigen machine met een alternatieve TLS/browser implementatie uitrust die de bovengenoemde technieken zoals padding e.d. gebruikt.

[DeVins]

Dit gebeurd natuurlijk al op grote schaal

[Bunga]

Een dure oplossing als het domain niet encrypted is. Wat boeien die individuele pagina's als je al weet dat je naar https://verbodensite.com surft.

De homepage kan ik er waarschijnlijk ook zo uit halen. Die is over het algemeen voor iedereen hetzelfde, als je dan kijkt naar de grootte en frequentie dan lukt dat wel met statistieken. Maar dan heb je nog altijd niet de inhoud gezien en dat is in het artikel ook zo.

[Fermion]

Hoe moeilijk kan dat zijn, de IP headers zijn namelijk niet encrypted. Je weet in elk geval waar het verkeer naar toe gaat, dan is het alleen nog achterhalen welke websites achter dat adrez schuil gaat. Je vergaart alle zone records op, zover dat nog een server toestaat, of je vraagt bij de IP registrar informatie van de organisatie op van het desbetreffende IP. Maar de inhoudt van het versleutelde verkeer is dan bog steeds niet te achterhalen, het is en blijft encrypted.

[bartvb]

Dat is juist het punt van het artikel. IP adres (en dus website) zijn makkelijk te achterhalen. Nu blijkt echter dat je op basis van de versleutelde HTTP sessie af kan leiden welke specifieke pagina's op die site worden opgevraagd.

[notsonewbie]

Veel werk zo een foot-print database aanleggen en dan ook nog per voorval iemand, net life actief, zien te koppelen als _de_ gebruiker van website x, vanaf bedrijfsnetwerken dan.

Wellicht daarvoor ook (alsmede, eveneens) die ddos aanvallen indertijd, zo veel mogelijk websites minimaal 500 keer bezoeken geautomatiseerd en 'indexeren die httpS hap'.

[Ossebol]

In hoeverre is deze methode van toepassing om het gedrag van een TOR-gebruiker te analyseren? Want ook dat is uiteindelijk te herleiden naar een individu, hetzij veel lastiger natuurlijk.

[Tunaflish]

De onderzoekers tekenen aan dat bezochte pagina's indicaties kunnen geven van iemands seksuele voorkeuren, financiële situatie en medische problemen. Onder meer werkgevers, die immers de internetverbinding van hun medewerkers beheren, zouden daarvan misbruik kunnen maken, stellen de onderzoekers.

Misschien moet je dan geen porno bekijken op je werk

[Verwijderd]

Om daar achter te komen hoef je natuurlijk geen ingewikkeld onderzoek te doen.
Daarvoor hoef je alleen de meta-data te onderzoeken (zoals met welke website je verbinding legt).

[Techneut]

Zou eigenlijk niet nodig moeten zijn zo'n opmerking, lijkt me logisch.
Toen wij jaren geleden op ons werk nog niet zo lang een internetverbinding hadden (begin jaren '90), kregen we het verbod opgelegd om de verbinding nooit anders te gebruiken dan wat met ons werk te maken had. Bijvoorbeeld een website van een leverancier waar we zaken mee deden. Alle contacten konden achteraf worden bekeken en afhankelijk van de ernst van een geconstateerde overtreding waren sancties mogelijk variërend van afgesloten worden van internet tot niet nader te noemen strenger maatregelen.

In die tijd bezocht ik een lezing van IBM over virussen, toen voor het grote publiek nog een tamelijk nieuw fenomeen. De man die ons het een en ander uitlegde vertelde dat hij een bedrijf kende waar mensen op staande voet ontslagen werden als op hun computer op het werk een virus werd geconstateerd. Toen (let wel toen!) werd blijkbaar gewoon gesteld dat bij normaal zakelijk verkeer een virus uitgesloten was. Toch een virus betekende "dus" misbruik.
Zo'n constatering als wat Tunaflish noemt in bovenstaande reactie zou denk ik bij dat bedrijf ook wel tot ontslag hebben geleid.

[HMC]

Pr0n gaat via de TOR natuurlijk.

Is het niet zo dat een site zelf bepaalt of het via https wordt aangeboden?
Kan je een site zelf (bv tweakers.net) in een https sessie starten? Niet voor zover ik weet.

[indigo79]

Is het niet zo dat een site zelf bepaalt of het via https wordt aangeboden?
Kan je een site zelf (bv tweakers.net) in een https sessie starten? Niet voor zover ik weet.

In principe bepaalt de configuratie van de webserver of een site via http of https wordt aangeboden, maar in veel gevallen (tweakers.net onder andere) worden beide ondersteund. In dat geval krijg je via "https://tweakers.net" een versleutelde pagina.

Er zijn trouwens ook plugins (HTTPS Everywhere voor Firefox bijvoorbeeld) die je automatisch doorsturen naar een beveiligde pagina als die ondersteund is (op basis van regels of door even te checken of er op https ook een antwoord komt; vooral dat laatste werkt niet altijd even goed: ik heb al gemerkt dat je op bijvoorbeeld Flickr geen favorieten kan (of kon intussen?) aanduiden via https).

[derkesthai]

Zorgen dat de browser een flinke dosis willekeurige onzin in de request meestuurt (welke uiteraard door de server genegeerd moet worden...) dan lijkt geen enkele request naar dezelfde pagina meer op elkaar toch?

[Upp3rd0G]

Offtopic, maar wel interessant (naar mijn idee...)

http://it.slashdot.org/st...mitm-attacks-on-employees

+ interessante link over hetzelfde topic via afzichtelijke jaren-90 site van Steve Gibson:

https://www.grc.com/fingerprints.htm

Verplichte leesvoer voor een ieder die wel eens privé activiteiten doet tijdens werktijd.