[Cryptography] Why aren’t we using SSH for everything?
Peter Gutmann
pgut001 at cs.auckland.ac.nz
Sun Jan 4 19:37:28 EST 2015
Nico Williams <nico at cryptonector.com> writes:
>And it's even worse still: there's often no way for the application to even
>know whether IPsec protection is available, who the peer is (even assuming it
>couldn't change), nor request IPsec protection, for that matter.
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.
This, combined with the issues already mentioned above, makes creating and
working with IPsec policies a very complex and error-prone task [348].
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. 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.
The GRE tunnel still has encryption applied as required but all of the
traffic is going via the lower-cost unencrypted link, with the encrypted GRE
tunnel standing idle. All of the routing and security mechanisms are
working exactly as they should be, but the traffic isnât being protected.
This problem is particularly bad in the presence of VPN split tunnels in
which traffic for the corporate LAN is sent over the VPN and traffic for
everywhere else (for example general web browsing) is sent directly over the
Internet in order to avoid the overhead and cost of tunnelling it back onto
the corporate LAN and then straight back out again. As you can probably
imagine, split tunnels are an accident waiting to happen.
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].
This illustrates what I mentioned in my previous message, that IPsec's
transparency means that "it's indistinguishable from security that's not
present".
>Everybody missed that boat because the sockets APIs were designed in an era
>of rather small networks, and this screw-up (hiding higher-layer naming from
>the OS) got baked-in, persisted, and will continue to be part of our lives
>for many, many more years. Because compatibility.
If you're willing to add at least a small number of new functions to update a
thirty-year-old API you can fix a fair few problems at the low-hanging fruit
level. Look at, for example, Winsock's AcceptEx() (accept an incoming
connection, report peer identity information, and return the first data item
sent by the peer, all in a single function call), or WSAConnectByName() (whose
name pretty much explains what it does).
Peter.
More information about the cryptography
mailing list