[Openswan dev] Opportunistic Encryption thought over - x509 certificates vs DNS TXT records

[Marcus Blomenkamp]

Am Freitag, 16. April 2004 18:05 schrieb Paul Wouters:
>
> OE without any third party integrity check is meant to help against passive
> sniffers, not against active attacks againt you, wether it be dns or
> something else.
> Whatever the technology used, if A and B want to talk encrypted, and they
> never met before, you MUST have a third party to help you autenticate some
> (or more) trust. For OE, that is DNS (and preferably DNSSEC). One could
> also use X.509 certificates, but it isn't much better. Anyone can get a
> certificate your Windows machine will trust, it's about what? $25 ?

Hi,
then 'mea culpa' for not explicitly pointing out that i'd setup a CA 
beforehand. I thought this was implicitly clear to anyone.

WRT to windows machines one can easily remove those certificates from within 
the management console. But i want to focus primarly on Linux machines so 
this is not the point here.


> IPsec doesnt really help you secure a nameserver you don't control. And
> settingup an IPsec tunnel to a dns server YOU trust, still hardly means
> anything if that trusted dns server then has to query completely untrusted
> dns servers anyway.

Having a secure tunnel to a trusted dns server authoritative for my local zone 
is crucial for trustable intra-zone OE'd traffic in my opinion.  


> > Joe has a wireless LAN with several machines running GNU/Linux. Naturally
> > he wants them to communicate privately. However he has the IP addresses
> > [...]
>
> This makes no sense whatsoever. I am not even understanding what you are
> trying to say here.
> If you have a wireless network, and you want machines in that network to
> talk securely, the only thing you need to do is create an CA, which creates
> host certificates, and distribute an ipsec.conf from one server. This is
> exactly what we have done with "WaveSEC for Windows", a Linux based AP that
> also serves you an X.509 host certificate, and some tools to setup the VPN
> with a double click. Then all traffic goes via IPsec to the AP, and then
> further into the world unencrypted.

This is a nice piece of software for automanaging DDNS entries but it does not 
fulfill my requirements as it is subject to many attacks all based on the 
fact that communication to the dhcp server is untrusted.

1. One can subvert or generate dns entries without pre-authentication. 
Creation of a dumb key pair and guessing/sniffing of forward dns names is 
sufficient. 

2. One can personate as gateway system, to what extent depends on the exact 
incarnation of the gateway system (dns server on or behind gateway etc).

So an active attacker can replace any part of your infrastructure 
transparently. Please keep in mind that my primar concern is not anonymous 
traffic between anonymous machines on my network but trustable traffic 
between machines i own. As far as i interpreted the specs and docs WaveSec 
does not provide that.


> [... windows specific]
> Also, certificates just won't scale.

Then I'd say OE in its current form does not even walk uprightly ;)


> [...]
> I am not sure what you are trying here. If you would fetch a certificate
> from DNS, how can you trust that? You will need to check the cert's CA.
> Then can you trust that? If so, how? By Verisign? By microsoft pre-install?
> By a virus?

Trampling on my impreciseness does not gain anybody anything :(


> i am curious how you think to use certificates for "anonymous encrypted"
> connections. you have similar problems as with OE. If we can do this
> somehow with certificates, I'm all for it, since it would get us "OE" for
> the Windows platform. But I don't currently see how this can be done.
>
> If you can somehow prsent a flowchart of events that lead from two machines
> who never met before, to two machines using IPsec, based on certificates, I
> would be very interested in that, and I'm sure we could help implementing
> something as well.

I do not see either how certificates are more appropriate for anonymous 
connections. But i think most valuable traffic, und thus in most need for 
protection, is generated between participants who are not anonymous.

In dynamic scenarios (such as drafted above) raw rsasigs are worse manageable 
because a key infrastructure has to be duplicated just to ensure proper 
authentication of dynamic updates.

Certificates instead would solve this automatically, under the specific 
constrain of not having a static ip addresses burned into them.

It seems to me that adapting xSWAN to dynamic scenarious is often disregarded 
in design and documentation. On reading docs often enough one finds 
statements analog to: "We do not know how to handle this dynamically so you 
better keep your setup static". However reality isn't always that simple.

Currently i am developing something which one could call poor-mans OE. Based 
on actual ip address and network constrains prospective eroutes are added and 
removed from pluto as needed. Not to mention that it works tightly coupled 
with dhclient and survives address changes. This is all done in bash script. 
However pluto status output is not easy to follow then. Additionally I have 
concerns against having that many explicit routes from a performance point of 
view. Or can this be ignored generally?

best regards, Marcus