Ik zal eerst wat inhoudelijk reageren en daarna de wat nuttelozere delen van de post behandelen;
Anders probeer je gewoon op een normale manier te reageren
Dit impliceert dat er iets abnormaals is aan mijn reactie, ik kan me niet vinden in die lezing.

Daarnaast een leuke poging om te proberen de put te vergiftigen door te stellen dat mijn reactie is zoals die is omdat het om Apple gaat, helaas moet ik je echter informeren dat dit niet het geval is; mijn reactie is zoals die is vanwege de onzin die je schreef en niets anders.

Om op je provider-verbinding DNS verkeer af te luisteren gaat het wel degelijk om een MITM aanval, dat staat voor 'Man in the Middle' namelijk, dat hoeft niet direct om het manipuleren van verkeer te gaan.
Oh ik dacht dat het voor Malcolm in the Middle stond, my bad. Is Man in the Middle ook een leuke serie? Anyway, in de context van het artikel: voor passieve eavesdropping, waar men het in het artikel de godganse tijd over heeft, is op geen enkele wijze een MitM-aanval nodig. Waarom zou je immers in vredesnaam een MitM uitvoeren voor actieve eavesdropping binnen een netwerk zonder isolation?
Daarnaast, zoals het artikel ook netjes schrijft - en jij ook gelezen hebt getuige een reactie aan iemand anders hier, heeft men het ook over de ISP als adversary. En daar kan je je wel degelijk tegen beschermen als je dat wil via bijvoorbeeld Private Relay of een andere VPN-dienst. Wederom dus een uitspraak in dat artikel die volkomen terecht gemaakt wordt en in die context volledig accuraat is; niets misleidend aan.

A: Onzin, Apple is degene met wie je de encryptie opzet ...
Enkel voor het ingress gedeelte (je communicatie met de relay server van Apple). Immers is het verkeer tussen jou en Apple's relay server uiteraard netjes versleutelt, zou wat zijn als dat plain-text is. Maar voor jouw versleuteling met de egress heeft Apple's relay server geen vinger in de pap en is dus voor dat stukje van de communicatie NIET de gene met wie je de encryptie opzit of namens jou dat doet. Dat zal ik hierna uitleggen:
Apple's servers zetten de encryptie op, de encryptie voorkomt dus niet afluisteren door Apple aangezien Apple dan de encryptie zou kunnen verzwakken/uitschakelen/decrypten met de sleutel die ze zelf genereren.
Nope, dit klopt niet. Je device zet de encryptie zelf op. Apple's servers krijgen geen privésleutels in bezit*. De key-exchange wordt geïnitieerd op jouw device, deze gaat vervolgens via de relay (ingress) van Apple naar de third-party provider (egress) nadat het verkeer gescrubt is. De third-party provider stuurt het versleutelde verkeer terug naar jou device, via de relay van Apple, en je device ontsleutelt het verkeer weer met zijn private key.
Het schema voor een request met antwoord is:
Device -> Apple relay (ingress) -> third-party provider (egress) -> bestemming -> third-party provider -> Apple relay -> Device. En in elke stap zit encryptie, een beetje als laagjes zoals we dat kennen van onion (om het misschien in een wat begrijpelijkere context te zetten als referentiekader.) Hierbij is de verbinding tussen alle endpoints onderling versleuteld, maar geniet je daarnaast ook van end-to-end encryptie met de egress; er is dus sprake van een dubbele vorm van encryptie over de lijn zelf.
Qua versleuteling verloopt dat dus ongeveer zo (basaal uitgelegd om een plaatje te vormen):
- iDevice versleutelt het verzoek aan de egress met de
pubkey A van de egress
- iDevice versleutelt dit versleutelde pakketje vervolgens met de
pubkey B van de ingress en stuurt het naar de ingress
- Ingress ontsleutelt het pakketje bedoelt voor zichzelf met
privésleutel B en verwijdert het laagje encryptie tussen jou en de ingress server dus. (
Privésleutel A heeft het niet, dus het pakketje aan de egress blijft netjes versleutelt; dat laagje blijft onaangetast.) Het versleutelt dit versleutelde pakketje bedoeld voor de egress met de
pubkey C van de egress en stuurt het op.
- Egress ontvangt het pakketje van de ingress en ontsleutelt deze met
privésleutel C. Het ziet nu het versleutelde pakketje van jouw iDevice en decrypt deze met
privésleutel A. Nu weet het wat je van de egress wilt en handelt dit verzoek af met je bestemming. De egress versleutelt de respons vervolgens met jouw
pubkey D. Om de communicatie met de ingress ook versleutelt te houden, versleutelt de egress het versleutelde pakketje voor jou met
pubkey E van de ingress en stuurt het op.
- De ingress ontvangt de respons van de egress en ontsleutelt deze met
privésleutel E. Het ziet nu het versleutelde pakketje dat voor jou bedoeld is (maar kan deze niet ontsleutelen.). De ingress versleutelt dit pakketje met jouw
pubkey F om de communicatie tussen jou en de ingress te versleutelen en stuurt het naar je op. Jij ontsleutelt dit pakketje met
privésleutel F en krijgt nu de versleutelde respons van de egress te zien. Deze ontsleutel je met
privésleutel D. Voila, je hebt nu het resultaat.
In deze gehele procedure is het resultaat dus dat zowel de endpoints als de tussenliggende PR-hops versleutelt met elkaar babbelen. De ingress kent jou als "origin", maar weet niet wat je bestemming is. De egress weet niet wie de origin is, maar weet wel wat de bestemming is. Apple's private relay servers kunnen niet zien wat jij inhoudelijk uitwisselt met de egress. Apple heeft daar de sleutels immers niet voor, die staan op je iDevice. (iPhone, iPad, Mac, whatever.)
De bewering van jou dat het Apple's dienst is die de versleuteling tussen jou en de egress opzet is niet waar, dat is namelijk mere conduit van encrypted verkeer dat lokaal op je apparaat wordt beheerd; onderling zet Apple wel de versleuteling tussen ingress en egress op, maar dat boeit niet zoveel voor het pakketje tussen jou en de egress. (Sterker nog, zelfs als iemand het voor elkaar krijgt om het encryptielaagje van de ingress te ontsleutelen moeten ze ook nog het laagje tussen device en egress zien te decrypten... Als iemand ingress' verkeer weet af te tappen kunnen ze de bestemming nog altijd niet zien.)
* = tenzij de functie binnen iOS al rigged zou zijn. Maar dat zou heel erg snel boven water komen.
En dat zou Apple _heel_ erg veel gezeik opleveren.B: De derde partij weet net zoals normaal alleen jouw publieke IP en trackt deze nog maar nauwelijks, tegenwoordig worden tracking-pixels en andere Javascript technieken gebruikt. Tracking puur op IP basis is al weer heel wat jaartjes geleden en hier helpt een VPN/Apple PR niet tegen tenzij PR nu ineens agressief bepaald trackings-verkeer gaat herkennen en blokkeren.
De derde partij weet helemaal jouw publieke IP niet, want dat is nou net het hele doel van die ingress relay van Apple.

C: Duplicaat van punt B?...
Als je het verschil niet weet tussen de egress server en je bestemming, dan is het een duplicaat van Punt B ja.

Maar ik ga het niet nog een keer uitleggen als je het niet erg vindt, lees het nog maar een keer; misschien snap je het dan beter.

ik wil best uitleggen hoe dit werkt en waarom dit je niet beveiligt tegen afluisteren door Apple maar dan is het handiger een topic op GoT over encryptie te starten

Met alle respect, maar als ik een (opfris)cursus in hoe encryptie werkt zou willen hebben dan vraag ik het liever aan iemand waarvan ik zeker weet dat die persoon er verstand van heeft - sorry. Maar toch bedankt voor het aanbod!

Houdt de quotes dus eens binnen hun verband
Haha, dat is een wel erg ironische uitspraak. Jij citeert iemand, verandert zonder dit duidelijk te vermelden blijkbaar de context daarvan, verzint daar dan iets bij en zegt vervolgens dat de auteur van die uitspraak misleidende uitspraken heeft gedaan, omdat het niet klopt in de context die jij er zelf bij verzonnen hebt.

Je kan de auteur van de originele uitspraak die prima klopt binnen de originele context toch niet kwalijk nemen dat het misschien of deels niet klopt in een compleet andere context die jij er bij zet?
Overigens weet ik nog steeds niet helemaal wat jouw context dan was, maar ik vermoed dat je dan misschien bedoelde "in de context van dit Tweakers-artikel". Dan was de uitspraak overigens ook niet misleidend, immers was die niet gemaakt in die context. En zelfs in die context kán het wel kloppen; zeker omdat, zoals je zelf ook weet

, meneer het verderop ook heeft over een ISP als adversary zien... Je had dan misschien iets kunnen zeggen als "Die uitspraak klopt bij dat artikel, maar in de context van mobiele providers moet je dat anders zien want blablabla"; dan viel er misschien nog (deels) iets voor te zeggen. Nee, jij zegt gewoon point-blank dat het een misleidende uitspraak is (dus zelfs binnen de originele context), en herhaalt dat nu nog eens in je reactie aan mij ("... eens dat Apple's statement dat dit het veilig maakt misleidend is"). Dat slaat gewoon echt nergens op wat mij betreft.
Helemaal mee eens
Fijn om te lezen dat je het er mee eens bent dat jouw lezing van het artikel nergens op slaat en je niet zomaar je eigen context/betekenis van een uitspraak in de mond van een ander mag leggen; al helemaal niet als die ander de context helder benoemd heeft.

blij dat we het daar over eens zijn dat Apple's statement dat dit het veilig maakt misleidend is.
Apple's statement dat het verkeer in de context van lokale adversaries (zoals publieke WiFi-operators, gebruikers op hetzelfde netwerk of ISP's) beter beveiligd kan zijn, is gewoon volledig accuraat. Niets aan gelogen, niets misleidend aan.

Dus nee, we zijn het er totaal niet over eens dat dat statement ook maar op enige wijze misleidend is.
De manier waarop het beschreven staat in dat artikel, zoals ik hierboven ook al uitgebreid uitleg, is gewoon spot-on. Dat jij het in je hoofd uit verband rukt en er een andere betekenis aan wil geven om je persoonlijke mening te botvieren is leuk voor jou, maar zo werkt het niet en dat is niet wat er in het artikel staat; al helemaal de zaken niet die je erbij verzint. Citeer me anders maar waar Apple stelt dat gebruikers binnen jouw lokale netwerk eerst een MitM-aanval moeten opzetten om je plain-text DNS verkeer te sniffen.

Hou alsjeblieft op met op een Forum FoK manier te reageren en ga gewoon op een normale manier de discussie aan, stel vragen waar je dingen niet begrijpt en laat het hele denigerende toontje even achterwege, vooral omdat je het zelf op een aantal punten gewoon fout hebt, zou je sieren.
Ik zou oprecht wensen dat
jij vragen zou stellen als je iets niet begrijpt, in plaats van boos te worden als je aangesproken wordt op de fouten in je post die je presenteert als feiten en dan net doet alsof de rest gek is.

Ik heb m'n posts overigens nog eens doorgelezen en kan mezelf niet betrappen op fouten, maar mocht je ze aan kunnen wijzen dan hoor ik dat natuurlijk graag - ik sta namelijk wél open voor feedback en ben, zo nodig, wél bereid fouten toe te geven en daarvan te leren. Ik heb ook best veel geschreven dus wie weet heb ik inderdaad ergens een zeldzame fout gemaakt die buiten mierencopuleren om werkelijk problematisch is.
Hoop dat je iets leert van de uitleg in plaats van zo boos en defensief te worden.

In ieder geval bedankt voor de moeite die je neemt om te proberen iets zinnigs te posten!
-edit- Typo fix en mark-up voor schema's toegevoegd
[Reactie gewijzigd door WhatsappHack op 23 juli 2024 12:24]