Postfix 3.5.6 (intermediate): SSL_accept error (no shared cipher) with Amazon SES

[sebastianlipponer]

Using Postfix 3.5.6 (Debian Bullseye) with the intermediate configuration and a RSA certificate I see this error with mails received via Amazon SES:

SSL_accept error from a1-161.smtp-out.eu-west-1.amazonses.com[54.240.1.161]: -1
warning: TLS library problem: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher:../ssl/statem/statem_srvr.c:2283:

I also found this excellent blog post. According to the author adding ECDHE-RSA-AES256-SHA384 to the cipher list solves the problem.

[tomato42]

That's misconfiguration on Amazon side

[sebastianlipponer]

Yes, indeed, I reported this also to AWS. Hopefully they will fix it soon. However, I just wonder, given the widespread use of Amazon SES, whether it is a good idea to recommend this configuration for almost all systems since I guess the transfer happens in plain text then.

[polarathene]

ECDHE-RSA-AES256-SHA384

To clarify, this cipher has forward secrecy and is generally fine, but the main concern for it not being part of intermediate is due to using CBC which has proven to be less reliably secure than AEAD ciphers right?

In practice, it's fine to use AFAIK, should no better ciphers be available, but without the cipher list containing all AEAD ciphers; it is then advised to require server preference in cipher choice, not client preference? (thus order in list matters)

[gstrauss]

@sebastianlipponer sorry to bother you on this old issue. Do you know if this is still an issue with AWS? (Likely stale issue)

@polarathene yes, if the only ciphers allowed are AEAD, then allowing client preference permits clients without AES hardware acceleration to prefer CHACHA20, and clients with AES hardware acceleration to prefer AES. However, if there are non-AEAD ciphers permitted, then requiring server preference (where cipher order matters more) is recommended to avoid potential cipher downgrade attacks to have the connection use ciphers without perfect forward secrecy (PFS).

For now, I am going to close this issue as Stale. If it is still an issue, please post and I'll re-open this. Thanks!

[janbrasna]

This issue is mostly about receiving from SES, and the linked blog post mentions sending to SES. I can't test SES outbound or all the regional endpoints, but for quick test without credentials to connect to SES:

$ openssl s_client -debug -connect email-smtp.us-west-2.amazonaws.com:587 -starttls smtp -crlf
Connecting to 44.225.148.59
CONNECTED(00000006)
[…]
subject=CN=email-smtp.us-west-2.amazonaws.com
issuer=C=US, O=Amazon, CN=Amazon RSA 2048 M01
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: ECDH, prime256v1, 256 bits
---
SSL handshake has read 6139 bytes and written 935 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
This TLS version forbids renegotiation.
Verify return code: 0 (ok)
---
250 Ok

So they support TLSv1.3 now — which is a change from when this was posted in ~2021 — as the quoted articles now include it in not just in HTTPS API access but also with SMTP submission. (When this issue started, it was more of a SSLv3–TLSv1.2 on the STMP side, now it states TLSv1.2+ only. We can only assume that is true for both inbound and outbound, though.)

They also mention (in general security docs) that ECDHE or DHE are the preferred choice, so just quickly testing RSA from intermediate, TLSv1.2–only:

ECDHE-RSA-AES128-GCM-SHA256 ✅

$ openssl s_client -cipher 'ECDHE-RSA-AES128-GCM-SHA256' -max_protocol TLSv1.2 -connect email-smtp.us-west-2.amazonaws.com:587 -crlf -starttls smtp
Connecting to 54.185.234.152
CONNECTED(00000006)
---
subject=CN=email-smtp.us-west-2.amazonaws.com
issuer=C=US, O=Amazon, CN=Amazon RSA 2048 M01
---
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: ECDH, prime256v1, 256 bits
---
SSL handshake has read 5763 bytes and written 344 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256
    Session-ID: B887…FEDAD56
    Session-ID-ctx: 
    Master-Key: D578A9D…46B46BE887
    Verify return code: 0 (ok)
    Extended master secret: yes
---
250 Ok

ECDHE-RSA-AES256-GCM-SHA384 ✅

$ openssl s_client -cipher 'ECDHE-RSA-AES256-GCM-SHA384' -max_protocol TLSv1.2 -connect email-smtp.us-west-2.amazonaws.com:587 -crlf -starttls smtp
Connecting to 52.13.3.84
CONNECTED(00000006)
---
subject=CN=email-smtp.us-west-2.amazonaws.com
issuer=C=US, O=Amazon, CN=Amazon RSA 2048 M01
---
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: ECDH, prime256v1, 256 bits
---
SSL handshake has read 5763 bytes and written 344 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: E6D76BFA7017B…34B4AE346A9B6
    Session-ID-ctx: 
    Master-Key: 076F312B0…39DE20E6C0FDE4F8D44
    Verify return code: 0 (ok)
    Extended master secret: yes
---
250 Ok

ECDHE-RSA-CHACHA20-POLY1305 ❌

"handshake failure"

$ openssl s_client -cipher 'ECDHE-RSA-CHACHA20-POLY1305' -max_protocol TLSv1.2 -connect email-smtp.us-west-2.amazonaws.com:587 -crlf -starttls smtp
Connecting to 52.13.3.84
CONNECTED(00000006)
00506273FF7F0000:error:0A000410:SSL routines:ssl3_read_bytes:ssl/tls alert handshake failure:ssl/record/rec_layer_s3.c:907:SSL alert number 40
---
New, (NONE), Cipher is (NONE)
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000

DHE-RSA-AES128-GCM-SHA256 ❗🗝️

"dh key too small"

$ openssl s_client -cipher 'DHE-RSA-AES128-GCM-SHA256' -max_protocol TLSv1.2 -connect email-smtp.us-west-2.amazonaws.com:587 -crlf -starttls smtp
Connecting to 52.13.3.84
CONNECTED(00000006)
00506273FF7F0000:error:0A00018A:SSL routines:tls_process_ske_dhe:dh key too small:ssl/statem/statem_clnt.c:2314:
---
New, (NONE), Cipher is (NONE)
Server public key is 2048 bit
Secure Renegotiation IS supported
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000

DHE-RSA-AES256-GCM-SHA384 ❗🗝️

"dh key too small"

(when you successfully connect with @SECLEVEL=1 you can see that Server Temp Key: DH, 1024 bits… so these are available, you just shouldn't use them — but anything's better than plaintext…)

So this sounds like it should not be an issue at this time, as there are handshakes feasible for TLSv1.2–only connections, and no issues for TLSv1.3–enabled counterparts.

https://docs.aws.amazon.com/ses/latest/dg/security-protocols.html

Email sender to Amazon SES

• SMTP interface
  • STARTTLS
    "Amazon SES supports TLS 1.2 and TLS 1.3."
  • TLS Wrapper
    "For TLS Wrapper connections, Amazon SES supports TLS 1.2 and TLS 1.3."

Amazon SES to receiver

• "While TLS 1.3 is our default delivery method, SES can deliver email to mail servers using earlier versions of TLS."
• "By default, Amazon SES uses opportunistic TLS. This means that Amazon SES always attempts to make a secure connection to the receiving mail server. If Amazon SES can't establish a secure connection, it sends the message unencrypted."
• "To configure Amazon SES to require TLS connections for a configuration set […] PutConfigurationSetDeliveryOptions API operation to set the TlsPolicy property for a configuration set to Require. When you send an email using this configuration set, Amazon SES only sends the message to the receiving email server if it can establish a secure connection. If Amazon SES can't make a secure connection to the receiving email server, it drops the message."

The rest is probably better to follow up in another Postfix–related issue, regarding configuring both ends differently (one should be stricter, the other more lax):

• Postfix config misses smtp_* parameters and includes several default settings #114