HTTP vs HTTPS
You obviously heard of “HTTP” and “HTTPS”. But do you know that we don’t have SMTPS in email?
SMTPS was actually introduced in the late 90s, but within a short period of time, it got
Whenever we mention the term “HTTP”, we are talking about “Plain Text”. When you load a HTML page, this is
how your internet service provider (ISP) sees the data.
When you submit username and password in a login form, it will be sent as Plain Text like
Your ISP can modify that data. In 2017, Comcast
HTTPS means fully encrypted. A secure connection is established first before exchanging any data.
That means your ISP cannot able to eavesdrop what you do online unless they have access to your
web browser or the web server or the private key. The snooped data would look like nothing but a
grabage text. So it’s not possible to inject code in the HTTPS case.
HTTP and HTTPS are two different protocols. HTTP official port is 80 and the HTTPS official port
is 443. When you visit www.facebook.com in HTTP, you are actually
connecting to www.facebook.com:80 and when you visit in HTTPS, you are connecting to www.facebook.com:443
Sir Tim Berners-Lee invented the World Wide Web in 1989 and introduced HTTP 1.0 in 1996 in an Informational RFC. HTTP officially became an
internet standard in 1997.
Now… let’s talk about some SSL/TLS history.
In the mid 90s, Netscape was the most popular web browser and the browsers were a paid software
at that time.
At that time, Microsoft also wanted to get into browser business. Microsoft’s Windows operating
system already had 90% of the market share. On new Windows OS releases, Microsoft included the
Internet Explorer browser for free, whereas you need to download other browsers. Keep in mind,
those were dial-up modem days. Hence, the internet speed was very slow. Microsoft strategies
helped them to gain browser market share. IE became the most popular browser in the late
Netscape actually developed the SSL protocol in mid 90s. The first version had some serious flaws
so they never released it to the public. Then, they released SSL 2.0 in 1995. But there were
still some flaws.
Microsoft created its own version of SSL for IE in 1995 and they called it the Private Communication
Technology (PCT). It works exactly like SSL 2.0 but it also fixed the flaws found in SSL 2.0
Netscape didn’t give up. They started to fix all the SSL flaws encountered back then and
released SSL 3.0 in 1996.
Industry insiders doesn’t want another SSL. So, they made Microsoft to negotiate a
deal with Netscape where a third party would take over the SSL and PCT projects and make it
open source. Thus begun the TLS Era. They named the new open source protocol as TLS.
TLS 1.0 is nothing but SSL 3.0 with some slight modifications. SSL was a proprietary protocol back then. All versions of SSL are outdated now. Your web servers
should not support SSL at all.
When it comes to marketing, the term “SSL” is widely used. So use the term “SSL” only if you are
planning to buy SSL certificates. For example, the search term “Buy SSL Certificates” can fetch you more relevant results than “Buy
TLS Certificates”. So, “Buy SSL, Use TLS”
HTTPS vs SMTPS
TLS 1.0 was introduced in 1999. HTTPS was
introduced in 2000.
HTTPS had some advantages when compared to SMTPS.
First, HTTP was relatively young standard while compared to SMTP. Email was invented in 1971 by
Ray Tomlinson. 10 years later, Jon Postel defined SMTP in 1982. When TLS 1.0 introduced in 1999,
SMTP was a very matured and widely used technology.
Second, HTTP already had redirect capabilities. 301 — Moved Permanently, 302 — Moved Temporarily.
Browsers can understand those HTTP status codes. So if you visit http version of www.example.com, the server can respond like this
HTTP/1.1 301 Moved Permanently
SMTP don’t have any such redirect capabilities.
Third, the majority of the people in the world, use web browsers for browsing the “world wide web
(www)”. So web browsers are the major HTTP clients. TLS is already a byproduct of both Netscape
and Microsoft. And they both held the major browser market share. All they have to do is just
add HTTPS support in their next browser versions. End of story.
In SMTP case, there is only a dozen commands out there. HELO, MAIL, RCPT, DATA, QUIT etc.
So it’s very easy to build your own SMTP client. That means the “SMTP Clients” are not
controlled by a handful of entities like “HTTP Clients”. Persuading every SMTP Client and SMTP
Server to support SMTPS is not possible here.
SMTP port is 25. When SMTPS got introduced they assigned port 465 for that. Since SMTPS is not
backward compatible, they discontinued that port and favoured Opportunistic TLS.
There is one problem here. A man-in-the-middle attack can be initiated in the Opportunistic TLS
that’s known as “STRIPTLS” attack.
In STRIPTLS attack, the attacker gonna strip the STARTTLS command. An experienced attacker would
make the command unrecognised by replacing the characters to make it compatible with the Packet
Size. e.g. STARTTLS => STARTXXX
Let’s go over our ESMTP example, one more time.
mail.example.com connecting to mail.yahoo.com with its IP address
yahoo.com => 220 mail.yahoo.com Yahoo ESMTP Service Ready
example.com => EHLO mail.example.com
yahoo.com => 250-Hello, nice to meet you, mail.example.com
yahoo.com => 250-SIZE 1000000
yahoo.com => 250-8BITMIME
yahoo.com => 250 STARTXXX
In the last example, the client (sender) is asking “Hello, What are the extensions do you
support?” and the receiver (server) responds with the list of extensions.
The attacker replaced the STARTTLS command in the last example. Since the client (sender) doesn’t
recognize the STARTXXX command, the whole mail will be transferred in “Plain Text”. Some ISPs in
the US and Thailand performed this attack on their customers back in 2014.
STRIPTLS attack is a serious issue. An attacker can hijack your social media account with the
help of STRIPTLS attacks.
e.g. Attacker Initiates forgot password request in Facebook, performs STRIPTLS attack. Now the
attacker has your password reset confirmation link. We are using Facebook as an example. It can be
applicable to any site that let you reset your password with a confirmation link.
Let's have a clear understanding of SMTP port history.
Year introduced: 1982
Since the inception of SMTP, the port always been 25. Port 25 is a public port. i.e. anyone can
use that port to deliver mail.
Port 25 will be used when a mail get transferred from one domain to another.
RFC 821 — Page 43 reads as follows
The SMTP transmission channel is a TCP connection established between the sender process
port U and the receiver process port L. This single full duplex connection is used as the
transmission channel. This protocol is assigned the service port 25 (31 octal), that is
IANA service name: smtp
Year introduced: 1998
When you send a mail from your mail client like iPhone app or any desktop mail app, SMTP is being
utilised in two areas. Submission and Transfer.
Your mail client (e.g. An iPhone mail app) submits the mail to the mail server (e.g. gmail.com)
The mail server performs spam and virus checks and then transfers the mail to the real recipient
(e.g. [email protected]).
So port 25 utilised for both “Submission” and “Transfer”.
After the invention of world wide web, internet started to see a hike in email usage. Mail
services like HotMail, YahooMail started to appear in the 90s.
There was a hike in email spam too. Hackers started to hijack user computers by spreading worms and use
them to send out spam mails without the users knowledge.
Internet Service Providers (ISP) who have millions of customers don’t want their Internet
Service utilised for sending spam mails. i.e. They don’t want their service used for “Transfer”
(direct-to-mx). Blocking all outgoing port 25 connections also blocks genuine mail submission connections.
So there was a need for another port dedicated for “Submission”. RFC 2476 introduced port 587.
It’s an exact replica of port 25 functionality. But requires authentication for mail submission
(i.e. iPhone mail app to Gmail Server).
In other words, port 25 is for “Public SMTP aka. Transfer”, port 587 is for “Private SMTP aka.
RFC 2476 — Abstract reads as follows
SMTP was defined as a message *transfer* protocol, that is, a means to route (if needed)
and deliver finished (complete) messages. Message Transfer Agents (MTAs) are not supposed to
alter the message text, except to add ‘Received’, ‘Return-Path’, and other header fields as
required by [SMTP-MTA].
However, SMTP is now also widely used as a message *submission* protocol, that is, a
means for message user agents (MUAs) to introduce new messages into the MTA routing network.
The process which accepts message submissions from MUAs is termed a Message Submission Agent
Messages being submitted are in some cases finished (complete) messages, and in other
cases are unfinished (incomplete) in some aspect or other. Unfinished messages need to be
completed to ensure they conform to [MESSAGE-FORMAT], and later requirements. For example,
the message may lack a proper ‘Date’ header field, and domains might not be fully qualified.
In some cases, the MUA may be unable to generate finished messages (for example, it might
not know its time zone). Even when submitted messages are complete, local site policy may
dictate that the message text be examined or modified in some way. Such completions or
modifications have been shown to cause harm when performed by downstream MTAs — that is,
MTAs after the first-hop submission MTA — and are in general considered to be outside the
province of standardized MTA functionality.
Separating messages into submissions and transfers allows developers and network
administrators to more easily:
Implement security policies and guard against unauthorized mail relaying or injection of
unsolicited bulk mail
Implement authenticated submission, including off-site submission by authorized users such as
Separate the relevant software code differences, thereby making each code base more
straightforward and allowing for different programs for relay and submission
Detect configuration problems with a site’s mail clients
Provide a basis for adding enhanced submission services in the future
This memo describes a low cost, deterministic means for messages to be identified as
submissions, and specifies what actions are to be taken by a submission server.
Page 3 reads as follows
Port 587 is reserved for email message submission as specified in this document. Messages
received on this port are defined to be submissions. The protocol used is ESMTP [SMTP-MTA,
ESMTP], with additional restrictions as specified here.
IANA service name: submission
The service name should have been termed as: SMSP (Simple Mail Submission Protocol)
Introduced: Early 1997
Discontinued: Late 1998
This is one messed up port.
When TLS got introduced in the late 90s, IANA quickly registered the port 465 with service name
“smtps”. In other words, this port is supposed to be used for secure version of the real SMTP.
i.e. Port 25 alternative (Transfer).
But there was no way to use that port in “Transfer”. The problem is identifying whether the
receiving server supports SMTPS or not. Recall our “301 — Moved Permanently” example. So they
took a different route and introduced Opportunistic TLS in port 25. i.e. STARTTLS
The port 465 was never used in the “Transfer”. Hence, IANA revoked “smtps” service and assigned
the port 465 to a completely irrelevant service called “URL Rendezvous Directory for SSM”
This is where things get interesting. IANA paid attention only to the “Transfer” part. But mail
client softwares started to use that port for “Submission”. i.e. Secure alternative for Port
Softwares are long lived. I mean, come on… People still use IE6.
When IANA assigned that port to some other service, developers continued to offer secure version
of port 587 unofficially in port 465.
RFC 8314 made port 465 official in 2018. So
IANA reassigned that port with the service name “submissions”. It’s not a plural form. “s”
stands for “secure”. It should be pronounced as “SubmissionS”
IANA service name: submissions
The service name should have been termed as: SMSPS (Simple Mail Submission Protocol Secure)
RFC 8314 — Section 7.3 reads as follows
Historically, port 465 was briefly registered as the "smtps" port.
This registration made no sense, as the SMTP transport MX
infrastructure has no way to specify a port, so port 25 is always
used. As a result, the registration was revoked and was subsequently
reassigned to a different service. In hindsight, the "smtps"
registration should have been renamed or reserved rather than
revoked. Unfortunately, some widely deployed mail software
interpreted "smtps" as "submissions" [RFC6409] and used that port for
email submission by default when an end user requested security
during account setup. If a new port is assigned for the submissions
service, either (a) email software will continue with unregistered
use of port 465 (leaving the port registry inaccurate relative to
de facto practice and wasting a well-known port) or (b) confusion
between the de facto and registered ports will cause harmful
interoperability problems that will deter the use of TLS for Message
Submission. The authors of this document believe that both of these
outcomes are less desirable than a "wart" in the registry documenting
real-world usage of a port for two purposes. Although STARTTLS on
port 587 has been deployed, it has not replaced the deployed use of
Implicit TLS submission on port 465.
Port 26 New Proposal
SMTP Over TLS on Port 26 is our new proposal.
Email "Submission" part supports both SMTP (587) and SMTPS (465)
Email "Transfer" part supports only SMTP (25). SMTPS is still missing.
Our proposal offers two ways.
1. STARTTLS Prefix
Use this prefix on your MX records only to deal with STARTTLS downgrade issue.
e.g. mx1.example.com should be prefixed like starttls-mx1.example.com.
Where “starttls-” says “Our port 25 supports Opportunistic TLS. So if STARTTLS command not found in the EHLO response or certificate is invalid, then drop the connection”.
2. SMTPS Prefix
Use this prefix on your MX records if you wanna support both Implicit TLS on port 26 and Opportunistic TLS on port 25.
e.g. mx1.example.com should be prefixed like smtps-mx1.example.com.
Where “smtps-” says “We prefer if you connect to our SMTPS in port 26. But we also accept mails in port 25. And our port 25 supports Opportunistic TLS. So if STARTTLS command not found in the EHLO response or certificate is invalid, then drop the connection”.
In “starttls-” prefix, port 25 MUST support encryption with Valid SSL certificates.
In “smtps-” prefix, BOTH port 26 and port 25 MUST support encryption with Valid SSL certificates.
Continue our SMTP Over TLS on Port 26 proposal here