Skip to content

Instantly share code, notes, and snippets.

@ryanhiebert
Last active December 19, 2015 07:08
Show Gist options
  • Save ryanhiebert/5916022 to your computer and use it in GitHub Desktop.
Save ryanhiebert/5916022 to your computer and use it in GitHub Desktop.

Secure URIs

Right now, HTTP has a problem. This problem isn't unique to HTTP, but it is most aggrevous in HTTP. The problem is Secure URIs.

WARNING: I don't really know the history of the problem. I'm making up a nice story. The points are still valid.

Introduction

In the beggining, there was HTTP. And the whole world saw that it was VERY GOOD. They designated a protocol scheme name for it: http://, so that it would go in a URI like this: http://example.com.

Then SSL was born, and now HTTP needed to be secure to allow secret messages. So they designated another protocol scheme for HTTP, that included this security layer. Now there was http:// and https://.

Other protocols had been created too, not just HTTP, and these other protocols followed the same pattern, creating both a regular URI scheme, as well as a secure version. This made it easy to note that security was being used. So now, we had many more protocols, very often in pairs, such as ftp://, ftps://, smtp://, smtps://, imap://, imaps://, ldap://, ldaps://, and many more.

Now somebody said "why do I have to have two protocols for everything?" In order to make one protocol capable of both secure and insecure traffic, the STARTTLS command was born. Now, each protocol had to describe for itself how to advertise and register the TLS session it started, but the practice of using a STARTTLS command became widespread. Many protocols often prefer to use this STARTTLS instead of using TLS (what used to be called SSL).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment