Re: no shared cipher revisited
> This is not a constructive way to disagree. Indeed. Please accept my apologies for being rude. And also being wrong. OpenBSDs acme-client clearly has "#define KBITS 4096". Olaf
Re: no shared cipher revisited
On Wed, Oct 05, 2022 at 08:26:26PM +0200, ch...@syscall.de wrote: > > OpenBSD used a 4096 bits one on top of Let's Encrypt, at least > > May I call this plain BS? Thanks This is not a constructive way to disagree. Can you point at some evidence to the contrary, or minimally explain what alternative conclusion you've reached and why? -- Viktor.
Re: no shared cipher revisited
> OpenBSD used a 4096 bits one on top of Let's Encrypt, at least May I call this plain BS? Thanks Olaf
Re: no shared cipher revisited
Nick Tait wrote in : |On 2/10/2022 10:51 pm, Matus UHLAR - fantomas wrote: |> yes, Let's Encrypt clients generate 4096 keys by default, which is |> silly because intermediate R3 certificate is only 2048-bit. |> |> I configure let's encrypt clients to create 2048 keys. | |AFAICT Certbot still uses 2048-bit keys by default. dehydrated uses 4096 by default (since 2016). OpenBSD used a 4096 bits one on top of Let's Encrypt, at least once this came up last... on June 15th this year. So please a little bit of respect for such decisions. (I do too, but do not ask me no questions.) --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: no shared cipher revisited
On 2/10/2022 10:51 pm, Matus UHLAR - fantomas wrote: yes, Let's Encrypt clients generate 4096 keys by default, which is silly because intermediate R3 certificate is only 2048-bit. I configure let's encrypt clients to create 2048 keys. AFAICT Certbot still uses 2048-bit keys by default. Nick.
Re: no shared cipher revisited
Le 02/10/2022 à 11:51, Matus UHLAR - fantomas a écrit : On 10/1/22 16:16, Viktor Dukhovni wrote: 4096-bit RSA certificates mostly work, but are pointless crypto exhibitionism, waste CPU, can run into client implementation limitations, and so are not a good idea. On 01.10.22 17:20, Shawn Heisey wrote: My cert from letsencrypt is 4096 bit. yes, Let's Encrypt clients generate 4096 keys by default, which is silly because intermediate R3 certificate is only 2048-bit. Silly, yes for the common usage and totally pointless. But keep in mind that key generation/primality test are not definitive primatily answer. A very extensively tested 2048 key is more secure than a very basically and lightly tested 4096 key. Key generation/test is something that is often badly neglected... Emmanuel.
Re: no shared cipher revisited
I do have it listening on port 465, hopefully I got the config right so that does not allow authentication. I think I also disabled TLS below 1.2 on port 587. On 10/1/22 20:44, Viktor Dukhovni wrote: What would be the use of "465" if SASL authentication is not allowed? It is should be configured essentially the same way (modulo wrapper mode, and the service name) as port 587. On 01.10.22 21:25, Shawn Heisey wrote: I am leaning towards completely disabling smtps and removing the permit on the AWS firewall. Since 465 is not an actual standard, I think everyone is using 587. I guess if I disable 465 and anyone is using it, I'll hear about it. not only it is a standard for nearly 4 years, it's also better because there's no possibility to have plaintest on 465 if you forget something I've also had problems with AV blocking tls on 587 in the past. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Despite the cost of living, have you noticed how popular it remains?
Re: no shared cipher revisited
On 10/1/22 16:16, Viktor Dukhovni wrote: 4096-bit RSA certificates mostly work, but are pointless crypto exhibitionism, waste CPU, can run into client implementation limitations, and so are not a good idea. On 01.10.22 17:20, Shawn Heisey wrote: My cert from letsencrypt is 4096 bit. yes, Let's Encrypt clients generate 4096 keys by default, which is silly because intermediate R3 certificate is only 2048-bit. I configure let's encrypt clients to create 2048 keys. At the link below is part of a report from SSL labs indicating which browsers can't handle my settings for https: https://www.dropbox.com/s/o1il6wbst3seuid/browser_compatibility_4096_bit.png?dl=0 The browsers that don't work are ones that I don't care about. The vast majority of users will have something newer. browsers don't communicate with postfix, MTAs and MUAs do. thus, you can get into troubles with otherwise perfect MUAs. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. "They say when you play that M$ CD backward you can hear satanic messages." "That's nothing. If you play it forward it will install Windows."
Re: no shared cipher revisited
On Sat, Oct 01, 2022 at 09:32:49PM +, Eddie Rowe wrote: > > You should have at least an RSA certificate (2048-bit key, not more), and > > only > I do not recall seeing this on the PostFix web site that discusses TLS > settings as I struggle to setup TLS with our existing wildcard certificate. > Can you confirm a 4096-bit certificate will not work? Who convinced you to use 4096-bit RSA in the first place? Even all those intermediate CA only use 2048-bit anyway. Bastian -- First study the enemy. Seek weakness. -- Romulan Commander, "Balance of Terror", stardate 1709.2
Re: no shared cipher revisited
On Sat, Oct 01, 2022 at 09:25:17PM -0600, Shawn Heisey wrote: > I am leaning towards completely disabling smtps and removing the permit > on the AWS firewall. Since 465 is not an actual standard, I think > everyone is using 587. I guess if I disable 465 and anyone is using it, > I'll hear about it. Actually, it is now a standard. https://datatracker.ietf.org/doc/html/rfc8314#section-3.3 -- Viktor.
Re: no shared cipher revisited
On 10/1/22 20:44, Viktor Dukhovni wrote: I do have it listening on port 465, hopefully I got the config right so that does not allow authentication. I think I also disabled TLS below 1.2 on port 587. What would be the use of "465" if SASL authentication is not allowed? It is should be configured essentially the same way (modulo wrapper mode, and the service name) as port 587. I am leaning towards completely disabling smtps and removing the permit on the AWS firewall. Since 465 is not an actual standard, I think everyone is using 587. I guess if I disable 465 and anyone is using it, I'll hear about it. Thanks, Shawn
Re: no shared cipher revisited
On Sat, Oct 01, 2022 at 10:44:48PM -0400, Viktor Dukhovni wrote: > > Sep 25 00:07:45 bilbo dovecot: imap-login: Disconnected: Connection > > closed: SSL_accept() failed: error:14209102:SSL > > routines:tls_early_post_process_client_hello:unsupported protocol (no > > auth attempts in 3 secs): user=<>, rip=205.210.31.140, lip=172.31.8.104, > > TLS handshaking: SSL_accept() failed: error:14209102:SSL > > routines:tls_early_post_process_client_hello:unsupported protocol, > > session= > > The connection was from: > > NetRange: 205.210.31.0 - 205.210.31.255 > CIDR: 205.210.31.0/24 > NetName:PAN-22 > Organization: Palo Alto Networks, Inc (PAN-22) > > I would not expect TLS version scans from them, but perhaps they too > carry out TLS feature studies where they look for support for legacy > TLS versions. That said, I too see what looks like a security scan from that network in my logs: Sep 30 16:35:20 amnesiac postfix/submission/smtpd[97237]: connect from unknown[205.210.31.51] Sep 30 16:35:20 amnesiac postfix/submission/smtpd[97237]: warning: non-SMTP command from unknown[205.210.31.51]: GET / HTTP/1.1 Sep 30 16:35:20 amnesiac postfix/submission/smtpd[97237]: disconnect from unknown[205.210.31.51] unknown=0/1 commands=0/1 Legitimate research security scans should come from hosts with PTR records, and, at the associated domain, web pages that document the project. This could also be abuse. -- Viktor.
Re: no shared cipher revisited
On Sat, Oct 01, 2022 at 08:19:41PM -0600, Shawn Heisey wrote: > These numbers suggest that most full connections are in fact using TLS. More precisely, most attempts at STARTTLS succeed. Neither set of numbers counts connections whether STARTTLS was not even attempted. > Here is the log from two connections that were made using TLS where it > was aborted without trying to transfer mail, and the disconnect log > doesn't have starttls in it: > > > Sep 25 00:05:26 bilbo postfix/smtps/smtpd[492903]: connect from > unknown[170.205.161.87] > Sep 25 00:05:27 bilbo postfix/smtps/smtpd[492903]: Anonymous TLS > connection established from unknown[170.205.161.87]: TLSv1.2 > with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) Not surprising, since this is the "smtps" *wrapper mode*, TLS-on-connect service, which does not use STARTTLS, because it is SMTP inside TLS, rather than SMTP inside STARTTLS inside SMTP. > Sep 25 00:05:31 bilbo postfix/smtps/smtpd[492903]: warning: > unknown[170.205.161.87]: SASL PLAIN authentication failed: The client is probably trying to brute force passwords. > I leave it to you to decide whether the omission of any info about TLS > in the disconnect log for this type of connection constitutes a bug. The use of TLS is implicit here, "smtps" always performs TLS before any SMTP commands can happen. > The config I was aiming for should not allow authentication on anything > other than port 587, Actually, it is also clearly allowed on port 465, which is the port used for "smtps". The client tries to guess a password, and the guess fails. > so even if somehow they have the right password, it shouldn't allow > the connection. Actually, they'd likely succeed. > I do have it listening on port 465, hopefully I got the config right > so that does not allow authentication. I think I also disabled TLS > below 1.2 on port 587. What would be the use of "465" if SASL authentication is not allowed? It is should be configured essentially the same way (modulo wrapper mode, and the service name) as port 587. > I may be in the minority using a "real" cert (from LE). Minority or not, these are fairly common, though of course not universal. > Mostly offtopic but interesting to me: Right after those logs, mail.log > contains a message about a failed TLS connection to dovecot on one of > the imap ports. For dovecot, I am refusing connections with TLS below 1.2: > > Sep 25 00:07:45 bilbo dovecot: imap-login: Disconnected: Connection > closed: SSL_accept() failed: error:14209102:SSL > routines:tls_early_post_process_client_hello:unsupported protocol (no > auth attempts in 3 secs): user=<>, rip=205.210.31.140, lip=172.31.8.104, > TLS handshaking: SSL_accept() failed: error:14209102:SSL > routines:tls_early_post_process_client_hello:unsupported protocol, > session= The connection was from: NetRange: 205.210.31.0 - 205.210.31.255 CIDR: 205.210.31.0/24 NetName:PAN-22 Organization: Palo Alto Networks, Inc (PAN-22) I would not expect TLS version scans from them, but perhaps they too carry out TLS feature studies where they look for support for legacy TLS versions. -- Viktor.
Re: no shared cipher revisited
On 10/1/22 18:04, Wietse Venema wrote: Look for the 'disconnect' logfile record, it will report if starttls was used, and if it was successful. A recent example: Sep 27 13:06:35 spike postfix/smtpd[78883]: disconnect from m227-25.mailgun.net[159.135.227.25] ehlo=1 starttls=0/1 commands=1/2 Sep 27 13:07:36 spike postfix/smtpd[78883]: disconnect from m227-25.mailgun.net[159.135.227.25] ehlo=2 starttls=1 mail=1 rcpt=1 data=1 commands=6 Their connections seem to come in pairs: the first one fails with an SSL_accept error, then they reconnect immediately and succeed with TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 Counts of disconnects where starttls starts with 0: elyograg@bilbo:~$ for i in /var/log/mail.log /var/log/mail.log.1 ; do echo -n "$i: " ; sudo cat $i | perl -lne 'print if m/smtpd\[\d+\]\: disconnect/' | grep -cw "starttls=0" ; done /var/log/mail.log: 147 /var/log/mail.log.1: 167 elyograg@bilbo:~$ for i in /var/log/mail.log.?.gz ; do echo -n "$i: " ; sudo zcat $i | perl -lne 'print if m/smtpd\[\d+\]\: disconnect/' | grep -cw "starttls=0" ; done /var/log/mail.log.2.gz: 125 /var/log/mail.log.3.gz: 183 /var/log/mail.log.4.gz: 182 Counts of disconnects where starttls starts with a number other than 0: elyograg@bilbo:~$ for i in /var/log/mail.log /var/log/mail.log.1 ; do echo -n "$i: " ; sudo cat $i | perl -lne 'print if m/smtpd\[\d+\]\: disconnect/' | grep -cw "starttls=[1-9]" ; done /var/log/mail.log: 2185 /var/log/mail.log.1: 1499 elyograg@bilbo:~$ for i in /var/log/mail.log.?.gz ; do echo -n "$i: " ; sudo zcat $i | perl -lne 'print if m/smtpd\[\d+\]\: disconnect/' | grep -cw "starttls=[1-9]" ; done /var/log/mail.log.2.gz: 1370 /var/log/mail.log.3.gz: 1762 /var/log/mail.log.4.gz: 1558 These numbers suggest that most full connections are in fact using TLS. A very different conclusion than when I was looking at connects. Based on the numbers, I am guessing that this only counts connections that didn't abort early for some reason. Here is the log from two connections that were made using TLS where it was aborted without trying to transfer mail, and the disconnect log doesn't have starttls in it: Sep 25 00:05:26 bilbo postfix/smtps/smtpd[492903]: connect from unknown[170.205.161.87] Sep 25 00:05:27 bilbo postfix/smtps/smtpd[492903]: Anonymous TLS connection established from unknown[170.205.161.87]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) Sep 25 00:05:31 bilbo postfix/smtps/smtpd[492903]: warning: unknown[170.205.161.87]: SASL PLAIN authentication failed: Sep 25 00:05:31 bilbo postfix/smtps/smtpd[492903]: lost connection after AUTH from unknown[170.205.161.87] Sep 25 00:05:31 bilbo postfix/smtps/smtpd[492903]: disconnect from unknown[170.205.161.87] ehlo=1 auth=0/1 commands=1/2 Sep 25 00:05:33 bilbo postfix/smtps/smtpd[492903]: warning: hostname 221-12-59-213.zjnetcom.com does not resolve to address 221.12.59.213: Name or service not known Sep 25 00:05:33 bilbo postfix/smtps/smtpd[492903]: connect from unknown[221.12.59.213] Sep 25 00:05:35 bilbo postfix/smtps/smtpd[492903]: Anonymous TLS connection established from unknown[221.12.59.213]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) Sep 25 00:05:40 bilbo postfix/smtps/smtpd[492903]: warning: unknown[221.12.59.213]: SASL PLAIN authentication failed: Sep 25 00:05:41 bilbo postfix/smtps/smtpd[492903]: lost connection after AUTH from unknown[221.12.59.213] Sep 25 00:05:41 bilbo postfix/smtps/smtpd[492903]: disconnect from unknown[221.12.59.213] ehlo=1 auth=0/1 commands=1/2 I leave it to you to decide whether the omission of any info about TLS in the disconnect log for this type of connection constitutes a bug. I am running Postfix 3.4.13 from the Ubuntu focal repository. Eventually I will upgrade to jammy, but not until a lot more PHP software supports PHP 8.1 out of the box. I was caught off guard by PHP software not supporting PHP 8.1 when I upgraded my server at home to Ubuntu jammy. The mailserver is a lot more mission critical than my basement server, so I am delaying that upgrade. Which means that it's not running anywhere near the latest version of postfix. The config I was aiming for should not allow authentication on anything other than port 587, so even if somehow they have the right password, it shouldn't allow the connection. I do have it listening on port 465, hopefully I got the config right so that does not allow authentication. I think I also disabled TLS below 1.2 on port 587. Outbound connections from postfix on port 25 is probably the one place where I would plan on not checking that the server cert validates, because chances are that a lot of MTAs will be using the default self-signed certificate that they get when they are installed. I may be in the minority using a
Re: no shared cipher revisited
On Sat, Oct 01, 2022 at 05:20:13PM -0600, Shawn Heisey wrote: > If the way I got the total counts is valid, then most of the connections > are NOT using TLS. I wonder how many of those are using plaintext > because my cert is 4096 bit and their encryption library cannot use it. > I don't know if there is any way to log enough information to determine > that. There's really no need. A 2048-bit TLS cert is just as strong as a 4096-bit cert, and sometimes more so, if interoperability is better. There isn't enough compute power on earth to perform a 2^112 attack. > The CPUs in this AWS instance are by AMD and have the "aes" flag. If > openssl 1.1.1f for Ubuntu 20.04 uses that capability, then encryption > should be greatly accelerated and be less of a CPU hog. Hardware-assisted AES does not speed up RSA. On a shiny new server, with all bells and whistles, "openssl speed" reports: signverifysign/s verify/s rsa 2048 bits 0.000304s 0.18s 3292.0 55984.2 rsa 4096 bits 0.004194s 0.65s238.4 15308.3 The time to sign (server's sign the TLS handshake) with rsa4096 ~13.8x higher than the time to sign with rsa2048. Clients also burn more CPU verifying the signature, though their cost is much lower. The question isn't why you should consider not using 4096-bit RSA, it is why you would in the first place. -- Viktor.
Re: no shared cipher revisited
Shawn Heisey: > If the way I got the total counts is valid, then most of the connections > are NOT using TLS.? I wonder how many of those are using plaintext > because my cert is 4096 bit and their encryption library cannot use it.? Look for the 'disconnect' logfile record, it will report if starttls was used, and if it was successful. A recent example: Sep 27 13:06:35 spike postfix/smtpd[78883]: disconnect from m227-25.mailgun.net[159.135.227.25] ehlo=1 starttls=0/1 commands=1/2 Sep 27 13:07:36 spike postfix/smtpd[78883]: disconnect from m227-25.mailgun.net[159.135.227.25] ehlo=2 starttls=1 mail=1 rcpt=1 data=1 commands=6 Their connections seem to come in pairs: the first one fails with an SSL_accept error, then they reconnect immediately and succeed with TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 I guess that they object to something about my TLS default settings or my self-signed certificate. Wietse
Re: no shared cipher revisited
On 10/1/22 16:16, Viktor Dukhovni wrote:
4096-bit RSA certificates mostly work, but are pointless crypto
exhibitionism, waste CPU, can run into client implementation
limitations, and so are not a good idea.
Interesting. This message is offtopic for the thread.
My cert from letsencrypt is 4096 bit. At the link below is part of a
report from SSL labs indicating which browsers can't handle my settings
for https:
https://www.dropbox.com/s/o1il6wbst3seuid/browser_compatibility_4096_bit.png?dl=0
The browsers that don't work are ones that I don't care about. The vast
majority of users will have something newer.
This report is browser-centric, so it's not directly applicable to
Postfix. My settings on postfix are a lot more lenient than those I
have on haproxy and dovecot. Here are all the tls settings grepped out
of postconf -n:
elyograg@bilbo:~$ postconf -n | grep tls
lmtp_tls_ciphers = $smtpd_tls_ciphers
lmtp_tls_mandatory_ciphers = $smtpd_tls_mandatory_ciphers
smtp_tls_ciphers = $smtpd_tls_ciphers
smtp_tls_loglevel = 1
smtp_tls_mandatory_ciphers = $smtpd_tls_mandatory_ciphers
smtp_tls_note_starttls_offer = yes
smtp_tls_security_level = dane
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_client_new_tls_session_rate_limit = 0
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = REDACTED
smtpd_tls_ciphers = medium
smtpd_tls_loglevel = 1
smtpd_tls_mandatory_ciphers = high
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes
tls_high_cipherlist =
ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256
tls_medium_cipherlist =
ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:AES256-SHA:AES128-SHA
tls_preempt_cipherlist = yes
Feel free to critique those settings, but if you do, please back up what
you say with real data.
Most the TLS connections I get on postfix are TLSv1.2. Here is a
summary of the counts for TLS versions in my mailserver logs:
elyograg@bilbo:~$ sudo zgrep -cE "TLSv1\.3" /var/log/mail.log*
/var/log/mail.log:1109
/var/log/mail.log.1:1348
/var/log/mail.log.2.gz:973
/var/log/mail.log.3.gz:1488
/var/log/mail.log.4.gz:946
elyograg@bilbo:~$ sudo zgrep -cE "TLSv1\.2" /var/log/mail.log*
/var/log/mail.log:6051
/var/log/mail.log.1:5937
/var/log/mail.log.2.gz:3217
/var/log/mail.log.3.gz:5453
/var/log/mail.log.4.gz:4217
elyograg@bilbo:~$ sudo zgrep -cE "TLSv1\s+" /var/log/mail.log*
/var/log/mail.log:0
/var/log/mail.log.1:1
/var/log/mail.log.2.gz:8
/var/log/mail.log.3.gz:2
/var/log/mail.log.4.gz:6
elyograg@bilbo:~$ sudo zgrep -cE "TLSv1\.1" /var/log/mail.log*
/var/log/mail.log:0
/var/log/mail.log.1:0
/var/log/mail.log.2.gz:0
/var/log/mail.log.3.gz:0
/var/log/mail.log.4.gz:0
And here are total connection counts that say "smtpd":
elyograg@bilbo:~$ for i in /var/log/mail.log /var/log/mail.log.1 ; do
echo -n "$i:" ; sudo cat $i | perl -lne 'print if m/smtpd\[\d+\]\:
connect/' | wc -l ; done
/var/log/mail.log:15829
/var/log/mail.log.1:10973
elyograg@bilbo:~$ for i in /var/log/mail.log.?.gz ; do echo -n "$i:" ;
sudo zcat $i | perl -lne 'print if m/smtpd\[\d+\]\: connect/' | wc -l ; done
/var/log/mail.log.2.gz:6959
/var/log/mail.log.3.gz:11920
/var/log/mail.log.4.gz:9655
If the way I got the total counts is valid, then most of the connections
are NOT using TLS. I wonder how many of those are using plaintext
because my cert is 4096 bit and their encryption library cannot use it.
I don't know if there is any way to log enough information to determine
that.
The CPUs in this AWS instance are by AMD and have the "aes" flag. If
openssl 1.1.1f for Ubuntu 20.04 uses that capability, then encryption
should be greatly accelerated and be less of a CPU hog.
Thanks,
Shawn
Re: no shared cipher revisited
On Sat, Oct 01, 2022 at 09:32:49PM +, Eddie Rowe wrote: > > You should have at least an RSA certificate (2048-bit key, not more), and > > only > > I do not recall seeing this on the PostFix web site that discusses TLS > settings as I struggle to setup TLS with our existing wildcard > certificate. Can you confirm a 4096-bit certificate will not work? 4096-bit RSA certificates mostly work, but are pointless crypto exhibitionism, waste CPU, can run into client implementation limitations, and so are not a good idea. -- Viktor.
RE: no shared cipher revisited
> Lists Nethead skrev den 2022-09-28 19:34: > >> (P-256 is plenty strong, not P-384 or P-521). > > > Yes agree, on my way there now. > > typo P-521 Gets confusing when you are so used to seeing things in increments in 128. https://community.letsencrypt.org/t/does-lets-encrypt-support-secp521r1-a-k-a-p-521/178331/12
RE: no shared cipher revisited
> You should have at least an RSA certificate (2048-bit key, not more), and only I do not recall seeing this on the PostFix web site that discusses TLS settings as I struggle to setup TLS with our existing wildcard certificate. Can you confirm a 4096-bit certificate will not work?
Re: no shared cipher revisited
On Wed, Sep 28, 2022 at 07:47:17PM +0200, Benny Pedersen wrote: > Lists Nethead skrev den 2022-09-28 19:34: > >> (P-256 is plenty strong, not P-384 or P-521). > > > Yes agree, on my way there now. > > typo P-521 There was no typo. -- Viktor.
Re: no shared cipher revisited
On 28.09.22 18:38, Lists Nethead wrote: Hello again postfix-users, After Viktor gave really helpful advise re SSLv3, now on to the next problem, dealing with crypto is opening a can of worms, at least where I am. We cannot receive messages from a Big Corp, our Postfix MX's responds with "no shared cipher". The configuration is pretty standard I think, smtpd_tls_security_level = may smtpd_tls_ciphers = medium smtpd_tls_protocols = >=TLSv1.2 smtpd_tls_exclude_ciphers = aNULL these affect communication from other mail servers, where plaintext option is used if TLS can't be established, because you set: smtpd_tls_security_level = may ...so disabling older TLS versions may lower security, not increase it. if you want to affect client-server communication, use smtpd_tls_mandatory_* parameters instead. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. A day without sunshine is like, night.
Re: no shared cipher revisited
Lists Nethead skrev den 2022-09-28 19:34: (P-256 is plenty strong, not P-384 or P-521). Yes agree, on my way there now. typo P-521
Re: no shared cipher revisited
Quoting Viktor Dukhovni : On Wed, Sep 28, 2022 at 07:22:37PM +0200, Lists Nethead wrote: > Your server defaults to an ECDSA P-384 certificate, the client may not > support ECDSA at all, or may not support P-384 (P-256 is a more broadly > supported choice): > > $ posttls-finger -c -lmay -Lsummary "[nh1.nethead.se]" > posttls-finger: Untrusted TLS connection established > to nh1.nethead.se[5.150.237.137]:25: > TLSv1.3 with > cipher TLS_AES_256_GCM_SHA384 (256/256 bits) > key-exchange X25519 > server-signature ECDSA (P-384) > server-digest SHA384 > > There appears to be no additional RSA certificate configured: > > $ posttls-finger -p TLSv1.2 -o tls_medium_cipherlist="aRSA" -c > -lmay -Lsummary "[nh1.nethead.se]" > posttls-finger: SSL_connect error to nh1.nethead.se[5.150.237.137]:25: -1 > posttls-finger: warning: TLS library problem: error:14094410:SSL > routines:ssl3_read_bytes:sslv3 alert handshake > failure:ssl/record/rec_layer_s3.c:1544:SSL alert number 40: > > $ posttls-finger -p TLSv1.2 -o tls_medium_cipherlist="aECDSA" -c > -lmay -Lsummary "[nh1.nethead.se]" > posttls-finger: Untrusted TLS connection established to > nh1.nethead.se[5.150.237.137]:25: TLSv1.2 with cipher > ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits) > > Your choice of private key (ECDSA P-384) is likely the problem. Thanks Viktor, that is exactly where my suspicions laid. Now on to fix it. You should have at least an RSA certificate (2048-bit key, not more), and only if you're feeling particularly expert also an ECDSA certificate (P-256 is plenty strong, not P-384 or P-521). Yes agree, on my way there now.
Re: no shared cipher revisited
On Wed, Sep 28, 2022 at 07:22:37PM +0200, Lists Nethead wrote: > > Your server defaults to an ECDSA P-384 certificate, the client may not > > support ECDSA at all, or may not support P-384 (P-256 is a more broadly > > supported choice): > > > > $ posttls-finger -c -lmay -Lsummary "[nh1.nethead.se]" > > posttls-finger: Untrusted TLS connection established > > to nh1.nethead.se[5.150.237.137]:25: > > TLSv1.3 with > > cipher TLS_AES_256_GCM_SHA384 (256/256 bits) > > key-exchange X25519 > > server-signature ECDSA (P-384) > > server-digest SHA384 > > > > There appears to be no additional RSA certificate configured: > > > > $ posttls-finger -p TLSv1.2 -o tls_medium_cipherlist="aRSA" -c > > -lmay -Lsummary "[nh1.nethead.se]" > > posttls-finger: SSL_connect error to nh1.nethead.se[5.150.237.137]:25: > > -1 > > posttls-finger: warning: TLS library problem: error:14094410:SSL > > routines:ssl3_read_bytes:sslv3 alert handshake > > failure:ssl/record/rec_layer_s3.c:1544:SSL alert number 40: > > > > $ posttls-finger -p TLSv1.2 -o tls_medium_cipherlist="aECDSA" -c > > -lmay -Lsummary "[nh1.nethead.se]" > > posttls-finger: Untrusted TLS connection established to > > nh1.nethead.se[5.150.237.137]:25: TLSv1.2 with cipher > > ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits) > > > > Your choice of private key (ECDSA P-384) is likely the problem. > > Thanks Viktor, that is exactly where my suspicions laid. Now on to fix it. You should have at least an RSA certificate (2048-bit key, not more), and only if you're feeling particularly expert also an ECDSA certificate (P-256 is plenty strong, not P-384 or P-521). -- Viktor.
Re: no shared cipher revisited
Quoting Viktor Dukhovni : On Wed, Sep 28, 2022 at 06:47:39PM +0200, Lists Nethead wrote: >> smtpd_tls_protocols = >=TLSv1.2 > > That's not the default setting. > >> smtpd_tls_exclude_ciphers = aNULL > > This is only appeases clueless auditors, in reality it is silly. > >> From what I can see, this is what they want: >> TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128 > > What certificate did you deploy? What is the name of the server, > would I be able to connect to it? Hm, what is the default then? The default is to allow TLS 1.0 or higher. If you want to be broadly interoperable, this is the recommended setting. There is no actual risk in SMTP from leaving TLS 1.0 enabled. When you support TLS 1.2, and the client does too, there is no known downgrade attack to TLS 1.0. Yes, nh1.nethead.se and vrt.nethead.se Your server defaults to an ECDSA P-384 certificate, the client may not support ECDSA at all, or may not support P-384 (P-256 is a more broadly supported choice): $ posttls-finger -c -lmay -Lsummary "[nh1.nethead.se]" posttls-finger: Untrusted TLS connection established to nh1.nethead.se[5.150.237.137]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384 There appears to be no additional RSA certificate configured: $ posttls-finger -p TLSv1.2 -o tls_medium_cipherlist="aRSA" -c -lmay -Lsummary "[nh1.nethead.se]" posttls-finger: SSL_connect error to nh1.nethead.se[5.150.237.137]:25: -1 posttls-finger: warning: TLS library problem: error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:ssl/record/rec_layer_s3.c:1544:SSL alert number 40: $ posttls-finger -p TLSv1.2 -o tls_medium_cipherlist="aECDSA" -c -lmay -Lsummary "[nh1.nethead.se]" posttls-finger: Untrusted TLS connection established to nh1.nethead.se[5.150.237.137]:25: TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits) Your choice of private key (ECDSA P-384) is likely the problem. Thanks Viktor, that is exactly where my suspicions laid. Now on to fix it. Thanks again, Per
Re: no shared cipher revisited
On Wed, Sep 28, 2022 at 06:47:39PM +0200, Lists Nethead wrote: > >> smtpd_tls_protocols = >=TLSv1.2 > > > > That's not the default setting. > > > >> smtpd_tls_exclude_ciphers = aNULL > > > > This is only appeases clueless auditors, in reality it is silly. > > > >> From what I can see, this is what they want: > >> TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128 > > > > What certificate did you deploy? What is the name of the server, > > would I be able to connect to it? > > Hm, what is the default then? The default is to allow TLS 1.0 or higher. If you want to be broadly interoperable, this is the recommended setting. There is no actual risk in SMTP from leaving TLS 1.0 enabled. When you support TLS 1.2, and the client does too, there is no known downgrade attack to TLS 1.0. > Yes, nh1.nethead.se and vrt.nethead.se Your server defaults to an ECDSA P-384 certificate, the client may not support ECDSA at all, or may not support P-384 (P-256 is a more broadly supported choice): $ posttls-finger -c -lmay -Lsummary "[nh1.nethead.se]" posttls-finger: Untrusted TLS connection established to nh1.nethead.se[5.150.237.137]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384 There appears to be no additional RSA certificate configured: $ posttls-finger -p TLSv1.2 -o tls_medium_cipherlist="aRSA" -c -lmay -Lsummary "[nh1.nethead.se]" posttls-finger: SSL_connect error to nh1.nethead.se[5.150.237.137]:25: -1 posttls-finger: warning: TLS library problem: error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:ssl/record/rec_layer_s3.c:1544:SSL alert number 40: $ posttls-finger -p TLSv1.2 -o tls_medium_cipherlist="aECDSA" -c -lmay -Lsummary "[nh1.nethead.se]" posttls-finger: Untrusted TLS connection established to nh1.nethead.se[5.150.237.137]:25: TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits) Your choice of private key (ECDSA P-384) is likely the problem. -- Viktor.
Re: no shared cipher revisited
Lists Nethead skrev den 2022-09-28 19:00: Quoting Benny Pedersen : Lists Nethead skrev den 2022-09-28 18:47: smtpd_tls_protocols = >=TLSv1.2 Hm, what is the default then? put an # infront of this line in main.cf, then do a postfix reload simple ? :=) If this would enable everything from tls1, no. i just answered how to set defaults if this gives problems show logs so we can help more
Re: no shared cipher revisited
Quoting Benny Pedersen : Lists Nethead skrev den 2022-09-28 18:47: smtpd_tls_protocols = >=TLSv1.2 Hm, what is the default then? put an # infront of this line in main.cf, then do a postfix reload simple ? :=) If this would enable everything from tls1, no.
Re: no shared cipher revisited
Lists Nethead skrev den 2022-09-28 18:47: smtpd_tls_protocols = >=TLSv1.2 Hm, what is the default then? put an # infront of this line in main.cf, then do a postfix reload simple ? :=)
Re: no shared cipher revisited
Quoting Viktor Dukhovni : On Wed, Sep 28, 2022 at 06:38:15PM +0200, Lists Nethead wrote: Hello again postfix-users, After Viktor gave really helpful advise re SSLv3, now on to the next problem, dealing with crypto is opening a can of worms, at least where I am. We cannot receive messages from a Big Corp, our Postfix MX's responds with "no shared cipher". The configuration is pretty standard I think, smtpd_tls_protocols = >=TLSv1.2 That's not the default setting. smtpd_tls_exclude_ciphers = aNULL This is only appeases clueless auditors, in reality it is silly. From what I can see, this is what they want: TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128 What certificate did you deploy? What is the name of the server, would I be able to connect to it? Hm, what is the default then? Yes, nh1.nethead.se and vrt.nethead.se Letsencrypt
Re: no shared cipher revisited
On Wed, Sep 28, 2022 at 06:38:15PM +0200, Lists Nethead wrote: > > Hello again postfix-users, > > After Viktor gave really helpful advise re SSLv3, now on to the next > problem, dealing with crypto is opening a can of worms, at least where > I am. > > We cannot receive messages from a Big Corp, our Postfix MX's responds > with "no shared cipher". The configuration is pretty standard I think, > > smtpd_tls_protocols = >=TLSv1.2 That's not the default setting. > smtpd_tls_exclude_ciphers = aNULL This is only appeases clueless auditors, in reality it is silly. > From what I can see, this is what they want: > TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128 What certificate did you deploy? What is the name of the server, would I be able to connect to it? -- Viktor.
no shared cipher revisited
Hello again postfix-users, After Viktor gave really helpful advise re SSLv3, now on to the next problem, dealing with crypto is opening a can of worms, at least where I am. We cannot receive messages from a Big Corp, our Postfix MX's responds with "no shared cipher". The configuration is pretty standard I think, smtpd_tls_security_level = may smtpd_tls_ciphers = medium smtpd_tls_protocols = >=TLSv1.2 smtpd_tls_exclude_ciphers = aNULL From what I can see, this is what they want: TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128 This seems to be available in the openssl version 1.1.1q-freebsd ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD that we currently use but we do not offer it, and why is beyond me unfortunately, any help welcome. Thanks, Per
