Just a quick&dirty guide on setting up SSL tunnelling in your development environment. This is written for Rails, but can be easily used for Django, Node, or any other web development.
Why SSL in development?
There’s no important reason to use SSL for development, but some times, you just seem to have to. I was trying to build an integration with helpscout, using their dynamic custom app. For some reason, helpscout forces you to use SSL for the external URL. Even for development. I won’t go into details why I think it’s unnecessary, but rather focus on how to set it up. After all, it might be something else that requires SSL within development, so here’s one quick way to do so.
Stunnel
stunnel is an openssl wrapper that makes it easy to tunnel non-secure protocols (HTTP, IMAP, POP3 etc) over SSL. It has a fairly simple configuration format and can be installed easily on both Linux and Windows. I focus this guide on Ubuntu/Debian.
Installing Stunnel
simply use sudo apt-get install stunnel4 on Ubuntu/Debian.
Enabling stunnel
edit /etc/default/stunnel4 and change ENABLED=0 to ENABLED=1
Generate a self-signed certificate
cd to /etc/stunnel, and run this command:
openssl req -new -x509 -days 365 -nodes -out stunnel.pem -keyout stunnel.pem
you’ll be asked to fill in some details. Since it’s a self-signed certificate, just put in whatever you like. It might be useful however that the CN (Common Name) is set to the DNS name of your development host. Do use a dns name and not an IP address though.
stunnel configuration file
Create a configuration file in /etc/stunnel/stunnel.conf. Mine looks like this:
cert = /etc/stunnel/stunnel.pem
sslVersion = SSLv3
pid = /tmp/stunnel.pid
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
[https]
; here we accept connections on port 443 and tunnel them to port 3000
; If you're using Django, change it to 8000...
accept = 443
connect = 3000
Running stunnel
To run stunnel, simply use sudo stunnel /etc/stunnel/stunnel.conf – it will automatically run as a daemon.
You can test that it’s listening on port 443 by using netstat -an |grep 443. You should see something like:
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN
And of course, run your development server as usual and then point your browser to https://<hostname> instead of the usual http://<hostname>:<port>.
Note that your browser will present a certificate warning, because the certificate is not trusted, and the CN might be different. However, for development purposes it should hopefully be enough.
Final thoughts
I find it odd that whilst some providers are not allowing you to use standard http urls, they typically do not perform any certificate validation. My self-signed certificate worked just fine (at least with helpscout, but if I recall also in other similar circumstances). In my opinion, if you’re concerned with someone eavesdropping on your communication (and hence force SSL), then you should really also force a more strict check on the certificate. Otherwise, any attacker who can eavesdrop on the communication, might be just as easily able to intercept and mount a simple man-in-the-middle attack. It’s true that the technical difficulty is slightly higher in the latter case, but I would dare say it’s not that much higher.
