[clug] Re: "Obfuscated TCP"

Daniel Pittman daniel at rimspace.net
Sun Oct 26 00:31:23 GMT 2008

Sunnz <sunnzy at gmail.com> writes:
> 2008/10/23 Daniel Pittman <daniel at rimspace.net>:
>>> 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.
> Ah, I see, so you really do need to pre share something to make a
> secure authentic connection, such as a preshared CA.
> About DNS, would DNSSEC give you strong authentication?

Kind of, because "strong authentication" is a slippery concept. ;)

Specifically, DNSSEC allows you to verify the links from the top down
when doing DNS resolution, so each level has implicit trust in the level

That makes the prospect of the Australian government being able to
arrange to bypass the security, by subverting the higher levels, pretty
unlikely -- so, you could more or less assume "yes" to that.

Anyway, assuming that DNSSEC is implemented from the root down for the
service in question, that makes the DNSSEC deployment at the root
servers a trusted third party certifying the data -- so, it fills that
particular role in the trust chain.

Sadly, this doesn't actually help with making your browsing secure: your
browser uses SSL and the PKI associated with that, not DNS, to identify
if it should trust the third party.

It would make it possible for a DNS based authentication system,
parallel to the standard SSL stuff, to be implemented.

So, yeah, it "kind of" gives you strong authentication -- you can use it
to build that, but someone would actually need to do all the work and
get it deployed for that to matter.

>>> 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.
> Ok. So say you know that the connection has been intercepted, and your
> VPN software wouldn't go further because it can't authenticate the
> other side... so what do you do then?

Personally?  Move to a country that has more liberal laws and better
personal protection from government snooping.  For you?  No idea.

> I mean, it is better to know that the connection has been intercepted.
> I guess what I am trying to say is, when the packet carrier purposely
> intercepting all encrypted traffic, then you are pretty much screwed,

Think about it this way:

If you knew that your partner was reading every SMS you sent or
received, you would choose some other method to set up a surprise
birthday party, right?

This is more or less the same: if you /know/ that something is
intercepted then you can decide what to do about it.  Maybe you don't
care, maybe you do it deliberately to provoke a legal issue, maybe you
avoid doing it.

If you don't know, though, you don't get any of those choices.  You can
assume that you are being watched, or that you are not, or that you
might be, but you can't rely on any of those...

> you just can't start a secure connection to anyone without the ISP
> inspecting your data... I mean, you can choose not to do anything at
> all, but then you won't get your data across... so effectively, the
> ISP would be like, "let us peek at your stuff, or we will simply
> denial to do our service for you.".

*nod*  They would, indeed.

At that point I would look for somewhere more liberal: a more liberal
ISP, a more liberal country, or whatever.  Because I know the problem
exists I can make an informed choice.


More information about the linux mailing list