Slashdot Mirror

← Back to Stories (view on slashdot.org)

GoAhead/DMF Web Server Gets Micro-SSL Support

Posted by timothy on from the smallness dept.

JimCricket writes "The world's most popular embedded web server has gained something embedded developers have long wished for: support for a small (~50kB) SSL library designed specifically for embedded use. See the press release. The GoAhead WebServer, SSL, and Device Management Framework (from Art & Logic) can now be built into a secure, small-footprint, embedded web application platform."

10 comments

  1. From the link by Dancin_Santa · · Score: 3, Interesting

    Love the quote:

    Mocana's software is optimized for embedded systems and NOT based on large, slow open source code.

    That and a buck fifty will get you a cup of coffee here at Slashdot.

    But I wonder about the usability of this kind of thing on larger platforms. The link also says that the SSL component is supported on Linux, VxWorks, Solaris, and Windows. It is also CPU-independent so it could theoretically run on any platform in existence given the right hooks into the OS.

    Why isn't anyone else able to come up with an SSL library that is that small? I can't believe that with all the work going into creating these libraries that someone else hasn't been able to build one that small too. Or is there something that we are not being told (like while the binary is only 50K, the runtime memory requirements are much larger)

    1. Re:From the link by Anonymous Coward · · Score: 3, Interesting

      Why isn't anyone else able to come up with an SSL library that is that small? I can't believe that with all the work going into creating these libraries that someone else hasn't been able to build one that small too. Or is there something that we are not being told


      The reason is that there's bugger-all demand for this sort of thing. Most use of SSL is in standard servers. Then you've got web-enabled devices, most of which just use straight HTTP with passwords because it's assumed they'll only ever be accessed over a LAN. Of the rest, many are running some standard OS/embedded OS like Linux or WinCE where you've already got SSL support. Then there's little things like cellphones and whatnot which have got vendor-specific SSL support (possibly as WTLS) already. What's left is web-enabled devices that need SSL, don't already have it provided by the vendor, and aren't running a standard OS. This is a pretty small market.
    2. Re:From the link by onomatomania · · Score: 4, Informative

      It's probably because SSL is like the 800lb gorilla... There are many components of the process: exchanging credentials, establishing the session, parsing the ASN.1 certificates, verifying the authority chain, etc. There was an article posted to Slashdot a month or two ago where someone that had a cryptographical background analyzed a handful of open-source tunneling apps and declared that they really stunk from a security standpoing. One of his conclusions was that developers seemed to have come upon the huge complexity of SSL/TLS and thouht to themselves, "I don't need all that garbage, I'll just roll my own with only the relevent parts." However, his conclusion was that all that cruft and complexity of SSL was why it was secure and that with few exceptions the best choice would have been to simply use existing SSL libs, even if they were large and cumbersome. To do otherwise made certain compromises, making certain attacks more feasible.

    3. Re:From the link by acaird · · Score: 3, Insightful
      The reason is that there's bugger-all demand for this sort of thing.

      I disagree. Yes, there's little demand for the average OSS user, which means it's unlikely that you'll ever see an equivalent OSS SSL library, but the assumption that most embedded devices are LAN only isn't quite accurate, mostly because LANs are fading with the growing number of wireless network devices. The physical security that was provided by CAT-5 needs to be replaced with something, and the safest thing for vendors to do is not to rely on then consumer to cope with the alphabet soup of WEP/SSID/LEAP/RADIUS/whatever, but to impose security on the end user. SSL is probably the single most broadly available means of security - everyone has it, whether he knows it or not. When your next VCR/DVR/stereo/refrigerator has built-in wireless and web access, won't you be happier with SSL?

      On another note, the article also mentions that Mocana is also providing an SSH server for embedded devices. Finally. telnet may yet die the death it so deserves.

      --
      Power corrupts. PowerPoint corrupts absolutely. E. Tufte
    4. Re:From the link by perlchild · · Score: 2, Insightful

      I'd like to qualify your "why it was secure" with a "Just what the heck are you trying to !@# secure?" "Oh, THAT!" "Well you're going to need 132112300000 things to go right" The key/cert pair management, etc... are complex issues dependant on the situation. Now most embedded systems tend to be used by even more diverse clients than other systems, and have "hands off" requirements, as well as storage requirements to make openssl,gnutls,etc... run for their collective mommies. Most embedded systems use small, flash-based devices for storage. Considering some of those factors, here's a few points:
      1) writing often isn't such a good idea, flash has rewrite-contraints built into it...
      2) writing a lot of data isn't that a good idea, as flash isn't as big as HD yet, and more expensive per byte.
      3) ssl/tls is a great idea, but a lot of it is meant to secure Internet traffic, not all embedded devices are connected to the great Net, and using different trust roots means you have to specify them in the flash somehow. Keep in mind that the end-user might have to do so, or some other integrator higher up in the vendor-chain.
      4) If you keep 3 in mind, and your vendor decides not to issue your device its own signing keys to minimize traffic(say it issues each device the public keys to validate transactions, but hardwires signing to a key trusted to a certificate it keeps off your network. Now imagine those keypairs are compromised, you would have an embedded system hardwired to trust a compromised key... Talk about a scary notion...
      5) Security in ssl/tls is based on the computational complexity of the math involved, and computing power is usually at a premium in embedded systems(your watch would have a hard time cracking a ssl transaction of more than a few kbytes, trust me)
      6) going back to the "What are you trying to secure?" question, most embedded systems designers don't always know what the ssl will be used to secure, so their assumptions may or may not be valid in a particular case, and that may hamper security...

    5. Re:From the link by TheLink · · Score: 1

      Openssl includes lots of other stuff as well - CA creation and management, cert format conversion etc.

      I won't be surprised if there's plenty to trim if you just want something for a server or client, even if it's client cert-based.

      That said, openssl doesn't look like it's gaining much more weight, which is a good thing. So in 1-2 years, embedded hardware will probably catch up.

      --
  2. No TLS, AES or session caching by Zubinix · · Score: 2, Interesting

    According to their info page here: http://www.mocana.com/ssl.html They implement SSLv3 with Triple-DES. What about TLS? How much would that add to their footprint? What about AES cipher and SSL session caching for the server? Seems to be a few pieces missing here.

  3. Umm, moderator? by Anonymous Coward · · Score: 0

    Why did you waste a mod point in this stupid topic no one will read on a comment that made a good point?

  4. Open Source Alternative... by presroi · · Score: 1
    Can someone think of any reason to use this one here instead of fefe's fnord http web server?

    Web server: fnord (by Felix von Leitner)

    Tutorial:

    To setup fnord to provide https, you need an up and running plain http fnord.

    Be aware that there are two methods on how to setup fnord using SSL. One is to use ucspi-ssl, or to use a patched version of ucspi-tcp. The patch can be found here. These two methods are a bit different. Specifics for each variant are marked in simple braces. For Example: (ucspi-ssl) or (patches ucspi-tcp)