"Obfuscated TCP" (was Re: [clug] OT: Protesting the proposed clean feed?)

[Daniel Pittman]

Sunnz <sunnzy at gmail.com> writes:
> 2008/10/23 Sam Couter <sam at couter.id.au>:
>>
>>> I have been looking at "Obfuscated TCP":
>>> http://code.google.com/p/obstcp/ which from what I understand, it uses
>>> DH to establish an encrypted TCP connection between any 2 endpoints,
>>> could it possibly be used to make https remain a secure protocol free
>>> of interception?
>>
>> If I'm going to the trouble of setting this up, why not just use IPSec?
>> And what makes Obfuscated TCP more difficult to intercept than HTTPS
>> already is?
>
> From what I have read, it just seems like OTCP is easier for the
> general public, if both client and server side supports it, it kind of
> just does it automatically, the user don't have to click on anything
> special

This is indistinguishable for opportunistic encryption within IPSec,
which operates on exactly the same basis, and can form any IPSec
supported associated dynamically.[1]

> OTCP is installed on their computer, any OTCP enabled servers will do
> encryption automatically. Like wise, if only one of the side doesn't
> support OTCP, the OTCP-enabled side just knows what to do, no user
> interaction required.

Again, these are the same properties that IPSec (or TLS, come to that)
protocols have.

> It uses DH which from what I understand, you can't do a MITM, or can
> you?

Absolutely.  The ability to perform a "man in the middle" attack is
related entirely, absolutely, one hundred percent to having a
trustworthy proof of identity for the third party.

Otherwise, you know, you just used the DH exchange to securely verify
that you were talking to the police data logger -- which isn't exactly
what you set out to achieve, right?


That proof of identity generally means you need one of a secure channel
to pre-exchange identity information, or a trusted third party to vouch
for the participants.

In this case, where you have no pre-shared secret, and no trusted third
party, MITM is trivial: you have no way of verifying that the remote
host is, in fact, the remote host and not a third party in the middle of
the exchange.


Also, in the context of a legally mandated, nation wide system, you can
assume that DNS is subject to tampering; unless you have suitably strong
authentication there[2] then you have *no* assurance of, well, anything.


Finally, note that this is a risk with TLS as implemented in your web
browser: because you have a list of trusted third parties, it would be
possible to conduct a successful MITM attack with the cooperation of any
one of those trusted certificate authorities.[3]

> Anyway, yea, IPsec or VPN would be more general solution, except, when
> the ISP do intercept your connection, and use their own certificate,
> then what are you going to do? If you don't accept it you can't
> connect to the server you want; if you accept it then you know your
> connection is being intercepted.

Knowing that the connection has been intercepted is a significant
advantage compared to not knowing.

Regards,
        Daniel

Footnotes: 
[1]  In fact, the specific goal of the now defunct FreeSWAN project was
     to get this form of oportunistic IPSec security widely deployed on
     the Internet; the project shut down because after close to ten
     years of effort they had made practically no inroads on this task.

[2]  You don't.

[3]  Not an invisible attack, thankfully, but a successfull attack that
     would not raise significant red flags with traditional SSL
     certificate validation.  The newer extended validation, I don't
     know about, not having looked into the protocol closely enough yet.