SMTP Pentest Guide
Back to Email Authentication Attacks

STARTTLS Downgrade Attacks

STARTTLS downgrade attacks prevent the encryption of SMTP connections, allowing attackers to intercept and read email content and potentially steal credentials.

Attack Summary: Preventing SMTP connections from upgrading to TLS encryption by intercepting and modifying the STARTTLS command, forcing communications to remain in plaintext.

Background: STARTTLS in SMTP

STARTTLS is an extension to plain text communication protocols, including SMTP, that offers a way to upgrade a plaintext connection to an encrypted (TLS or SSL) connection without requiring a separate port for encrypted communications. The process works as follows:

  1. The client connects to the server on the standard port (e.g., port 25 for SMTP)
  2. The server advertises its capabilities, including STARTTLS support
  3. The client issues the STARTTLS command
  4. The server responds with a ready message
  5. The client and server perform a TLS handshake
  6. If successful, the rest of the session is encrypted

Unlike protocols that use separate ports for encrypted connections (like SMTPS on port 465), STARTTLS starts with an unencrypted connection and then upgrades it. This initial plaintext negotiation creates an opportunity for attackers to interfere with the upgrade process.

Attack Methodology

STARTTLS downgrade attacks exploit the initial plaintext negotiation to prevent the connection from being upgraded to TLS.

STARTTLS Stripping
Removing STARTTLS capability advertisements

This attack involves intercepting the server's capability response and removing the STARTTLS advertisement, making the client believe that the server doesn't support TLS.

STARTTLS Stripping Attack

Intercepting and modifying SMTP capability advertisements

# Normal SMTP server response: 220 mail.example.com ESMTP Server EHLO client.example.com 250-mail.example.com 250-PIPELINING 250-SIZE 10240000 250-VRFY 250-ETRN 250-STARTTLS 250-AUTH PLAIN LOGIN 250-ENHANCEDSTATUSCODES 250 8BITMIME # Modified response with STARTTLS removed: 220 mail.example.com ESMTP Server EHLO client.example.com 250-mail.example.com 250-PIPELINING 250-SIZE 10240000 250-VRFY 250-ETRN 250-AUTH PLAIN LOGIN 250-ENHANCEDSTATUSCODES 250 8BITMIME
Explanation: In this attack, the attacker intercepts the server's response to the EHLO command and removes the '250-STARTTLS' line before forwarding it to the client. Since the client doesn't see the STARTTLS capability, it continues the session in plaintext, allowing the attacker to intercept all subsequent communications, including potentially sensitive information and authentication credentials.

Man-in-the-Middle Requirements

To perform this attack, an attacker needs to:

  • Gain a network position: Be in a position to intercept traffic between the client and server
  • Modify traffic: Have the ability to modify packets in transit
  • Handle TCP connections: Maintain proper TCP state for both client and server

This can be achieved through ARP spoofing, DNS poisoning, BGP hijacking, or compromising network infrastructure.

STARTTLS Command Injection
Injecting errors into the STARTTLS command

This attack involves intercepting the client's STARTTLS command and replacing it with an invalid command or injecting an error response.

STARTTLS Command Injection

Intercepting and modifying the STARTTLS command

# Normal client request: STARTTLS # Attacker replaces with: STARTFLS # Or the attacker lets the STARTTLS command through but injects a fake error response: STARTTLS 454 TLS not available due to temporary reason
Explanation: In this attack, the attacker either replaces the STARTTLS command with an invalid command (STARTFLS) that the server won't recognize, or allows the command through but injects a fake error response. In both cases, the client will fall back to plaintext communication, allowing the attacker to intercept the traffic.

Client Behavior on TLS Failure

When TLS negotiation fails, clients typically behave in one of three ways:

  • Fail open: Continue with plaintext communication (vulnerable to downgrade)
  • Fail closed: Terminate the connection (resistant to downgrade)
  • User prompt: Ask the user whether to continue (depends on user decision)

Many older or misconfigured email clients "fail open," making them vulnerable to this attack.

TLS Handshake Interference
Disrupting the TLS handshake process

This attack involves allowing the STARTTLS command to proceed but interfering with the subsequent TLS handshake to cause it to fail.

TLS Handshake Interference

Disrupting the TLS handshake process

# The client and server begin the TLS handshake: # Client Hello # Server Hello # Certificate # Server Key Exchange # Server Hello Done # The attacker injects TCP RST packets or corrupts handshake messages
Explanation: In this attack, the attacker allows the STARTTLS command and response to proceed normally but interferes with the TLS handshake by injecting TCP RST (reset) packets or corrupting the handshake messages. This causes the TLS negotiation to fail, and if the client is configured to 'fail open,' it will fall back to plaintext communication.

Protocol Downgrade Attacks

Similar techniques can be used to force downgrades to weaker protocols:

  • TLS version downgrade: Forcing the use of vulnerable TLS 1.0 or SSL 3.0
  • Cipher suite downgrade: Forcing the use of weak encryption algorithms
  • Authentication downgrade: Forcing the use of weaker authentication methods

These attacks can make it easier for attackers to decrypt the traffic or exploit known vulnerabilities.

Impact

STARTTLS downgrade attacks can have significant impacts:

  • Exposure of email content that would otherwise be encrypted
  • Interception of authentication credentials
  • Ability to modify email content in transit
  • Potential for session hijacking
  • Bypass of security controls that rely on encryption
  • Compromise of sensitive information in emails

Detection

Organizations can detect STARTTLS downgrade attacks by:

  • Monitoring for unexpected plaintext SMTP sessions
  • Analyzing SMTP server logs for failed TLS negotiations
  • Using network monitoring tools to detect manipulation of SMTP traffic
  • Implementing client-side alerts for unexpected encryption downgrades
  • Monitoring for unusual patterns in SMTP traffic

Mitigation

To protect against STARTTLS downgrade attacks, organizations should:

  • Implement MTA-STS: SMTP MTA Strict Transport Security (RFC 8461) helps prevent downgrade attacks by allowing domains to specify that TLS is required
  • Use DANE: DNS-based Authentication of Named Entities (RFC 7672) provides a way to authenticate SMTP servers using DNSSEC
  • Configure clients to fail closed: Email clients should be configured to terminate connections if TLS negotiation fails
  • Use dedicated TLS ports: When possible, use ports dedicated to TLS (e.g., 465 for SMTPS) instead of STARTTLS
  • Implement SMTP over TLS: Use SMTPS (SMTP over TLS) instead of STARTTLS when possible
  • Monitor for downgrade attacks: Implement monitoring to detect unexpected plaintext communications
  • Educate users: Train users to be cautious of security warnings related to encryption

Testing

Security professionals can test for STARTTLS downgrade vulnerabilities using the following approach:

  1. Set up a test environment with a mail server that supports STARTTLS
  2. Use a proxy tool like Burp Suite or mitmproxy to intercept SMTP traffic
  3. Modify the server's capability response to remove STARTTLS
  4. Observe whether the client continues with plaintext communication
  5. Test different email clients to identify those that "fail open"
  6. Document findings and recommend appropriate mitigations

References

Previous: SMTP Relay AttacksNext: SMTP User Enumeration