Saving Opportunistic Encryption

sunder sunder at sunder.net
Wed Mar 17 06:02:17 PST 2004


Eugen Leitl wrote:

> No, anything requiring publishing DNS records won't fly. OE is
> *opportunistic*. It doesn't care about what the true identity of the opposite
> party is. Any shmuck on dynamic IP should be able to use it instantly, with
> no observable performance degradation, using a simple patch.
> 
> If it doesn't fit these minimal requirements, it will die, just the same way
> FreeS/WAN did.

I absolutely agree.  While it's possible to do things like MIM attacks if 
you don't know who the other guy is, look at how successful SSH is over any 
other kind of solution.  Its biggest competitor at the time it was 
introduced was kerberized telnet/ftp.  How many networks do you know that 
use Kerberos instead of ssh these days?

Look at how many folks use PGP - those who really know it and want it, or 
those who know enough about it and have some easily automated 
implementation that plugs in to their mail client. (i.e. commercial pgp 
with Eudora/Outlook plug in.  As an aside, I'm still pissed off that the 
Mozilla mail client doesn't support PGP/GPG in addition to S/MIME or 
whatever the hell..)

Adding another infrastructure requirement that requires ISP layer changes 
will exponentially raise resistance to its adoption.  While I do run my own 
server for mail/web, 99.9% of the internet luser population doesn't - and 
even so, I chose not to run my own DNS server.  (Allowing register.com to 
do so makes it safer for me: it's one less service that might be 
compromised due to possible bugs.)

Making it optional to add that infrastructure layer - whether it's via DNS, 
LDAP, signed public keys, web o' trust / pgp keyserver, finger, or even 
something entirely new, is probably the safer way to go, BUT don't require it.

There do exist transparent web caching proxies out there (usually 
advertised as web accelerators.)  I ran across such a few months ago when 
our satellite office couldn't connect to one of our servers.  We were using 
private dns virtual host names to access management web pages on our 
servers.  However the proxy intercepted those requests, and tried to 
resolve DNS, but obviously couldn't, so everyone in the office got a DNS 
error.  It took some pretty strong words to get the ISP to even admit that 
they were using such a beast, much less disable it just for us.

It's certainly possible to create a proxy to do MitM interception that 
would foil even SSH.  This wouldn't work so well against mobile devices 
which might fortuitously use a different route, but would work very well 
one hop above the server if that's the only pipe the server has.

There are ways to protect against this such as publishing a line for the 
known-hosts entry by other means, but no one does this (yet?)  (i.e: 
sneakernet, finger, web page, pgp signed/encrypted email, over the 
telephone, etc.)   (Another useful thing is to use public keys for SSH 
instead of passwords: this way the attacker won't be able to reuse your 
password - but you're still compromised the second you login.)

There are some rare cases where you absolutely want to know who you are 
talking to.  For example an https server that allows control of financial 
data.  Even in that case the server doesn't fully know who the client is, 
and doesn't need to (in order to establish the secure link) -- until a 
login (or CC info) is presented.  In the case of using OE to talk to a 
server, the client already has some idea of the server's identity, and the 
server will eventually have some idea of who the client is.


As an aside: Just doing the above to encapsulate emails won't help at all 
against spamming: the spammers will just randomly generate throw away 
public keys, etc.  They've already written trojan spammers with their own 
SMTP servers built in, it's only a few more (thousand?) lines of code to 
incrementally bypass that layer as well.

I've already seen a few years ago spam sites that return "yahoo.com" and 
"msn.com" in reverse DNS, but doing traceroutes reveals that they're 
actually in Korea or China, etc.  So you can't fully rely on (spoofable) 
DNS info anyway.


If any of you remember the recent virii attacks where the attachment is a 
password protected zip file with the password in the body of the email, 
guess what: the evil ones kicked it up a notch once more.

Just yesterday, I saw a new form of this on cpunx: instead of a ZIP 
attachment, the new malware uses a RAR archive, and instead of the password 
being in clear text, it's inside an a randomly named attached .GIF file! 
They've not obscured it, so it's possible to add OCR to the anti-virus 
code, but it's now it's that much harder for the anti-virus to block.

Just as the virus authors evolve their code to adapt their offenses to the 
defenses of virus scanners, so will the spammers evolve their code to 
bypass spam filters, and we've already seen that spammers use virii/worms 
to spread their code...

Distributed computing is already here.  Shame that it's biggest use is 
currently for evil.  Ugh! :(





More information about the cypherpunks-legacy mailing list