[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

>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).


More information about the cryptography mailing list