Over a million developers have joined DZone.

What HTTPS Really Protects

DZone's Guide to

What HTTPS Really Protects

In this post, a security professional discusses the basics of HTTPS, how and why it is more secure, and the protocols it uses.

· Security Zone ·
Free Resource

Protect your applications against today's increasingly sophisticated threat landscape.

We see HTTPS in URLs more and more today. In the past, we used to use HTTPS to protect financial transactions - connecting to our bank, buying things online, that kind of thing. Web designers felt that there was no reason to impose the additional overhead of encrypted communications to protect an HTML-ized catalog, for example.

As websites became more functional, dynamic, and complex, this started to change. Consumers felt that not only did they want their financial details protected, but they wanted other things to be kept confidential too. Things like what they said on social media. Or who their friends were. And they sure didn't want other folks to be able to spoof them, and troll their friends. And so we began to use more and more HTTPS. Today, we have more HTTPS-protected websites than not. A good thing overall.

But what exactly are we protecting, and what aren't we?

So first, HTTPS is just HTTP over SSL (or today, TLS). Now, we have two different network models in common use today - the OSI model and the TCP/IP model. The TCP/IP model is a reductive mapping of the OSI model to modern networks, where the original seven layers of the OSI model are reduced to four (or five, depending on how you segment the bottom layers). We'll look at the four-layer TCP/IP model to describe how HTTPS works.

The four-layer model has the lowest layer, the Network Access Layer, where we run Ethernet and similar protocols. Right above that is the Internet Layer - this is where the IP protocol lives. Then, right above that, we have the Transport Layer. Think TCP here. Finally, we have the Application Layer. This layer maps to three layers in the OSI model - the OSI Session, Presentation, and Application layers. This is where both HTTPS and TLS are used.

TLS runs just below HTTP in HTTPS, encrypting all HTTP specific communications. All of it. This includes everything HTTP, like the URLs, cookies, contents, attributes, everything. But everything below the TCP/IP Application Layer is unencrypted. This includes port numbers, IP addresses, Ethernet addresses, really anything required to manage the connection to a host.

So the content of an HTTP request/response pair is encrypted, but only that.

So this provides some measure of confidentiality of transmission, certainly, but so what? What stops somebody from claiming to be Facebook, providing some encryption magic, and grabbing your info?


HTTPS can be used in either mutual or simple mode. The vast majority of the time it's used in simple mode, where the server authenticates to the client. In order to do this, the client must be preloaded with a certificate, that it trusts, that can be used to validate the certificate offered by a server. These prepackaged certificates, shipped with all major browsers by default, identify certificate authorities which issue certificates to folks to install them on servers. This way, when you connect to a server, the server offers it's certificate to you to prove to you that the server is who it says it is. You then validate that certificate using the preinstalled browser certificate, because you implicitly trust the certificate authority. If everything looks good at this point, you begin chatting with the remote server like an old friend. If not, well, proceed at your own risk.

So HTTPS allows you to verify that you're talking to who you think you are, and it hides what you're talking about. It does not, however, hide when you're talking, who you're talking to, or how often you keep in touch.

Rapidly detect security vulnerabilities in your web, mobile and desktop applications with IBM Application Security on Cloud. Register Now

https ,ssl/tls ,security ,web security

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}