GoAhead/DMF Web Server Gets Micro-SSL Support

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

From the link

[Dancin_Santa]

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)

Re:From the link

[Anonymous Coward]

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 a

Re:From the link

[acaird]

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 no

Re:From the link

[onomatomania]

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.

Re:From the link

[perlchild]

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 s

Re:From the link

[TheLink]

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.

No TLS, AES or session caching

[Zubinix]

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.

Open Source Alternative...

[presroi]

Can someone think of any reason to use this one here instead of fefe's fnord http web server?

Web server: fnord [www.fefe.de] (by Felix von Leitner)

Tutorial [projectdream.org]:

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