Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Software Security

Security Focus Interviews Damien Miller 80

Posted by ScuttleMonkey from the bread-and-butter dept.
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."
This discussion has been archived. No new comments can be posted.

Security Focus Interviews Damien Miller More

Security Focus Interviews Damien Miller

Comments Filter:

  • Effective cryptography is a hard problem. (Score:5, Informative)

    by Sheetrock ( 152993 ) on Wednesday December 21, 2005 @02:30AM (#14306914) Homepage Journal
    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. (Score:5, Insightful)

      by blahnana ( 124569 ) on Wednesday December 21, 2005 @02:39AM (#14306942)
      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. (Score:4, Funny)

      by HermanAB ( 661181 ) on Wednesday December 21, 2005 @03:09AM (#14307042)
      "Grammer tip" - Looks like you need a "Speling tip" too. :-) Oh well, what the hell...

    • Yes and no. (Score:5, Interesting)

      by jd ( 1658 ) <imipak@ y a hoo.com> on Wednesday December 21, 2005 @03:38AM (#14307119) Homepage Journal
      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.

      • Wicked reply, all great points.

      • Re:Yes and no. (Score:3, Interesting)

        by rodac ( 580415 )
        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

        • TCP over TCP (Score:2, Insightful)

          by chosner ( 940487 )
          >>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.

    • Re:Effective cryptography is a hard problem. (Score:5, Informative)

      by interiot ( 50685 ) on Wednesday December 21, 2005 @03:41AM (#14307124) Homepage
      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 [sites.inka.de] (PDF [www.ispl.jp]).

      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?

    • Further tip - "Effect" and "Affect" are both verbs, but they don't mean the same thing. ("Effect" is also a noun.)
    • Informative? It looks more like "funny" to me.

      To wit: Additionally, if you accidentally store your encrypted files amongst files containing random noise you run the risk of generating new data during decryption. Didn't anyone read this post before they moderated it?

    • Most experts agree the product of the best cryptography will be indistinguishable from random noise

      So you are saying it will be written in Perl?
    • Grammer tip: 'Effect' is used as a noun. 'Affect' is used as a verb.

      ef-fect tr.v. 1. To bring into existence. 2. To produce as a result. 3. To bring about.

      af-fect n. 1. Feeling or emotion, especially as manifested by facial expression or body language: "The soldiers seen on television had been carefully chosen for blandness of affect" (Norman Mailer).

    • You may effect change - verb. So much for your smart quote. English is a complex language...

  • Thanks guys (Score:5, Informative)

    by pchan- ( 118053 ) on Wednesday December 21, 2005 @02:42AM (#14306952) Journal
    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 [openbsd.org]
  • Thank you devs! I've been waiting forever for the ability to do VPN like that. /me builds shrine

  • Hacker Summary (Score:5, Informative)

    by this great guy ( 922511 ) on Wednesday December 21, 2005 @03:01AM (#14307012)

    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 !

  • 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.

  • telnet forever! (Score:5, Funny)

    by Gravis Zero ( 934156 ) on Wednesday December 21, 2005 @03:14AM (#14307055)
    $ 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.
  • 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 [sourceforge.net]) and convert them to port forwarding requests compatible with old servers.

  • I disagree on one point. (Score:5, Interesting)

    by Z00L00K ( 682162 ) on Wednesday December 21, 2005 @03:47AM (#14307135) Homepage Journal
    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 (Score:4, Informative)

    by marcushnk ( 90744 ) <senectus@nOSPam.gmail.com> on Wednesday December 21, 2005 @04:45AM (#14307285) Journal
    Anyone seen this before?:
    http://www.hamachi.cc/ [hamachi.cc]

    Loos like a better way of doing VPN.. though ssh with in built vpn is going to be nice...
    • It looks like an udp-based, ssl-based VPN, only that it uses the "third server" trick to get NAT-to-NAT traversal. From the site:

      How Hamachi Works Hamachi is a UDP-based virtual private networking system. Its peers utilize the help of a 3rd node called mediation server to locate each other and to boot strap the connection between themselves. The connection itself is direct and once it's established no traffic flows through our servers.

      Looks nice, but nothing spectacularly new. It might be handy if y

      • A nice plus of OpenVPN is HTTP Proxy support- you can tunnel through a HTTP Proxy. The worst networks i've been on lock everything but HTTP, and that goes through a proxy server. No arbitrary UDP packets going out...
    • I couldn't resist to do a quick search... and here it is:

      nat-traverse [sourceforge.net]

      They even give specific examples of how to use it in combination with OpenVPN.

      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.

      • 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

    • Re:kick arse vpn (Score:3, Informative)

      by gfilion ( 80497 )

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

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

      Here's my not so humble opinion about Hamachi:

      Software review: Hamachi [filion.org]

      In short: some good, some bad, some really great, some horrible.

      • .. yes, a public, routable, full blown, IP address.

        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
    • "Whenever someone thinks that they can replace [IPSec] with something much better that they designed this morning over coffee, their computer speakers should generate some sort of penis-shaped sound wave and plunge it repeatedly into their skulls until they achieve enlightenment." -- Peter Gutmann [auckland.ac.nz]
      • Wesley, I am fully aware of this quote. Hamachi was not designed 'over the morning coffee'. Please have a look at http://hamachi.cc/security [hamachi.cc].

        Alex (ap@hamachi.cc)
        • Hamachi's security looks pretty good, but I just couldn't resist using the quote. If Hamachi is as secure (and thus as complex) as IPSec, why isn't it IPSec? And even so, Hamachi's protocols and code haven't gotten as much peer review as IPSec. Rather than reinventing the wheel, why not put your talents into (for example) designing a usable opportunistic mode for IPSec?
          • Hamachi is a second attempt at zero-conf system.

            I dealt with IPsec *very* extensively in the past and in the first revision we were in fact using IKE for p2p and SSL for client-server security. The issue was essentially that IKE was an overkill and SSL added 4 extra messages to the login sequence. Former affected development schedule and latter affected server performance under the load (yes, I am aware of HW SSL accelleration, it was not an option at that moment).

            For the second revision we stripped down al

  • SSH tunnels is a stupid idea. (Score:3, Interesting)

    by rodac ( 580415 ) on Wednesday December 21, 2005 @06:05AM (#14307498) Homepage
    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.

    • VPN over TCP (Score:2, Redundant)

      by apankrat ( 314147 )
      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
  • view source on the 2nd page of the interview.
    • Those hidden bits in full:

      Another statistic suggests that more than 80% of the SSH servers on the Internet run OpenSSH. I'm wondering if you have ever verified which version they are running, and what is the average behaviour of an OpenSSH administrator. Does people update the server as soon as a new release is available?

      Damien Miller: Funny you mention this, we just completed another version survey with the assistance of Mark Uemura from OpenBSD Support Japan. The results of this should be going u

    • Pesky paranoids..

      maybe a new form of stenography? or maybe its eliptical curve control to aid with the slashdotting?

      I wonder, do you check your logs as as vigourously as you do websites html source?
  • Is that the correct use?
  • 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 st
  • 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,
  • 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?
    • These are 2 options in the sshd_conf file

      #AllowTcpForwarding yes
      #PermitTunnel no

      You can disable TCP forwarding if you want
      You have to manually enable tunneling as it appears it is not on by default

      A brute force attack is no more feasible than it was before. Don't use password auth (or use good passwords) and you should be just fine.
      Also, if you have SSH access to an SSH server, you can likely already then access most devices that the SSH server can access already.

      I would trust an OpenSSH based VPN more than

  • Damien (Score:3, Funny)

    by blair1q ( 305137 ) on Wednesday December 21, 2005 @10:45AM (#14308780) Journal
    Damien, do you think that catchers will start using the inside protector any time soon?
  • Did anybody else first read this as interview of Dennis Miller?
  • 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 t

    • Re:SSH is SSH and VPN is VPN (Score:1, Informative)

      by Anonymous Coward
      "I'd like to see something like easier tunneling of X of an SSH session"

      WHAT???

      You, "olde scholar" find too dificult just `ssh -X user@host` and then `startx`?

      Now: how can it be any easier!?

Slashdot Top Deals

I have hardly ever known a mathematician who was capable of reasoning. -- Plato

Close