141–150 of 151 posts
In other words, if we know that they are cutting off the handshake at the ServerKeyExchange phase, for example, couldn't we generate large amount fake SSL traffic that stops one step before that, cause the router to hang?
Is it possible to bypass their physical network altogether? For example, is satellite Internet available/legal over Iran?
tl;dr: Iran gov't is the actor, not ISPs; filtering most but not all SSL in a couple different ways; specific targeting of privacy tools & Google.
See here (will be updating it soon w/ more): https://plus.google.com/u/0/103112149634414554669/posts/PT3e...
Earlier quoted context omitted.
TLV ( http://en.wikipedia.org/wiki/Type-length-value ) isn't recognisable as a protocol. It is something you'd have to hand-roll, i.e. serialize to. The resulting byte array would be encrypted using anything you like (I'm using RSACryptoServiceProvider), so it'd be unrecognisable to DPI. Not being familiar with specific DPI implementations I would imagine if such filtering was white list -based then anything unrecogn…
The obvious workaround is to uuencode your TLV data and then wrap it in . If it's properly formatted HTML, and the body isn't recognizable as, say, a ZIP file, DPI will pass it. Granted, someone could do entropy detection, and e.g. pass only things that look statistically like valid English/Persian/etc. text. But that needs more compute power, and can be worked around as well using statistical methods similar to Huff…
My experience of DPI is limited to Tenix diodes (which are white-list based, and are more focused around stripping malicious code by converting known objects to another format, eg .jpg to .png and back, or Word to PDF and back), or McAfee's Secure Web (used to be Web Washer), which does URL filtering, SSL scanning, etc. Also white list based.
Earlier quoted context omitted.
But DPI is used in Iran and just using different ports does _not_ help
Do you have any supporting data for your statement? I'm not trying to be an ass by asking; I'm actually curious, but testing it myself (American) is not particularly smart. Anyhow, if DPI is in place and at wire-speed (rare, but would cover everything), then the answer is obvious; ssh over http. It can be done with gothard [1] and corkscrew [2]. [1] http://www.nazgul.ch/dev.html [2] http://www.agroman.net/corkscrew/
http://www.slideshare.net/bleidl/net-neutrality-and-internet...
Earlier quoted context omitted.
If. That is why I asked the question.
They drop all secure connections. For security reasons, I had to access a VPS on port 33 (instead of 22), and in the past couple months I've been unable to do so.
Would it be possible to DDoS the deep-packet-inspecting routers with fake SSL handshake requests, or some partial part of it? Sort of like a TCP-SYN attack at the SSL level, and force them to give up DPI? In other words, if we know that they are cutting off the handshake at the ServerKeyExchange phase, for example, couldn't we generate large amount fake SSL traffic that stops one step before that, cause the router to…
I haven't checked yet whether they're using layer 7 filtering or just blocking ports, but assuming it was a lame combination of the two, you can try tunneling through HTTP on port 80. Download proxytunnel and follow this guide to set up Apache (or whatever server you prefer) to http proxy ssh connections to port 22: http://dag.wieers.com/howto/ssh-http-tunneling/ Then run ssh with proxytunnel as the ProxyCommand (as…
Link? :)
aaawwwww mannn... :(