HTTP Tunneler

[Armin]

Well I'm at school right now and I'm basically just pissed that almost every website I try to go to is blocked. When I get home, I'll probably install a HTTP Tunneler on my server. Anyone know of any decent remote HTTP Tunnelers written in PHP?

[iago]

Can you connect to external computers on port 22?  If so, you can tunnel through SSH, that's the best way. 

Alternatively, install an HTTP Proxy (not Socks) that runs on port 80.  An HTTP proxy basically tunnels HTTP requests over HTTP. 

[Sidoh]

I'm not very experienced in this area, but I don't think using a Proxy would make much of a difference.

Also, if your filter doesn't overlook content (IE page title, first few blocks of HTML, etc), you're still screwed even if you use HTTP tunneling.

[iago]

True, it would have to be encrypted.  I think you can  use a proxy over SSL, though.

[Sidoh]

True, it would have to be encrypted.  I think you can  use a proxy over SSL, though.

Yeah, I think that would work too, unless the content filter is in some way able to request/obtain the encryption key.  But then not very many pages on the internet have secured versions. :\

[iago]

True, it would have to be encrypted.  I think you can  use a proxy over SSL, though.

Yeah, I think that would work too, unless the content filter is in some way able to request/obtain the encryption key.  But then not very many pages on the internet have secured versions. :\

Well, you'd set up a proxy, which uses SSL.  Between the proxy and the destination page, who cares?

You <==encrypted==> filter <==encrypted==> your proxy <==unencrypted==> destination

[Blaze]

I just use www.formetopoopon.com to get around anything.

[Joe]

The filter sits right between you and the proxy and has access to everything you say to eachother, including the key exchange. Wheather it takes advantage of that or not is beyond me, but it has the ability to.

[iago]

The filter sits right between you and the proxy and has access to everything you say to eachother, including the key exchange. Wheather it takes advantage of that or not is beyond me, but it has the ability to.

No, because SSL uses public key cryptography.  I don't feel like explaining it again, but suffice it to say, public key cryptography isn't vulnerable to being sniffed, that's the entire point. 

[Sidoh]

The filter sits right between you and the proxy and has access to everything you say to eachother, including the key exchange. Wheather it takes advantage of that or not is beyond me, but it has the ability to.

What iago said.  It doesn't...

There isn't any key exchanging in public key cryptography.

[Quik]

Just install apache and php and grab a webproxy script (something like ezproxy.net if it were ever up) and mirror pages in a frame.

[iago]

The filter sits right between you and the proxy and has access to everything you say to eachother, including the key exchange. Wheather it takes advantage of that or not is beyond me, but it has the ability to.

What iago said.  It doesn't...

There isn't any key exchanging in public key cryptography.

There IS key exchange, but it's public keys.  When symmetric keys are exchanged over SSL (I'm pretty sure they are), they're encrypted with a public key.

[Sidoh]

There IS key exchange, but it's public keys.  When symmetric keys are exchanged over SSL (I'm pretty sure they are), they're encrypted with a public key.

Oh yeah, forgot the public/private keys had to be relational.  Silly me.

[Joe]

Er, when we were discussing MITM attacks, didn't you say that if you have the persons public key, you can read what they're saying, just not say something for them?

[Ergot]

Hmm I think it might be the other way around... You can send things but you can't read them.

[iago]

If the Proxy does a MITM attack (which is very doubtful), then ok, it can encrypt/decrypt all traffic.  I was talking about a traffic capture, which Proxies really do. 

[Sidoh]

Er, when we were discussing MITM attacks, didn't you say that if you have the persons public key, you can read what they're saying, just not say something for them?

A Proxy is a man in the middle.

[iago]

Er, when we were discussing MITM attacks, didn't you say that if you have the persons public key, you can read what they're saying, just not say something for them?

A Proxy is a man in the middle.

It's a MITM in a different sense.  A MITM attack is when the attacker is in the middle and decrypts/re-encrypts all packets with its own keys.  Proxies don't do that, they just forward. 

[Joe]

I'm not talking about the proxy doing it, I'm talking about the filter taking the key, decrypting the web page, and if its "bad", sending its own "Access Denied" page.

[Sidoh]

It's a MITM in a different sense.  A MITM attack is when the attacker is in the middle and decrypts/re-encrypts all packets with its own keys.  Proxies don't do that, they just forward. 

I know, it was a play on his words.

I'm not talking about the proxy doing it, I'm talking about the filter taking the key, decrypting the web page, and if its "bad", sending its own "Access Denied" page.

How's it going to decrypt the page with a public key?  SSL doesn't use crappy encryption algorithms.

[iago]

I'm not talking about the proxy doing it, I'm talking about the filter taking the key, decrypting the web page, and if its "bad", sending its own "Access Denied" page.

How's it going to decrypt the page with a public key?  SSL doesn't use crappy encryption algorithms.

To Joe: The proxy server is what does the filtering.  They're known as filtering proxies.  I could name some, but Google can name more.  And these proxies/filters aren't going to perform Man-in-the-Middle attacks.  That would be dangerous for anybody who's behind them, because it means that they could be attacked more easily. 

To Sidoh: It is possible, regardless of the encryption algorithm.  The problem is that whenever you request content from an encrypted page, there are two separate encrypted tunnels:
You: Key A
Server: Key B
Proxy: Key C

Outgoing data:
You ===encrypted with A===> Proxy ===encrypted with C===>Server
Incoming data
You<===encrypted with C===Proxy <===encrypted with B<===Server

So everything you receive is encrypted with the same key.  The problem there is that, whenever you go to an encrypted site, you'll get an error because the key you receive doesn't match the key that the server ought to have (because you're getting the proxy's key).  So you'll always get a warning, and if somebody IS doing an attack on you, you won't know, because you're still getting the wrong key.  For that reason, doing this is dumb, and no school or business would do it.

[Sidoh]

To Joe: The proxy server is what does the filtering.  They're known as filtering proxies.  I could name some, but Google can name more.  And these proxies/filters aren't going to perform Man-in-the-Middle attacks.  That would be dangerous for anybody who's behind them, because it means that they could be attacked more easily. 

To Sidoh: It is possible, regardless of the encryption algorithm.  The problem is that whenever you request content from an encrypted page, there are two separate encrypted tunnels:
You: Key A
Server: Key B
Proxy: Key C

Outgoing data:
You ===encrypted with A===> Proxy ===encrypted with C===>Server
Incoming data
You<===encrypted with C===Proxy <===encrypted with B<===Server

So everything you receive is encrypted with the same key.  The problem there is that, whenever you go to an encrypted site, you'll get an error because the key you receive doesn't match the key that the server ought to have (because you're getting the proxy's key).  So you'll always get a warning, and if somebody IS doing an attack on you, you won't know, because you're still getting the wrong key.  For that reason, doing this is dumb, and no school or business would do it.

But why would the server be encrypting something if it isn't an SSL page?  I thought we were talking about a Proxy that accesses the web normal means and then encrypts it using SSL and sends it to you.

[Joe]

See my thead about gaim-encryption, where I said "and it can still be decrypted", and iago says "Exactly!". I'd link, but I'm lazy.

[iago]

To Joe: The proxy server is what does the filtering.  They're known as filtering proxies.  I could name some, but Google can name more.  And these proxies/filters aren't going to perform Man-in-the-Middle attacks.  That would be dangerous for anybody who's behind them, because it means that they could be attacked more easily. 

To Sidoh: It is possible, regardless of the encryption algorithm.  The problem is that whenever you request content from an encrypted page, there are two separate encrypted tunnels:
You: Key A
Server: Key B
Proxy: Key C

Outgoing data:
You ===encrypted with A===> Proxy ===encrypted with C===>Server
Incoming data
You<===encrypted with C===Proxy <===encrypted with B<===Server

So everything you receive is encrypted with the same key.  The problem there is that, whenever you go to an encrypted site, you'll get an error because the key you receive doesn't match the key that the server ought to have (because you're getting the proxy's key).  So you'll always get a warning, and if somebody IS doing an attack on you, you won't know, because you're still getting the wrong key.  For that reason, doing this is dumb, and no school or business would do it.

But why would the server be encrypting something if it isn't an SSL page?  I thought we were talking about a Proxy that accesses the web normal means and then encrypts it using SSL and sends it to you.

Well, the solution of using a SSL proxy would replace server with "Your Proxy", which would make the diagram a bit bigger:

You: Key A
Your proxy: Key B
Proxy: Key C

If a MITM attack was being performed, it would look like:
Outgoing data:
You ===encrypted with A===> Proxy ===encrypted with C===> Your Proxy ===Unencrypted===> Webserver
Incoming data
You<===encrypted with C===Proxy <===encrypted with B<=== Your Proxy <===Unencrypted=== Webserver

But that's a different issue.  We're talking about:
a) The filtering proxy performing a man-in-the-middle attack on an SSL connection, and
b) Using a SSL proxy to bypass the filtering proxy

The diagram in this thread illustrates both parts of that. 

[Sidoh]

See my thead about gaim-encryption, where I said "and it can still be decrypted", and iago says "Exactly!". I'd link, but I'm lazy.

That doesn't have anything to do with my previous post.

Well, the solution of using a SSL proxy would replace server with "Your Proxy", which would make the diagram a bit bigger:

You: Key A
Your proxy: Key B
Proxy: Key C

If a MITM attack was being performed, it would look like:
Outgoing data:
You ===encrypted with A===> Proxy ===encrypted with C===> Your Proxy ===Unencrypted===> Webserver
Incoming data
You<===encrypted with C===Proxy <===encrypted with B<=== Your Proxy <===Unencrypted=== Webserver

But that's a different issue.  We're talking about:
a) The filtering proxy performing a man-in-the-middle attack on an SSL connection, and
b) Using a SSL proxy to bypass the filtering proxy

The diagram in this thread illustrates both parts of that. 

Maybe I'm misunderstanding this.  I thought that this would look something like the following

A -- Key A (optional since not all pages are SSL) -- You ( Key A )
B -- No key, since it doesn't need one -- Filter (assuming it can't be bypassed by simply changing/removing the webproxy)
C -- Key B -- SSL Proxy
D -- Key C (optional since not all pages are SSL) -- Webserver

Outgoing:
You ======> Filter ======> SSL Proxy ======> Webserver

Incoming:
You <===(encrypted with B)=== Filter <===(encrypted with B)=== SSL Proxy <====== Webserver

Since the data from the incoming website is encrypted using a public key and the filter doesn't know the private key (and the makers of the filter probably aren't going to waste enormous amounts of its resources deriving a private key from a public key; I would think it would take a lot of resources/time, anyway), it wouldn't be able to parse the content of the page and block you from viewing it if it doesn't like it.

[iago]

Data going between you and the SSL tunnel will ALWAYS be encrypted with the Tunnel's key.  The SSL Tunnel will decrypt it, and, if the end host requires it, re-encrypt it with the end hosts's key. 

[Sidoh]

Data going between you and the SSL tunnel will ALWAYS be encrypted with the Tunnel's key.  The SSL Tunnel will decrypt it, and, if the end host requires it, re-encrypt it with the end hosts's key. 

Oh.