HTTP Tunneler

[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.