"Om te checken of dit inderdaad zo was heb ik vervolgens in het hosts bestand ook de hostname van de VPN provider aan de IP adressen van de VPN provider gemapt. En wat denk je? Ik kan weer gewoon youtube bekijken."

Wat heeft dit dan van doen met het vermeende onderscheppen van de VPN verkeer door TTNET ? Indien je hierdoor een probleem met Youtube zou hebben, dan zou het plaatsen van andere hosts en ip adressen in je hostfile dat niet kunnen verhelpen ?

Verder lijkt het mij heel erg sterk dat je provider je 128-bits encrypted tunnel decrypt en vervolgens verkeer kan blokkeren. Wat dat betreft zijn je conclusies waarschijnlijk voorbarig.

"Voor een service provider is dat natuurlijk niet zo moeilijk lijk te realiseren met behulp van een "man in the middle attack" "

Leg dan eens uit hoe je een MiTM attack uitvoert op een encrypted tunnel, zonder dat je daarbij beschikt over de encryption keys, benodigde certificaten en dergelijke ?

Elke deftige VPN client toont een fingerprint. Heb je die gecontroleerd? Als die zou juist zijn, dan is een MITM moeilijk.

Weet je ook zeker dat Flash ook gebruikmaakt van jouw VPN-verbinding? Test effe met netstat en/of Wireshark.

Je verhaal is warrig en onlogisch. Ze kunnen in je VPN sessie niet specifiek verkeer gaan blokkeren wat daar overheen gaat. Je trekt voorbarige conclusie die gebasseerd zijn op lucht.

En aanvullend http://foxyproxy.mozdev.org/ al geprobeerd?

Het is al een onwaarschijnlijkheid dat een provider de interesse zou hebben om een VPN tunnel te decrypten.

Daarnaast is het gewoon niet mogelijk voor een provider om dit te doen. Het is ten eerste onwaarschijnlijk dat men ook maar ergens de kennis heeft om zo'n MITM attack op te zetten. Daarnaast is een MITM aanval niet mogelijk als er gebruik wordt gemaakt van een veilig VPN protcool met sterke keys.

Mocht men om welke wazige reden dan ook toch beschikken over deze kennis, wil en resources, dan zal dit een goed bewaard geheim zijn, en dit niet gebruikt worden om een willekeurige user te pesten die alleen maar youtube wil kijken.

Ik zou het probleem toch elders zoeken...

VPN is nogal een breed begrip, dus om zomaar te lopen lullen dat het "lek" is vind ik wat overrated.

Dus, wat voor VPN is het ?

In openvpn is het namelijk zo dat je tls-auth en client keys hebt, waardoor MITM niet mogelijk is.
Pushed je VPN provider ook je DNS of maak je nog gewoon gebruik van een turkse dns server ?

1+1=2

Heb je de proxy instellingen van de VPN verbinding in IE al eens bekeken? Wat is je default gateway tijdens de VPN verbinding?

@anoniem en rob
Foxyproxy hetzelfde resultaat: "An error occurred, please try again later."

En ja TTNET doet er alles aan om youtube onmogelijk te maken. Youtube ligt hier erg gevoelig i.v.m beledigende video's over Atatürk. Niet alleen youtube trouwens. Ze zijn hier bijvoorbeeld ook druk bezig alle porno sites stuk voor stuk te blokkeren. Dus als ze hier de moeite nemen om stuk voor stuk de pornosites te blokkeren, dacht je dat ze dat met youtube niet zouden doen dan?

Maar blijkbaar doen ze de blokkades voornamelijk op hostname en alleen in bijzondere gevallen op ip-adres. Youtube is dus blijkbaar geblokkeerd op IP-adres en inmiddels van mijn VPN provider de hostname, maar nog niet het ip-adres. Volgens mij de reden waarom ik door de hostname aan het ip-adres te mappen nog wel youtube kan zien. En dat ze proberen de VPN te blokkeren is ook niet zo verwonderlijk omdat de Turkse kranten de laatste tijd er vol mee hebben gestaan dat je de blokkade via VPN providers kan omzeilen. En zoveel zijn er daar nu ook weer niet van, dus ook die vallen stuk voor stuk te onderscheppen.

Wat betreft het the man in the middle attack. Zo moeilijk is dat ook niet. Jullie zijn er toch vast ook van op de hoogte dat de meeste router fabrikanten zoals bijvoorbeeld Cisco sinds jaren routers voor "lawfull" intercept op de markt brengen http://www.ietf.org/rfc/rfc3924.txt Daarmee is het mogelijk op zeer simpele wijze een MITM attack uit te voeren. Daar is verder weinig technische kennis en manpower meer voor nodig. Deze routers worden naar mijn weten standaard in de hardware infrastructuur ingebouwd. Ook in Nederland.

En natuurlijk kan ik het fout hebben en wordt VPN niet onderschept. Is er iemand die me dan uit kan leggen waarom ik op hostname youtube niet kan bekijken en met een mapping naar IP-Adres wel. Leg me dat dan maar eens uit.

Nou sloepie, voordat je op zo'n wazige manier gaat redeneren dat VPN wel lek moet zijn en je zogenaamd nieuws hebt: je onderzoek en je logica laten zwaar te wensen over. Ik kan me niet aan de indruk onttrekken dat je ergens een flink stuk kennis mist over hoe communicatie verloopt en je daar geen rekening mee wenst te houden. Anders had je wel wat meer onderzoek gedaan. Waarschijnlijk ben je geschrokken en ben je je gaan haasten?
Tip: zet eens een netwerk sniffer te luisteren op je ethernet kaart en kijk dan eens naar het verkeer wat je systeem naar welke diensten slingert en ontvangt.

Je http(s) gaat via VPN tunnel en je DNS afvraging niet via de tunnel maar naar de lokale Turkse DNS server?

Waarschijnlijk gaan je DNS queries niet door de VPN tunnel.

Ik denk eerder dat jouw pc zo lek is als een mandje.
Als je keys bekend zijn dan kan dit gebeuren, als je goede encryptie gebruikt niet.

Succes ermee

As i said before :-)

Klinkt als name resolution "probleem"
Gaat je DNS verkeer wel via je VPN tunnel? Daar zit waarschijnlijk je probleem

@anoniem. Als jij nu eens stopt met wazige kritiek en maak je de vakkennis waar die je suggereert te hebben. Nee ik ben geen netwerk specialist. maar ik kan rationeel genoeg redeneren.
Tot ruim een maand geleden kon je in Turkije via een simpele mapping naar het ip adres de youtube blokkade omzeilen. Vervolgens kreeg van het ene moment op het andere, niet alleen ik, maar iedereen die youtube wilde zien de melding "An error occurred" Dat zegt mij dus dat TTNET op een of andere manier er in slaagt om ook via een gemapt IP youtube adres te blokkeren.
Daar hoef ik echt geen netwerk specialist voor te zijn. Vervolgens stap ik over op VPN wat een ruim een maand goed gaat, maar na een paar grote kranteartikelen wordt zonder dat er ook maar iets aan mijn systeem is gewijzigd met precies dezelfde melding "An error occurred" ook youtube via mijn VPN geblokkeerd. Hoe is dat mogelijk zonder dat mijn VPN verkeer wordt onderschept? Een blokkade die ik weer ongedaan kan maken door de hostname van mijn provider naar zijnIP-adres te mappen?

Ik vermoed dat er het volgende gebeurt. Er wordt door TTNET geconstateerd dat een x- aantal gebruikers van een bepaalde VPN provider gebruik maken. Vervolgens wordt bij het leggen van de tunnel naar die provider het verkeer naar een lawfull intercept router geleidt die een MITM attack uitvoert en die de verbinding vervolgens weer met de VPN provider legt. Via de lawfull intercept router wordt vervolgens een controle uitgevoerd op verboden sites die vervolgens worden geblokkeerd terwijl de rest gewoon aan de VPN provider wordt doorgegeven. Voor de goede orde. Ik werk met Linux en non script en installeer alleen applicaties via synaptic of apt-get van vertrouwde sources. Het is natuurlijk niet onmogelijk dat ik iets binnen heb gehaald wat dat soort geintjes uithaalt, maar ook weer niet zo heel erg waarschijnlijk, zeker gezien het feit dat ik met ip mapping wel youtube kan zien en zonder ip mapping niet.
Dus bespaar me je meewarige en arrogante kritiek. Bovendien kan je niet lezen. Waarom denk je dat ik dat vraagteken in de kop heb geplaatst?

@anoniem 14:32. Voordat ik een VPN tunnel heb moet ik eerst, zonder IP-mapping in hosts inderdaad eerst de DNS van TTNET gebruiken om verbinding met mijn VPN provider in Nederland te kunnen leggen. En op dat moment kan TTNET mij dus eerst naar een Lawfull Intercept Router sturen voordat er verbinding met mijn VPN provider is en dus ook nog geen encryptie plaats vindt.
Daardoor kan die router mijn sessie key onderscheppen en een nieuwe key met de provider aanmaken en vervolgens in klare taal al het verkeer tussen mij en mijn provider onderscheppen en zo nodig blokkeren. Dat heeft niets met de sterkte van de sleutels te maken en alles met de MITM attack.

Echter doordat ik het ip adres van mij VPN provider in hosts map gaat mijn tunnel aanvraag niet eerst via de DNS van TTNET maar direct naar mijn provider, waardoor ik niet langs de Lawfull Intercept Router kom en ik vervolgens wel een veilige verbinding op kan bouwen. Reden waarom ik op die manier vanaf dat moment dus wel youtube kan zien.

@ Anoniem 14.06 Kom op dan, wat is er nu zo wazig aan mijn manier van redeneren? Waar zit het met mijn logica niet goed? Of ontbreekt het jou als zelfbenoemd deskundige misschien zelfs aan de meest elementaire kennis van de MITM attack?

@anoniem 13.44 Je hebt gelijk dat je zegt dat mijn opmerking enigszins overrated is. Echter zolang geen 100% wederzijdse authenticatie en uitwisseling van sleutels plaats heeft gevonden is en blijft een MITM attack op VPN mogelijk, zeker als de infrastructuur provider lawfull intercept router routers gebruikt. En ik ken maar weinig bedrijven die VPN gebruiken die werkelijk 100 % authenticatie gebruiken en dus op betrouwbare wijze sleutels uit kunnen wisselen. Bovendien; wat is een 128 bits sleutel tegenwoordig nog waard? Zelfs 1024 bits sleutels zijn al aan het eind van hun life-cycle en wordt geadviseerd op minimaal 2048 bits sleutels over te gaan. Een 128 bits sleutel is toch een lachertje.

@sloepie 15:06
De provider kan idd uw verkeer omleiden via dns requests te veranderen, routeren naar zo'n "lawfull intercept router',... maar in al die gevallen gaat de fingerprint verschillend zijn van diegene die je hebt gekregen van de VPN provider. Die fingerprint dient om te controleren dat je met de echt vpn endpoint praat en niet met een MITM. Anders kan je nooit 100% zeker zijn dat er niemand tussen zit ( hoewel ik wel straf zou vinden ... zeker als ze zoiets doen om youtube te blokkeren )

Ehm, kan deze thread gesloten worden? Appels worden met peren vergeleken en dit wordt alleen maar flamen.

Het is, zoals iemand anders al opmerkte zeer waarschijnlijk het DNS verkeer dat niet via de VPN loopt. Het enige dat een host bestand doet is de DNS 'overriden'. Als het een blokkade op packet niveau zou hebben, zou men wel op ip adres filteren. Het lijkt mij zeer ONwaarschijnlijk dat men een soort MITM aanval uitvoet op je VPN om dan alleen de DNS lookups te blokkeren.

Het zou voor de discussie ook handig kunnen zijn om het type VPN (versie) te vermelden. Dit is iets als zeggen dat je browser zo lek is als een mandje, maar verder niet vermeldt welke browser en welke versie je gebruikt.

Probeer je data eens te sniffen op je normale, niet VPN, device. Zeer waarschijnlijk zie je daar de DNS replies naar de turkse DNS voorbijkomen..

p.s. sleutellengte zegt niet zoveel als je het gebruikte algoritme er niet bij vermeldt.

Daarom maakt OpenVPN gebruik van TLS-AUTH :-)

tls-auth voegt een HMAC handtekening toe aan alle ssl/tls handshakes (zoals we dat netjes noemen), en ieder UDP pakketje dat die handtekening (HMAC) niet heeft wordt automatisch gedropt.

Zie; http://openvpn.net/howto.html#security

ps; misschien zou uw VPN provider daar ook nog een leer uit kunnen slaan.

@Anoniem 16:23 Ik weet eerlijk gezegd niet hoe die vingerprint bij VPN werkt. Ik neem aan dat het op een a-symmetrisch algoritme is gebaseerd. Waarschijnlijk RSA? Met symetrische sleutels is immers geen MITM attack mogelijk, want dan zou die "man in de middle" die ook moeten hebben. Dat kan wel, maar in principe alleen als bij de allereerste aanmelding bij de VPN provider tijdens de uitwisseling van de sleutels de communicatie ook al werd onderschept.
Hetzelfde geldt voor een a-symmetrische sleutel. De provider krijgt dan de vingerprint van de LIR (Lawfull Intercept Router) in plaats van de vingerprint van de gebruiker. En bij de gebruiker gebeurt hetzelfde, ook die krijgt de vingerprint van de LIR. Je kan de MITM immers alleen maar uitsluiten als beide betrokken partijen elkaar persoonlijk de desbetreffende public keys overhandigen, wat in de praktijk uiteraard hoogst zelden gebeurt. Bezwaar van deze methode is wel dat de LIR een database bij moet houden van alle logon-id's en de daarbij behorende sleutelparen. Maar dat lijkt me tegenwoordig nauwelijks meer een belemmering

Wat mij echter in deze hele discussie verbaast is dat iedereen zo vertrouwt op een sleutel van 128 bit.
512 bit RSA is al jaren geleden gekraakt en ik neem aan dat alle mogelijke 128 bit sleutelparen inmiddels allemaal al wel bekend zullen zijn, zeker bij organisaties zoals de AIVD en de Turkse geheime dienst. En die zullen voor de werkelijk lawfull intercepts dus wel aan de LIR's zijn toegevoegd. Het enige dat de LIR dan nog hoeft te doen is de secret key van de bij de VPN sessie gebruikte public key uit de database te vissen en klaar is Kees. Ik vermoed dus dat alle VPN verbindingen allemaal standaard worden onderschept. Al was al alleen maar om te kunnen zien wie met wie waarvandaan communiceert. Want je kan met VPN natuurlijk prima je eigen ip-adres en locatie verbergen. De geheime diensten zijn echter ook niet gek en die snappen best dat de meeste mensen met de verkeerde bedoelingen graag gebruik zullen maken van technieken als VPN.

Maar wat mij inderdaad ook verbaast is dat TTNET dit blijkbaar ook gebruikt voor zaken als het blokkeren van youtube. Vergeet echter niet dat de Turken heel erg zwaar tillen aan het beledigen van Atatürk. Daar draai je zo een paar jaar voor de gevangenis in en dat is immers ook de reden dat youtube wordt geblokkeerd. Bovendien is TTNET in de praktijk in Turkije de enige internet provider en ook eigenaar van technische infrastructuur. Er zijn een paar andere providers, maar die maken allemaal wel gebruik van de TTNET technische infrastructuur. Net zoals een hoop technische infrastructuur ook nog altijd in handen van KPN is. De meeste ADSL verbindingen worden vanaf de woning immers pas in de wijkcentrales van de KPN infrastructuur losgekoppeld. Dus een LIR voor die koppeling is al voldoende om de boel te onderscheppen. En als ex-staats bedrijf heeft TTNET, net als KPN, ook nog altijd diepe banden met allerlei overheidsinstanties.

Klok, klepel... ga je eens verdiepen in de verschillen tussen symmetrische (128bit) en a-symmetrische (public, private key, 512,1024 ,2048bit) encryptie.
De symmetrische sleutels zijn iedere sessie anders en worden op basis van een andere encryptievorm uitgewisseld tussen zender en ontvanger. Verificatie van public keys, fingerprints en hashes moeten er voor zorgen dat je zeker weet dat je met de juiste partij praat.

Overigens ben je wel aan een alu-hoedje toe als je denkt dat een provider sleutelparen kraakt, bewaart en probeert te hergebruiken. Zelfs in een beetje dictatuur kost dat nog steeds bakken geld en rekentijd. Die resources gaan meestal naar uiterlijk militair vertoon en blingbling voor de regerende instantie.

Daarnaast riekt je 'probleem' naar een (split)DNS verhaal (of een aardig probeersel om TTNET/KPN/doorsnee ISP in een kwader daglicht te stellen).

@ TopicStarter

Die 128-bits encryptie is de sterkte van je tunnel, dat is gewoon een symmetrische block-cipher, alleen de authenticatie gebeurd met asymmetrische encryptie.

Een symmetrische cipher van 128-bits is ongeveer gelijk aan 1024-bits asymmetrisch, wat sterkte betreft.

@ wimbo en kwukduck. Jullie hebben gelijk. Ik ging ging er van uit dat de 128 bits key de RSA key was. Mea Culpa. Wat blijft is dat hoe je het ook wendt of keert, zonder wederzijdse authenticatie, blijft VPN hoe dan ook open staan voor de MITM attack.

@wimbo Wat betreft het kraken van code's door overheden kan je me dan wel een alu hoedje vinden (speel je nu op de man in een poging me belachelijk te maken om zo iedere verdere discussie over dit onderwerp onmogelijk maken? Wat een zwaktebod!)
Maar ik denk dat jij ongelofelijk naïef bent te veronderstellen dat overheden niet zullen proberen alle dataverkeer te onderscheppen. Vast wel eens van echelon gehoord? Dan weet je vast ook wel dat Airbus mogelijk miljarden orders misliep ten gunste van Boeing door het afluisteren van communicatie door Echelon. En ook dat Nederland Echelon ondersteunt met een hele grote afluister centrale in Zoutkamp.
Gezien de grote economische belangen die kunnen spelen bij het afluisteren van grote bedrijven en het bestaan van organisaties als echelon lijkt het kostenaspect van het onderscheppen van elektronisch dataverkeer, juist bij VPN dus een volstrekt kul-argument van je. Dit nog afgezien van het belang voor terrorisme- en criminaliteits bestrijding. Bovendien; waar zijn al die "lawfull intercept routers" dan voor bestemd? Zeker niet om het dataverkeer te onderscheppen? Interessant in dat verband is ook term "lawfull" Geen enkele niet-overheid organisatie zal ooit toestemming van de rechter krijgen een andere organisatie af te luisteren. Dat lawfull kan dus alleen maar betrekking hebben op de overheid. Dus reken maar dat de overheden, ook uit commerciele overwegingen, er alles aan zullen doen om juist het VPN verkeer af te kunnen tappen al dan niet met de medewerking van de eigenaren van de infrastructuur. En mag ik je er aan herinneren dat sedert heel recent de Nederlandse overheid heeft bepaald dat alle dataverkeer voor minimaal een half jaar moet worden vastgelegd. Denk je dat die niet zal proberen het gebruik van VPN providers om die regelgeving te ontduiken met alle mogelijke middelen teniet te doen? En ook daar zullen ze al dan niet gedwongen de medewerking van de eigenaren van de infrastructuur van verlangen. Dus hoezo in een kwaad daglicht stellen, het is simpelweg de realiteit van alle dag! Dus bespaar me s.v.p. je slappe en kortzichtige gelul over aluhoedjes. Dat draagt nou niet bepaald bij aan een zinvolle discussie over dit onderwerp.

Tenslotte nog dit. Als je alles zo goed weet leg me dan eens uit hoe het in vredesnaam mogelijk is dat, ondanks het gebruik van VPN, alleen het in Tukije verboden Youtube wordt geblokkeerd, maar dat ik wel iedere andere site op kan die niet in Turkije verboden is, zoals bijvoorbeeld Liveleak die ook Flashplayer gebruikt. Als er al iets mis zou zijn met mijn systeem dan is het toch uiterst merkwaardig dat het heel selectief alleen mis gaat met die sites die in Turkije verboden zijn. Grappig zo'n uiterst selectieve fout. Ongetwijfeld zal je nu wel roepen dat ik door iets anders dan via VPN wordt geblokkeerd en dat mijn systeem dus lek is.
Als dat al zo zou zijn, waarom wordt ik dan niet geblokkeerd wanneer ik in mijn hosts bestand de hostname van mijn VPN provider map aan de IP-adressen van mijn VPN provider. Dat is het enige verschil, het aangepaste hosts bestand. Verder is alles precies hetzelfde

Dit heeft allerlei kenmerken van een troll.
1) Er wordt weinig informatie verstrekt, wat voor VPN, welke versie, etc..
2) Er wordt off-topic op allerlei bijzaken ingegaan zonder op suggesties in te gaan of die te onderzoeken, of verdere informatie te posten die zou kunnen helpen met het oplossen van het probleem.
3) Er wordt met allerlei termen geschermd (lawfull intercept router) terwijl niet eens bekend is of dit überhaupt wel zo is.
4) Er worden allerlei claims gedaan van 'bewijs' dat VPN (wat voor VPN? wat voor protocol, welk type, etc..) 'lek' zou zijn.

@topicstarter: show us the packet intercepts, dan praten we verder

roepen dat vpn zo lek als een mandje is is net zo dom als roepen dat internet stuk is, want: welke software, encryptie, protocol, tunnel,type enz.

en als je nameserver naar de lokale router wijst (verkregen via dhcp?) blijf je gewoon resolven in turkije

@sloepie:
Die LIR's zullen er best zijn en die zullen ook best dingen doen waar we liever niet over nadenken, maar denk je nu echt dat enkele connecties om youtube te kunnen kijken zo vreselijk zwaar gedwarsboomt zullen worden, terwijl er legio mogelijkheden zijn die te omzeilen (VPN/SSL/SSH Tunnels, proxies, e.d.)?
Stel dat TTNET het verkeer richting jouw VPN provider onderschept, dan is het heel eenvoudig te zien voor de gebruiker of je ook daadwerkelijk met je provider geconnect bent (fingerprints, hashes, public keys). Als die niet kloppen en je connect toch, dan is het je eigen schuld (of onwetendheid). Maar gezien je betoog en 'kennis' tot nu toe hou ik het in jouw geval op een groot deel eigen schuld.
Als men zelfs bij het meest pietluttige stukje opensource software al MD5 en SHA-1 hases publiceert om de software te kunnen 'valideren/authenticeren', waarom denk je dat dit bij een VPN/SSL/SSH sessie zou gebeuren? Dat heeft een reden, om te kunnen controleren dat je je gebruikersnaam en wachtwoord niet zomaar naar iedere 'boef' stuurt.

Al vast vooruitlopend op een mogelijke volgende reactie: hoelang denk je dat er nodig is om een 2048bit RSA keypair te kraken (of zelfs een 1024bit), laat staan te dupliceren (kraken != dupliceren)? Al die rekenkracht voor 1 (pietluttig) VPN providertje in Nederland? Als dat nog steeds een uitgangspunt is voor je betoog, dan denk ik inderdaad dat je een alu-hoedje nodig hebt. Op de man gespeeld of niet.

De enige (vergezochte) reden die ik kan verzinnen dat ze inderdaad actief sleutelPAREN lopen te kraken te dupliceren is dat jouw VPN providertje DE spil in het al qaeda netwerk is en de NSA-achtige diensten allemaal de krachten hebben gebundeld. Maar dan zouden die niet youtube tegenhouden laat staan jou laten merken dat er wat met je Internet verbinding aan de hand is.

Naast je vergissing betreffende de symmetrische en a-symmetrische sleutellengtes misschien ook maar eens kijken naar (split)DNS en hoe dat KAN werken in je voor- en nadeel. Split DNS kan een instelling zijn bij je VPN provider. Iets wat jij wellicht zelf niet in de hand hebt. Iets wat in theorie ook van dag tot dag kan wijzigen (als het aan de VPN beheerder ligt).

Voor de mensen die denken dat youtube in turkije niet belangrijk genoeg is om geblokt te worden, kijk dan even naar deze search naar youtube "an error" op de google turkije die bijna 6 miljoen hits geeft. http://www.google.com.tr/#hl=tr&source=hp&q=youtube+%22an+error+occurred%22+&btnG=Google%27da+Ara&meta=&aq=f&oq=youtube+%22an+error+occurred%22+&fp=fe5981145c686b70

wat betreft mijn VPN provider: itshidden.com

wat betreft mijn resolve.conf die staat gemapt naar opendns. Bovendien staat youtube in hosts ook nog eens gemapt
naar de youtube ip's zowel in Engeland als in NL

en nogmaals ik ben geen netwerk specialist en misschien ben ik te voorbarig geweest in mijn conclusie. Maar voor mij blijft het een compleet raadsel hoe het kan dat ik hoewel ik een VPN verbinding gebruik, OpenDns gebruik en de youtube ip adressen gemapt heb, ik toch voor youtube geblokkeerd wordt.

Ik heb even tijd nodig maar ik zal proberen zoveel mogelijk op alle vragen in te gaan.

Mensen ik zal proberen vanmiddag een antwoord te geven op alle openstaande vragen.

wat betreft VPN; ik gebruik pptp-linux en network-manager-pptp

@iedereen
Ik moet met het schaamrood op de lippen bekennen dat er een probleem met mijn systeem is en helemaal niets met VPN. Vanmorgen liep mijn systeem opeens helemaal vast doordat mijn HD helemaal vol zat, hoewel werd aangegeven dat ik nog ruim 19 GB vrije ruimte zou moeten hebben. Dat was van de week al eerder gebeurd en had toen al 19 GB uit mijn prullenbak verwijderd.
Het blijkt echter dat wanneer ik mijn prullenbak leegmaakte, de te verwijderen bestanden naar root.cache werden weggeschreven in plaats van ze werkelijk te verwijderen? Nadat ik root.cache leeg had gemaakt kon ik inderdaad weer gewoon op youtube komen, ook zonder dat ik de VPN hostname gemapt had aan de VPN- ip adressen.
Wat ik nu vermoed dat er is gebeurd, is dat de foutmelding "an error occurred" kwam doordat youtube de video door de volle harddisk niet kon cashen. Omdat ik in het verleden dezelfde melding kreeg door de blokkade van youtube door TTNET ging ik er ten onterecht van uit dat de melding nu weer door de blokkade van TTNET kwam. Mijn excuses aan iedereen.

Hoe het kan dat ik wel youtube video's wel kon zien wanneer ik de hostname van de VPN provider aan zijn ip-adres mapte is me nog steeds een raadsel, maar daar zal ik me maar niet meer in verdiepen.

Dus nogmaals: Mijn excuses voor mijn voorbarigheid. VPN IS NIET LEK

Of VPN wel of niet lek is kan ik zelf niet bepalen...

Heb wel eens via via gehoord dat (USA) geheime diensten geen gebruik maken van IPSEC. Daar zal best een rede voor zijn...

Overheid / Opsporingsdiensten maken zich zorgen over encryptie skype (hoor je ook niks meer van), maar IPSEC is geen probleem... mmmm

Sloepie heeft hier eerlijk en open aangegeven dat hij/zij ook fouten kan maken, waarvoor hulde. Toch even een vraag.

Mijn vraag nu aan sloepie: waarom denk je zelf dat je weinig open stond voor je ongelijk?

Allemachtig, wat een "fijne" reacties hier weer zeg: flamen, troll, en noem maar op. Geweldig, al die arrogante deskundigen hier. Dit is nog eens een fijne discussie voeren. En heel flink dat Sloepie ondanks die scheldpartijen toch nog gewoon zegt dat hij zich vergiste. Dat vind ik een heel wat volwassener reactie dan dat afkatten door sommigen hier. Leer eens je te verplaatsen in een ander, eikels!

Ik denk dat door die volle harddisk je /etc/resolv.conf niet bijgewerk kon worden en je dus zoals hier boven een aantal keren genoemd de DNS van de turkse provider gebruikte.

Hm een veroordelende topic en post terwijl dit toch echt op u.s.e.r. error lijkt. Ik zou voortaan eerst maar eens gaan lezen en een dagje laten bezinken voordat je ongefundeerde conclusies trekt en zo in de pen klimt.
Daarnaast raad ik je aan de topic en het bericht aan te passen zodat je de tijd van anderen niet verdoet hiermee.

Ik denk dat het om 2 dingen gaat hier..

A) ze willen youtube blokeren..
B) ze laten geen VPN tunnels toe buiten Turkije..

en B is natuurlijk om te zorgen dat A klopt..

Goede reactie van een anoniem! Wel eens gehoor dvan "Practice what you preach"?

@Anoniem 23:14 "Ik denk dat door die volle harddisk je /etc/resolv.conf niet bijgewerk kon worden"
Ik denk dat dat inderdaad wel eens het geval zou kunnen zijn. Ik kwam er pas achter dat er wat aan de hand was toen ik zaterdagmorgen een e-mail wilde beantwoorden en verzenden, waarop ik het volgende bericht kreeg "Delivery to the following recipient failed permanently: Technical details of permanent failure: DNS Error: DNS server returned answer with no data"

@grafixworld en verder ook alle anoniem critici.

"Practice what you preach"? Dat heb ik wel degelijk gedaan en ik heb in de afgelopen maanden in de strijd om Youtube met TTNET de zaak helemaal dichtgetimmerd wat überhaupt naar het DNS van TTNET had kunnen verwijzen d.m.v OpenDNS en de mapping van de Youtube Hostname naar de ip-adressen van Youtube. Daarnaast had ik geen enkele reden te veronderstellen dat mijn hard disk vol zou kunnen zijn. (zie toelichting onderdaan) Bovendien weet ik voldoende van cryptografie om te weten dat, ook al gaat iedereen hier op zijn kop staan, zolang er geen 100% wederzijdse authenticatie heeft plaatsgevonden VPN 100% open staat voor "the man in the middle attack". Fingerprint of geen fingerprint (@Wimbo!). Als deze attack immers wordt uitgevoerd bij de eerste initiatie krijgen zowel de gebruiker als de VPN provider de fingerprint en keys van de "man in the middle" in plaats van elkaar en denkt men daarom onterecht dat de fingerprint klopt.

Daarnaast besteden organisaties als NSA en Echelon miljarden dollars om ook encrypted data te kunnen onderscheppen. Niet alleen voor de bestrijding van terrorisme, maar ook om daar commercieel voordeel mee te behalen. Zo is er een ernstig vermoeden dat Boeing onderschepte contracten van Airbus in heeft mogen zien, waardoor Airbus mogelijk voor miljarden euro's aan contracten mis is gelopen ten gunste van Boeing. En er is niemand van alle zogenaamde "deskundigen" hier die mij met 100% zekerheid kan garanderen dat de 1024 bits RSA sleutels nog steeds niet zijn gekraakt. Het is immers al een paar jaar geleden dat de 512 bits RSA key, vergeleken met de NSA, door "amateurs" werd gekraakt. Kraken is eigenlijk een groot woord. Op zich is het voldoende om 1-malig alle mogelijke sleutelparen van een 1024 bits key te berekenen, wat theoretisch ik weet niet hoe lang zou moeten duren. Maar niemand weet hoeveel brute rekenkracht NSA daarvoor over heeft. Het is niet voor niets dat men inmiddels op een minimaal 2048 bits RSA key over wil stappen. En NSA zelf zal uiteraard de laatste zijn die bekend zal maken wat ze al wel hebben weten te kraken.

Maar alleen al om de mogelijke MITM attack heb ik VPN nooit als echt "veilig genoeg" beschouwd voor onderschepping door overheden en geheime diensten, maar alleen als een leuk tooltje om het onderscheppen van dataverkeer door particuliere organisaties en hackers zoveel mogelijk tegen te gaan. Ervan uitgaande dat deze moeilijker in de hardware infrastructuur in kunnen breken dan dat de overheid dat kan. Let wel: "moeilijker", niet "onmogelijk" Daarom ook heb ik me nooit zo verdiept in de sleutelstructuur van VPN. Als ik zelf critische toepassingen via VPN zou moeten installeren zou ik dat alleen met regelmatig wisselende preset keys doen bij zowel de provider als de gebruiker.

Gezien de gigantische bedragen die overheden wereldwijd uitgeven aan het onderscheppen van datacommunicatie en het ogenschijnlijk daarmee tegenstrijdige gegeven dat het gebruik van RSA sind een aantal jaren geen strobreed meer in de weg wordt gelegd, doet mij vermoeden dat RSA al lang en breed is gekraakt. Dat in Engeland er de rechter bij te pas moest komen om de sleutels vrij te geven zegt immers helemaal niets. Het is juist van het grootste belang voor de geheime diensten dat de mensen RSA blijven gebruiken zolang ze denken dat het niet te kraken is. Opvallend in dat verband vind ik de toestanden met Skype dat immers een eigen geheim en gesloten algoritme gebruikt. Maar voor hetzelfde geld is ook dat weer zand in de ogen van criminelen gooien om ze aan te sporen Skype te blijven gebruiken omdat al lang en breed gekraakt is.

Voor de gewone doorsnee bedrijven zal dit allemaal weinig uitmaken. Zolang hun activiteiten niet in de belangstelling van overheden en geheime diensten komen te staan is VPN een prima middel om concurrenten en krakers buiten de deur te houden.

Echter; Het gegeven dat Turkije Navo partner is en ook van groot strategisch belang is voor de VS. (Turkije is een belangrijke aanvoerhaven van het Amerikaanse leger voor Irak). Het regelmatig voorkomen van soms zware terroristische aanslagen in Turkije (denk aan de aanslagen in Istanbul in 2004 en 2008). De Ergenekon en PKK toestanden en het gegeven dat TTNET formeel wel, maar in in de praktijk nog lang niet los is van de Turkse overheid en als beheerder van die infrastructuur ongetwijfeld al dan niet gedwongen afluister apparatuur en "lirs" in die infrastructuur zal hebben geplaatst, deed mij vermoeden dat TTNET e.e.a ook gebruikt had om het gebruik van Youtube tegen te gaan. Dit des te meer omdat de foutmelding die ik van Youtube kreeg precies dezelfde was als de foutmelding die ik kreeg zonder dat ik VPN gebruikte. Wat betreft Youtube en Atatürk: In Nederland klinkt zoiets volkomen absurd, maar het beledigen van Atatürk is voor zeer veel Turken, zeker de ultra nationalisten, een uitermate serieuze zaak. Lees ter lering en vermaak het volgende artikel maar eens http://www.nu.nl/opmerkelijk/1963882/turkse-boer-laat-koe-onderduiken.html En vergis je niet. Een hoop Turken op hoge posities zowel bij de Turkse overheid als bij het leger zijn zonder dat iemand daar weet van heeft lid van een of andere (politieke) organisatie, waar Ergenekon bijvoorbeeld een goed voorbeeld van is. Dus als zo iemand op een sleutelpositie bij TTNET vindt dat Atatürk wordt beledigd, is hij absoluut bij machte om zoiets te doen. Bovendien is de kans klein dat uitkomt dat VPN zou zijn gekraakt. In Nederland al helemaal niet omdat, voor zover ik weet, er geen verboden sites zijn. Je komt daar dus alleen achter door situaties zoals in Turkije waar je VPN moet gebruiken om youtube te kunnen bekijken en dat dat desondanks (in mijn geval schijnbaar) toch wordt geblokkeerd.

Dit zou, voor zover bekend, de allereerste keer zijn geweest dat een organisatie als TTNET misbruik had gemaakt van de mogelijkheid de lirs te gebruiken, het bestaan waarvan, gezien hun reacties, de meeste van mijn critici trouwens ook nauwelijks van op de hoogte waren, en ik vond dat ik daar zo snel mogelijk melding van moest maken. Achteraf realiseer ik me dat ik e.e.a. anders had moeten formuleren. De kop van mijn stukje was wel juist, de inhoud van mijn stukje had anders gemoeten.

Tot slot nog dit: Mijn dank aan de mensen die mijn veronderstelling wel op een normale konden reageren. Verder echter een hele dikke vinger voor de flamende zogenaamde "deskundigen" Typisch eigenlijk dat ondanks dat jullie nooit fouten maken er toch zoveel in de IT fout gaat. Maar jullie zijn waarschijnlijk de uitzondering die de regel bevestigd. Van de flamers was echter, net zo min als ik, ook maar iemand op het idee gekomen dat de reden dat er geen resolv plaats vond, wel eens had zijn dat de harde schijf vol was. En ondanks al jullie "deskundige" commentaar over fingerprints is en blijft het een feit dat VPN, zonder 100% wederzijdse authenticatie, in principe lek is, zeker voor overheden en geheime diensten. En net alleen de Turkse, maar ook de Nederlandse overheid. Verder is mijn case er weer eens een goed voorbeeld van dat een niet aan VPN gerelateerde fout in het systeem, uiteindelijk toch kan leiden tot een lek.

Wat betreft de harde schijf: In feite off-topic maar ik wil toch even laten weten wat daarmee gebeurde:

Ik moet e.e.a nog verder uitzoeken maar ik heb mijn werk partitie te klein gemaakt. Alvorens dit groter te maken wilde ik een bacup maken naar mijn externe usb schijf. Maar bij het maken van een back-up van grote bestanden gaat iets mis (op internet staan verwijzingen naar een Linux kernel probleem) Om te testen heb ik toen een 19 GB groot testbestand met een aantal veel kleinere bestanden op mijn externe USB schijf geplaatst. De volgende dag bleek mijn hard disk opeens helemaal vol te zitten. Uit een eerste onderzoek toen bleek een kopie van die backup in /media/extern te staan (extern is de label van mijn externe usb schijf) Dit terwijl de externe usb schijf helemaal niet meer fysiek aan met mijn computer verbonden was, laat staan dat ik de schijf aangekoppeld had. Uiteindelijk heb ik /media/extern maar met shift delete verwijderd waarna de 19 Gb op mijn harde schijf inderdaad weer vrijkwam. Tot mijn stomme verbazing stond de volgende dag (afgelopen zaterdag) die 19 GB toch weer in /media/extern zonder dat ik mijn externe usb schijf ooit nog weer aan had gesloten of aangekoppeld.

Vermoedelijk heeft anoniem 23:14 dus gelijk dat het vollopen van mijn harde schijf er de oorzaak van was dat ik toch weer met de DSN van TTNET te maken kreeg, wat weer de blokkade van Youtube door TTNET tot gevolg had. Een frappant voorbeeld van oorzaak en gevolg van zaken die op het eerste gezicht helemaal niets met elkaar lijken te hebben.

http://www.vpntunnel.se/en/ are a good VPN provider they have their servers in Netherlands with GE port. You get 100 Gb for only $7.

orally ?