Digg this story   Add to del.icio.us   (page 1 of 2 ) next 
OpenSSH cutting edge
Federico Biancuzzi, 2005-12-19

Federico Biancuzzi interviews OpenSSH developer Damien Miller to discuss features included in the upcoming version 4.3, public key crypto protocols details, timing based attacks and anti-worm measures.

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 algorithm to generate/exchange keys? For example, why didn't you include an implementation of ECC, used by the NSA?

Damien Miller: ECC (Elliptic Curve Cryptography) has some speed and key size advantages, but there are two impediments to use using it. First, no ECC key exchange method has been specified for the SSH protocol. This isn't too much of a problem as the protocol has a great extension mechanism that allows us to define new methods without breaking other implementations or having to go begging to the IANA for a number reservation.

The second reason is more of a killer: many ECC methods are patented. The NSA made the press recently for licensing these patents, something that we have neither the means nor the desire to do. There are ECC methods that are not patented, but the whole area is a minefield that we don't really want to navigate. Also, some of the ECC methods that are patented are the optimizations that give ECC its performance advantage.

On modern machines, the key exchange isn't much of a delay anyway and can often be avoided by using the connection multiplexing support that has been in openssh-3.9 (reusing the one SSH connection for multiple commands, file transfer or login sessions).

The recent version 4.2 "added support for the improved arcfour cipher modes from draft-harris-ssh-arcfour-fixes-02. The improves the cipher's resistance to a number of attacks by discarding early keystream output". Could you tell us something more?

Damien Miller: Remember that RC4 is a stream cipher; generating a stream of random-looking bytes (based on the key you feed it) that you XOR with the data that you want to encrypt. Fluhrer, Mantin and Shamir found that this early keystream can be correlated with the original key. This unfortunate property may be used to construct an attack that recovers the original key. In its strongest form, this attack is devastating (it is the basis of the 802.11 WEP crack for example) - fortunately the use of RC4 in the SSH protocol has been better engineered, but it still needed to be fixed.

An easy and computationally cheap way to avoid this attack is to simply discard this early keystream. These new cipher modes discard the first 1.5KB of keystream. This doesn't slow down the cipher at all, and so these modes are recommended for people who want to use a faster, but weaker cipher than AES. I.e. use these in favour of the original 'arcfour' cipher. A future release of OpenSSH will probably remove the old method from the default list of accepted ciphers.

Story continued on Page 2 



Federico Biancuzzi is freelancer; in addition to SecurityFocus he also writes for ONLamp, LinuxDevCenter, and NewsForge.
    Digg this story   Add to del.icio.us   (page 1 of 2 ) next 
Comments Mode:
OpenSSH cutting edge 2005-12-21
Alex Blewitt (1 replies)
Re: OpenSSH cutting edge 2005-12-21
Kelly Martin
Editorial: alter use of HTML-comments 2005-12-21
Anonymous (1 replies)
OpenSSH cutting edge 2005-12-21
Anonymous (4 replies)
Re: OpenSSH cutting edge 2005-12-21
Anonymous (1 replies)
Re: Re: OpenSSH cutting edge 2005-12-22
Anonymous
Re: OpenSSH cutting edge 2005-12-21
Anonymous (1 replies)
Re: Re: OpenSSH cutting edge 2005-12-29
Anonymous
Re: OpenSSH cutting edge 2005-12-22
Anonymous (1 replies)
Re: Re: OpenSSH cutting edge 2005-12-29
Anonymous
Re: OpenSSH cutting edge 2005-12-22
Anonymous
TCP over TCP considered harmful 2005-12-22
Anonymous (3 replies)
Re: TCP over TCP considered harmful 2005-12-22
Anonymous (1 replies)
Re: TCP over TCP considered harmful 2006-01-03
Baron von Leezard
Brute force attack 2005-12-22
Jules
OpenSSH cutting edge 2006-01-03
Anonymous (2 replies)
Re: OpenSSH cutting edge 2006-01-07
communIT
Re: OpenSSH cutting edge 2007-11-10
Anonymous
OpenSSH cutting edge 2006-01-24
Chris Kendon


 

Privacy Statement
Copyright 2010, SecurityFocus