Telenet redirect = grove schending van de privacy & BEWEZEN

[ubremoved_2964]

Als je bij Telenet wordt opgemerkt als grootverbruik bij vrij downloaden, of als je bij telenet met een niet-fup product over een bepaalde limiet gaat, wordt je geredirect naar een eigen pagina van telenet.

Als voormalig web security specialist weet ik dat de client (je webbrowser) hiervan niet op de hoogte is (de client denkt dat de server de authentieke server is, terwijl dit eigen een Telenet server is). Bij gevolg worden cookies en dus bijhorende authenticatie gegevens eveneens blind naar Telenet versluisd door niets vermoedende gebruikers.

Stel je download 's nachts en gaat over je limiet. 's Morgens log je aan op je favoriete blog/forum/... waarbij de client een cookie meestuurt die je authenticeert op de site, zodat je niet telkens je username/password moet invullen. In de plaats krijg je een antwoord van een telenet server. Op dat moment beschikt Telenet dus over authenticatie gegevens (jouw persoonsgegevens) en ook al lijkt het niet dat Telenet iets met deze data doet, het feit dat Telenet de site die je tracht te bereiken spoofed, is eigenlijk een grove inbreuk op de privacy alsook valsheid in geschrifte, aangezien telenet gegevens onderschept en vervalst.

We vinden het niet kunnen data Telenet HTTP requesten onderschept en zo onrechtmatig toegang krijgt tot persoonsgegevens. Dit behoort niet tot de taken van een ISP. Een ISP wordt immers niet geacht toe te zien op de inhoud van een pakket, maar door HTTP te termineren op een spoofed site, krijgt telenet wel toegang tot de data die niet voor hen bedoeld is:

Precedent is er reeds:

Some ISPs had implemented the block by redirecting The Pirate Bay traffic to a site owned by the IFPI.[137] Italian security expert Matteo Flora suggested that by having the page redirected this way, IFPI could access Italian users' cookies and impersonate them on the official The Pirate Bay website.[138]

[Jelly]

Zo had ik het nog niet bekeken.
Zeker eens aankaarten.

[Dima_2005]

Dit gebeurt als je naar een pagina gaat! Dus stel dat je naar een pagina gaat van je favoriete forum, stuur je een REQUEST voor die pagina. Die request wordt echter geweigerd. En het antwoord wordt teruggestuurd in vorm van een redirect.

Nu, op zich, zou je moeten weten, dat als je een pagina bezoekt, dat je niet elke keer je cookies meestuurt! Maar dat een stukje code bij het laden van de pagina echter de cookies opvraagt. Echter geraak je nooit tot aan die pagina, waardoor er nooit een aanvraag naar cookies zou gebeuren. Toch?

//Correct me if i'm wrong. (ik bekijk het gewoon in de vorm van PHP-programmeren hoe je met cookies omgaat).

Het enige "gevaar" is dat je NET over je limiet gaat wanneer je NET op een knop drukt van "login". En dat jouw gegevens dan onderschept worden bij het inloggen. Maar goed, ik vermoed niet dat telenet iets doet met die gegevens...

[mailracer]

Daar heb je een goed punt.

Stel je eens voor dat je tijdens een on-line banktransactie onderbroken word. Dat is maar de vraag of je transactie gelukt is.

Kan dus niet.

[ubremoved_2964]

Dit gebeurt als je naar een pagina gaat! Dus stel dat je naar een pagina gaat van je favoriete forum, stuur je een REQUEST voor die pagina. Die request wordt echter geweigerd. En het antwoord wordt teruggestuurd in vorm van een redirect.

de site mag whatever HTTP errorcode terugsturen, ondertussen heb jij de headers opgestuurd voor je verzoek, en hierin zitten ook de cookies

Nu, op zich, zou je moeten weten, dat als je een pagina bezoekt, dat je niet elke keer je cookies meestuurt! Maar dat een stukje code bij het laden van de pagina echter de cookies opvraagt. Echter geraak je nooit tot aan die pagina, waardoor er nooit een aanvraag naar cookies zou gebeuren. Toch?

nee, als je op een site zit zoals deze, dan wordt voor elke pagina verzoek door je browser dezelfde cookie meegestuurd, zodat de site niet telkens je username en passwoord moet vragen
als je deze sessieid steelt, dan kan iemand anders onder jouw sessie verdersurfen

vergelijk het met mac address spoofin op een AP met mac address filtering

//Correct me if i'm wrong. (ik bekijk het gewoon in de vorm van PHP-programmeren hoe je met cookies omgaat).

Het enige "gevaar" is dat je NET over je limiet gaat wanneer je NET op een knop drukt van "login". En dat jouw gegevens dan onderschept worden bij het inloggen. Maar goed, ik vermoed niet dat telenet iets doet met die gegevens...

Nee, niet enkel tijdens de login, maar ook de sessie kan gehijacked worden als een rogue server over jouw cookie beschikt, die de niets vermoedende browser domweg meestuurt ook al is het niet de echte site, maar een telenet redirect site.

PS: jarenlang HTTP low-level moeten troubleshooten bij firewall design ed ... dus ik weet wat in een request zit en wat niet

[Dima_2005]

Hmm, ja... Je hebt gelijk.
Nog eens nagekeken, en dat klopt wel, want hoe haalt die anders de $_COOKIE.

Ik gebruik gewoon heel vaak AJAX voor opvragen van cookies. Om die reden was ik beetje verward.

Trouwens, met een goede beveiliging is je sessie_id verbonden aan een PHP_sessie_id en aan je IP-adres. Maar natuurlijk kan Telenet ze allemaal spoofen. Maar de vraag is heel simpel: WAAROM zouden ze dat nu doen?

[Opus]

Dus ga jij nu direkt naar een advokaat stappen en een rechtszaak inspannen ja ??!!

Dit doet telenet al zolang en niemand kan daar wat aan doen.

[meon]

Overigens doen 101 publieke access points die dingen ook en potentieel gebeurt daar hetzelfde...

[ubremoved_15739]

Mooie combinatie.
's Nachts downloaden promoten.
Een grens tussen "vrij gebruik" en "grootverbruik" waarvan je niet weet wanneer deze bereikt is. (Op een klein uur tijd is je "extra" 10GB erdoor op TurboNet)
Je internet verkeer onderscheppen indien deze grens bereikt is.
En je download manager of automatische scripts blijven maar pompen ....

Je op smalband plaatsen en een e-mail sturen is duidelijk niet genoeg....

PS Heb je voor het onderscheppen van dataverkeer geen gerechtelijk bevel nodig?

[mailracer]

Mooie combinatie.
's Nachts downloaden promoten.
Een grens tussen "vrij gebruik" en "grootverbruik" waarvan je niet weet wanneer deze bereikt is. (Op een klein uur tijd is je "extra" 10GB erdoor op TurboNet)
Je internet verkeer onderscheppen indien deze grens bereikt is.
En je download manager of automatische scripts blijven maar pompen ....

Je op smalband plaatsen en een e-mail sturen is duidelijk niet genoeg....

PS Heb je voor het onderscheppen van dataverkeer geen gerechtelijk bevel nodig?

een mailtje is voldoende en smalband hoeft niet We weten wel dat we ergens over gaan.

[ubremoved_15739]

Mooie combinatie.
's Nachts downloaden promoten.
Een grens tussen "vrij gebruik" en "grootverbruik" waarvan je niet weet wanneer deze bereikt is. (Op een klein uur tijd is je "extra" 10GB erdoor op TurboNet)
Je internet verkeer onderscheppen indien deze grens bereikt is.
En je download manager of automatische scripts blijven maar pompen ....

Je op smalband plaatsen en een e-mail sturen is duidelijk niet genoeg....

PS Heb je voor het onderscheppen van dataverkeer geen gerechtelijk bevel nodig?

een mailtje is voldoende en smalband hoeft niet We weten wel dat we ergens over gaan.

Ik vind wel dat Charlotte hier dringend eens duidelijkheid mag over verschaffen op het forum.

[Sasuke]

Volgens mij werkt telenet met een transparante proxy, dus als ze het correct gedaan hebben kunnen zij de requests blocken VOORALEER jouw browser de cookie en/of authenticatie stuurt.

Je browser doet namelijk eerst een request, en krijgt dan een reply en request terug (voor de auth/cookie data). Als telenet de eerste request onderschept is er geen vuiltje aan de lucht imho.

Grtz,
Sasuke

[deej]

Tja als je het echt extreem ver drijft overtreden ze daarmee de wet op de afluisterpraktijken. Maar ik denk niet dat Telenet die server met kwaadwillige bedoelingen heeft opgezet hoor. De vraag is inderdaad of de irrelevante rommel die je browser meestuurt ook effectief wordt opgeslagen of gedumpt in /dev/null.

En zoals meon al zei, elke guest portal die met zulke redirects werkt doet dit ook. Zijn die dan plots allemaal in overtreding met de privacywetgeving?

[ubremoved_2964]

Volgens mij werkt telenet met een transparante proxy, dus als ze het correct gedaan hebben kunnen zij de requests blocken VOORALEER jouw browser de cookie en/of authenticatie stuurt.

Is dat wel legaal ? Alle HTTP verkeer onderscheppen ? Zo houden ze ook logs bij van de payload (eg concrete pagina's, zoektermen van google, en andere zaken waar ze geen recht toe hebben dit te loggen).

Je browser doet namelijk eerst een request, en krijgt dan een reply en request terug (voor de auth/cookie data).

Als telenet de eerste request onderschept is er geen vuiltje aan de lucht imho.

Grtz,
Sasuke

Helaas, als je 1x aangelogd bent op een site, dan is er vanaf dan een cookie gezet op je client, die met elke nieuwe HTTP request wordt meegestuurd. Als je bvb op een site aanvinkt: blijf een dag aangelogd, en je logt 's avonds aan, en 's morgen krijg je die redirect tijdens het surfen naar die site, wel dan heeft telenet die cookie.

[ubremoved_2964]

volgens mijn testjes draaien ze geen transparante proxy

[root@nas ~]# traceroute -T -p 21 klinktbeter.be
traceroute to klinktbeter.be (195.189.202.122), 30 hops max, 40 byte packets
1 DD-WRT (172.20.0.1) 0.627 ms 1.601 ms 1.968 ms
2 dD577C801.access.telenet.be (213.119.200.1) 19.832 ms 21.860 ms 23.878 ms
3 dD5E0C0E1.access.telenet.be (213.224.192.225) 26.240 ms 28.271 ms 36.539 ms
4 dD5E0FD49.access.telenet.be (213.224.253.73) 30.285 ms 32.328 ms 34.364 ms
5 dD5E0FD1D.access.telenet.be (213.224.253.29) 38.807 ms 40.826 ms 42.833 ms
6 kpn.bnix.net (194.53.172.59) 44.847 ms 22.283 ms 24.188 ms
7 134.222.100.91 (134.222.100.91) 52.505 ms 22.476 ms 24.589 ms
8 ge1-0-48.cs0.bebru1.unix-solutions.be (109.68.160.6) 51.747 ms 24.813 ms 26.987 ms
9 klinktbeter.be (195.189.202.122) 62.178 ms 62.155 ms 62.129 ms

[root@nas ~]# traceroute -T -p 80 klinktbeter.be
traceroute to klinktbeter.be (195.189.202.122), 30 hops max, 40 byte packets
1 DD-WRT (172.20.0.1) 0.642 ms 1.635 ms 2.027 ms
2 dD577C801.access.telenet.be (213.119.200.1) 19.871 ms 21.906 ms 23.938 ms
3 dD5E0C0E1.access.telenet.be (213.224.192.225) 26.317 ms 28.363 ms 30.402 ms
4 dD5E0FD49.access.telenet.be (213.224.253.73) 32.472 ms 34.519 ms 36.631 ms
5 dD5E0FD1D.access.telenet.be (213.224.253.29) 87.429 ms 85.285 ms 89.432 ms
6 kpn.bnix.net (194.53.172.59) 39.825 ms 18.607 ms 20.779 ms
7 134.222.100.91 (134.222.100.91) 71.047 ms 23.175 ms 25.372 ms
8 ge1-0-48.cs0.bebru1.unix-solutions.be (109.68.160.6) 52.914 ms 22.716 ms 26.700 ms
9 klinktbeter.be (195.189.202.122) 56.168 ms 53.413 ms 53.243 ms

waar ze port 25 blocken valt wel op

[root@nas ~]# traceroute -T -p 25 klinktbeter.be
traceroute to klinktbeter.be (195.189.202.122), 30 hops max, 40 byte packets
1 DD-WRT (172.20.0.1) 0.645 ms 1.641 ms 2.030 ms
2 dD577C801.access.telenet.be (213.119.200.1) 19.900 ms 21.933 ms 23.959 ms
3 * * *
4 * * *
5 * * *
6 * * *

deze hop dus:

3 dD5E0C0E1.access.telenet.be (213.224.192.225) 26.317 ms 28.363 ms 30.402 ms

[deej]

Tenzij je expliciet de telenet proxy in je browser definieert ga je geen enkele proxy passeren. Die oude proxy draait nog om dat telenet een hoop klanten uit het verleden hebben die die settings gewoon niet wijzigen (omdat ze het waarschijnlijk niet kunnen).

[selder]

Tenzij je expliciet de telenet proxy in je browser definieert ga je geen enkele proxy passeren.

Hoe denk je dat een transparent proxy werkt dan?

[ubremoved_2964]

En nu de bewijzen:

plots merk ik dat ik op de welbekende redirect pagina uitkom:



en mij nog 10 GByte rest. Omdat ik Telenet er niet kon van betrappen op basis van TCP traceroute dat ze HTTP onderscheppen alvorens deze redirect pagina van toepassing was, heb ik opnieuw getraced, en merkte dat de packets nog steeds mijn webserver bereiken:

FTP wordt althans traceroute nergens onderschept:

Code: Selecteer alles

[root@nas ~]# traceroute -T -p 21 klinktbeter.be
traceroute to klinktbeter.be (195.189.202.122), 30 hops max, 40 byte packets
 1  DD-WRT (172.20.0.1)  0.512 ms  1.063 ms  1.288 ms
 2  dD577C801.access.telenet.be (213.119.200.1)  9.385 ms  11.587 ms  11.693 ms
 3  dD5E0C0E1.access.telenet.be (213.224.192.225)  15.278 ms  15.604 ms  15.757 ms
 4  dD5E0FD49.access.telenet.be (213.224.253.73)  12.012 ms  12.188 ms  12.277 ms
 5  dD5E0FD1D.access.telenet.be (213.224.253.29)  12.985 ms  13.178 ms  17.510 ms
 6  kpn.bnix.net (194.53.172.59)  19.042 ms  18.580 ms  18.847 ms
 7  134.222.100.91 (134.222.100.91)  19.073 ms  17.831 ms  17.743 ms
 8  ge1-0-48.cs0.bebru1.unix-solutions.be (109.68.160.6)  17.754 ms  18.056 ms  18.328 ms
 9  klinktbeter.be (195.189.202.122)  24.195 ms  24.344 ms  24.257 ms

Zelfde met HTTP:

Code: Selecteer alles

[root@nas ~]# traceroute -T -p 80 klinktbeter.be
traceroute to klinktbeter.be (195.189.202.122), 30 hops max, 40 byte packets
 1  DD-WRT (172.20.0.1)  0.493 ms  1.225 ms  1.472 ms
 2  dD577C801.access.telenet.be (213.119.200.1)  12.054 ms  12.218 ms  12.336 ms
 3  dD5E0C0E1.access.telenet.be (213.224.192.225)  14.647 ms  14.988 ms  15.382 ms
 4  dD5E0FD49.access.telenet.be (213.224.253.73)  12.905 ms  13.159 ms  13.272 ms
 5  dD5E0FD1D.access.telenet.be (213.224.253.29)  19.918 ms  20.023 ms  20.099 ms
 6  kpn.bnix.net (194.53.172.59)  15.871 ms  15.342 ms  15.431 ms
 7  134.222.100.91 (134.222.100.91)  15.520 ms  13.252 ms  13.328 ms
 8  ge1-0-48.cs0.bebru1.unix-solutions.be (109.68.160.6)  19.335 ms  17.233 ms  18.467 ms
 9  klinktbeter.be (195.189.202.122)  28.534 ms  21.462 ms  21.342 ms

Dus dan maar tcpdump op de webserver gedraaid en de packets in een pcap gedumpt, dit is de inhoud:

Code: Selecteer alles

reading from file /tmp/authentic.http, link-type EN10MB (Ethernet)
20:11:55.930129 IP dD577C981.access.telenet.be.49945 > www.klinktbeter.be.http: S 1831289874:183128
9874(0) win 5840 <mss 1452,sackOK,timestamp 79204303 0,nop,wscale 6>
        0x0000:  4500 003c cbdd 4000 3806 49ad d577 c981  E..<[email protected]..
        0x0010:  c3bd ca7a c319 0050 6d27 4412 0000 0000  ...z...Pm'D.....
        0x0020:  a002 16d0 fadc 0000 0204 05ac 0402 080a  ................
        0x0030:  04b8 8fcf 0000 0000 0103 0306            ............
20:11:55.930423 IP www.klinktbeter.be.http > dD577C981.access.telenet.be.49945: S 176862945:1768629
45(0) ack 1831289875 win 5792 <mss 1460,sackOK,timestamp 1511108742 79204303,nop,wscale 2>
        0x0000:  4500 003c 0000 4000 4006 0d8b c3bd ca7a  E..<..@[email protected]
        0x0010:  d577 c981 0050 c319 0a8a b6e1 6d27 4413  .w...P......m'D.
        0x0020:  a012 16a0 2ef4 0000 0204 05b4 0402 080a  ................
        0x0030:  5a11 b086 04b8 8fcf 0103 0302            Z...........
20:11:55.943642 IP dD577C981.access.telenet.be.49945 > www.klinktbeter.be.http: . ack 1 win 92 <nop
,nop,timestamp 79204318 1511108742>
        0x0000:  4500 0034 cbde 4000 3806 49b4 d577 c981  [email protected]..
        0x0010:  c3bd ca7a c319 0050 6d27 4413 0a8a b6e2  ...z...Pm'D.....
        0x0020:  8010 005c 73f0 0000 0101 080a 04b8 8fde  ...\s...........
        0x0030:  5a11 b086                                Z...
20:12:10.718924 IP dD577C981.access.telenet.be.49945 > www.klinktbeter.be.http: P 1:44(43) ack 1 wi
n 92 <nop,nop,timestamp 79219084 1511108742>
        0x0000:  4500 005f cbdf 4000 3806 4988 d577 c981  [email protected]..
        0x0010:  c3bd ca7a c319 0050 6d27 4413 0a8a b6e2  ...z...Pm'D.....
        0x0020:  8018 005c 2d22 0000 0101 080a 04b8 c98c  ...\-"..........
        0x0030:  5a11 b086 4745 5420 2f76 616c 7368 6569  Z...GET./valshei
        0x0040:  642d 696e 2d67 6573 6368 7269 6674 652e  d-in-geschrifte.
        0x0050:  6874                                     ht
20:12:10.719124 IP www.klinktbeter.be.http > dD577C981.access.telenet.be.49945: . ack 44 win 1448 <
nop,nop,timestamp 1511123537 79219084>
        0x0000:  4500 0034 0676 4000 4006 071d c3bd ca7a  E..4.v@[email protected]
        0x0010:  d577 c981 0050 c319 0a8a b6e2 6d27 443e  .w...P......m'D>
        0x0020:  8010 05a8 faff 0000 0101 080a 5a11 ea51  ............Z..Q
        0x0030:  04b8 c98c                                ....

Zoals je kan zien in het 4e packet, komt mijn request 'GET /valsheid-in-geschrifte.html HTTP/1.0' wel degelijk toe op mijn eigen server.

Maar het antwoord komt niet van mijn server:

Code: Selecteer alles

[root@nas ~]# telnet www.klinktbeter.be 80
Trying 195.189.202.122...
Connected to www.klinktbeter.be (195.189.202.122).
Escape character is '^]'.
GET /valsheid-in-geschrifte.html HTTP/1.0

HTTP/1.0 302 Found
Location: http://redirect.telenet.be/lngtlm/redirect/fup_tips.html?n=00:15:CE:2E:B2:3D&s=7
Content-Type: text/html; charset=utf-8
Content-Length: 197
Connection: close

<html><head><title>Object moved</title></head><body>
<h2>Object moved to <a href='http://redirect.telenet.be/lngtlm/redirect/fup_tips.html?n=00:15:CE:2E:B2:3D&s=7'>here</a>.</h2>
</body></html>
^]
telnet> quit
Connection closed.

Telenet onderschept dus mijn HTTP response en stuurt zelf een andere boodschap in de plaats. Dit is dus volgens de wet:

- valsheid in geschrifte
- schending van het briefgeheim
- privacy schending

aangezien Telenet niet het recht heeft packets te onderscheppen en te herschrijven naar eigen dunken.

Eenmaal ik in de redirected pagina het bericht confirmeer, krijg ik terug de authentieke respons van mijn eigen server:

Code: Selecteer alles

[root@nas ~]# telnet www.klinktbeter.be 80
Trying 195.189.202.122...
Connected to www.klinktbeter.be (195.189.202.122).
Escape character is '^]'.
GET /valsheid-in-geschrifte.html HTTP/1.0

HTTP/1.1 404 Not Found
Date: Wed, 25 Aug 2010 18:21:56 GMT
Server: Apache/2.0.52 (CentOS)
Content-Length: 309
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL /valsheid-in-geschrifte.html was not found on this server.</p>
<hr>
<address>Apache/2.0.52 (CentOS) Server at www.klinktbeter.be Port 80</address>
</body></html>
Connection closed by foreign host.

Ik acht het dus bewezen dat Telenet zich moeit met onze traffiek, en dit ondanks het feit dat het in de telenet voorwaarden staat:

Wij stellen de Internetdienst enkel ter beschikking. De inhoud van de communicatie die u verwezenlijkt via het gebruik van de Internetdienst blijft in alle gevallen uw eigen verantwoordelijkheid en Telenet wordt niet geacht die te beperken of daarop toe te zien, noch kan Telenet aansprakelijk worden gesteld voor de inhoud van deze communicatie. U erkent dat wij geen controle hebben over de informatie, kwaliteit, veiligheid of de prijs van gegevens, programma’s of diensten op het Internet waartoe u toegang heeft via onze Internetdienst, en dat wij de inhoud van de informatie die u zendt, downloadt en uploadt of ontvangt, niet onderzoeken.

Hoe kan ik nu erkennen dat ze geen controle hebben, als ze packets herschrijven ?

Ik ben dus van plan een nieuwe klacht bij de ombudsdienst neer te leggen. Hoe zouden jullie dit aanpakken ?

[AnD]

Class action case of dit ook aan de media melden...

[ubremoved_2964]

Actie 1:

klachtenformulier

Wij hebben op meetbare en objectieve wijze vastgesteld dat Telenet internet traffiek onderschept, met name HTTP traffiek waarbij de response van een echte internet webserver vervangen wordt door een boodschap van telenet.


Voor de technische analyse alsook packet dumps verwijzen we naar volgende url:

http://userbase.be/forum/viewtopic.php? ... =0#p337550

Althans de Telenet voorwaarden:

Wij stellen de Internetdienst enkel ter beschikking. De inhoud van de communicatie die u verwezenlijkt via het gebruik van de Internetdienst blijft in alle gevallen uw eigen verantwoordelijkheid en Telenet wordt niet geacht die te beperken of daarop toe te zien, noch kan Telenet aansprakelijk worden gesteld voor de inhoud van deze communicatie. U erkent dat wij geen controle hebben over de informatie, kwaliteit, veiligheid of de prijs van gegevens, programma’s of diensten op het Internet waartoe u toegang heeft via onze Internetdienst, en dat wij de inhoud van de informatie die u zendt, downloadt en uploadt of ontvangt, niet onderzoeken.

is Telenet niet bevoegd om de inhoud van pakketen te onderzoeken en te herschrijven. Dit is dus een schending van de privacy, het briefgeheim. Ook valsheid in geschrifte is van toepassing.

Wij wensen dan ook dat het illegaal onderscheppen van traffiek zoals het herschrijven van HTTP ( al dan niet transparant ) onmiddelijk stopt, of wie zien ons genoodzaakt verdere juridische stappen te nemen en diverse instanties mbt privacy en telecom recht te contacteren.

[tomw]

Ik snap het probleem niet echt. Telenet zal hier wel geen kwade bedoelingen mee hebben zeker?
Ook gaat AL uw trafiek nu ook sowieso door het telenetnetwerk en ze kunnen overal onderscheppen moetsen ze willen.

[liger]

Ik snap het probleem niet echt. Telenet zal hier wel geen kwade bedoelingen mee hebben zeker?
Ook gaat AL uw trafiek nu ook sowieso door het telenetnetwerk en ze kunnen overal onderscheppen moetsen ze willen.

1. je weet helemaal niet wat hun bedoeling is
2. je weet ook niet wat hun bedoeling gaat zijn in de toekomst
3. duidelijk: ze gaan niet uw bankgegevens stelen. Niks houdt hen tegen "beetje" info te stelen
4. Wet = wet

[Trojan]

Denk je nu echt dat telenet zich gaat bezighouden met redirects te manipuleren en te misbruiken? Ze zijn uw provider en kunnen elke bit en byte die niet via beveiligde kanalen verzonden is lezen en zo zien wat gij allemaal doet op het internet. Deze redirects zijn heus wel het minste van uw/mijn zorgen dan hoor. Ik zou me meer druk maken om bedrijven ala google die miljarden verdienen met zulke informatie.

[ubremoved_2964]

Ik was gisteren een post aan het voorbereiden op een website, was al een half uur aan het typen, en door die stomme redirect ben ik m'n message kwijt. Moet ik dan steeds een copy paste nemen van mijn bericht alvorens ik het commit, nooit wetende wanneer die telenet redirect mijn HTTP hijacked ? Ik ben dit stomme FUP gedoe kotsbeu.

Ik wil echt niet via een redirect weten dat ik voortaan nog 10G aan normale snelheid rest, daarvoor is een mail ook voldoende.

Ik snap het probleem niet echt. Telenet zal hier wel geen kwade bedoelingen mee hebben zeker?
Ook gaat AL uw trafiek nu ook sowieso door het telenetnetwerk en ze kunnen overal onderscheppen moetsen ze willen.

4. Wet = wet

inderdaad, en het begint bij een simpele redirect en het eindigt bij .... geen controle voor de user of zijn HTTP al dan niet stiekem gemodificeerd wordt door Telenet als monkey in the middle

[Dafke]

Ik snap het probleem niet echt. Telenet zal hier wel geen kwade bedoelingen mee hebben zeker?
Ook gaat AL uw trafiek nu ook sowieso door het telenetnetwerk en ze kunnen overal onderscheppen moetsen ze willen.

Dat maakt toch NIETS uit????

Ook al doen ze er niets mee, ze KUNNEN er wel iets mee doen. Dat is al voldoende. Stel dat die servers gehackt worden en alles free beschikbaar is...???
Neen, ik ben verbolgen hiervan.. En trouwens WET IS WET!

[philippe_d]

Neen, ik ben verbolgen hiervan.. En trouwens WET IS WET!

Wet is ook interpreteerbaar (en ook niet altijd op nieuwe media en technieken toepasbaar)
Ik denk dus niet dat je het op een juridische basis niet ver zal kunnen drijven.

Aan de andere kant ben ik het 100% me eens dat een http re-direct niet het geschikte medium is om aan de klant een boodschap te sturen. Daarvoor kan je inderdaad e-mail gebruiken, of een pop-up bericht op je persoonlijke pagina's van "mijn telenet". Als de meerderheid van de klanten dit als storend ervaren (zoals ub4b, die een halfuur typwerk verliest), dan zou Telenet daarmee rekening moeten houden.

Ik zou dus eerder het argument "klant-onvriendelijk" gebruiken dan die juridische muggezifterij. Als je 100% privacy wil, dan mag je Internet niet gebruiken (dixit de baas van Facebook )

Philippe.

[ndj]

we zullen de rollen eens omdraaien en dat wij eens Telenet servers gaat spoofen, we zullen eens zien hoe lang het duurt voordat de arm der wet voor ons deurstaat!!

[Joe de Mannen]

In uw citaat uit de algemene voorwaarden staat: "U erkent dat...". Dit wil niet zeggen dat het zo is maar dat u, door de algemene voorwaarden te onderschrijven, akkoord gaat dat Telenet zegt dat het zo is. Kan u zich niet (meer) vinden in die voorwaarden dan rest er u niets anders dan het contract te stoppen of niet aan te gaan.
Het citaat is voor mij duidelijk.
J.

[Studenteninternet]

Of dit nu een legaal issue is of niet, die redirect is ronduit storend.
Vroeger kon je die uitzetten in mijn telenet en op die manier kon ik ermee leven, maar zoals 't nu is NIET!
Ik heb dit trouwens een tweetal maanden geleden reeds aangekaart bij telenet.
Ben al blij dat er ondertussen meerdere mensen over vallen, hopelijk wordt het na genoeg klachten weer een uitschakelbare optie in mijn telenet.

mvg

[trobbelke]

Ge zegt dat ge web security specialist zijt, maar ge beseft niet dat ge helemaal niet de volledige inhoud van de packets hoeft te bekijken vooraleer ge ze herschrijft? En dat Telenet niet anders kan dan de header info lezen en herschrijven, om uw packets naar de juiste server te sturen?

Telenet wil u laten weten dat ge over uw limiet gegaan zijt, en ik snap wel dat ge de manier waarop ze dat doen, niet leuk vindt. Maar: al wat Telenet moet doen is een packet dat van uw adres komt redirecten en ze gebruiken daarvoor de header info die sowieso moet uitgelezen en herschreven worden. Ik wens u veel plezier met het aanspannen van een rechtszaak, maar ik denk niet dat ge gaat winnen

[ubremoved_2964]

Ge zegt dat ge web security specialist zijt, maar ge beseft niet dat ge helemaal niet de volledige inhoud van de packets hoeft te bekijken vooraleer ge ze herschrijft? En dat Telenet niet anders kan dan de header info lezen en herschrijven, om uw packets naar de juiste server te sturen?

Telenet wil u laten weten dat ge over uw limiet gegaan zijt, en ik snap wel dat ge de manier waarop ze dat doen, niet leuk vindt. Maar: al wat Telenet moet doen is een packet dat van uw adres komt redirecten en ze gebruiken daarvoor de header info die sowieso moet uitgelezen en herschreven worden. Ik wens u veel plezier met het aanspannen van een rechtszaak, maar ik denk niet dat ge gaat winnen

je hebt mijn analyse niet gelezen

de originele HTTP Request Header komt 1:1 toe op de originele webserver
de originele HTTP Response Header (het antwoord van de originele webserver) wordt domweg vervangen door een andere response, met daarin een Location header:

http://en.wikipedia.org/wiki/HTTP_302

inderdaad, de response headers bevatten oa:
HTTP/1.0 302 Found
Location: http://redirect.telenet.be/lngtlm/redir ... :B2:3D&s=7

de browser ziet deze 302 code, en lanceert dan een 2e HTTP request, maar dan naar de Telenet server, met name de URL in de Location header

Het grote probleem is dat er redelijk wat tools zijn die HTTP gebruiken, en die met de spoofed output van telenet niet overweg kunnen.
En als je net op dat moment een lang bericht aan het typen was in een form, dan is de kans ook groot dat je de inhoud van die form kwijt speelt.

Dit zijn zaken die niet kunnen volgens ons, en tal van wetgevingen schendt.

[ubremoved_15739]

Zou Telenet bij het overschrijden van de inbegrepen belminuten "Optie FreePhone Buurlanden" ook je telefoongesprek onderscheppen en je de keuze laten om bijvoorbeeld verder te bellen mits betalen / beëindigen van het gesprek?

Een analogie waar toch wel iets voor te zeggen valt mijns inziens.

[trobbelke]

je hebt mijn analyse niet gelezen

Dit zijn zaken die niet kunnen volgens ons, en tal van wetgevingen schendt.

had ik inderdaad niet volledig gelezen. Het alternatief is natuurlijk dat ze doodgewoon u op smallband zetten zonder waarschuwing he.

En dan nog, Telenet is een prive bedrijf dat u een dienst aanbiedt. ALs het u niet bevalt, verander dan van provider. Misschien moeten ze duidelijker uitleggen dat ze inderdaad kunnen een transparent proxy gebruiken om een redirect te doen, als ge uw limiet overschreden hebt.

En eigenlijk, moet ge dan niet vragen aan Telenet om te garanderen dat uw verbinding niet over WAN accelerators, caches en andere traffic optimizers gaat omdat dit kan betekeken dat uw gevoelige gegevens ergens op een harde schijf staan?

[ubremoved_2964]

had ik inderdaad niet volledig gelezen. Het alternatief is natuurlijk dat ze doodgewoon u op smallband zetten zonder waarschuwing he.

notificatie gewoon per e-mail ipv hijacken van HTTP, dan breekt er niks

En dan nog, Telenet is een prive bedrijf dat u een dienst aanbiedt. ALs het u niet bevalt, verander dan van provider. Misschien moeten ze duidelijker uitleggen dat ze inderdaad kunnen een transparent proxy gebruiken om een redirect te doen, als ge uw limiet overschreden hebt.

En eigenlijk, moet ge dan niet vragen aan Telenet om te garanderen dat uw verbinding niet over WAN accelerators, caches en andere traffic optimizers gaat omdat dit kan betekeken dat uw gevoelige gegevens ergens op een harde schijf staan?

als ze daar al op willen antwoorden, zelfs op aangetekend schrijven geven sturen ze gewoon standaard antwoorden die totaal naast de kwestie zijn

[Mathy]

Ik zit al anderhalf jaar niet meer bij Telenet, maar vroeger kon je dat gewoon in Mijn Telenet aanpassen. Daar kon je kiezen tussen email en/of http redirect. Is dat met de vernieuwingen niet meer?

[Ofloo]

dat is dus de rede waarom googlecache een ip is anders geef je je gmail en andere cookies prijs aan onderliggende sites.

[ubremoved_539]

Je browser doet namelijk eerst een request, en krijgt dan een reply en request terug (voor de auth/cookie data). Als telenet de eerste request onderschept is er geen vuiltje aan de lucht imho.

Cookies worden STEEDS meegezonden, ook bij het allereerste request (maw. dus gewoon bij ieder request).

Nu ja, TN heeft zo ie zo controle over alles wat er over hun netwerk gaat... daar hoeven ze heus geen redirects voor te doen... gewoon een filter op jou verkeer en loggen maar.