"Obfuscated TCP" (was Re: [clug] OT: Protesting the proposed clean
daniel at rimspace.net
Thu Oct 23 01:19:47 GMT 2008
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
This is indistinguishable for opportunistic encryption within IPSec,
which operates on exactly the same basis, and can form any IPSec
supported associated dynamically.
> 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)
> It uses DH which from what I understand, you can't do a MITM, or can
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
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 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.
> 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.
 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.
 You don't.
 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.
More information about the linux