Privacy en je internetprovider?

[privacy1234]

De laatste tijd heb ik me verdiept in privacy en ben ik me er meer van bewust hoe online diensten omgaan met de privacyrechten van klanten/bezoekers. Een andere observatie is dat het veel mensen niet uitmaakt wat er van ze wordt verzameld.

Ik ben recent overgestapt naar een nieuwe provider, en dat heeft me aan het denken gezet: hoelang bewaren providers je internetgegevens? Ik weet dat providers een log bijhouden met welke IP-adressen je hebt en welke domeinen worden bezocht.

Maar als je bijvoorbeeld 5 jaar ergens klant bent geweest en vervolgens overstapt, heeft het toch geen zin meer om deze gegevens te bewaren? Kan iemand mij hier meer over vertellen?

Waar ik blij mee ben is dat Europa een van de voorlopers is wat betreft privacy, en hopelijk blijft dat zo! Het is een recht waarvan veel mensen zich niet bewust zijn. Helaas wordt het verzamelen van data gezien als normaal.

[SVMartin]

Ik ken de huidige status niet, maar je doelt waarschijnlijk hier op?

nieuws: Minister beperkt bewaarplicht tot identificerende gegevens na uitspra...

Verder is je isp verplicht om een financiële boekhouding te hebben met klantregistatie, facturatie en betaalgegevens. Die moet 10 jaar bewaard worden.

Meer info vind je waarschijnlijk ook in de privacy voorwaarden van je vorige isp.

[ Voor 29% gewijzigd door SVMartin op 01-04-2024 21:17 ]

[JukeboxBill]

10 seconden zoeken en je weet (een groot deel van) het antwoord:
https://www.vpngids.nl/pr...nternetprovider-over-jou/

[DukeBox]

JukeboxBill schreef op maandag 1 april 2024 @ 21:19:
10 seconden zoeken en je weet (een groot deel van) het antwoord:
https://www.vpngids.nl/pr...nternetprovider-over-jou/

Jouw internetprovider kan zien wat jij online doet. Wil je anoniemer browsen? Dat kan met behulp van een VPN. Een VPN versleutelt je internetverbinding en beschermt je IP-adres tegen nieuwsgierige internetproviders.

Niet direct als reactie op JukeboxBill maar meer in zijn algemeen.

Het meest mooie vind ik nog dat je nu dat punt verlegt naar de VPN provider, dus voor beveiliging/privacy schiet je niet heel veel mee op. Sterker nog, sommige VPN providers leveren mooie tools mee om de verbinding op te zetten, voor het zelfde geld zit daar meteen SSL termination in verwerkt en/of DNS injection.

Dan ga ik liever gewoon via mijn eigen provider met eigen keuze in DNS, controle over SSL etc. Wil ik om een of andere reden iets voor mijn provider afschermen dan doe ik dat wel met een VPS en een eigen tunnel.

[ Voor 3% gewijzigd door DukeBox op 15-04-2024 07:49 ]

[SVMartin]

Sorry, maar dat is wat mij betreft niet een objectieve informatiebron, men wil hier vooral von verkopen.

[JukeboxBill]

Wat is er dan niet objectief aan?
Als je even verder scrollt, staat daar wat providers wettelijk verplicht zijn en wat ze mogen doen.
De website zelf verkoopt geen VPN, maar is o.a. een vergelijkingssite.
Dan zou ook niemand meer gaslicht.com e.d. mogen noemen in dit forum.

[CodeCaster]

JukeboxBill schreef op maandag 1 april 2024 @ 21:33:
Wat is er dan niet objectief aan?
Als je even verder scrollt, staat daar wat providers wettelijk verplicht zijn en wat ze mogen doen.
De website zelf verkoopt geen VPN, maar is o.a. een vergelijkingssite.
Dan zou ook niemand meer gaslicht.com e.d. mogen noemen in dit forum.

quote: https://www.vpngids.nl/pr...nternetprovider-over-jou/

Een internetprovider kan al jouw onvergrendelde internetverkeer zien, ook als je je thuisnetwerk zo goed mogelijk beveiligt. Denk aan e-mails die je verstuurt en websites die je bezoekt. De websites die jij bezoekt vragen je om het gebruik van cookies te accepteren. Cookies optimaliseren jouw gebruikerservaring en zorgen ervoor dat jij gepersonaliseerde advertenties te zien krijgt.

Niet alleen op websites, maar ook op social media kan jouw internet provider cookies opslaan. Je krijgt zo ook gepersonaliseerde advertenties te zien op social media.

Je hoeft gelukkig niet bang te zijn dat je internet provider meeleest met je chatgesprekken. WhatsApp-berichten zijn beveiligd met end-to-end-encryptie en dus niet zichtbaar voor je internetprovider. Deze versleutelde gegevens zijn alleen door zender en ontvanger te zien.

De door je internetprovider verzamelde gegevens kunnen worden samengevoegd in dossiers. Deze dossiers kunnen zelfs adressen, financiële gegevens en informatie over je gezondheid bevatten.

Wat een ongefundeerde bangmakerij zeg.

Er wordt al decennia lang geen onversleutelde mail meer verstuurd, en de meeste mail loopt toch echt niet via providers, maar externe partijen. En je provider plaatst geen cookies op andermans websites. Wat een onzin.

[ Voor 8% gewijzigd door CodeCaster op 01-04-2024 21:40 ]

[sypie]

Dat is inderdaad een boel onzin bij elkaar. Een provider die allerlei gegevens van jou in een dossier stopt? Volgens mij heeft een ISP een andere taak dan een dossier van iedere klant opbouwen. Laat dat maar aan de socials over.

[privacy1234]

Ik heb de VPN website snel doorgelezen, maar ik word er niet wijzer van. Je komt tegenwoordig bijna geen website meer tegen die HTTP gebruikt. Ik heb gekeken naar het privacystatement van Ziggo, maar daar kon ik niet snel antwoord vinden op mijn vragen.

Vandaar dat ik hem hier stel, omdat er hier mensen zitten met meer kennis dan ik over dit onderwerp.

[lol_anarchist]

*knip* Zo'n bold statement maken zonder verdere onderbouwing of bronnen is niet de bedoeling op Tweakers.

[ Voor 91% gewijzigd door rens-br op 02-04-2024 13:42 ]

[jimmy87]

zo makkelijk werkt dat niet gelukkig Dat hebben meerdere providers al meermaals bewezen geloof ik.

Ik hoef aan een Ziggo / KPN etc echt niet te gaan vragen welk ip jij 5 jaar gelden had, dan krijg ik toch keihard een deksel op mijn neus.

[privacy1234]

*knip*

[ Voor 99% gewijzigd door rens-br op 02-04-2024 13:42 ]

[99ruud99]

Wettelijk gezien moeten ze het 5 jaar bewaren. In praktijk wordt er 1x per jaar vernietigd, dus zal er max 6 jaar bewaard worden.

Het kost een isp enkel geld om die database oneindig te bewaren.

Facturatie moet 10 jaar bewaard worden, van de belastingdienst.

Als je wilt kan je altijd een inzage verzoek doen bij je provider over welke gegevens ze van je hebben.

[Boudewijn]

lol_anarchist schreef op dinsdag 2 april 2024 @ 00:48:
*knip*

*knip*

[ Voor 73% gewijzigd door rens-br op 02-04-2024 13:41 ]

[privacy1234]

99ruud99 schreef op dinsdag 2 april 2024 @ 07:00:
Wettelijk gezien moeten ze het 5 jaar bewaren. In praktijk wordt er 1x per jaar vernietigd, dus zal er max 6 jaar bewaard worden.

Het kost een isp enkel geld om die database oneindig te bewaren.

Facturatie moet 10 jaar bewaard worden, van de belastingdienst.

Als je wilt kan je altijd een inzage verzoek doen bij je provider over welke gegevens ze van je hebben.

Ik kan nergens vinden dat ze wettelijk gezien je gegevens 5 jaar moeten bewaren. Heb je een link met meer informatie? Ik ben namelijk best benieuwd naar de wetten voor dataopslag.

[99ruud99]

Archiefwet1995 voor Nederland,
Voor België moet ik even zoeken, maar gezien je Ziggo noemde neem ik aan dat je NL zoekt.

[privacy1234]

99ruud99 schreef op dinsdag 2 april 2024 @ 07:12:
Archiefwet1995 voor Nederland,
Voor België moet ik even zoeken, maar gezien je Ziggo noemde neem ik aan dat je NL zoekt.

Als ik dat zo snel lees, gaat het over informatie van overheidsinstanties. Dat is wat anders dan een ISP, denk ik?

[99ruud99]

Klopt, maar dat is de basis voor bedrijven. Ik zou moeten opzoeken hoe de wet exact heet. Dat weet fopjurist beter.

https://www.eerstekamer.n...el/31145_wet_bewaarplicht
Is het deze niet?

[ Voor 26% gewijzigd door 99ruud99 op 02-04-2024 07:19 ]

[privacy1234]

99ruud99 schreef op dinsdag 2 april 2024 @ 07:17:
Klopt, maar dat is de basis voor bedrijven. Ik zou moeten opzoeken hoe de wet exact heet. Dat weet fopjurist beter.

https://www.eerstekamer.n...el/31145_wet_bewaarplicht
Is het deze niet?

Volgens mij is die wet aangepast: er wordt alleen nog essentiële informatie opgeslagen. Ik neem aan dat ze daarmee je IP-adres en persoonlijke gegevens (NAW-gegevens( bedoelen.

[ Voor 17% gewijzigd door privacy1234 op 02-04-2024 07:46 ]

[Ulster Seedling]

SVMartin schreef op maandag 1 april 2024 @ 21:16:
Verder is je isp verplicht om een financiële boekhouding te hebben met klantregistatie, facturatie en betaalgegevens. Die moet 10 jaar bewaard worden.

99ruud99 schreef op dinsdag 2 april 2024 @ 07:00:
Facturatie moet 10 jaar bewaard worden, van de belastingdienst.

Volgens mij is dit (in principe) 7 jaar: https://www.belastingdien...en/administratie_bewaren/

[jurroen]

Wauw. Wat een berg aan nutteloze (mis)informatie. Ik had gehoopt dat we dat op Tweakers wel beter zouden doen, maar helaas.

Uiteraard heeft de genoemde site (VPNgids) wel degelijk commercieel baat bij bangmakerij. Dit is affiliate marketing 101. Ze krijgen commissies bij de verkopen van abonnementen, door traffic vanaf hun site te 'funnelen'.

Als je de DNS servers én mail van je provider gebruikt, kunnen ze in theorie meekijken met de websites die je bezoekt. Onder die websites vallen bijvoorbeeld: pornhub.com en login.huisarts.nl. Maar wat daar niet onder valt is bijvoorbeeld huisarts.nl/faq/help/ik-heb-een-soa. Bij e-mail kunnen ze uiteraard alles zien. Althans, in theorie.

Als je een andere DNS provider gebruikt, zéker een met DoH/DoT/DNScrypt kan je provider dat uiteraard niet meer zien. Maar pas wel op: je lost hiermee geen probleen op, maar verlegt het. Stel dat je Google DNS gebruikt kan Google het (in theorie) zien.

Zelfde voor e-mail. Het is niet oplossen, maar verleggen van het probleem.

Maar ... moeten providers je dataverkeer bijhouden en zijn ze daarbij gebaat? Ik zou zeggen van niet. In tegenstelling tot in de VS mogen ze die data niet verzamelen voor marketingdoeleinden of verkoop. Als KPN alle DNS requests bijhoud zitten ze op terabytes per dag. En dat was een jaar of tien geleden. Veel opslag zonder dat het iets oplevert.

Wettelijk gezien moet de administratie zeven jaar bewaard worden. Maar dat gaat om facturen en financiele informatie. Niet om jouw IP.

Wél moet elke provider continu gegevens delen met het CIOT: NAW, IP adres, eventuele telefoonnummers én mailadressen die je van de provider afneemt. Maar ook daar dus niet websites die je bezoekt, mails die je verstuurd etc.

[Duke of Savage]

lol_anarchist schreef op dinsdag 2 april 2024 @ 00:48:
*knip*

*knip*

[ Voor 72% gewijzigd door rens-br op 02-04-2024 13:41 ]

[privacy1234]

jurroen schreef op dinsdag 2 april 2024 @ 11:29:
Wauw. Wat een berg aan nutteloze (mis)informatie. Ik had gehoopt dat we dat op Tweakers wel beter zouden doen, maar helaas.

Uiteraard heeft de genoemde site (VPNgids) wel degelijk commercieel baat bij bangmakerij. Dit is affiliate marketing 101. Ze krijgen commissies bij de verkopen van abonnementen, door traffic vanaf hun site te 'funnelen'.

Als je de DNS servers én mail van je provider gebruikt, kunnen ze in theorie meekijken met de websites die je bezoekt. Onder die websites vallen bijvoorbeeld: pornhub.com en login.huisarts.nl. Maar wat daar niet onder valt is bijvoorbeeld huisarts.nl/faq/help/ik-heb-een-soa. Bij e-mail kunnen ze uiteraard alles zien. Althans, in theorie.

Als je een andere DNS provider gebruikt, zéker een met DoH/DoT/DNScrypt kan je provider dat uiteraard niet meer zien. Maar pas wel op: je lost hiermee geen probleen op, maar verlegt het. Stel dat je Google DNS gebruikt kan Google het (in theorie) zien.

Zelfde voor e-mail. Het is niet oplossen, maar verleggen van het probleem.

Maar ... moeten providers je dataverkeer bijhouden en zijn ze daarbij gebaat? Ik zou zeggen van niet. In tegenstelling tot in de VS mogen ze die data niet verzamelen voor marketingdoeleinden of verkoop. Als KPN alle DNS requests bijhoud zitten ze op terabytes per dag. En dat was een jaar of tien geleden. Veel opslag zonder dat het iets oplevert.

Wettelijk gezien moet de administratie zeven jaar bewaard worden. Maar dat gaat om facturen en financiele informatie. Niet om jouw IP.

Wél moet elke provider continu gegevens delen met het CIOT: NAW, IP adres, eventuele telefoonnummers én mailadressen die je van de provider afneemt. Maar ook daar dus niet websites die je bezoekt, mails die je verstuurd etc.

De reactie van lol_anarchist sloeg helemaal nergens op. Ik kan me ook niet voorstellen dat een internetprovider jaren later nog weet wat jouw IP daar was, al zouden ze dat moeten overdragen. Of denk jij van wel?

[Room42]

privacy1234 schreef op dinsdag 2 april 2024 @ 14:37:
[...]


De reactie van lol_anarchist sloeg helemaal nergens op. Ik kan me ook niet voorstellen dat een internetprovider jaren later nog weet wat jouw IP daar was, al zouden ze dat moeten overdragen. Of denk jij van wel?

Jawel, die gegevens worden 'gedateerd' en zijn dus terug te leiden naar je, als bekend is op welke datum en tijd je een verdachte transactie deed. Zie ook: Wikipedia: CIOT#Verstrekte_gegevens

[privacy1234]

Room42 schreef op dinsdag 2 april 2024 @ 14:47:
[...]

Jawel, die gegevens worden 'gedateerd' en zijn dus terug te leiden naar je, als bekend is op welke datum en tijd je een verdachte transactie deed. Zie ook: Wikipedia: CIOT#Verstrekte_gegevens

Volgens mij worden de gegevens in de CIOT database elke dag overschreven met de nieuwste data. Dat zou betekenen dat elke dag de database gevuld is met de meest recente gegevens. Naar mijn weten slaan ze niks historisch op.

[CyBeR]

privacy1234 schreef op dinsdag 2 april 2024 @ 15:53:
[...]


Volgens mij worden de gegevens in de CIOT database elke dag overschreven met de nieuwste data. Dat zou betekenen dat elke dag de database gevuld is met de meest recente gegevens. Naar mijn weten slaan ze niks historisch op.

Dat zou wat zijn. Crimineel ding doen, modem een uurtje uit, nieuw IP-adres van Ziggo, et voila de dag erna niemand meer die weet dat ik 't was.

Natuurlijk heeft het CIOT een bewaartermijn.

[privacy1234]

CyBeR schreef op dinsdag 2 april 2024 @ 16:02:
[...]


Dat zou wat zijn. Crimineel ding doen, modem een uurtje uit, nieuw IP-adres van Ziggo, et voila de dag erna niemand meer die weet dat ik 't was.

Natuurlijk heeft het CIOT een bewaartermijn.

Geen idee hoe dat exact in zijn werk gaat in dat geval, maar ik baseer mijn eerdere uitspraak op dit artikel:

nieuws: Intern rapport: regels bij raadplegen database telecomgegevens onduid...

De database met de naam Centraal Informatiepunt Onderzoek Telecommunicatie bevat het volledige klantenbestand van alle providers, inclusief ip-nummers en telefoonnummers. Het gaat alleen om huidige gegevens en bevat geen historisch overzicht van personen of telefoonnummers en ip-adressen

Het lijkt me dat ze in dit geval dan meerdere IP-nummers zouden noteren. Ik verwacht wel dat zoiets in het achterhoofd wordt gehouden, anders kom je er makkelijk mee weg. Maar ik kan me nog steeds niet voorstellen dat ze de gegevens jarenlang bewaren.

[Room42]

privacy1234 schreef op dinsdag 2 april 2024 @ 16:44:
[...] Maar ik kan me nog steeds niet voorstellen dat ze de gegevens jarenlang bewaren.

Waarom niet?

[ouweklimgeit]

CodeCaster schreef op maandag 1 april 2024 @ 21:36:
[...]


[...]

Wat een ongefundeerde bangmakerij zeg.

Er wordt al decennia lang geen onversleutelde mail meer verstuurd, en de meeste mail loopt toch echt niet via providers, maar externe partijen. En je provider plaatst geen cookies op andermans websites. Wat een onzin.

TS vraagt naar privacy en je internet provider. Dat het mailtje onderweg van mailbox A naar B versleuteld wordt is in feite niet zo interessant. Maar als je een kpn/ziggo accountje gebruikt kan deze vanaf de ISP server wel voorzien worden van een TLS verbinding, maar die ISP bewaart al je emails onversleuteld op hun IMAP servers. Exact hetzelfde bij Gmail, Hotmail, etc. Je complete archief, alle verstuurde en ontvangen emails zijn volledig inzichtelijk voor dergelijke partijen. Dit is exact de reden dat er geen enkel mailtje ouder dan een paar maanden in mijn mailbox staat. Elke paar maanden archiveer ik alles naar mijn Synology NAS.

Wat betreft internet verkeer kan een provider wel degelijk e.e.a. loggen. Buiten de DNS verzoeken (dus de IP adressen die je bezoekt) kunnen ze http verkeer volledig monitoren. Bezoek je een https website, dan kunnen ze achter de extensie verder niets meer zien.

Goede stap die je kunt nemen is een alternatieve DNS, bijvoorbeeld Pi-Hole of NextDNS. Buiten het feit dat je provider je DNS verzoeken niet meer ziet, kan een eigen DNS ook een enorme hoeveelheid trackers blokkeren.

[ Voor 5% gewijzigd door ouweklimgeit op 08-04-2024 16:27 ]

[deHakkelaar]

jurroen schreef op dinsdag 2 april 2024 @ 11:29:
Als je een andere DNS provider gebruikt, zéker een met DoH/DoT/DNScrypt kan je provider dat uiteraard niet meer zien.

ouweklimgeit schreef op maandag 8 april 2024 @ 16:25:
Goede stap die je kunt nemen is een alternatieve DNS, bijvoorbeeld Pi-Hole of NextDNS. Buiten het feit dat je provider je DNS verzoeken niet meer ziet, kan een eigen DNS ook een enorme hoeveelheid trackers blokkeren.

Houd rekening dat de SNI nog gesniffed kan worden voor elke TLS verbinding!

The desired hostname is not encrypted in the original SNI extension, so an eavesdropper can see which site is being requested.

EDIT:

deHakkelaar schreef op dinsdag 11 oktober 2022 @ 18:29:
2) Of via de firewall van je ISP waarbij de SNI gegevens in de SSL/TLS handshake wordt ge-sniffed vergelijkbaar met onderstaande:

pi@ph5b:~ $ curl -IL https://tweakers.net
HTTP/2 200
server: Apache
[..]

pi@ph5b:~ $ sudo tcpdump -nqtX tcp port 443
[..]
IP 10.0.0.4.54222 > 213.239.154.31.443: tcp 517
[..]
        0x00c0:  0100 0175 0000 0011 000f 0000 0c74 7765  ...u.........twe
        0x00d0:  616b 6572 732e 6e65 7400 0b00 0403 0001  akers.net.......

EDIT2: Made easy
https://github.com/Dethada/SNI-Sniffer

[ Voor 39% gewijzigd door deHakkelaar op 08-04-2024 18:09 ]

[CodeCaster]

ouweklimgeit schreef op maandag 8 april 2024 @ 16:25:
[...]

TS vraagt naar privacy en je internet provider. Dat het mailtje onderweg van mailbox A naar B versleuteld wordt is in feite niet zo interessant.

De bangmakende claim van de VPN-referral-site waartegen ik ageer, is:

Een internetprovider kan al jouw onvergrendelde internetverkeer zien, ook als je je thuisnetwerk zo goed mogelijk beveiligt. Denk aan e-mails die je verstuurt en websites die je bezoekt.

Deel één van die claim is waar; deel twee is onzin.

Ervan uitgaand dat de provider aan DPI doet en dus al jouw verkeer kan analyseren (en dat kan), dan nog kunnen ze niet zomaar je e-mails lezen. Ja, de mail die je bij de provider in hun box stalt, maar niet de mail die je versleuteld uitwisselt met andere providers, om het even of dit via HTTPS gebeurt (webmail, API-clients) of via SMTP+TLS/SMTPS. En dat gebeurt letterlijk al decennia.

Maar als je een kpn/ziggo accountje gebruikt kan deze vanaf de ISP server wel voorzien worden van een TLS verbinding, maar die ISP bewaart al je emails onversleuteld op hun IMAP servers. Exact hetzelfde bij Gmail, Hotmail, etc. Je complete archief, alle verstuurde en ontvangen emails zijn volledig inzichtelijk voor dergelijke partijen.

Eens.

Dit is exact de reden dat er geen enkel mailtje ouder dan een paar maanden in mijn mailbox staat. Elke paar maanden archiveer ik alles naar mijn Synology NAS.

Indexeren duurt luttele milliseconden, dus dat hebben ze al gedaan zodra de mail arriveert of verstuurd wordt. Waarom zou je het jezelf moeilijk maken en de mail eraf halen?

Wat betreft internet verkeer kan een provider wel degelijk e.e.a. loggen. Buiten de DNS verzoeken (dus de IP adressen die je bezoekt) kunnen ze http verkeer volledig monitoren. Bezoek je een https website, dan kunnen ze achter de extensie verder niets meer zien.

Goede stap die je kunt nemen is een alternatieve DNS, bijvoorbeeld Pi-Hole of NextDNS. Buiten het feit dat je provider je DNS verzoeken niet meer ziet, kan een eigen DNS ook een enorme hoeveelheid trackers blokkeren.

Natuurlijk ziet je provider die verzoeken wel. Net als dat ze in jouw scenario het HTTP-verkeer kunnen bekijken, kunnen ze net zo goed uitgaand plattetekstverkeer over poort 53 sniffen.

Tenzij je dat verkeer gaat versleutelen (DNSSec, DNS over HTTPS, DNSCrypt,...), maar dat noem je niet.

[ChaserBoZ_]

privacy1234 schreef op dinsdag 2 april 2024 @ 15:53:
[...]


Volgens mij worden de gegevens in de CIOT database elke dag overschreven met de nieuwste data. Dat zou betekenen dat elke dag de database gevuld is met de meest recente gegevens. Naar mijn weten slaan ze niks historisch op.

Nope, iedere isp is verplicht iedere 24 uur data aan te leveren. Heb jij een jaar hetzelfde ip adres, dan hebben ze dus 365/366 entries daarvan met daaraan gekoppeld jouw naw gegevens.

CodeCaster schreef op maandag 8 april 2024 @ 17:04:
[...]

De bangmakende claim van de VPN-referral-site waartegen ik ageer, is:

[...]

Deel één van die claim is waar; deel twee is onzin.

Ervan uitgaand dat de provider aan DPI doet en dus al jouw verkeer kan analyseren (en dat kan), dan nog kunnen ze niet zomaar je e-mails lezen. Ja, de mail die je bij de provider in hun box stalt, maar niet de mail die je versleuteld uitwisselt met andere providers, om het even of dit via HTTPS gebeurt (webmail, API-clients) of via SMTP+TLS/SMTPS. En dat gebeurt letterlijk al decennia.

Nou, die ssl laag is te strippen, je cliënt verwacht een ssl sessie, met een man in the middle aanval kun je dat verkeer ontsleutelen-lezen-versleutelen.

Je moet dan uiteraard een ssl certificaat hebben wat niet leidt tot waarschuwingen

Destijds werd zo, via de Diginotar hack, mail ingezien die bij Google stond.

[ Voor 47% gewijzigd door ChaserBoZ_ op 08-04-2024 17:53 ]

[jurroen]

deHakkelaar schreef op maandag 8 april 2024 @ 16:52:
[...]

Houd rekening dat de SNI nog gesniffed kan worden voor elke TLS verbinding!

Nog wel, gelukkig komt daar ook een einde aan met ECH.

CodeCaster schreef op maandag 8 april 2024 @ 17:04:

Indexeren duurt luttele milliseconden, dus dat hebben ze al gedaan zodra de mail arriveert of verstuurd wordt. Waarom zou je het jezelf moeilijk maken en de mail eraf halen?

Eerste deel eens. Tweede deel is subjectief en afhankelijk van de situatie en setup. Ik gebruik zelf ook een dergelijke setup - mijn mail client verwijderd automatisch de mail na het volledig downloaden. Dat doe ik deels uit een security-overweging en deels ook uit het gemak. Ik kan berichten lezen onafhankelijk van de uptime van de provider en als het catastrofaal misgaat kwak ik het MX record om en klaar.

ChaserBoZ_ schreef op maandag 8 april 2024 @ 17:48:
[...]

Nou, die ssl laag is te strippen, je cliënt verwacht een ssl sessie, met een man in the middle aanval kun je dat verkeer ontsleutelen-lezen-versleutelen.

Je moet dan uiteraard een ssl certificaat hebben wat niet leidt tot waarschuwingen

Destijds werd zo, via de Diginotar hack, mail ingezien die bij Google stond.

Daar zijn gelukkig ook dingen tegen te doen. Sommige mail clients ondersteunen certificate pinning, een paar kunnen de geldigheid checken aan de hand van DANE (TLSA) records in de DNS.

DANE is qua web helaas nog vrijwel niet ondersteund (Chromium en Firefox kunnen het geloof ik allebei niet), maar qua MTAs ligt de ondersteuning en adoptie een stuk hoger.

[fopjurist]

privacy1234 schreef op dinsdag 2 april 2024 @ 15:53:
[...]


Volgens mij worden de gegevens in de CIOT database elke dag overschreven met de nieuwste data. Dat zou betekenen dat elke dag de database gevuld is met de meest recente gegevens. Naar mijn weten slaan ze niks historisch op.

Het CIOT bewaart gegevens gedurende drie jaar.

Je moet onderscheid maken tussen wat technisch mogelijk is en wat er in de praktijk gebeurt. De grote providers houden niet bij wat je op het internet doet, tenzij ze daar een bevel van de OvJ voor krijgen (voor een specifieke aansluiting). Dat gebeurt alleen bij verdenking van een ernstig misdrijf, dwz misdrijven waarvoor voorlopige hechtenis is toegestaan en die een ernstige inbreuk op de rechtsorde opleveren gelet op de aard of de samenhang met andere door de verdachte begane misdrijven, alleen indien het onderzoek dit dringend vordert, en dan nog eens voor een vastgestelde duur. Zodra het belang van het onderzoek dat toelaat moet je ervan op de hoogte worden gesteld dat je bent afgetapt.

[deHakkelaar]

ChaserBoZ_ schreef op maandag 8 april 2024 @ 17:48:
Nou, die ssl laag is te strippen, je cliënt verwacht een ssl sessie, met een man in the middle aanval kun je dat verkeer ontsleutelen-lezen-versleutelen.

Je moet dan uiteraard een ssl certificaat hebben wat niet leidt tot waarschuwingen

Nee dat gaat niet met bv browsers omdat deze hun eigen cert store aan boord hebben met trusted CA certs:

$ ls -1 /usr/share/ca-certificates/mozilla
ACCVRAIZ1.crt
AC_RAIZ_FNMT-RCM.crt
AC_RAIZ_FNMT-RCM_SERVIDORES_SEGUROS.crt
ANF_Secure_Server_Root_CA.crt
Actalis_Authentication_Root_CA.crt
AffirmTrust_Commercial.crt
AffirmTrust_Networking.crt
AffirmTrust_Premium.crt
AffirmTrust_Premium_ECC.crt
Amazon_Root_CA_1.crt
Amazon_Root_CA_2.crt
Amazon_Root_CA_3.crt
Amazon_Root_CA_4.crt
Atos_TrustedRoot_2011.crt
Autoridad_de_Certificacion_Firmaprofesional_CIF_A62634068.crt
Autoridad_de_Certificacion_Firmaprofesional_CIF_A62634068_2.crt
Baltimore_CyberTrust_Root.crt
Buypass_Class_2_Root_CA.crt
Buypass_Class_3_Root_CA.crt
CA_Disig_Root_R2.crt
CFCA_EV_ROOT.crt
COMODO_Certification_Authority.crt
COMODO_ECC_Certification_Authority.crt
COMODO_RSA_Certification_Authority.crt
Certainly_Root_E1.crt
Certainly_Root_R1.crt
Certigna.crt
Certigna_Root_CA.crt
Certum_EC-384_CA.crt
Certum_Trusted_Network_CA.crt
Certum_Trusted_Network_CA_2.crt
Certum_Trusted_Root_CA.crt
Comodo_AAA_Services_root.crt
D-TRUST_BR_Root_CA_1_2020.crt
D-TRUST_EV_Root_CA_1_2020.crt
D-TRUST_Root_Class_3_CA_2_2009.crt
D-TRUST_Root_Class_3_CA_2_EV_2009.crt
DigiCert_Assured_ID_Root_CA.crt
DigiCert_Assured_ID_Root_G2.crt
DigiCert_Assured_ID_Root_G3.crt
DigiCert_Global_Root_CA.crt
DigiCert_Global_Root_G2.crt
DigiCert_Global_Root_G3.crt
DigiCert_High_Assurance_EV_Root_CA.crt
DigiCert_TLS_ECC_P384_Root_G5.crt
DigiCert_TLS_RSA4096_Root_G5.crt
DigiCert_Trusted_Root_G4.crt
E-Tugra_Certification_Authority.crt
E-Tugra_Global_Root_CA_ECC_v3.crt
E-Tugra_Global_Root_CA_RSA_v3.crt
Entrust.net_Premium_2048_Secure_Server_CA.crt
Entrust_Root_Certification_Authority.crt
Entrust_Root_Certification_Authority_-_EC1.crt
Entrust_Root_Certification_Authority_-_G2.crt
Entrust_Root_Certification_Authority_-_G4.crt
GDCA_TrustAUTH_R5_ROOT.crt
GLOBALTRUST_2020.crt
GTS_Root_R1.crt
GTS_Root_R2.crt
GTS_Root_R3.crt
GTS_Root_R4.crt
GlobalSign_ECC_Root_CA_-_R4.crt
GlobalSign_ECC_Root_CA_-_R5.crt
GlobalSign_Root_CA.crt
GlobalSign_Root_CA_-_R3.crt
GlobalSign_Root_CA_-_R6.crt
GlobalSign_Root_E46.crt
GlobalSign_Root_R46.crt
Go_Daddy_Class_2_CA.crt
Go_Daddy_Root_Certificate_Authority_-_G2.crt
HARICA_TLS_ECC_Root_CA_2021.crt
HARICA_TLS_RSA_Root_CA_2021.crt
Hellenic_Academic_and_Research_Institutions_ECC_RootCA_2015.crt
Hellenic_Academic_and_Research_Institutions_RootCA_2015.crt
HiPKI_Root_CA_-_G1.crt
Hongkong_Post_Root_CA_1.crt
Hongkong_Post_Root_CA_3.crt
ISRG_Root_X1.crt
ISRG_Root_X2.crt
IdenTrust_Commercial_Root_CA_1.crt
IdenTrust_Public_Sector_Root_CA_1.crt
Izenpe.com.crt
Microsec_e-Szigno_Root_CA_2009.crt
Microsoft_ECC_Root_Certificate_Authority_2017.crt
Microsoft_RSA_Root_Certificate_Authority_2017.crt
NAVER_Global_Root_Certification_Authority.crt
'NetLock_Arany_=Class_Gold=_F'$'\305\221''tan'$'\303\272''s'$'\303\255''tv'$'\303\241''ny.crt'
OISTE_WISeKey_Global_Root_GB_CA.crt
OISTE_WISeKey_Global_Root_GC_CA.crt
QuoVadis_Root_CA_1_G3.crt
QuoVadis_Root_CA_2.crt
QuoVadis_Root_CA_2_G3.crt
QuoVadis_Root_CA_3.crt
QuoVadis_Root_CA_3_G3.crt
SSL.com_EV_Root_Certification_Authority_ECC.crt
SSL.com_EV_Root_Certification_Authority_RSA_R2.crt
SSL.com_Root_Certification_Authority_ECC.crt
SSL.com_Root_Certification_Authority_RSA.crt
SZAFIR_ROOT_CA2.crt
SecureSign_RootCA11.crt
SecureTrust_CA.crt
Secure_Global_CA.crt
Security_Communication_ECC_RootCA1.crt
Security_Communication_RootCA2.crt
Security_Communication_RootCA3.crt
Security_Communication_Root_CA.crt
Starfield_Class_2_CA.crt
Starfield_Root_Certificate_Authority_-_G2.crt
Starfield_Services_Root_Certificate_Authority_-_G2.crt
SwissSign_Gold_CA_-_G2.crt
SwissSign_Silver_CA_-_G2.crt
T-TeleSec_GlobalRoot_Class_2.crt
T-TeleSec_GlobalRoot_Class_3.crt
TUBITAK_Kamu_SM_SSL_Kok_Sertifikasi_-_Surum_1.crt
TWCA_Global_Root_CA.crt
TWCA_Root_Certification_Authority.crt
TeliaSonera_Root_CA_v1.crt
Telia_Root_CA_v2.crt
TrustCor_ECA-1.crt
TrustCor_RootCert_CA-1.crt
TrustCor_RootCert_CA-2.crt
Trustwave_Global_Certification_Authority.crt
Trustwave_Global_ECC_P256_Certification_Authority.crt
Trustwave_Global_ECC_P384_Certification_Authority.crt
TunTrust_Root_CA.crt
UCA_Extended_Validation_Root.crt
UCA_Global_G2_Root.crt
USERTrust_ECC_Certification_Authority.crt
USERTrust_RSA_Certification_Authority.crt
XRamp_Global_CA_Root.crt
certSIGN_ROOT_CA.crt
certSIGN_Root_CA_G2.crt
e-Szigno_Root_CA_2017.crt
ePKI_Root_Certification_Authority.crt
emSign_ECC_Root_CA_-_C3.crt
emSign_ECC_Root_CA_-_G3.crt
emSign_Root_CA_-_C1.crt
emSign_Root_CA_-_G1.crt
vTrus_ECC_Root_CA.crt
vTrus_Root_CA.crt

Je kunt dus niet een eigen publieke MITM cert aanmaken en deze proberen aan te bieden omdat deze dan niet signed is door een trusted CA en de clients deze dan weigeren.
Gelukkig maar

[ Voor 0% gewijzigd door deHakkelaar op 08-04-2024 18:59 . Reden: ohw my ]

[CodeCaster]

ChaserBoZ_ schreef op maandag 8 april 2024 @ 17:48:
[...]


Nope, iedere isp is verplicht iedere 24 uur data aan te leveren. Heb jij een jaar hetzelfde ip adres, dan hebben ze dus 365/366 entries daarvan met daaraan gekoppeld jouw naw gegevens.


[...]


Nou, die ssl laag is te strippen, je cliënt verwacht een ssl sessie, met een man in the middle aanval kun je dat verkeer ontsleutelen-lezen-versleutelen.

Je moet dan uiteraard een ssl certificaat hebben wat niet leidt tot waarschuwingen

Destijds werd zo, via de Diginotar hack, mail ingezien die bij Google stond.

Tsja, als een staatshacker bij een CA binnenkomt en daar certificaten kan maken voor om het even welk domein, en de landelijke DNS mag poisonen... Je kunt moeilijk certificaten gaan pinnen in browsers.

deHakkelaar schreef op maandag 8 april 2024 @ 18:41:
[...]

Je kunt dus niet een eigen publieke MITM cert aanmaken en deze proberen aan te bieden omdat deze dan niet signed is door een trusted CA en de clients deze dan wijgeren.
Gelukkig maar

Tenzij je dus een ingang hebt bij een CA, en dat is in het verleden gebeurd.

https://slate.com/technol...rnets-infrastructure.html

jurroen schreef op maandag 8 april 2024 @ 18:07:
[...]

Eerste deel eens. Tweede deel is subjectief en afhankelijk van de situatie en setup. Ik gebruik zelf ook een dergelijke setup - mijn mail client verwijderd automatisch de mail na het volledig downloaden. Dat doe ik deels uit een security-overweging en deels ook uit het gemak. Ik kan berichten lezen onafhankelijk van de uptime van de provider en als het catastrofaal misgaat kwak ik het MX record om en klaar.

Begrijp ik hoor. Het is natuurlijk ook zo dat hoe langer het ergens staat, des te meer kans er is dat er iets mee gebeurt.

[ Voor 41% gewijzigd door CodeCaster op 08-04-2024 18:57 ]

[jurroen]

deHakkelaar schreef op maandag 8 april 2024 @ 18:41:

[...]

Je kunt dus niet een eigen publieke MITM cert aanmaken en deze proberen aan te bieden omdat deze dan niet signed is door een trusted CA en de clients deze dan wijgeren weigeren.
Gelukkig maar

Fixed that for you Plus, gewoon even Ahmed bellen.

Maar je bericht klopt wel; je krijgt niet zomaar een selfsigned cert voor MitM geaccepteerd in de browser geaccepteert. Dan moet je ofwel certs kunnen pushen (denk aan een bedrijfsnetwerk waar alle clients Intune'd zijn) ofwel een CA zo ver krijgen dat ze jou subsignen. Maar de kans dat ze dat doen... is nihil. Immers, dan kunnen ze net zo goed de deuren sluiten.

Er zijn wel een paar (hele zeldzame) uitzonderingen waar je zelf de CA wilt zijn. Bijvoorbeeld Signal doet dat (op cdn.signal.org). Daar hebben ze gegronde redenen voor.Mind you: tenzij je de materie volledig snapt en het veilig kan doen, moet je zeker niet zelf CAtje gaan spelen.

CodeCaster schreef op maandag 8 april 2024 @ 18:47:
[...]

Begrijp ik hoor. Het is natuurlijk ook zo dat hoe langer het ergens staat, des te meer kans er is dat er iets mee gebeurt.

Zeker! Plus ik hoef er nul moeite voor te doen, hooguit een keer per maand even het herstellen van een backup testen. De rest heb ik volledig weggeautomatiseerd

[ Voor 14% gewijzigd door jurroen op 08-04-2024 19:00 ]

[F_J_K]

99ruud99 schreef op dinsdag 2 april 2024 @ 07:12:
Archiefwet1995 voor Nederland,
Voor België moet ik even zoeken, maar gezien je Ziggo noemde neem ik aan dat je NL zoekt.

De overheidsorganen zijn verplicht de onder hen berustende archiefbescheiden in goede, geordende en toegankelijke staat te brengen en te bewaren, alsmede zorg te dragen voor de vernietiging van de daarvoor in aanmerking komende archiefbescheiden.

Ziggo is geen overheid.

edit:
Oeps, zegt ik als spuit 11

Wel: Telecommunicatiewet artikel 13.2a.

In dit artikel wordt verstaan onder:

a. gegevens: de verkeers- en locatiegegevens, bedoeld in artikel 11.1, onderdeel b respectievelijk onderdeel d, alsmede de daarmee verband houdende gegevens die nodig zijn om de abonnee of gebruiker te identificeren;

b. oproeppoging zonder resultaat: een communicatie waarbij een telefoonoproep wel tot een verbinding heeft geleid, maar onbeantwoord is gebleven of via het netwerkbeheer is beantwoord.

2 Aanbieders van openbare telecommunicatienetwerken of openbare telecommunicatiediensten bewaren de in de bij deze wet behorende bijlage aangewezen gegevens, voorzover deze in het kader van de aangeboden netwerken of diensten worden gegenereerd of verwerkt, ten behoeve van het onderzoeken, opsporen en vervolgen van ernstige misdrijven.

3 De gegevens, bedoeld in het tweede lid, worden door de aanbieders bewaard gedurende een periode van:

a. twaalf maanden voor gegevens in verband met telefonie over een vast of mobiel netwerk, bedoeld in de bij deze wet behorende bijlage, onder A, of

b. zes maanden voor gegevens in verband met internettoegang, e-mail over het internet en internettelefonie, bedoeld in de bij deze wet behorende bijlage, onder B, gerekend vanaf de datum van de communicatie.

4 De verplichting, bedoeld in het tweede lid, heeft betrekking op gegevens van oproeppogingen zonder resultaat, voorzover deze gegevens door de aanbieders bij het aanbieden van openbare telecommunicatienetwerken of openbare telecommunicatiediensten worden gegenereerd, verwerkt en opgeslagen of gelogd.

Edit: en voor andere gegevens geldt ook bewaarplicht, zoals de financiele administratie van die VPN-leverancier.

[deHakkelaar]

Bedankt en wederdienst

jurroen schreef op maandag 8 april 2024 @ 18:58:
Maar je bericht klopt wel; je krijgt niet zomaar een selfsigned cert voor MitM geaccepteerd in de browser geaccepteert.
[..]
Mind you: tenzij je de materie volledig snapt en het veilig kan doen, moet je zeker niet zelf CAtje gaan spelen.

Je huis staat waarschijnlijk vol met eigen CAtjes
Je router, NAS, PC's, en IoT grut hebben vaak hun eigen private CA sleutel om een CSR te genereren + signen.
En het resulterende publieke cert kan dan worden aangeboden aan de clients voor van alles en nog wat TLS gerelateerd.

[jurroen]

deHakkelaar schreef op maandag 8 april 2024 @ 19:20:
Bedankt en wederdienst


[...]

Je huis staat waarschijnlijk vol met eigen CAtjes
Je router, NAS, PC's, en IoT grut hebben vaak hun eigen private CA sleutel om een CSR te genereren + signen.
En het resulterende publieke cert kan dan worden aangeboden aan de clients voor van alles en nog wat TLS gerelateerd.

Ha! Nee hoor. De enige in mijn huis die een eigen CA is, ben ik. Mijn apparatuur echt niet. Maar... ik ben dan wel een gigantische uitzondering. Dat besef ik ook heel goed.

[deHakkelaar]

@jurroen , m'n router:

dehakkelaar@router:/tmp/home/root# ls -1 /etc/
[..]
cert.crt
cert.pem
key.pem

M'n NAS:

dehakkelaar@nas:~$ sudo cat /usr/syno/etc/www/certificate/system_default/cert.conf
ssl_certificate          /usr/syno/etc/www/certificate/system_default/XXXa301ebb8.pem;
ssl_certificate_key      /usr/syno/etc/www/certificate/system_default/fXXX22be18d.pem;

Vanuit die private CA key's (key.pem & ssl_certificate_key) worden de publieke certs aangemaakt (cert.pem & ssl_certificate).

[ Voor 4% gewijzigd door deHakkelaar op 08-04-2024 19:50 ]

[deHakkelaar]

CodeCaster schreef op maandag 8 april 2024 @ 18:47:
... en de landelijke DNS mag poisonen

Onder staat een interesant YT filmje wbt dit onderwerp.
Met een knipoog naar een geweldige IT Crowd aflevering
https://anthillonline.com/real-elders-internet-know-video/

EDIT: Ow en success met:

As of 2024-04-08T18:07:19Z, the root server system consists of 1810 instances operated by the 12 independent root server operators.

https://root-servers.org/

[ Voor 24% gewijzigd door deHakkelaar op 08-04-2024 20:09 ]

[bert pit]

Als je niet wil dat je IP adressen van de bezochte sites worden bewaard, kun je je DNS verleggen naar een andere provider. Ik heb jaren geleden ook een soortgelijk onderzoekje gedaan en kwam uit bij de DNS provider Cloudflare (1.1.1.1) Cloudflare bewaart geen IP gegevens anders dan om de internetservice te verlenen.
Voor huis tuin en keuken toepassingen zou dit een redelijke oplossing moeten zijn.

Ik ben niet naïef (in dit geval) en weet ook wel dat dit niet waterdicht is en dat een handige tweaker binnen enkele minuten mijn gegeven boven water krijgt. Ik kan dus geslacht worden, maar ik heb het idee dat ik niet vrijwillig mezelf naar de slachterij breng.

[deHakkelaar]

@bert pit , Cloudflare is een Amerikaans bedrijf dus onderheving aan hun wetten ... NSA etc.
Ik prefereer m'n eigen recursieve DNS resolver thuis (Unbound).
DNS is dan wel niet encrypted maar geen enkele partij (EDIT: behalve m'n ISP) kan van mij m'n volledige browse history achterhalen omdat de verzoekjes opgesplits worden en naar verschillende DNS servers worden verstuurd:
deHakkelaar in "[Pi-Hole] Ervaringen & discussie"

[CodeCaster]

deHakkelaar schreef op maandag 8 april 2024 @ 20:06:
[...]

Onder staat een interesant YT filmje wbt dit onderwerp.
Met een knipoog naar een geweldige IT Crowd aflevering
https://anthillonline.com/real-elders-internet-know-video/

EDIT: Ow en success met:

[...]

https://root-servers.org/

Heb je gelezen wat er in het geval van DigiNotar is gebeurd?

DNS is een (omgekeerde) boomstructuur. Als het blaadje dat jij bevraagt (bijvoorbeeld de DNS van je provider) antwoord geeft alsof die weet wat het A(AAA)-record voor een bepaalde host is, dan wordt de tak niet verder naar boven bewandeld. Een gemiddeld consumentenverzoek benadert nooit de rootservers (.local daargelaten...).

Als een (dictatoriale) regering de internetproviders van dat land opdraagt om bepaalde DNS-verzoeken te beantwoorden met malafide IP's, dan zal het gros van de bewoners verbinden met die IP's, denkend dat die behoren bij de domeinen die ze bezoeken.

Je hoeft geen rootserver te hacken om dat voor elkaar te krijgen.

[deHakkelaar]

CodeCaster schreef op maandag 8 april 2024 @ 20:36:
Heb je gelezen wat er in het geval van DigiNotar is gebeurd?

Heb je mogelijk een linkje?

CodeCaster schreef op maandag 8 april 2024 @ 20:36:
Als een (dictatoriale) regering de internetproviders van dat land opdraagt om bepaalde DNS-verzoeken te beantwoorden met malafide IP's, dan zal het gros van de bewoners verbinden met die IP's, denkend dat die behoren bij de domeinen die ze bezoeken.

Nee want dan gaat DNSSEC klagen.

EDIT:

DNSSEC was designed to protect applications using DNS from accepting forged or manipulated DNS data, such as that created by DNS cache poisoning.

[ Voor 11% gewijzigd door deHakkelaar op 08-04-2024 20:47 ]

[CodeCaster]

deHakkelaar schreef op maandag 8 april 2024 @ 20:45:
[...]

Heb je mogelijk een linkje?

[...]

Nee want dan gaat DNSSEC klagen.

EDIT:

[...]

Als je een compromised DNS server hebt, doet die niks met DNSSEC, wat alleen is om upstream responses te valideren.

Je hebt een Pi-hole, toch? Jouw clients vertrouwen de responses daarvan, zonder dat jij beschikt over sleutels waarmee die DNS-data ondertekend kan worden.

Zie https://www.eff.org/deepl...-iranian-diginotar-attack over DigiNotar. Of het nou via DNS ging of proxyservers, kan ik niet vinden.

[jurroen]

deHakkelaar schreef op maandag 8 april 2024 @ 19:48:
@jurroen , m'n router:

dehakkelaar@router:/tmp/home/root# ls -1 /etc/
[..]
cert.crt
cert.pem
key.pem

M'n NAS:

dehakkelaar@nas:~$ sudo cat /usr/syno/etc/www/certificate/system_default/cert.conf
ssl_certificate          /usr/syno/etc/www/certificate/system_default/XXXa301ebb8.pem;
ssl_certificate_key      /usr/syno/etc/www/certificate/system_default/fXXX22be18d.pem;

Vanuit die private CA key's (key.pem & ssl_certificate_key) worden de publieke certs aangemaakt (cert.pem & ssl_certificate).

Ow ja, ik weet heel goed hoe het werkt Zowel mijn router als NAS zijn custom BSD machientjes

[deHakkelaar]

CodeCaster schreef op maandag 8 april 2024 @ 21:05:
[...]

Als je een compromised DNS server hebt, doet die niks met DNSSEC, wat alleen is om upstream responses te valideren.

Je hebt een Pi-hole, toch? Jouw clients vertrouwen de responses daarvan, zonder dat jij beschikt over sleutels waarmee die DNS-data ondertekend kan worden.

Zie https://www.eff.org/deepl...-iranian-diginotar-attack over DigiNotar. Of het nou via DNS ging of proxyservers, kan ik niet vinden.

Dat klopt alleen hoeven ze de antwoorden niet te wantrouwen omdat Pi-hole al DNSSEC validatie toepast voor al z'n clients.
En de DNSSEC --trust-anchor / sleutel komt hier vandaan:

pi@ph5b:~ $ man dnsmasq
[..]
       --trust-anchor=[<class>],<domain>,<key-tag>,<algorithm>,<digest-
       type>,<digest>
              Provide DS records to act a trust anchors for DNSSEC validation.
              Typically these will be the DS record(s) for Key Signing  key(s)
              (KSK)  of  the  root zone, but trust anchors for limited domains
              are also possible. The current root-zone trust  anchors  may  be
              downloaded    from   https://data.iana.org/root-anchors/root-an‐
              chors.xml

[CodeCaster]

deHakkelaar schreef op maandag 8 april 2024 @ 21:16:
[...]

Dat klopt alleen hoeven ze de antwoorden niet te wantrouwen omdat Pi-hole al DNSSEC validatie toepast voor al z'n clients.
En de DNSSEC --trust-anchor / sleutel komt hier vandaan:

pi@ph5b:~ $ man dnsmasq
[..]
       --trust-anchor=[<class>],<domain>,<key-tag>,<algorithm>,<digest-
       type>,<digest>
              Provide DS records to act a trust anchors for DNSSEC validation.
              Typically these will be the DS record(s) for Key Signing  key(s)
              (KSK)  of  the  root zone, but trust anchors for limited domains
              are also possible. The current root-zone trust  anchors  may  be
              downloaded    from   https://data.iana.org/root-anchors/root-an‐
              chors.xml

En dan terug naar mijn vorige verhaal: stel, je bent een burger die de DNS-servers van zijn provider vertrouwt (of móet gebruiken, omdat staatsfirewall).

Dan zegt de overheid: "hey, (provider), vanaf nu zegt jouw DNS dat mail.google.com uitkomt op (IP onder controle van de overheid) want anders (galg of andere middeleeuwse martelwerktuigen)".

Dus als de brave burger dan in diens browser naar mail.google.com gaat, komt die uit op een server van de overheid.

Daar gaat DNSSEC niets aan veranderen.

[deHakkelaar]

@CodeCaster , DNSSEC detecteert ofdat met de DNS records gesjoemeld is en verhindert dat de applicatie gaat proberen te verbinden dmv een BOGUS antwoord.

[ChaserBoZ_]

deHakkelaar schreef op maandag 8 april 2024 @ 18:41:
[...]

Nee dat gaat niet met bv browsers omdat deze hun eigen cert store aan boord hebben met trusted CA certs:

[...]

Je kunt dus niet een eigen publieke MITM cert aanmaken en deze proberen aan te bieden omdat deze dan niet signed is door een trusted CA en de clients deze dan weigeren.
Gelukkig maar

Dat is dus exact wat is gebeurd bij de Diginotar hack. De hackers maakten hun eigen certificaten, met Diginotar als (toen nog) overal geaccepteerde certificate authority . . .

Zie Wikipedia: Hack bij DigiNotar

[jurroen]

ChaserBoZ_ schreef op maandag 8 april 2024 @ 23:15:
[...]

Zie Wikipedia: Hack bij DigiNotar

Plus zie Stuxnet. Mooie, valide signature.

[deHakkelaar]

ChaserBoZ_ schreef op maandag 8 april 2024 @ 23:15:
[...]


Dat is dus exact wat is gebeurd bij de Diginotar hack. De hackers maakten hun eigen certificaten, met Diginotar als (toen nog) overal geaccepteerde certificate authority . . .

Zie Wikipedia: Hack bij DigiNotar

Dus als kwaadwillige overheid heb je een hack nodig om bij een cert boer binnen te geraken.
Plus DNSSEC om de tuin leiden (zie YT link filmpje die ik eerder plaatste).
En natuurlijk een great firewall die dit verkeer omleid.
En dat allemaal voor onbeperkte tijd zonder ontdekt te worden.
Tja ...

[ouweklimgeit]

CodeCaster schreef op maandag 8 april 2024 @ 17:04:
[...]

Indexeren duurt luttele milliseconden, dus dat hebben ze al gedaan zodra de mail arriveert of verstuurd wordt. Waarom zou je het jezelf moeilijk maken en de mail eraf halen?
[...]

Daar heb ik maar 1 reden voor; in het geval die IMAP server gecompromitteerd wordt. Of het nou van buitenaf of binnenuit is, niemand mag de mogelijkheid hebben om mijn complete leven aan e-mails in te kunnen zien. Je complete email archief is extreem privacy gevoelige informatie en ondanks dat ik Protonmail gebruik en er vanuit mag gaan dat alles on-disk versleuteld is, toch het zekere voor het onzekere.

bert pit schreef op maandag 8 april 2024 @ 20:07:
Als je niet wil dat je IP adressen van de bezochte sites worden bewaard, kun je je DNS verleggen naar een andere provider. Ik heb jaren geleden ook een soortgelijk onderzoekje gedaan en kwam uit bij de DNS provider Cloudflare (1.1.1.1) Cloudflare bewaart geen IP gegevens anders dan om de internetservice te verlenen.
Voor huis tuin en keuken toepassingen zou dit een redelijke oplossing moeten zijn.

Ik ben niet naïef (in dit geval) en weet ook wel dat dit niet waterdicht is en dat een handige tweaker binnen enkele minuten mijn gegeven boven water krijgt. Ik kan dus geslacht worden, maar ik heb het idee dat ik niet vrijwillig mezelf naar de slachterij breng.

Maar dit geldt alleen op een eigen netwerk Mijn firewall stuurt al het dns verkeer naar Pi-Hole, wat je op je client device ook hebt ingesteld als dns server. Dus zodra je op een 4/5G verbinding zit ben je overgeleverd aan je ISP.

DoH en DoT (die laatste is trouwens weer makkelijk te blokkeren) daargelaten, is DNS verkeer op geen enkele manier privé.

[jurroen]

deHakkelaar schreef op dinsdag 9 april 2024 @ 00:52:
[...]

Dus als kwaadwillige overheid heb je een hack nodig om bij een cert boer binnen te geraken.

Niet per se. In onze moderne westerse wereld wellicht, maar een CA om de oren slaan met een rechtsbevel én gag order is natuurlijk ook een optie in een dictatoriaal regime.

En er zijn ook nog wat andere opties. Als het "target" de infrastructuur niet op orde heeft - dus bijvoorbeeld geen RPKI, geen proper geconfigureerd CAA record etc, zou je als kwaadwillende kunnen proberen om de BGP te hijacken en zo een cert te fixen. Maar dat ks vrij zichtbaar en een certificaat kan vrij eenvoudig revoked worden.

Ten slotte zou je ook de ISP zelf kunnen binnendringen. Dat was anno 2015 bij een Duitse kabelboer niet eens zo heel erg lastig.

[deHakkelaar]

@jurroen , laat ik het dan anders verwoorden.
Vanuit een technisch aspect is het niet mogelijk als deze zaken in orde zijn inclusief beveiliging.

EDIT: Mbt:

deHakkelaar schreef op maandag 8 april 2024 @ 18:41:
Je kunt dus niet een eigen publieke MITM cert aanmaken en deze proberen aan te bieden omdat deze dan niet signed is door een trusted CA en de clients deze dan weigeren.
Gelukkig maar

[ Voor 51% gewijzigd door deHakkelaar op 10-04-2024 18:24 ]

[Juup]

Meerdere mensen zeggen in dit topic dat SMTP al jaren met TLS is versleuteld. En dat klopt - deels:
https://www.quora.com/Wha...is-secured-using-SMTP-TLS
"it's estimated that around 90% of email flowing around the Internet is secured using SMTP TLS."

Maar omdat SMTP vaak over meerdere servers heen hopt is de kans dat jouw email ergens een keer onbeveiligd tussen 2 servers gaat groter dan 10%.

[deHakkelaar]

jurroen schreef op woensdag 10 april 2024 @ 17:38:
Dat was anno 2015 bij een Duitse kabelboer niet eens zo heel erg lastig.

Leuk filmpje maar de introductie was beschamend

[jurroen]

deHakkelaar schreef op woensdag 10 april 2024 @ 19:10:
[...]

Leuk filmpje maar de introductie was beschamend

De meeste die-hard geeks zijn daar niet bijster goed in. Is IMHO ook niet erg, lukt mij aardig goed om er doorheen te kijken.

[jurroen]

Juup schreef op woensdag 10 april 2024 @ 18:48:

Maar omdat SMTP vaak over meerdere servers heen hopt is de kans dat jouw email ergens een keer onbeveiligd tussen 2 servers gaat groter dan 10%.

Ehm, hoe zie je dit voor je? Stel dat je vanaf jouw mailservertje in Amsterdam een mail stuurt naar ee.n vriend in de VS, dan gaat het traffic over meerdere netwerken heen, zeker. Maar elke hop decrypt & encrypt het niet.

Als je doelt op de mail infra bij de ontvangende óf verzendende partij, dan heb je zeker een punt. Maar dit is veelal een afgeschermd / intern netwerk, het is niet dat je daar zomaar verbinding mee kunt maken, laat staan aftappen wat er over de lijn gaat.

[Juup]

jurroen schreef op woensdag 10 april 2024 @ 21:14:
Ehm, hoe zie je dit voor je? Stel dat je vanaf jouw mailservertje in Amsterdam een mail stuurt naar ee.n vriend in de VS, dan gaat het traffic over meerdere netwerken heen, zeker. Maar elke hop decrypt & encrypt het niet.

Als je doelt op de mail infra bij de ontvangende óf verzendende partij, dan heb je zeker een punt. Maar dit is veelal een afgeschermd / intern netwerk, het is niet dat je daar zomaar verbinding mee kunt maken, laat staan aftappen wat er over de lijn gaat.

Vaak gaat het maar om 1 extra hop
Local mailclient <=> Mijn ISP's SMTP server <=> Ontvangende mail server
Dat zijn in dit geval 2 verbindingen die beveiligd kunnen zijn.
Zie ook https://stackoverflow.com...multiple-mail-server-hops

[jurroen]

Juup schreef op woensdag 10 april 2024 @ 21:44:
[...]

Vaak gaat het maar om 1 extra hop
Local mailclient <=> Mijn ISP's SMTP server <=> Ontvangende mail server
Dat zijn in dit geval 2 verbindingen die beveiligd kunnen zijn.
Zie ook https://stackoverflow.com...multiple-mail-server-hops

True. Tussen MTA's is het vaak al wel TLS, maar helaas forceert niet elke provider het voor de MDA.

TLS || die()

(ben overigens wel aan het bijhouden op grote mailclusters hoeveel procent TLSv1.2 en hoeveel procent TLSv1.3 doet - in Q3 tik ik er een publiek rapport over)

[ Voor 13% gewijzigd door jurroen op 10-04-2024 22:57 ]