Slashdot Mirror
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."
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'.
Try not. Do or do not, there is no try.
-- Dr. Spock, stardate 2822-3.
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
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
Thank you devs! I've been waiting forever for the ability to do VPN like that. /me builds shrine
Silence is golden... and duct tape is silver.
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:
Tun(4) interfaces are indeed very convenient. That's all folks !
As someone who uses and deploys OpenSSH in a fairly large environment as part of my 'day job', hats-off to the OpenSSH team. Great interview by Federico Biancuzzi (who apparently is a freelancer) as some nice questions were asked and some interesting, detailed answers were provided by Damien - this is not your usual fluff writeup - RTFA highly recommended.
Hulk SMASH Celiac Disease
$ 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.
Anons need not reply. Questions end with a question mark.
This new tunneling mode requires upgrading both the client and server. It should be possible to get more-or-less the same functionality using only client-side support: capture the packets sent to the tun interface, decode individual TCP streams (similar to slirp) and convert them to port forwarding requests compatible with old servers.
Stop worrying about the risks of nuclear power and start worrying about the risks of not using nuclear power.
You have to use randomly chosen types of compression. If you use the same type of compression repeatedly, it will tend to induce similarities into the plaintext, and thus the ciphertext is vulnerable if the eavesdropper can aquire multiple transmissions for a comparison attack. But why bother to compress? Bandwidth, memory, and disk space are cheap and getting cheaper, wheareas governments are becoming more intrusive. Better yet, add some random garbage.
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.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Blacklisting will at least make it harder for stupid bots.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
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...
"Consider how lucky you are that life has been good to you so far. Alternatively, if life hasn't been good to you so far
This requires you to be the admin at both ends to install this new version, this isn't always possible. If this were already the case then you could simply run pppd over an ssh session creating two ppp0 interfaces on each end (I do exactly this at the moment, but obviously may investigate tun0 further if I can actually find an advantage). This has been possible since they added pty support in to the pppd daemon, or you might have to kludge it with silly looped back cables from ttyS0 -> ttyS1 physically :)
With pppd at one end you can use slirp at the remote without needing root or an upgrade of sshd , with this you gain a natted vpn.
My reason for using this is to connect out to gain an Internet interface from behind socks, my sockified ssh client locally and root on an Internet based host lets me have a high speed ppp0 for direct access for things like online gaming or poorly written applications that can't cope with a socks f/wall or squid proxy. I'm not convinced companies will open an ssh hole in to a host on their network which will then gain multiple tun* interfaces for external VPN staff, especially when the norm is IPsec. For connections IN to work, a single ssh session is obviously all you need anyway unless you're some kind of Windows user or something that needs a host of open ports etc and GUI things run to be able to work.
solid and documented (!) security architecture,
built-in NAT-to-NAT tunnelling,
zero-configuration,
slick gui (where available),
stable, supported and rapidly maturing
it is really f$cking amazing
Looks nice, but nothing spectacularly new. It might be handy if you need to set up a VPN through NAT-to-NAT, but I'm sure there are many other (open source) systems which achieve the NAT-to-NAT thing.
Since I don't need NAT-to-NAT, my ssl VPN of choice is OpenVPN. Moreover, it can be used over udp or tcp.
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.
view source on the 2nd page of the interview.
Moreover, this technique looks like it should work with any kind of NAT, whether full-cone, restricted-cone, or symmetric. On the other hand, the "third-node" (mediator) technique will not work with symmetric NAT.
Is that the correct use?
Arash Partow's Philosophy: Be a person who knows what they don't know, and not a person who doesn't know.
Moreover, this technique looks like it should work with any kind of NAT,
Looks can be deceiving. Hamachi's main strength IS its NAT traversal capabilities. In addition to symmetric, cone-this, cone-that types, it supports traversing a handful of completely obscure NAT types. Like reverse sequential NAT (external ports are allocated in decreasing order), burst overloaded NAT (ports are incremented in random increments), and random port NAT. Statistically it can connect 95% of all UDP-capable peers. The rate of standard NAT traversal techniques (including nat-traverse thingy) is about 80%.
And, yes, I am involved with Hamachi project, so I do know what I am talking about.
3.243F6A8885A308D313
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.
3.243F6A8885A308D313
yes, ssh is a tool used daily by huge numbers of people and hats off to the development team for that gift to us. However, a serious black mark for the standards of documentation. In reality, no documentation at all that is easy to find apart from the man pages and an FAQ that assumes fairly high-level knowledge, if you check the website. There are plenty of third-party how-tos, but how do I know I can trust what a third-party says? It's 2005. I just find it incredible that this of all program suites is still in the 1970s hairy-beardy geek era with regard to providing clear and comprehensible information to the end-user.
Las qué passoun
tournoun pas maï
>>You just can not run TCP over TCP. It just doesnt work. Actually this is not true. TCP over TCP is a problem when you have packet delay and the back off times on the redundant layers cause a meltdown and stop your connection. When congestion is at a reasonable level, this will not happen. So TCP over TCP works fairly well if you don't have a near capacity link.
It's nice to see OpenSSH following in the footsteps of OpenVPN. They are using the TUN interface and the OpenSSL library, just like OpenVPN starting doing three years ago. I think this is a cool addition and will be fun to play with, but if you are thinking of using it to build a serious VPN, there are a lot better, more mature VPN products out there that have robust feature sets built on top of this kind of tunneling, like OpenVPN. Oh, and OpenVPN runs TCP-over-UDP, unless you really want TCP-over-TCP, in which case it can do that too.
When I read this my thoughts immediately drifted to network infiltration. If someone doesn't have to take the additional time to find the 3rd party software necessary for VPNing into my network, wouldn't that step an entire step out of breaking in? Granted it would be nice to VPN into work from anywhere using a protocol I can use about anywhere, but what would also prevent an entire internet cafe from launching a brute force attack using the same method?
Damien, do you think that catchers will start using the inside protector any time soon?
when will sftp chroot become integrated instead of a patch/hack?
Did anybody else first read this as interview of Dennis Miller?
Support the FairTax
.. yes, a public, routable, full blown, IP address.
/apankrat
No, it is not. It's exactly the opposite. The address is private and globally UNroutable.
Who the fuck do they think they are distributing IP addresses like that?
Hamachi uses 5.0.0.0/8 for *private* networking. We are not distributing Internet addresses, we are distributing IPs used in Hamachi's own routing domain. Which of course is fully isolated from Internet.
The only problem Hamachi can run into later on is if IANA starts assigning IPs from this subnet to Internet nodes. These nodes will need to employ some creative routing to get Hamachi going. That's it, no dead end. No broken Internet.
IPv6 is not an option. At least not now. Try talking your parents through setting up IPv6 stack on windows, and then making poor box work again.
PS In case if anyone has any doubts, - I'm involved with Hamachi project.
3.243F6A8885A308D313
And stop whining too.
Interesting comments, but SHA-1 isn't an encryption algorithm. It is a digest algorithm. Also, RSA and ECC aren't normally used for bulk encryption so speed is not a real issue there either. So, what is your point?
I really don't see the need for it. SSH is for probably 90+% of it's users, a console for a remote box. I really don't feel the need to establish a VPN from my desk to the server down the hall. I'd rather not have that built in to my SSH by default, thank you kindly. I'm from the "old school" - if it ain't installed, it ain't a problem.
Frankly, we're pretty happy using SSH as it is right now. I'd like to see something like easier tunneling of X of an SSH session. Other than that, unless you can spank the already rather well done open source VPN's that are out there, I could care less about VPN as a part of SSH.
2 cents,
Queen B
HDGary secures my bank