HTTPS support
-
Right now the Duet WiFi web interface is wide open to anyone on your WiFi network. As long as your WiFi network is encrypted, that is still a restriction, though it does mean you can't use the Duet WiFi on a semi-public network like the one at a university (Eduroam, say). But it would be nice to have at the least a password protecting the web interface. Unfortunately, passwords aren't much use without encryption on the transport mechanism - encryption of the underlying WiFi really doesn't help against anyone who has access to the network: http://www.howtogeek.com/204335/warning-encrypted-wpa2-wi-fi-networks-are-still-vulnerable-to-snooping/ So to get the Duet WiFi network connection secure, it's pretty much necessary to implement HTTPS, HTTP over TLS. Which is how many of us do our shopping and banking, so it'd better be okay. Is it realistic to try to get HTTPS working on the Duet WiFi?
Implementing modern cryptography, even without attempting all of TLS, is a recipe for pain, suffering, and security holes. (I speak as one who has tried.) Fortunately there exist crypto libraries - even TLS libraries - designed for embedded systems. One example is mbed TLS https://tls.mbed.org/. Given the library, making the web server run on top should be straightforward. It can probably be stripped down to about 30k of RAM use, maybe a bit less, though it does more or less require dynamic memory allocation. Is this within the realm of possibility for the Duet WiFi?
-
I don't see anything in a 3d printer would interest what most hackers go for: money.
-
Unfortunately mischief is often sufficient. And you might be able to start a fire with control of a 3d printer.
-
I've looked at this but not in much detail. Two main issues:
1. Does the ESP have enough speed and RAM to implement TLS efficiently? I have read that is struggles, but that could be one particular bad implementation.
2. Most users don't understand SSL certificates and wouldn't want the cost and hassle of getting one.
So my initial focus is likely to be on making the login message more secure so that the login password info is encrypted and protected from replay attacks.
-
I don't think there is any real security to be had short of TLS. There are operating modes of TLS that are easier and secure enough in this application (pre-shared keys, for example), so if it can be implemented it would work. But TLS memory usage is going to be a problem for these wimpy devices. Unless you control the client you're pretty much stuck with a minimum 16k buffer size, plus anything needed to implement TLS.
A bit of searching suggests that mbed TLS is about the best you can do, and it requires something like 30-60k of RAM in the kind of configuration it needs to work with web browsers. There's also a certain amount of RAM required per client connected. I wouldn't worry much about speed.
I don't know anything about the ESP chip, including its number, but it does seem like the ESP SDK might actually include TLS support: https://io.adafruit.com/blog/security/2016/07/05/adafruit-io-security-esp8266/
-
I expose my Duet to the Internet through a reverse proxy (a machine running HAProxy) that adds a layer of HTTP authentication and TLS. Not the most convenient solution, but it works.
-
I do the same, and I actually prefer this solution because it offloads all the TLS overhead to a more suitable processor…I'm my case the quad-core Intel CPU running my PFSense firewall. The same could be easily accomplished with a Raspberry Pi, Beaglebone, Pine 64, etc.
Even if TLS isn't possible without impacting the snappy performance of the Duet web interface, I think a simple username/password arrangement like OctoPrint uses would be better than nothing. And if David decides to add Telnet support back it could be used to authenticate telnet sessions as well.
Honestly, I'm surprised security isn't taken more seriously with these "Internet of Things" modules such the ESP device the Duet WiFi uses. You'd think they would have some sort of crypto "acceleration" capabilities enabled in the silicon rather than relying entirely on the developer's software with only marginal resources available to accomplish it...
W3DRK
I expose my Duet to the Internet through a reverse proxy (a machine running HAProxy) that adds a layer of HTTP authentication and TLS. Not the most convenient solution, but it works.
-
The more I think about intelligent printer boards such as Duet, the more I believe the future has to involve letting a more powerful CPU (Raspberry Pi-level performance) running a high-level OS (embedded Linux or equivalent) do things like running the web server. A co-processor can do real-time things like running motors. I think Replicape does something like this?
Implementing an increasing amount of relatively high-level things without an underlying OS doesn't seem sustainable when there's a big and mature ecosystem for Unix-like OSes.
-
Machinekit achieves exactly that with the Beaglebone Black and a "CRAMPS" board. I have one and although it works well it's FAR from user-friendly when compared to a conventional controller board.
BeagleBone Black - https://beagleboard.org/black
Machinekit - http://www.machinekit.io/
CRAMPS "cape" - http://pico-systems.com/osc2.5/catalog/product_info.php?products_id=35The Beaglebone's TI ARM CPU has two embedded 200MHz 32-bit MCUs which Machinekit uses for real-time stuff like step generation, while the general purpose CPU cores run the Linux Kernel and does the gcode streaming, etc.
If someone bolted on a friendly web based interface like the Duet has and made it easy to configure like Duet, it would be a potent combination for sure!
W3DRK
The more I think about intelligent printer boards such as Duet, the more I believe the future has to involve letting a more powerful CPU (Raspberry Pi-level performance) running a high-level OS (embedded Linux or equivalent) do things like running the web server. A co-processor can do real-time things like running motors. I think Replicape does something like this?
Implementing an increasing amount of relatively high-level things without an underlying OS doesn't seem sustainable when there's a big and mature ecosystem for Unix-like OSes.
-
For expensive industrial printers, I think you are probably right. For low cost and hobby printers, the pricing doesn't work yet. The cost of adding a processor capable of running Linux would be too high, also the support costs would be much higher. Bear in mind that we don't have anything like the volume of the RPI and we don't manufacture in China. For domestic users, I think lack of https is only a serious issue if you want to use an unencrypted WiFi network or you want to expose the printer through the router.
I recognise that bugs in routers might allow the printer to be exposed unintentionally, and that is why I think it is important to make the login protocol more secure.
However, there are developments that may make it easier to support TLS. The ESP8266 will eventually be supplanted by the ESP32 (we have a sample already). Also, there are now even more powerful embedded processors available than the one we use on the Duet WiFi, at very little extra cost. So even if we can't implement TLS on the existing board, we will on the next generation one.
-
Ah, hmm. Yeah, I didn't consider the relatively small scale. Powerful chips seem to be everywhere these days. Even my IoT light switches run Linux, but D-Link sell huge amounts of those.
-
Yes but that's where the Cape/Shield idea currently makes sense. You can leverage the low pricing of a RPI/BeagleBone/whatever and drop the necessary supporting hardware right on top in the form of a Cape.
MachineKit with CRAMPS is halfway there, but there doesn't seem to have been much progress made in the form of a decent web based interface or useful things like delta auto calibration. Currently it's more of a platform for someone to build upon.
-
Passwords without encryption do not improve security substantially (*). It's easy - as in, "just download wireshark" - to watch all the traffic to a printer you want to mess with, as long as you're on the same WiFi network. And since people so often reuse passwords, such a system is likely to let attackers break into other systems that do have security. It's TLS or nothing. Or, I suppose, a dedicated symmetric-keys-only TCP connection to a server that forwards web requests. Personally I'm happy with letting anyone on my WiFi network access my printer; if I want to control it from elsewhere I can use SSH tunneling.
The Duet WiFi is already an MCU doing the heavy lifting of robot control, communicating through a specified custom protocol with a coprocessor that handles the network stuff. (Over SPI, I think?) Is there any reason the coprocessor couldn't just be a Raspberry Pi? That's how Octoprint works, except that the USB connection they use to connect the Pi to the printer is a terrible setup using a bad protocol. But the Pi has SPI, and it's probably easier to teach a Pi to talk a custom protocol to a Duet than it is to run a secure web server on the Duet.
(*) Actually, HTTP Digest authentication is not completely terrible. Only passwords hashed with one-time nonces go across the Net. And the only major new piece of code is an implementation of MD5, which you could probably just pull out of mbed TLS. Of course MD5 is terrible and broken, but it's not clear that it's broken yet in a way which ruins HTTP Digest. So this could be a fairly lightweight to add password support to the Duet web interface.
-
Anne
I have just looked at the RPI B+ cost is ~£20 so thats reasonable, and as you say it does have SPI.
The ESP headers, including the dedicated SPI are broken out on the production boards, under the ESP so that can be de-soldered, or not fitted, and you then have SPI and a few other control lines to connect to the RPI.The heavy lifting is writing a "driver" that talks SPI for the RPI. The other bit of work is porting DWC so it runs on Apache or similar, however that is not much work as it already partially runs:
https://www.duet3d.com/DuetWebControlSim/Also with an RPI you get the ability to add a video camera on the cheap.
Anyone following this thread used to writing code for RPI to access the SPI system?
-
(*) Actually, HTTP Digest authentication is not completely terrible. Only passwords hashed with one-time nonces go across the Net. And the only major new piece of code is an implementation of MD5, which you could probably just pull out of mbed TLS. Of course MD5 is terrible and broken, but it's not clear that it's broken yet in a way which ruins HTTP Digest. So this could be a fairly lightweight to add password support to the Duet web interface.
Hashing the password with a one time nonce is exactly what I has in mind, using one of the better SHA algorithms instead of MD5.
-
HTTP Digest is supported by browsers already, though. I guess your idea is to use a web form and set a cookie rather than HTTP Digest's direct inclusion in the headers? Both are somewhat vulnerable to spoofing, unless the Digest approach does something with one-off nonces. I suppose people are more used to typing passwords into web forms than having the browser pop up an authentication dialog.
Just to make sure I understand: although there are HTTP, FTP, and telnet servers in RepRapFirmware, the Duet WiFi runs all its network services on the ESP8266, right? I see there is an HTTP server there. Presumably it communicates with the Duet CPU via SPI, via G-codes and file transfers.
-
undefined Nazar referenced this topic
