HTTP vs. HTTPS: What's the Difference?

Target audience

This article is geared toward a general reader with a basic understanding of how the Internet works.

Introduction

When you surf the Internet, most web pages are delivered to your computer using a communications protocol called HTTP, which serves the vast majority of web pages on the World Wide Web. However, it can be a vulnerable communications scheme, which is where HTTPS comes into play.

HTTP

When a user types a web address into the browser’s address bar and presses ‘Enter’, a lot happens behind the scenes before the web page is displayed in the browser window. The client computer first queries a DNS (Domain Name System) server for the actual numerical IP address of the web server associated with the web address. Once it knows the IP address, the client computer makes a request for the requested resource from the web server. The server then responds and the web page is delivered to the user’s computer. All of this usually happens within milliseconds and uses a protocol called HTTP.

HTTP (HyperText Transfer Protocol) is the mechanism by which the vast majority of web pages are delivered over the World Wide Web. It is a server/client request protocol, in which the client (usually the user’s computer) requests a data package (usually a web page) from the server. For Example, When a virtual private server hears a request, it responds with a status response, normally “HTTP/1.1 200 OK”. It then follows with the requested data. So a request/response from a client to a server might look something like this:

CLIENT:
GET /index.html HTTP/1.1
Host: www.example.com
User-agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:42.0) Gecko/20100101 Firefox/42.0

SERVER:
HTTP/1.1 200 OK
Date: Wed, 16 Sept 2015 23:59:59 GMT
Server: Apache 1.3.3.3 (Unix)
Content-Type: text/html
Content-Length: 1922
<html>
<head>
<title>Welcome to my site!</title>
</head>
<body>
This is a very simple web page, written in HTML.
</body>
</html>

.
The protocol has been in use since 1991, and is a recognized, valid, useful communications protocol. However, it was never designed with security in mind. The exchange is unencrypted, meaning that if it is intercepted, anyone can read the contents of both the request and the response. It is particularly vulnerable to the ‘man-in-the-middle’ attack, in which an unauthorized computer acts as an intermediary between the user’s computer and the Internet, reading and logging all messages sent and received.

Securing the Web with HTTPS

There is another protocol, however, that works similarly to HTTP but is significantly more secure: HTTPS, which stands for HyperText Transfer Protocol Secure. HTTPS uses TLS (Transport Layer Security) to encrypt the communications between the client computer and the server, rendering the data useless and unreadable if it is intercepted. You may also hear TLS called SSL (Secure Socket Layer). SSL was the predecessor to TLS and many still use that term when talking about the technology that helps to secure HTTPS.

TLS works via digital certificates. Upon request, a Certificate Authority (CA) issues a certificate to a server, which serves to authenticate that server to any connected clients. In an HTTPS transaction, a client contacts a TLS-enabled server and requests an encrypted session. The server then responds with a copy of its digital certificate. That certificate includes the trusted CA that issued it and the server’s public key for encryption.

The client receives the server’s certificate information and can verify from the issuing authority that the certificate is valid. Once the client has satisfied itself that the server is authentic, it generates a random number. It then uses that random number to generate a session key. The client then encrypts the random number using the server’s public key, and sends it to the server. Because it’s encrypted using the server’s public key, the server is the only one able to decrypt the message with its private key. Once the server decrypts the client’s message, it has the same random number to generate the same session key client generated. From that point on, all communication between the server and the client is encrypted and decrypted using that session key. The information that is transmitted is just like the HTTP traffic, only now it is encrypted before sending, so if it should happen to be intercepted, the intercepting entity would be unable to decipher the information. Compare what the below HTTPS traffic looks like with the earlier example of HTTP traffic:

...........s.....*...."..*.....r.].di.s0.$. .<...v.b..'.....O..Z|.~$..!N...X...+./.
.......3.9./.5.
.............www.atlantic.net......
.................#..zS...$z.W..0.......c...#.;qu..*...3...... -.E;W...@..../P.rU..0.....5P......#X...n.b.......C.&...tRgW.a.....{v.......)...-1..J9S.V..G.In......|..u..O0.....mU...|..q..Ja.O.n..G..E.W}8E.Q...0..k3t.........h2.spdy/3.1.http/1.1..........
...........................c...................................................................................................
....Q...M..V.Q$._...9.&ye.L.i..T'.l.y..3`]| .<...v.b..'.....O..Z|.~$..!N...X./..................([email protected]...#8....u
..........(...........[[email protected]
.............g.m4..a..V&!B..d....bv.......3......&...c......
.....G...z..x.....SzV...H.P...L`...T.....s.{...ip....PY..)Z.[.<N.f}WOv$.>........../.....^.....hc ..e.\..`.L.!.c.m.=`...[....An...c2.N..?......$.|....M.?WA.x......NCIk.....j+VUZ..p...\ZM....=.<....Ra..S..% .o...{....\ nc..~c=.......'.]...D.t..p0.-b.8*g$Yo....!c...y.#......d..H9.o.+..'..xn\.... q.....H}-....Q>..D!...~.yV..v..
\Vi.P.....K.FV-........W.>]y....M...A\....>....i/o.+..b.P.."..H..xP..:......'...VX.......j.........0D...J..Zw....b.;b.
.....*.(..h.V.F.K..8..L.M.s...rwdc.{F%o.j....=.C...w.<.|..).3.. =32..g..>...h8(..;\}.h<....yP\6r.y..3.......592.W...r..pT.*.-D....e.]..).....
.....<.i..o`[email protected]_d"....m..!L .G.{........U.....[..r..S....a)?.SY...%....>...jl.....
.W.4.....X.Nd.....Z...%...a.;...om..mH..B.._...*......H..}(fi...,0..8..,}.[Z8.N..H...F....yj.N..b.^...].S.'......u..Z.j....spS.p.C.vhk...O..!..Y".|.w)El....t........R..h.....L.0i.M.)...E..V.C.....U........u..i.w......H..;.F.......u..
2Op.%........Z.>2.N2),.o..M..
...f.Z........7r9
.....

Obtaining a TLS Certificate from a Certificate Authority

Certificate Authorities offer a wide variety of TLS certificates. Prices vary depending on the extent of authentication desired. A very basic certificate (perhaps used to validate users within an organization, for example) is free. The three most common levels of validation are DV, or Domain Validation, OV, or Organization Validation, and EV, or Extended Validation. DV certificates are the most common, and are usually verified by emailing the controller of a domain name. OV certificates offer a bit more trust; the CA verifies not only control of the domain, but also the business uses that domain. EV certificates are the most trusted, and require significant documentation from the organization to prove that they are legitimate. These certificates are often used by organizations that want to present a secure web experience, particularly if they have a financial relationship with their visitors.

While the encryption process is strong, making the HTTPS messages particularly secure compared to unsecured HTTP transactions, there is one weak link in the chain: the Certificate Authorities operate on trust. If a CA were to be hijacked, for example, it could issue a trusted certificate for any domain that would be accepted as valid and trusted by all browsers. An attacker with such a certificate could then set up a fraudulent copy of that domain that would appear to be trusted with the intention of intercepting traffic to that domain. Such an event happened in 2011, where a Dutch CA was compromised by the government of Iran and used to intercept Iranian citizens’ browsing sessions. It is not a common occurrence, but it is one that security-conscious users should definitely be aware of.
.

Identifying an HTTPS Connection

The easiest way to verify your HTTPS connection is secure is to look at the address bar of your browser. Most browsers identify HTTPS connections with a padlock icon somewhere near the web address, while unencrypted HTTP connections have no such icon. Below is an example of a regular HTTP connection in Firefox, followed by example HTTPS connections in Firefox and Google Chrome.

HTTP connection in Firefox

HTTPS indicator in Firefox

HTTPS indicator in Chrome

You may also see a green lock icon that includes the organization or site name next to it. This more noticeable icon shows that the organization has acquired an EV certificate, as below.

HTTPS indicator (with EV TLS Certificate) in Firefox

Conclusion

HTTPS fulfills a need that HTTP leaves open — that of security. The exchanges and the protocol used are the same; only HTTPS adds an extra step of encryption that helps protect information passed across the Internet. While nothing is absolutely secure, it’s worth checking to make sure that a website is using HTTPS encryption before sending sensitive information such as passwords or credit card/bank account numbers across the wire.

Atlantic.Net

Since 1995, Atlantic.Net has been providing internet services to customers, including managed, cloud and dedicated hosting. In 20+ years of service, our solutions have been focused on providing the very best in web solutions to our valued customers!

Atlantic.Net Blog

HTTP vs. HTTPS : What is the difference?

Target audience

Introduction

HTTP

Securing the Web with HTTPS

Obtaining a TLS Certificate from a Certificate Authority

Identifying an HTTPS Connection

Conclusion

Atlantic.Net

Get a $250 Credit and Access to Our Free Tier!