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

Effective cryptography is a hard problem.

[Sheetrock]

As suggested in the article, the better security gets, the more it will interfere with usability.

For example, if you create a VPN with this latest OpenSSH, a lossy network will hold up your traffic. Despite the fact that TCP/IP will try to continue operating with dropped packets, with OpenSSH if you miss one packet the loss cascades into succeeding packets until the client and server are able to resync or the packet is delivered. This accumulation of tolerances is not a problem with IPsec, which is designed cipherwise to work around occasional packet loss.

Most experts agree the product of the best cryptography will be indistinguishable from random noise. This means that it is difficult to share the benefits of compression with file encryption because random noise compresses very poorly, as anyone who attempts to archive their MP3s of today's artists will attest. Additionally, if you accidentally store your encrypted files amongst files containing random noise you run the risk of generating new data during decryption.

The secret is to understand the technology before you use the technology. The problem with encryption is twofold -- some people are overconfident in what they're using and either lose data or risk more than they would if they were fully informed, and others think it's too difficult a topic to broach and leave themselves open to exploitation by network explorers. Certainly when I was in the second category I became convinced of the problem once I saw tools like 'tcpdump' and 'ethereal'.

Re:Effective cryptography is a hard problem.

[blahnana]

Most experts agree the product of the best cryptography will be indistinguishable from random noise. This means that it is difficult to share the benefits of compression with file encryption

Surely not if you compress it and _then_ encrypt it?

Re:Effective cryptography is a hard problem.

[HermanAB]

"Grammer tip" - Looks like you need a "Speling tip" too. :-) Oh well, what the hell...

Re:Effective cryptography is a hard problem.

[interiot]

the better security gets, the more it will interfere with usability

What does that have to do with TCP-over-SSH? Secure or not, TCP-over-TCP is always considered harmful (PDF).

On the other hand, if TCP-over-TCP is your only option (eg. due to the lame firewall my employer set up), then SSH is a great option.

But what does that have to do with increasing security again?

Thanks guys

[pchan-]

OpenSSH just keeps getting better. Not just a great shell client and server, but support for multiple streams, secure tunnels, SCP, SFTP, every authentication method you could want, and finally VPN (the next logical extension). OpenSSH ships with every Linux distribution I can name (well, except embedded ones), the BSDs, and MacOS, and is available for Windows (under Cygwin) and every other major UNIX and UNIX-like OS out there. The code is all available to anyone for any purpose with no real restrictions (other than giving some credit to the developers), so you could include it in any app you make, regardless of license (GPL included). Thanks, everyone who works on this valuable tool. I think I'll go buy a T-shirt

Hacker Summary

[this great guy]

For those hackers who are already familiar with the forwarding features of ssh (-L, -R and -d options), and who are wondering what the hell is this new "support for tunneling", here is a hacker summary. Quoting TFA:

[This] 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.

Tun(4) interfaces are indeed very convenient. That's all folks !

Re:Hacker Summary

[interiot]

Holy cow, that's very convenient indeed. Though, most likely this will only make IT firewall admins scowl even more at the mention of SSH forwarding.

telnet forever!

[Gravis Zero]

$ telnet 293.myremotepc.com
login: mr_moo
password: moowoo
> lynx slashdot.org

ssh is great and all but telnet is secure enough for me as far as __ALL_YOUR_BASE_ARE_BELONG_TO_US__ wha? who typed that? what's __H4X0RZ_4EVA!__

CONNECTION TERMINATED.

Yes and no.

[jd]

You are correct, but only as far as you go. It is possible to compress first and then encrypt. Indeed, this is generally regarded as the superior method, precisely because the compression will disguise a lot of the information that cryptography will leave behind.

Secondly, cryptography is generally expensive on the CPU but cryptographic processors exist. Motorola's processor unit (before they spun it off) had a very nice unit called the S1, which could encrypt or decrypt four streams in parallel. They had a very nice manual, describing the complete protocol to communicate with it. Despite this, I never have yet seen a Linux driver for it. A pity, regardless of what you think of the S1, simply because it would have been a good opportunity to win over those who do use such chips.

TCP offload engines are also beginning to come into the picture. When TCP stacks didn't do a whole lot, it cost more to offload than you'd gain by having a co-processor. These days, a glance at the multitude of QoS protocols defined in papers, the staggering range of TCP algorithms in Linux, and the complex interleaving of the Netfilter layers -- it almost has to be better to have all that shoved onto a network processor.

(Notice that I'm including more than just the basic operations here. It's the ENTIRE multitude of layers that is expensive. Linux supports Layer 7 filtering, virtual servers, DCCP. There's even an MPLS patch, if anyone cares to forward-port it to a recent kernel. IGMPv3 isn't cheap, cycle-wise. Nor is IPSec.)

There is also the crypto method to consider, too. RSA is expensive but ECC and NTRU are considerably cheaper. SHA-1 is much slower than TIGER and is not clearly better. Whirlpool is also better than SHA-1 on speed and strength.

I'll also mention that OpenSSH is sub-optimal on the implementation, that there are patches out there to make it faster. I mentioned those the last time OpenSSH became a hot topic. Even if the patches themselves aren't "good enough", they must surely be evidence that it is possible to tighten the code a great deal in places. If nothing else, slow code is more vulnerable to DoS attacks.

Re:Yes and no.

[rodac]

You dont understand the problem. The problem is not the TCP overhead (which is neglible) nor can it be solved by TCP offload engines.
The problem is that TCP over TCP just doesnt work and has well understood and well documented perfromance characteristics.

IPsec which does work, as CIPE and things like IPIP and GRE all have in common that they do NOT use TCP as a transport. IF you use TCP as transport for the tunnel and IF you transport TCP atop said tunnel it will just not work.

When tail packetloss occurs in TCP there will be a retransmission timeout, this will stall the tunnel and wreak havoc for the clock in the next upper layer TCP causing even worse stalls. Somehing that was well documented and understood many years ago.

You just can not run TCP over TCP. It just doesnt work. An offload engine will not change this.

I disagree on one point.

[Z00L00K]

There is actually a point in locking out (blacklisting) IP addresses from where a brute force is attempted. This since those bots often try one site at a time and scans for known login/passwords. It isn't that common that an attacker uses several different sources at the same time when attacking a site unless it's a DOS attack.

Blacklisting will at least make it harder for stupid bots.

kick arse vpn

[marcushnk]

Anyone seen this before?:
http://www.hamachi.cc/

Loos like a better way of doing VPN.. though ssh with in built vpn is going to be nice...

SSH tunnels is a stupid idea.

[rodac]

SSH tunnels and VPN can already today be done using ssh and pppd. i have used it for many years. It is still a stupid idea and useless for other things than toy networks.

SSH uses TCP as transport. You should NOT transport TCP/ip ontop of TCP. TCP over TCP has well known and well documented poor performance characteristics.

Google for TCP over TCP to find any number of researchpapers on why this just doesnt work, or try running IP traffic yourself across an SSH tunnel and find out first hand why TCP over TCP just dont work well.

Maybe, I hope, they plan to add a new SSH mode that uses UDP and will use UDP-SSH as basis for the tunnel. That would work. But you can neveruse more than one single TCP layer in any stack. If not (i.e. they plan to tunnel traffic atop a TCP ssh session) it will fail and they will learn.