Encrypted communication is has become far more common over the past decade, and at this point unencrypted traffic is the exception and not the rule. This is a fantastic development 🙌
Of course, as attackers we are looking for a way around that. In systems that deploy encryption it is sometimes possible to downgrade the system to a take of weaker encryption, or to using no encryption at all.
When a user/machine opens a new connection to a server for HTTPS (i.e. HTTP over TLS) or another encrypted protocol, the first step is to initiate the connection, figure out how they want to the connection encrypted, or if it should be encrypted at all.
Sometimes this negotiation includes the user. The client will connect and ask for encryption, the server might respond it only supports TLS 1.0. User has to decide, how badly do they want to visit that website? Is it worth using a broken encryption protocol? This is not the kind of negotiation you want to be a part of. [1]
Example of an (older) Firefox error message. Check out badssl.com for examples in your own browser.
Usually, this negotiation is invisible to the user. In a TLS handshake, it starts with the client sending over the TLS version and ciphers (i.e. encryption methods) it supports and the server picks the one to use for establishing the connection. Because this is the first step and occurs before there is a secure channel, this negotiation is unencrypted and unauthenticated until after it is complete.
At a high level, TLS downgrade attacks work by intercepting and modifying the negotiation messages sent between client and server to trick them into using an older, vulnerable, version of the protocol. In particular, an attacker might try to trick the client and server into using SSL 3.0 / TLS 1.0 which has severe know vulnerabilities, or using and EXPORT or NULL cipher. Key to this attack is that the attacker will trick the client and server to use the weakest protocol both are willing to support. If a client (or server) is only willing to use the latest strong encryption, then the attacker will be out of luck. [2]
The key take away here is that strong encryption should be non-negotiable 🧑⚖️
STARTTLSWhen the early text-based protocols were first developed, security was not on their minds. In many protocols, including the Simple Mail Transfer Protocol (SMTP) protocol developers have tried to bolt it on after the fact.
STARTTLS is a command in SMTP, and a number of other text-based protocols, used to establish a TLS connection after making an initial TCP connection. Below is an example of establishing a secure session using STARTTLS
Server : <waits for connection on TCP port 25>
Client : <opens connection>
Server : 220 mail.example.org ESMTP service ready
Client : EHLO client.example.org
Server : 250-mail.example.org offers a warm hug of welcome
Client : STARTTLS
Server : 220 Go ahead
Client : <starts TLS negotiation>
Client & Server : <negotiate a TLS session>
Client & Server : <check result of negotiation>
Client : EHLO client.example.org
SMTP session start out using plaintext. when the server gets the STARTTLS command, it will respond with 220 (or an error code if TLS is not supported). After that point the server will expect a TLS client hello message and the protocol switches to using TLS to wrap the rest of the session.
So here is the key question: What happens when the server responds to STARTTLS with an error? Does the client abort that connection (and tell their boss they can’t send email today), or does the client go ahead and send their mail unencrypted?
If the client chooses to send unencrypted mail, this is an example of opportunistic TLS. Opportunistic as in “I’d like to use TLS, but I’m also a little bit lazy”. The client is negotiating to use TLS, but is willing to bargain and send their email without it.
More information about STARTTLS in SMTP can be found in RFC 3207.
Connect to the Open Letter challenge. You know the drill by now. I’ll tell you this, state secrets may be at stake here.
<aside> ⛳ Compromise the email exchange to capture the flag 🇺🇸
</aside>