SSL Encryption for Django’s Local/Native Server

Django comes packaged with a lightweight python server. It is not intended to be a production server but more a testing/development host. Running the server is as easy as running the following command within a Django project:

python runserver

Since it’s so lightweight, it doesn’t come with the same abilities as other servers like Apache or Nginx. It can’t perform encryption, however, there’s a nifty tool called stunnel that can do it for you!

“Stunnel is an open-source multi-platform computer program, used to provide universal TLS/SSL tunneling service” (Wikipedia).


The following steps were performed on my iMac running OS X Mavericks with a Django 1.5 installation. I believe my instructions should still work for different versions (most) and Linux distributions.


Initially, I downloaded the latest version of Stunnel, however I ran into numerous compiling issues. One of them being: “ld: warning: directory not found for option ‘-L/usr//lib64.’” The error indicated I did not have the necessary 64x library. When I downloaded version, 4.54, everything compiled nicely.

  • Download the stunnel-4.54.tar.gz source code.
  • Open a terminal window and run the following command to untar (unzip) the file.
 tar –xvf stunnel-4.54.tar.gz
  • Run the following commands to enter the directory and install the tool (credit).
cd stunnel-4.54
./configure && make && make check && sudo make install
  • During the install stage, you will be required to enter in certificate data. Stunnel will conveniently make a self-signed SSL certificate for you and save it to /usr/local/etc/stunnel/stunnel.pem. Thanks Stunnel!
  • Create a configuration file for Stunnel (credit). I put the file inside my Django project to keep things organized.
vim dev_https
  • Edit the file and add the following lines in order to manipulate Stunnel to work with your environment.
  • Save the file (For vim: ESC ‘:wq’ ENTER).


  • Start the Stunnel HTTPS tunneling service.
sudo stunnel <PATH OF dev_https>

  • Next, start your Django server.


Note – I used purposefully as my hosting IP address, I only want Django to run locally. I do not want the server to run on a public/accessible IP.  Only stunnel will receive web requests.

That’s it! Now stunnel is listening for all encrypted, incoming messges on whatever port you specified. When a request comes in, it will decrypt it and send it locally to your Django server. Following, Django will then respond through the tunnel to the requesting client with the proper data.

Stop the MitM Attacks! Use Encryption!

So I’ve been having fun with Amazon’s Developer Services for user authentication. In order to get the darn thing working, Amazon requires your server to use HTTPS. This isn’t a bad thing but in order to have HTTPS, you need to get a valid certificate. Now it’s easy to create a certificate (see below) however, not as easy to get a trusted certificate. Trusted certificates are those that are authenticated by a Certificate Authority or CA. I wouldn’t really trust a self-authenticated certificate. Reminds me of online dating where everyone lies, you kind of want a third party, reliable source to tell you the truth.


Here is the process to create a certificate request or CSR:

The below uses Openssl (this is native on a lot of Linux distributions, IIS on Windows handles these things differently).

Generate a RSA encrypted private key

openssl genrsa –out gen.key 2048

Create a CSR for the key

openssl req –new –key gen.key –out key.csr

Answer all the questions, leave the password blank, it’s not needed.

To get it approved:

Self (Untrusted…lame)

Remove RSA passphrase, if you don’t, the server you are running will require it upon each request

openssl rsa -in gen.key -out server.key

Generate a Year Long Certificate

openssl x509 -req -days 365 -in key.csr -signkey server.key -out key.crt


Take it to a company such as Verisign, Thawte and RapidSSL.

Wrap it Up

You now have a certificate that can be included in your server configuration. Check your documentation for the correct implementation. There are too many server variations out there for me to describe the process.

So why do we care about HTTPS?

Well it’s secure! HTTPS stands for Hypertext Transfer Protocol Secure and utilizes SSL/TLS protocol to lockdown communications. It is used to prevent man-in-the-middle attacks with the use of encryption (preventing some of the attacks in the ettercap post). If your data is encrypted, little hacker man can’t read it. This is why whenever you are entering in confidential information, look for “https://” in the URL, else your private data is being broadcasted in clear text (there was an ettercap attack mentioned in my last post that removed the security from a Facebook form, changing the login URL from HTTPS to HTTP… be warned).

Explanation of the SSL/TLS process:

  1. Client browses to a secure site (HTTPS)
  2. Hosting server sends its certificate and public key to requesting client
  3. The client’s browser checks the server’s certificate (Looks to see if it comes from a trusted CA, relates to the correct sire, and is currently valid) – This is why you should pay attention to browser warnings, it may be trying to prevent you from going to an untrusted site.
  4. The browser uses the public key to encrypt a random symmetric encryption key and sends it to the server
  5. The server decrypts the key using its private key, the following communication between hosts is encrypted with the symmetric key
  6. Once communications have concluded, the symmetric key is discarded

The Public Key is available to anyone and anything that wants it. Anyone can retrieve it from the server. That’s all fine and dandy. The Private Key, on the other hand, is kept a secret and only the owner knows it. These keys are mathematically related, whatever is encrypted with a Public Key can only be decrypted by its corresponding Private Key. So even though a hacker can get the Public Key, he/she cannot decrypted the SSL/TLS communications because they do not have the Private Key.

So here is an example of how it all works. Jack wants to send a secret message to Jill, he doesn’t want anyone else to read the message. So Jack,encrypts his message with Jill’s Public Key. Jill is cool with giving out her Public Key to anyone who wants it because it is after all public. Jill is the only person who can decrypt the Public Key because she is the only one with its corresponding Private Key. So now Jack’s message can only be read by Jill. Even if hacker Todd gets a hold of the encrypted data, he can’t read it because he doesn’t have the decryption or Private key.

Crazy security…