Security Focus Interviews Damien Miller

An anonymous reader writes "The upcoming version 4.3 of OpenSSH will add support for tunneling allowing you to make a real VPN using OpenSSH without the need for any additional software. This is one of the features discussed in SecurityFocus' interview of OpenSSH developer Damien Miller. The interview touches on, among other things, public key crypto protocols details, timing based attacks and anti-worm measures."

Comments

Part 1 of the Interview

[uchihalush]

Could you introduce yourself? Damien Miller: I am one of the developers of OpenSSH and OpenBSD. I have been working on OpenSSH since starting the project to port it to other platforms (initially Linux) back in 1999, but found myself working more and more on the native OpenBSD version of OpenSSH and on the OpenBSD operating system itself as time went on. I also maintain a couple of other free software projects, most notably a collection of NetFlow tools (pfflowd, flowd and softflowd). The upcoming OpenSSH version 4.3 will add support for tunneling. What type of uses is this feature suited for? Damien Miller: Reyk and Markus' new tunneling support allows you to make a real VPN using OpenSSH without the need for any additional software. This goes well beyond the TCP port forwarding that we have supported for years - each end of a ssh connection that uses the new tunnel support gets a tun(4) interface which can pass packets between them. This is similar to the type of VPN supported by OpenVPN or other SSL-VPN systems, only it runs over SSH. It is therefore really easy to set up and automatically inherit the ability to use all of the authentication schemes supported by SSH (password, public key, Kerberos, etc.) The tunnel interfaces that form the endpoints of the tunnel can be configured as either a layer-3 or a layer-2 link. In layer-3 mode you can configure the tun(4) interfaces with IP or IPv6 addresses and route packets over them like any other interface - you could even run a dynamic routing protocol like OSPF over them if you were so inclined. In layer-2 mode, you can make them part of a bridge(4) group to bridge raw ethernet frames between the two ends. A practical use of this might be securely linking back to your home network while connected to an untrusted wireless net, being able to send and receive ICMP pings and to use UDP based services like DNS. Like any VPN system that uses a reliable transport like TCP, an OpenSSH's tunnel can alter packet delivery dynamics (e.g. a dropped transport packet will stall all tunnelled traffic), so it probably isn't so good for things like VOIP over a lossy network (use IPsec for that), but it is still very useful for most other things. Some companies have included crypto features in their hardware, for example Intel included a PRNG in some chipsets, and VIA bundled a full hardware set of crypto functions in its recent CPUs. How and when can OpenSSH take advantage of specific types of hardware like these? Damien Miller: OpenSSH depends on OpenSSL for cryptographic services and therefore depends on OpenSSL to take advantage of hardware facilities. On OpenBSD at least, this support is seamless - OpenSSL has hooks to directly use Via Padlock instructions (which are amazingly fast) or go via the crypto(4) device to use co-processors like hifn(4) or ubsec(4). On other operating systems, OpenSSL needs some application support to tell it to load "engine" modules to provide access to hardware services. Darren Tucker has posted patches to portable OpenSSH to get it to do this, but we haven't received any test reports back yet. Why did you increase the default size of new RSA/DSA keys generated by ssh-keygen from 1024 to 2048 bits? Damien Miller: Firstly, increasing the default size of DSA keys was a mistake (my mistake, corrected in the next release) because unmodified DSA is limited by a 160-bit subgroup and SHA-1 hash, obviating the most of the benefit of using a larger overall key length, and because we don't accept modified DSA variants with this restriction removed. There are some new DSA standards on they way that use larger subgroups and longer hashes, which we could use once they are standardized and included in OpenSSL. We increased the default RSA keysize because of recommendations by the NESSIE project and others to use RSA keys of at least 1536 bits in length. Because host and user keys generated now will likely be in use for several years we picked a longer and more conservative key length. Also, 2048 is a nice round (binary) number. Do you plan to add any other a

VPN over TCP

[apankrat]

Running VPN over TCP is bad for another major reason, which seems
to completely escape the attention of people promoting this type
of VPNs.

TCP is an UNAUTHENTICATED sessioned transport and the state of
entire VPN DEPENDS on it. Anyone capable of closing TCP session
can bring VPN down. Moreover VPN nodes may not even get a chance
to exchange a single packet if an attacker proactively resets all
connection attempts.

This is drastically different from standard VPNs that use IP or
UDP for data delivery. In order for a packet to alter VPN state
it must first be authenticated.

Essentially TCP-based VPNs are not resilient. They might be OK
for an occasional use, but deploying them in a production is
far too risky.