Author Topic: HTTP Tunneler  (Read 2510 times)

0 Members and 1 Guest are viewing this topic.

Offline iago

  • Leader
  • Administrator
  • Hero Member
  • *****
  • Posts: 17928
  • Fnord.
    • View Profile
    • SkullSecurity
Re: HTTP Tunneler
« Reply #15 on: December 10, 2005, 05:06:24 PM »
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. 

Offline Sidoh

  • x86
  • Hero Member
  • *****
  • Posts: 17668
  • MHNATY ~~~~~
    • View Profile
    • sidoh
Re: HTTP Tunneler
« Reply #16 on: December 10, 2005, 05:08:31 PM »
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.

Offline iago

  • Leader
  • Administrator
  • Hero Member
  • *****
  • Posts: 17928
  • Fnord.
    • View Profile
    • SkullSecurity
Re: HTTP Tunneler
« Reply #17 on: December 10, 2005, 05:13:43 PM »
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. 

Offline Joe

  • B&
  • x86
  • Hero Member
  • *****
  • Posts: 10316
  • In Soviet Russia, text read you!
    • View Profile
    • William's Blog
Re: HTTP Tunneler
« Reply #18 on: December 10, 2005, 05:35:18 PM »
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.
I'd personally do as Joe suggests

You might be right about that, Joe.


Offline Sidoh

  • x86
  • Hero Member
  • *****
  • Posts: 17668
  • MHNATY ~~~~~
    • View Profile
    • sidoh
Re: HTTP Tunneler
« Reply #19 on: December 10, 2005, 06:06:08 PM »
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.

Offline iago

  • Leader
  • Administrator
  • Hero Member
  • *****
  • Posts: 17928
  • Fnord.
    • View Profile
    • SkullSecurity
Re: HTTP Tunneler
« Reply #20 on: December 10, 2005, 06:39:14 PM »
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.

Offline Sidoh

  • x86
  • Hero Member
  • *****
  • Posts: 17668
  • MHNATY ~~~~~
    • View Profile
    • sidoh
Re: HTTP Tunneler
« Reply #21 on: December 10, 2005, 06:45:40 PM »
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.

Offline Joe

  • B&
  • x86
  • Hero Member
  • *****
  • Posts: 10316
  • In Soviet Russia, text read you!
    • View Profile
    • William's Blog
Re: HTTP Tunneler
« Reply #22 on: December 10, 2005, 06:59:26 PM »
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.
I'd personally do as Joe suggests

You might be right about that, Joe.


Offline iago

  • Leader
  • Administrator
  • Hero Member
  • *****
  • Posts: 17928
  • Fnord.
    • View Profile
    • SkullSecurity
Re: HTTP Tunneler
« Reply #23 on: December 10, 2005, 07:05:52 PM »
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. 

Offline Sidoh

  • x86
  • Hero Member
  • *****
  • Posts: 17668
  • MHNATY ~~~~~
    • View Profile
    • sidoh
Re: HTTP Tunneler
« Reply #24 on: December 11, 2005, 12:34:35 PM »
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.

Offline iago

  • Leader
  • Administrator
  • Hero Member
  • *****
  • Posts: 17928
  • Fnord.
    • View Profile
    • SkullSecurity
Re: HTTP Tunneler
« Reply #25 on: December 11, 2005, 01:41:36 PM »
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. 

Offline Sidoh

  • x86
  • Hero Member
  • *****
  • Posts: 17668
  • MHNATY ~~~~~
    • View Profile
    • sidoh
Re: HTTP Tunneler
« Reply #26 on: December 11, 2005, 01:53:54 PM »
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. :)