[Cryptography] Why aren’t we using SSH for everything?

[Paul Wouters]

On Mon, 5 Jan 2015, Peter Gutmann wrote:

> Yup, IPsec is a whole minefield of problems.  For example:
>
>  Getting into IPsec-specific peculiarities, the way that traffic is protected
>  is that packets are pattern-matched to successive processing rules, with the
>  type of processing that gets applied being determined by the order of the
>  rules in the IPsec security policy database (SPD).  So if a packet matches
>  two rules, one saying that it should be sent out encrypted (PROTECT in IPsec
>  terminology, although strictly speaking PROTECT is an entire family of
>  actions because nothing is ever simple in IPsec) and one saying that it
>  should be sent out unencrypted (BYPASS in IPsec terminology) then the action
>  that gets taken is based on whatever happens to appear first in the SPD.

No. Sane implementations of IPsec/IKE have always ensured a better
policy. This is usually based on longest prefix match first. This is
what KLIPS (from freeswan to libreswan) has always done, and what
freeswan to libreswan has emulated for NETKEY/XFRM to do. Additionally,
libreswan allows a manual override (priority=) and has a group of very
low priorities reserved for opportunistic encryption, so that
opportunistic will always be picked only if no staticly configured IPsec
tunnel matches first. If you have multiple policies, you have to create
some kind of automatic or manual order. That is not at all specific to
IPsec. Of course, building it into your applications (and thereby
increasing the complexity and exposure of all your applications with
crypto code) hasn't really worked so well with SSL/TLS either :P

Or compare that with the security model of openvpn where the servers can
suck random routes out of your system :P

>  A real-world example of how sensitive traffic can end up unprotected as a
>  matter of course occurs when setting up a Generic Routing Encapsulation
>  (GRE) tunnel from one router to another.

This is like talking about the security and safely of the plane, and
then saying it's all weak and failure because the airport allows
terrorists to board :P Don't blame Airbus for airport security.

IPsec protects the transport. If you decide to use that secure transport
to build really dumb policies (like 0.0.0.0/0 GRE tunnels) then I cannot
help you other than pointing out your house of cards. You might have
build some privacy, but you definitely did not build something secure.
Sysadmins who build "routing based VPNs", where the policy is "allow all
to all" and the routes determine what you throw over the VPN are lazy
and not doing their job. And it's 90% of the big IPsec vendor's customer
base, so they had to make these unsafe features. Don't blame the
protocol, blame the admins.

>  Since it???s sensitive data you
>  define a security policy requiring that all data over the GRE tunnel must be
>  encrypted.  Some time later the router discovers a lower-cost route that
>  doesn???t involve the GRE tunnel and switches all the traffic across to that.

Of course you already configured an EGRESS filtering right? So you never
have accidental packet leaks? Which helps against the above AND all
other rogue stupid routing hacks and compromises you have on your
internal network aimed at your outgoing links.

>  As you can probably
>  imagine, split tunnels are an accident waiting to happen.

If you split tunnel is to RFC1918 space, again proper EGRESS should be a
fail safe. If you have a VPN to a public range, you should ensure that
range is added to your EGRESS filters if it is supposed to go over the
VPN.

>  It???s not just fancy features like split tunnels that cause issues.  Another
>  problem case crops up with IPv4 and IPv6 dual-stacked systems.  If the VPN
>  tunnel only supports IPv4 (as many do) then any DNS lookup that returns an
>  IPv6 address will result in traffic being sent over the unencrypted IPv6
>  link instead of the encrypted IPv4 one [349].

Yes, and everyone who owns a swiss army knife has managed to cut
themselves, and therefor these knives are bad and should be avoided at
all cost? You got a knife with 20 features - if you want to ensure you
don't cut yourself when using the knife as a screwdriver, get a
screwdriver.

> This illustrates what I mentioned in my previous message, that IPsec's
> transparency means that "it's indistinguishable from security that's not
> present".

While I'll admit that our tools could be better, I find these examples
to be extremely poor. It mixes up enterprise networking (where admins
are supposed to have clue) with enduser laptops (where users should not
need any clue).

There any many things wrong with IKE/IPsec, and if I did not have to
care about stupid decade old (and recent) certification nonsense, I
would be the first to strip out a lot of crap that the design by
committee caused. Unfortunately that would just mean people cannot use
our IKE/IPsec software. So please if you want to improve IKE/IPsec, tell
the certification people to update their stupid checkboxes.

Meanwhile, we have to ship a swiss army knife with 20 functions, and
you are like the young boy sucking his thumb because he cut himself on
his new swiss army knife :P


Paul