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