Exploring HTTPS and Cryptography in Python (Overview)
Have you ever wondered why it’s okay for you to send your credit card information over the Internet? You may have noticed the
https:// on URLs in your browser, but what is it, and how does it keep your information safe? Or perhaps you want to create a Python HTTPS application, but you’re not exactly sure what that means.
In this course, you’ll get a working knowledge of the various factors that combine to keep communications over the Internet safe. You’ll see concrete examples of how a Python HTTPS application keeps information secure.
In this course, you’ll learn how to:
- Monitor and analyze network traffic
- Apply cryptography to keep data safe
- Describe the core concepts of Public Key Infrastructure (PKI)
- Create your own Certificate Authority
- Build a Python HTTPS application
- Identify common Python HTTPS warnings and errors
00:00 Welcome to Exploring HTTPS and Cryptography in Python. My name is Chris and I will be your guide. The ultimate goal of this course is to produce some code that allows you to issue certificates so that you can host your own internal HTTPS content. In order to do that, there’s a lot of things you need to learn along the way. First off, what is HTTPS and how does it work? Secondly, in order to test things over HTTPS, you’re going to need a web application, so I’ll show you how to use a little bit of Flask to do that. Third, moving into cryptography and how certificates work. Fourth, using Fernet ciphers as a symmetric cryptography mechanism to secure your content. Fifth, moving on to asymmetric cryptography. Sixth, how to actually use Python to write a Certificate Authority. Seventh, how to combine all of this into an HTTPS Flask application.
The code samples inside of this course were tested using Python 3.8, Flask 1.1,
requests 2.23, and
cryptography 2.9. Other versions should work equally well, but if you’re running into weird inconsistencies, always remember to check your versions.
As this course uses outside libraries, such as Flask and Python
cryptography, it’s expected that you have a basic understanding of
pip and virtual environments and be able to install these packages. Great! Let’s get started.
Your computer opens up a TCP/IP socket to the hostname. That host comes from the first part of the URL. If you type in
example.com it looks up the host
example.com. HTTP traffic, by default, is on port 80, so your web browser automatically opens port
80 to the server.
It also tells it that it was asking
example.com. It does this so that if the web server is hosting multiple domains, it knows which one you connected to. Finally, the
Accept parameter tells the server what kind of content that can come back.
POST is for sending content to the server, such as submitting a form. There are other methods as well, but we’ll skip over those for now. Secondly, the path tells the server what content to fetch. In the example before, this was
03:08 The request should also include the HTTP version. There are multiple versions of HTTP. This is the browser telling the server what version of the protocol that it wishes to speak. Most commonly, this is still version 1.1. Although version 1.0 is still around, 2.0 is becoming increasingly common and 3.0 is actively supported by most of the popular browsers. In addition to these pieces, the HTTP request can also include additional headers.
Cookies are a way for the browser and the server to keep common content through multiple connections. The
Cookie header is the browser telling the server that the last time they spoke, the server asked the browser to send this information back up on the next visit.
This is how cookies and state work. As I mentioned in the example, the
Host is the domain name of the server for multi-domain hosting. The
User-Agent header identifies the browser that is visiting the server.
This is an HTTP response. The two main parts of this are a status code—in this case,
200, telling the browser the content was served fine—and then some information about what the content type is. For
kittens.html, it’s going to be some HTML. Attached to this, then, is the body—the body being the HTML that’s being served. Now, the kitten’s adorable, but I’ve skipped over a step. Images actually don’t come down in the first hit.
05:37 The HTTP response itself always contains the version number. This is to confirm the version of the protocol that the server is speaking. Normally this is the same version as was included by the browser in the HTTP request.
The status code is a numeric code indicating the success or error of the call. Some ones are
200, indicating it was successful,
404, saying the path you asked for is not found, or
500, indicating something went wrong on the server-side. Just like the request, the response can include additional headers giving metadata about the response.
Some common examples are
Content-Encoding, indicating what kind of content the body has and how it is encoded,
Content-Length, the amount of information in the body, in bytes,
Server, identifying the web server that is serving the content, and
This corresponds to the
Cookie header in the request. This is the server requesting that the browser—the next time it connects to the server—sends up information that’s encoded inside of this header.
07:13 Instead of creating a new protocol, HTTPS is just HTTP over an encrypted channel. TLS is a way of encrypting that channel. Older versions also used SSL, but for the sake of the course, I’m going to concentrate on TLS. Because TLS is used to create a generic encrypted channel, this means it can be used for all sorts of protocols, including email, IM, and VoIP.
This separates the concerns between the encryption and the protocol being used over the encryption. Let’s look at an HTTPS connection. Like before, you type in the URL, this time with the
s on the end of
A socket is connected to the server. The port, notice, is different. The default port for web is 80. The default port for TLS is 443, so when you type in
https into your browser, the browser uses port 443 to connect to the server. The default nowadays, if you don’t type in the schema, is to use HTTPS in order to try and make sure that your connection is secure. Once the socket is established, TLS protocol is connected over that socket.
This is the encryption channel. Within that encryption channel, HTTP is then used to communicate to the server. This is the same as the previous example, just inside of the TLS channel. Throughout this course, I’m going to be using a command-line browser called
curl comes for free in Mac, Linux, and Windows distributions now.
If you’re using a slightly older version of Windows 10—before the 1803 build—you may have to go off to the web to download it, but otherwise, it’s there. In its simplest form, you type
curl and the URL that you’re going to.
By using the
-I parameter, you can look at the headers coming back from the server. In this case,
content-type: text/html, and the fact that I’m using Cloudflare to front the server.
This is actually how I get my HTTPS certificate—Cloudflare’s doing it for me. The
-I parameter only shows the headers that come back. You can use
--include, instead, to see both the headers and the content.
10:08 Next up, the secure connection is confirmed and a certificate comes back from the server, telling the browser who it is. The browser confirms the certificate through one of its known Certificate Authorities and then—because it passes—establishes the connection.
Become a Member to join the conversation.