From: Paul Wouters (paul_at_xtdnet.nl)
Date: Wed Jul 31 2002 - 10:12:40 CEST
On Tue, 30 Jul 2002, Ian Brown wrote:
> > Ahh but my setup would be hosed. As soon as my freeswan sees the KEY/TXT
> > records are gone, *it* will stop doing OE, and so your connection to me will
> > in fact, not work. Ofcourse, DNSSEC would protect against this kind of
> > attack, but we're not there yet.
>
> Really? I don't see how you'd be hosed. If I don't see your
> key/txt, I won't even touch your udp port 500.. which means I'd talk
> directly to whatever port I want to connect to. This would bypass your
> freeswan completely.
Only if my machine is doing a passive form of OE (eg a webserver). But if my
machine does a regular (active) OE, then even though you sent it a plaintext
packet, it will still attempt to setup OE with your machine.
> Your OE would only be hosed as far as outgoing
> communications went. But I bet even that wouldn't be broken if you have
> your own dns server. you'd be asking 127.0.0.1 for your txt and key
> records... you wouldn't be talking to the man-in-the-middle so your
> system would keep humming along.
Indeed, it might be hard or impossible to fool the DNS of an OE machine. So
the attacker would have to mess up my dns records to you, and filter out
your dns records for me, and then our machines will probably talk in the
clear. Note that this is fairly difficult to do, and becomes even harder
with DNSSEC.
> In fact, I believe that this setup might
> even allow for half-way encryption... my text to you is plain, but your
> text to me would be encrypted. I wonder if freeswan looks for this and
> panics.
that can never happen. Either both machines agree on an IPsec connection,
or they don't. But they don't setup an IPsec connection one way.
> Lets assume that you are hosed. Are you saying that if your OE
> were to stop, you're whole system would be dead in the water? How would
> you administer it?
>From a machine that has absolutely no TXT/KEY records whatsoever, that
would never get into OE negotiations. Also, some machines I administer have
a host route set to a certain machine (over the normal default gateway).
This route is more specific then the OE route, so it will always be used first,
and thus bypasses OE. Ofcourse, i then only use that to connect with ssh.
> > No, when you put in the TXT/KEY records you advertise "If you can do IPSEC,
> > you may only connect with IPSEC and the keys I've specified". My machine
> > will insist on OE/IPsec, and we won't be able to communicate.
>
> Maybe there should be a configuration option that doesn't do it
> that way, but will try plain-text if all else fails.
You can get there by using passive OE. But you run into plaintext when two
passive OE machines talk to each other, which seems a missed opportunity.
> Perhaps you could set this by which port the connections are happening on.
> Say, disable if telnet, but let through if www.
That can be done by regular firewalling, regardless of wether the packets
arrive crypted or not.
> > I don't think so. your TXT record contains enough information for me to
> > initiate OE with you, even without a KEY record.
>
> I didn't know that. What is the KEY record for?
It is for the key. But OE also needs to know a potential gateway machine, so
it always has to look at the TXT record as well.
> Okay, So OE isn't meant to be a passive encryption type setup.
See above, it can be.
> It's
> supposed to replace many of thestatic tunnels we've got to set up by
> hand.
That's one partial goal. The other is to make configuration easier. Another
is to try and make more crypto connections happen in general.
> One of the problems I've got with this is that OE only protects the
> communications and not the system itself. With OE someone could still try
> to hack into your telnet service; the only difference would be that their
> hack attempt would be encrypted if they had OE.
Use normal firewall rules, just like for any non-IPsec system. If you are
using specific IPsec tunnels to restrict access to some machine, you shouldn't
be using OE.
> who gets to encrypt as well. I would much prefer a hacker having to do
> his business in plain-text then I would encrypted. This would be like a
> robber having to rob you during the daylight instead of at night. It
> would be a lot easier to detect.
I don't see the importance here. For the target system, the attack looks
similar to a plaintext attack. I've never investigated a hack by sniffing
the packets before it hits the machine. I'll easily sacrifice that option
for having generic crypto to that machine.
> As for the scaling factor, ssh is just as easy to use as telnet, yet
> there are no scaling issues like you would have with telnet + freeswan.
Not entirely true. You're obviously ignorning all the ssh key and known
host problems. you just type "yes" whenever ssh asks you if you're sure
you want to connect to a specific hostkey. If you truly wanted to do things
secure, you'd have to be constnatly be building/revising a known host key
list for you and/or your users.
> Why make it more complex than it has to? Also, what if you need to
> administer your router and you're not on an OE box? Does that mean you
> have to log in to your telnet server plain-text? With ssh, I just load a
> client on whatever I'm running and I'm good to go.
You can still run ssh to an OE box, as long as your client machine has
absolutely no IPsec keys, or if you have setup a specific route for
your client machine on the OE box.
> But allowing anyone to connect to *you* using OE...
Use regular firewall rules for that part. Wether or not the packets are
encrypted with IPsec is a completely seperate issue from wether you allow
certain services on that box to be reached by anyone.
Paul
_______________________________________________
Users mailing list
Users_at_lists.freeswan.org
http://lists.freeswan.org/mailman/listinfo/users
This archive was generated by hypermail 2.1.4 : Mon Aug 05 2002 - 21:01:34 CEST