Miller on OpenSSH
Interesting interview:
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.
Comments
Greg • December 22, 2005 1:12 PM
I am interested in ppls idea about SSH and its complexity. It now got lots of options and fetures that in my opionin, reduce security. It looks like more fetures are going to be added…. Do we really need this?
Support for ssh 1 notwithstanding, woun’t it be better to have a small compact peice of code that can be easily debuged and tested. Than this trend to big complex systems which our current set of tools deals with poorly.
Jon • December 22, 2005 1:44 PM
Gah:
Presumably it will be able to be restricted by an option in the sshd_config file, just like the AllowTcpForwarding option.
complich8 • December 22, 2005 2:42 PM
Following up on Gah and Jon’s comments, I would also suspect that tunneling the whole system’s communications would have to be done with admin-level privs. Nonprivileged users can’t normally create device nodes and alter routing tables.
So, it’s probably more of an answer to an easier-to-implement version of openvpn.
To Greg’s comment, I’d say that the openssh devels are pretty aware of the point you’re trying to make, but there’s a difference between being feature-rich and being feature-rich at the cost of having a larger attack surface. It’s not like they’re adding a flight simulator, they’re implementing natural extensions to what it’s already used for.
If I can replace my openvpn tunnels with simpler ssh tunnels, then I’ve excised an entire attack surface from my systems. While superficially it seems like the added features are an increase in code complexity, for someone who’s using something else to satisfy features that logically could be implemented in openssh it’s actually a net decrease in exposure.
Paul Crowley • December 22, 2005 3:08 PM
Gah – I would guess that VPN tunneling would ship disabled out-of-the-box, and admins would explicitly enable it with suitable limitations.
Pity it transports the packets over TCP. That’s a good thing to write first, but it would be worthwhile adding a UDP transport option. Maybe that will be next.
PerfDave • December 22, 2005 3:35 PM
Hmm, TCP tunneling over SSH will be interesting. It’ll certainly be useful for rapid prototyping or quick fixes to system, but I think I’ll continue to use OpenVPN for deployed systems – it’s fairly trivial to set up in a sensible and secure manner.
Gah • December 22, 2005 4:15 PM
It’s not ‘tcp tunneling’. That’s been there forever. It’s layer2/layer3 tunneling.
And it’s been doable for a long time. But it being ubiquitous AND easy, means that I can see a lot of people with root doing bad things with it. Not necessarily evil, but bad as in dumb.
LIke bridging a network in a dmz to a local machine for ‘convience’.
Ray • December 22, 2005 6:41 PM
“I’m not too thrilled with the idea of a ubiquitous encrypted tunnel potentially on every server in the enterprise.”
Be that as it may VPN is here and here to stay. And it’s only going to get used more and more. I’ve seen my job go from working on it now and then to being almost full time over the past couple of years and it’s only going to get worse.
Having said that. Replacing ipsec with OpenSSH is like a dream come true and promises to be much more secure.
Ubiquitous encrypted tunnels are going to happen. The only question is how. Having the OpenSSH/OpenBSD team on the forefront of this can only be a good thing.
I feel like Santa has come early and brought me a working Firefly.
rodac • December 22, 2005 7:02 PM
I wouldnt worry too much about the tunneling options.
They have simply not tested the idea yet in real world environments or just fail to understand the problem space.
SSH uses TCP and you just dont create tunnels using TCP as a transport.
These tunnels would be TCPoverTCP which has well known and well documented poor performance characteristics. (google and find any number of whitepapers on why TCPoverTCP just dont work as you care to read).
Since this just will not work well at all outside of local toy networks i expect the feature to be dropped as soon as they learn why it doesnt work.
Anyway, i have personally used SSH tunnels for many many years, just see :
http://www.tldp.org/HOWTO/ppp-ssh/
or if you just want a single commandline, no configuration required :
http://www.lesbell.com.au/Home.nsf/b8ec57204f60dfcb4a2568c60014ed0f/f947a03d41f9c605ca256ef9000a0b95?OpenDocument
it just doesnt work well in real-world non-pristine networks.
rodac • December 22, 2005 7:05 PM
Seeing the comment i made:
As english is my second language i want to make some corrections.
I wish not to imply (the words “just see”) that i wrote that howto or am involved in in in any way.
I am not.
Just read it as JUST SEE “this is similar to what i have been doing for many years” and a lot of others are apparently also doing it.
rodac • December 22, 2005 7:08 PM
to Gah:
…”I can see a lot of people with root doing bad things with it”…
If they got root already the ability to create trivial tunnels would be the least of my worries.
Nix • January 8, 2006 3:52 PM
Oh, and Greg: adding extra features is fairly safe because of the privilege separation. Any attacker would have a job getting from the almost-permissions-free chrooted sshd talking over the network to the sshd with actual privileges.
Ted • January 8, 2006 4:22 PM
What do you suggest as a solution.
Subscribe to comments on this entry
Leave a comment
Sidebar photo of Bruce Schneier by Joe MacInnis.
Gah • December 22, 2005 12:43 PM
I’m not too thrilled with the idea of a ubiquitous encrypted tunnel potentially on every server in the enterprise.
I’ve spent years trying to get admins to use SSH. Now it may be a network security nightmare if the layer2/layer3 tunneling is abused.