After adding SSL to my HTTPWebSocket server, I found that originally it was not so secure due to the fact the the linux distribution I used did not get essential security updates. I used Qualsys SSL Labs: https://www.ssllabs.com/ssltest/analyze.html to analyze the security level of my server. Well, it started out with ‘grade E’. Finally, I ended up with ‘grade A+’. These are the steps to follow: Read More
As a next step, I created a SSL/HTTPS – Secure Web and WebSocket server in python. It can be found in github as wotking example and as (updated) gist:
In this post, I described how to setup a python webserver that servers normal webpages, as well as websockets at the same port. In other words, at the same page. I real application using it is the Plugwise-2-py web application. This application can actually switch on and off lights, so there are some demands on its security and robustness.
Enabling SSL/HTTPS in a python webserver is actually very simple. Read More
Ubuntu server 14.04 LTS does not get security updates to the ARM repository. Despite LTS standing for Long Term Support. Something that I did not expect.
When running webservers with SSL HTTPS on the Odroid-XU, it is vulnerable to several security issues, such as the POODLE and CCS Injection Vulnerability (CVE-2014-0224). This is solved in more recent versions of OpenSSL, but those are not available from the ARM repositories. To solve this OpenSSL can be build from source. CVE2014-0224 is solved from OpenSSL 1.0.1h, and POODLE from 1.0.1j. Generally it is best to install the most recent version of OpenSSL. The following steps describe how to get the job done. This is assuming the build is performed as the root user. Otherwise sudo may need to be added before the make install and cp and ln commands:
#update openssl to fix various SSL vulnerabilities
tar xzvf openssl-1.0.1m.tar.gz
./config --prefix=/usr/ --openssldir=/etc/ssl shared
make #make -j5 fails!
cp -a /lib/arm-linux-gnueabihf/libssl.so.1.0.0 /lib/arm-linux-gnueabihf/libssl.so.1.0.0.backup
cp -a /lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 /lib/arm-linux-gnueabihf/libcrypto.so.1.0.0.backup
ln -sf /usr/lib/libssl.so.1.0.0 /lib/arm-linux-gnueabihf/libssl.so.1.0.0
ln -sf /usr/lib/libcrypto.so.1.0.0 /lib/arm-linux-gnueabihf/libcrypto.so.1.0.0
Then to check whether the build succeeded, extended version information can be retrieved. Read More
I have extended Plugwise-2-py with a dedicated very light webserver and two web applications.
- Control Switches, Schedules and read actual power.
- Configuration: Circle properties and Schedule editor.
Plugwise circles have this nice schedule and standby-killer functionality. Using the standby-killer raises an issue for some devices. Like the need for a button to switch devices on again. And otherwise, one may prefer to turn on lights that otherwise are turned off by the programmed schedule.
For use under linux, in the open source domain, there were not many UI-based solutions available, so I felt the need of solving this. I developed a control app that works on phones, tablets and common webbrowsers on the PC’s. By using Bootstrap 3 and AngularJS technology, I ended up having a compact and dynamic application. And the webserver is standard library python!
Depending on the enabling of 10-seconds monitoring and/or logging of buffered circle recordings, the power reading is updated regularly. Circles which are configured as always-on, can’t be switched on or off, or operated by a schedule. This comes in handy when for example monitoring the production of solar PV installation, or monitoring your fridge.
I have written a HTTP and WebSocket handler in python being able to serve them on one and the same port:
Although this sounded very obvious as application, I could not find an example only using standard python 2 (2.7) libraries. There are some WebSocket extensions for well-known python web-server applications such as Tornado.
I wanted to make a web-interface for a python application controlling and reading Plugwise devices from small linux computers suchs as Raspberry Pi, Beagle Bone Black or Odroid U3 or XU. It would add value if it was a standalone webserver, not requiring further installation of something like LAMP, or having the need to copy the to be served files to specific webserver locations. Python has nice HTML page serving in its standard library.
As it had to become a dynamically updating application, I was considering server side events (SSE) or WebSockets. I found a few websocket implementaitons for python, but they all used lower level socket libraries. I tried to get two of them work to serve HTTP and websockets on the same port, but did only get it partially working. The upside was that I was starting to get a deeper understanding of standard python SocketServer, BaseHTTPServer and SimpleHTTPRequestHandler. This has led to a combined HTTP- and WebSocket server, which is able to use the same port.
I was inspired by two earlier implementations:
In its design it is simply using SimpleHTTPServer which just acts as a basic webserver responding to GET requests to serve files. This is specialized into a new HTTPWebSocketsHandler which overrides handle_one_request(self) to intercept any request to be able to handle it as websocket communication, once the connection is upgraded to a websocket.
The other method it overrides is do_GET() so it can tap into GET requests to detect a WebSocket upgrade request, and put the handler into the websocket state. For other GET requests, it just calls the super-class handler: SimpleHTTPRequestHandler.do_GET(self)
def do_GET(self): if self.headers.get('Upgrade', None) == 'websocket': self.handshake() else: SimpleHTTPRequestHandler.do_GET(self)
In the Plugwise-2-py application, I further specialize HTTPWebSocketsHandler into class PW2PYwebHandler(HTTPWebSocketsHandler) to handle GET and POST requests, where one normally would use PHP scripts to handle for example AJAX calls. If this specialized class decides not to handle the request, it calls the super class methods.
This handler also implemements overrides for the websocket handling, for example to publish and handle received MQTT messages.
See my github for the plugwise application: