Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#706423: openssl: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:337:
805 views
Skip to first unread message
Gedalya
Jun 11, 2013, 10:20:02 PM6/11/13
to
Hi,
I think this problem is a little more serious. It basically means that:
1. We have to disable TLSv1.1/1.2 if we want to be interoperable with
certain systems that are (sadly) still widely used. TLSv1.2 is a major
new feature, disabling it is not what we want.
2. Since you can't always disable TLSv1.1/1.2 in every application, it
means we sometimes have to disable TLS altogether, or where TLS is
required, you just won't be able to connect. This means openssl in
wheezy is sometimes unusable.
The discussion here[1] seems to be misguided. Of course it's nice for
every app to expose openssl options in its config, but openssl is what
is broken here.
As for blaming the remote side - GnuTLS apps in wheezy are able to talk
to MS Exchange (same exact servers having this error with postfix) with
no specific configuration changes, having TLSv1.2 still enabled (e.g. exim).
[1] http://web.archiveorange.com/archive/v/ATzXXOjuq9y3yWEltUyY
Thanks,
Gedalya
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
I think this problem is a little more serious. It basically means that:
1. We have to disable TLSv1.1/1.2 if we want to be interoperable with
certain systems that are (sadly) still widely used. TLSv1.2 is a major
new feature, disabling it is not what we want.
2. Since you can't always disable TLSv1.1/1.2 in every application, it
means we sometimes have to disable TLS altogether, or where TLS is
required, you just won't be able to connect. This means openssl in
wheezy is sometimes unusable.
The discussion here[1] seems to be misguided. Of course it's nice for
every app to expose openssl options in its config, but openssl is what
is broken here.
As for blaming the remote side - GnuTLS apps in wheezy are able to talk
to MS Exchange (same exact servers having this error with postfix) with
no specific configuration changes, having TLSv1.2 still enabled (e.g. exim).
[1] http://web.archiveorange.com/archive/v/ATzXXOjuq9y3yWEltUyY
Thanks,
Gedalya
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Kurt Roeckx
Jun 12, 2013, 12:40:02 PM6/12/13
to
On Tue, Jun 11, 2013 at 10:05:30PM -0400, Gedalya wrote:
> The discussion here[1] seems to be misguided. Of course it's nice
> for every app to expose openssl options in its config, but openssl
> is what is broken here.
I'm pretty sure that the other side is broken, it's just that
> The discussion here[1] seems to be misguided. Of course it's nice
> for every app to expose openssl options in its config, but openssl
> is what is broken here.
openssl is exposing the problems on the other side. Maybe
we can work around it, but in that case I need more info.
> As for blaming the remote side - GnuTLS apps in wheezy are able to
> talk to MS Exchange (same exact servers having this error with
> postfix) with no specific configuration changes, having TLSv1.2
> still enabled (e.g. exim).
the same problem talking to servers as openssl has. So if this
is a server I can access over the internet, can you give more
details?
Kurt
Gedalya
Jun 12, 2013, 2:00:02 PM6/12/13
to
On 06/12/2013 12:35 PM, Kurt Roeckx wrote:
> On Tue, Jun 11, 2013 at 10:05:30PM -0400, Gedalya wrote:
>> The discussion here[1] seems to be misguided. Of course it's nice
>> for every app to expose openssl options in its config, but openssl
>> is what is broken here.
> I'm pretty sure that the other side is broken, it's just that
> openssl is exposing the problems on the other side. Maybe
> we can work around it, but in that case I need more info.
>
>> As for blaming the remote side - GnuTLS apps in wheezy are able to
>> talk to MS Exchange (same exact servers having this error with
>> postfix) with no specific configuration changes, having TLSv1.2
>> still enabled (e.g. exim).
> This is new for me. In all recent cases I've seen gnutls had
> the same problem talking to servers as openssl has. So if this
> is a server I can access over the internet, can you give more
> details?
>
>
> Kurt
>
Jun 9 07:03:27 mailout1 postfix/smtp[4748]: Untrusted TLS connection
> On Tue, Jun 11, 2013 at 10:05:30PM -0400, Gedalya wrote:
>> The discussion here[1] seems to be misguided. Of course it's nice
>> for every app to expose openssl options in its config, but openssl
>> is what is broken here.
> I'm pretty sure that the other side is broken, it's just that
> openssl is exposing the problems on the other side. Maybe
> we can work around it, but in that case I need more info.
>
>> As for blaming the remote side - GnuTLS apps in wheezy are able to
>> talk to MS Exchange (same exact servers having this error with
>> postfix) with no specific configuration changes, having TLSv1.2
>> still enabled (e.g. exim).
> This is new for me. In all recent cases I've seen gnutls had
> the same problem talking to servers as openssl has. So if this
> is a server I can access over the internet, can you give more
> details?
>
>
> Kurt
>
established to mail.megacontractinginc.com[64.61.170.194]:25: TLSv1 with
cipher DES-CBC3-SHA (168/168 bits)
Jun 9 07:03:27 mailout1 postfix/smtp[4748]: warning: TLS library
problem: 4748:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version
number:s3_pkt.c:337:
Jun 9 07:03:27 mailout1 postfix/smtp[4748]: 727D91FED2: lost connection
with mail.megacontractinginc.com[64.61.170.194] while sending MAIL FROM
Jun 9 07:03:27 mailout1 postfix/smtp[4748]: Untrusted TLS connection
established to mail.megacontractinginc.com[50.74.229.90]:25: TLSv1 with
cipher DES-CBC3-SHA (168/168 bits)
Jun 9 07:03:27 mailout1 postfix/smtp[4748]: warning: TLS library
problem: 4748:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version
number:s3_pkt.c:337:
You can try to send to aaaaaaaaaaaaaa at megacontractinginc.com,
reproducing the problem would mean you get cut off after MAIL FROM, a
550 user unknown is success.
in my trials, postfix+openssl has the problem, exim+GnuTLS does not.
But I believe this should be the same with IIS6, etc, I don't think it
has anything to do with Exchange, or with any particular server. I'll
try to dig around more and bring more examples.
Thanks
Kurt Roeckx
Jun 12, 2013, 2:40:02 PM6/12/13
to
openssl s_client -connect mail.megacontractinginc.com:25 -starttls smtp -crlf
But I can reproduce some weird behaviour with it that goes away
when I use -no_tls1_2.
Kurt
Gedalya
Jun 12, 2013, 2:50:01 PM6/12/13
to
On 06/12/2013 02:35 PM, Kurt Roeckx wrote:
> openssl s_client -connect mail.megacontractinginc.com:25 -starttls smtp -crlf
Right. I don't know how to do -crlf with gnutls-cli that's why I just
> openssl s_client -connect mail.megacontractinginc.com:25 -starttls smtp -crlf
piped something to exim.. but it worked, without disabling TLS 1.2. I
don't doubt there's something wrong on the remote side but the remote
side is all over, and I believe we can and must find a way to work
around it.
Gedalya
Jun 12, 2013, 2:50:02 PM6/12/13
to
On 06/12/2013 02:35 PM, Kurt Roeckx wrote:
> openssl s_client -connect mail.megacontractinginc.com:25 -starttls smtp -crlf
Ooops.. silly me. --crlf, right there on the gnutls-cli man page :D
> openssl s_client -connect mail.megacontractinginc.com:25 -starttls smtp -crlf
Gedalya
Jun 12, 2013, 5:40:01 PM6/12/13
to
On 06/12/2013 02:35 PM, Kurt Roeckx wrote:
> This start a succesful (TLSv1) connection for me:
> openssl s_client -connect mail.megacontractinginc.com:25 -starttls smtp -crlf
>
> But I can reproduce some weird behaviour with it that goes away
> when I use -no_tls1_2.
>
>
> Kurt
Found another example.
> This start a succesful (TLSv1) connection for me:
> openssl s_client -connect mail.megacontractinginc.com:25 -starttls smtp -crlf
>
> But I can reproduce some weird behaviour with it that goes away
> when I use -no_tls1_2.
>
>
> Kurt
GnuTLS negotiates the same cipher as openssl would with only TLSv1 enabled.
$ swaks -f some...@something.net -t dfg...@example.com -s
mail.acsgs.com -tls
=== Trying mail.acsgs.com:25...
=== Connected to mail.acsgs.com.
<- 220 acsgsemail1.acsgs.com Microsoft ESMTP MAIL Service, Version:
6.0.3790.4675 ready at Wed, 12 Jun 2013 15:18:43 -0600
-> EHLO nws.gedalya.net
<- 250-acsgsemail1.acsgs.com Hello [xx.xx.xx.xx]
<- 250-TURN
<- 250-SIZE
<- 250-ETRN
<- 250-PIPELINING
<- 250-DSN
<- 250-ENHANCEDSTATUSCODES
<- 250-8bitmime
<- 250-BINARYMIME
<- 250-CHUNKING
<- 250-VRFY
<- 250-TLS
<- 250-STARTTLS
<- 250-X-EXPS GSSAPI NTLM
<- 250-AUTH GSSAPI NTLM
<- 250-X-LINK2STATE
<- 250-XEXCH50
<- 250 OK
-> STARTTLS
<- 220 2.0.0 SMTP server ready
=== TLS started w/ cipher DES-CBC3-SHA
=== TLS peer subject DN="/C=US/ST=Utah/L=Sandy/O=Affiliated Computer
Services/OU=Global Services/CN=mail.acsgs.com"
~> EHLO nws.gedalya.net
<~ 250-acsgsemail1.acsgs.com Hello [xx.xx.xx.xx]
<~ 250-TURN
<~ 250-SIZE
<~ 250-ETRN
<~ 250-PIPELINING
<~ 250-DSN
<~ 250-ENHANCEDSTATUSCODES
<~ 250-8bitmime
<~ 250-BINARYMIME
<~ 250-CHUNKING
<~ 250-VRFY
<~ 250-X-EXPS GSSAPI NTLM LOGIN
<~ 250-X-EXPS=LOGIN
<~ 250-AUTH GSSAPI NTLM LOGIN
<~ 250-AUTH=LOGIN
<~ 250-X-LINK2STATE
<~ 250-XEXCH50
<~ 250 OK
~> MAIL FROM:<some...@something.net>
*** Remote host closed connection unexpectedly.
$ openssl s_client -connect mail.acsgs.com:25 -starttls smtp -crlf
CONNECTED(00000003)
depth=1 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU =
Terms of use at https://www.verisign.com/rpa (c)05, CN = VeriSign Class
3 Secure Server CA
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:/C=US/ST=Utah/L=Sandy/O=Affiliated Computer Services/OU=Global
Services/CN=mail.acsgs.com
i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use
at https://www.verisign.com/rpa (c)05/CN=VeriSign Class 3 Secure Server CA
1 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use
at https://www.verisign.com/rpa (c)05/CN=VeriSign Class 3 Secure Server CA
i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification
Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFEzCCA/ugAwIBAgIQc/v1FFQpqdbVOIy00Zd9vDANBgkqhkiG9w0BAQUFADCB
......
EXVDfqHCvw==
-----END CERTIFICATE-----
subject=/C=US/ST=Utah/L=Sandy/O=Affiliated Computer Services/OU=Global
Services/CN=mail.acsgs.com
issuer=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use
at https://www.verisign.com/rpa (c)05/CN=VeriSign Class 3 Secure Server CA
---
No client certificate CA names sent
---
SSL handshake has read 3076 bytes and written 545 bytes
---
New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA
Server public key is 1024 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : DES-CBC3-SHA
Session-ID:
7505000001B9853811768E688C104416E731661E9846180362564B8460685E82
Session-ID-ctx:
Master-Key:
DA18807E33A53A66DB57339E5D68F1F0FAB1675980AEC6ADF4472D4DB987D993ED18EF1BDF39B0369F2535E2D691B492
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1371072152
Timeout : 300 (sec)
Verify return code: 20 (unable to get local issuer certificate)
---
250 OK
EHLO nws.gedalya.net
250-acsgsemail1.acsgs.com Hello [xx.xx.xx.xx]
250-TURN
250-SIZE
250-ETRN
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-8bitmime
250-BINARYMIME
250-CHUNKING
250-VRFY
250-X-EXPS GSSAPI NTLM LOGIN
250-X-EXPS=LOGIN
250-AUTH GSSAPI NTLM LOGIN
250-AUTH=LOGIN
250-X-LINK2STATE
250-XEXCH50
250 OK
139789032576680:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong
version number:s3_pkt.c:337:
$ gnutls-cli --crlf -s -p 25 mail.acsgs.com
WARNING: gnome-keyring:: couldn't connect to:
/home/jedi/.cache/keyring-V3kT53/pkcs11: No such file or directory
Resolving 'mail.acsgs.com'...
Connecting to '216.115.162.156:25'...
- Simple Client Mode:
220 acsgsemail1.acsgs.com Microsoft ESMTP MAIL Service, Version:
6.0.3790.4675 ready at Wed, 12 Jun 2013 15:23:10 -0600
EHLO nws.gedalya.net
250-acsgsemail1.acsgs.com Hello [xx.xx.xx.xx]
250-TURN
250-SIZE
250-ETRN
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-8bitmime
250-BINARYMIME
250-CHUNKING
250-VRFY
250-TLS
250-STARTTLS
250-X-EXPS GSSAPI NTLM
250-AUTH GSSAPI NTLM
250-X-LINK2STATE
250-XEXCH50
250 OK
STARTTLS
220 2.0.0 SMTP server ready
*** Starting TLS handshake
- Certificate type: X.509
- Got a certificate list of 2 certificates.
- Certificate[0] info:
- subject `C=US,ST=Utah,L=Sandy,O=Affiliated Computer
Services,OU=Global Services,CN=mail.acsgs.com', issuer
`C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=Terms of use at
https://www.verisign.com/rpa (c)05,CN=VeriSign Class 3 Secure Server
CA', RSA key 1024 bits, signed using RSA-SHA1, activated `2008-07-30
00:00:00 UTC', expires `2010-07-30 23:59:59 UTC', SHA-1 fingerprint
`766cb36ca76254171dab4ff747b413f974b8d2c6'
- Certificate[1] info:
- subject `C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=Terms
of use at https://www.verisign.com/rpa (c)05,CN=VeriSign Class 3 Secure
Server CA', issuer `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary
Certification Authority', RSA key 2048 bits, signed using RSA-SHA1,
activated `2005-01-19 00:00:00 UTC', expires `2015-01-18 23:59:59 UTC',
SHA-1 fingerprint `188590e94878478e33b6194e59fbbb28ff0888d5'
- The hostname in the certificate matches 'mail.acsgs.com'.
- Peer's certificate issuer is unknown
- Peer's certificate is NOT trusted
- Version: TLS1.0
- Key Exchange: RSA
- Cipher: ARCFOUR-128
- MAC: MD5
- Compression: NULL
EHLO nws.gedalya.net
250-acsgsemail1.acsgs.com Hello [xx.xx.xx.xx]
250-TURN
250-SIZE
250-ETRN
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-8bitmime
250-BINARYMIME
250-CHUNKING
250-VRFY
250-X-EXPS GSSAPI NTLM LOGIN
250-X-EXPS=LOGIN
250-AUTH GSSAPI NTLM LOGIN
250-AUTH=LOGIN
250-X-LINK2STATE
250-XEXCH50
250 OK
MAIL FROM:<some...@something.net>
250 2.1.0 some...@something.net....Sender OK
RCPT TO:<sggs...@example.com>
550 5.7.1 Unable to relay for sggs...@example.com
QUIT
221 2.0.0 acsgsemail1.acsgs.com Service closing transmission channel
*** Fatal error: A TLS packet with unexpected length was received.
*** Server has terminated the connection abnormally.
Kurt Roeckx
Jun 12, 2013, 5:50:01 PM6/12/13
to
On Wed, Jun 12, 2013 at 05:29:20PM -0400, Gedalya wrote:
> On 06/12/2013 02:35 PM, Kurt Roeckx wrote:
> >This start a succesful (TLSv1) connection for me:
> >openssl s_client -connect mail.megacontractinginc.com:25 -starttls smtp -crlf
> >
> >But I can reproduce some weird behaviour with it that goes away
> >when I use -no_tls1_2.
> >
> >
> >Kurt
>
> Found another example.
> GnuTLS negotiates the same cipher as openssl would with only TLSv1 enabled.
I didn't notice before that -no_tsl1_2 also resulted in a
> On 06/12/2013 02:35 PM, Kurt Roeckx wrote:
> >This start a succesful (TLSv1) connection for me:
> >openssl s_client -connect mail.megacontractinginc.com:25 -starttls smtp -crlf
> >
> >But I can reproduce some weird behaviour with it that goes away
> >when I use -no_tls1_2.
> >
> >
> >Kurt
>
> Found another example.
> GnuTLS negotiates the same cipher as openssl would with only TLSv1 enabled.
different cipher being selected. Without -no_tsl1_2 I get
DES-CBC3-SHA, with I get RC4-MD5.
gnutls-cli goes for:
- Key Exchange: RSA
- Cipher: ARCFOUR-128
- MAC: MD5
Kurt
- Cipher: ARCFOUR-128
- MAC: MD5
Kurt Roeckx
Jun 15, 2013, 11:20:01 AM6/15/13
to
forwarded 706423 http://rt.openssl.org/Ticket/Display.html?id=3072&user=guest&pass=guest
thanks
I forwarded it to upstream.
thanks
I forwarded it to upstream.
Gedalya
Jun 15, 2013, 9:20:02 PM6/15/13
to
OK, it's no longer "just some old Exchange 2003 servers".... this is major.
$ openssl s_client -connect smtp.live.com:587 -starttls smtp -crlf -quiet
depth=1 C = BE, O = GlobalSign nv-sa, CN = GlobalSign Organization
Validation CA - G2
AUTH LOGIN
334 VXNlcm5hbWU6
140689921832616:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong
version number:s3_pkt.c:337:
Found out about this at https://github.com/andris9/Nodemailer/issues/140
Gedalya
$ openssl s_client -connect smtp.live.com:587 -starttls smtp -crlf -quiet
depth=1 C = BE, O = GlobalSign nv-sa, CN = GlobalSign Organization
Validation CA - G2
verify error:num=20:unable to get local issuer certificate
verify return:0
250 OK
verify return:0
AUTH LOGIN
334 VXNlcm5hbWU6
140689921832616:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong
version number:s3_pkt.c:337:
Found out about this at https://github.com/andris9/Nodemailer/issues/140
Gedalya
Kurt Roeckx
Nov 9, 2013, 6:40:02 PM11/9/13
to
On Sat, Jun 15, 2013 at 05:14:00PM +0200, Kurt Roeckx wrote:
> forwarded 706423 http://rt.openssl.org/Ticket/Display.html?id=3072&user=guest&pass=guest
> thanks
So I just found this:
> forwarded 706423 http://rt.openssl.org/Ticket/Display.html?id=3072&user=guest&pass=guest
> thanks
http://www.ietf.org/mail-archive/web/tls/current/msg10471.html
Kurt Roeckx
Nov 9, 2013, 7:40:02 PM11/9/13
to
> http://www.ietf.org/mail-archive/web/tls/current/msg10471.html
Can I suggest that we just change the default cipher list the
postfix sends to the server?
I currently see this in postfix's config:
tls_export_cipherlist = aNULL:-aNULL:ALL:+RC4:@STRENGTH
tls_high_cipherlist = aNULL:-aNULL:ALL:!EXPORT:!LOW:!MEDIUM:+RC4:@STRENGTH
tls_low_cipherlist = aNULL:-aNULL:ALL:!EXPORT:+RC4:@STRENGTH
tls_medium_cipherlist = aNULL:-aNULL:ALL:!EXPORT:!LOW:+RC4:@STRENGTH
tls_null_cipherlist = eNULL:!aNULL
smtpd_tls_ciphers = export
smtp_tls_mandatory_ciphers = medium
The first thing I have to wonder about is why it says:
"aNULL:-aNULL:ALL". That doesn't seem to make sense to
me. You start with the anonymous ciphers, you remove
them, but non permanent, and then you add ALL, which
which add them again, and you just end up with "ALL".
(But the order seems to be different, I don't really
understand.)
The "+RC4" shouldn't change much either, since that just
reorders things (and doesn't add anything), and then you
reorder the whole thing with @STRENGTH.
Please not that openssl's default (DEFAULT) is ALL:!aNULL:!eNULL
where the ! permanently deletes those from the list and can't be
added later again.
I really see no good reason to have anonymous ciphers in the list
since they are vulnerable to a MITM attack. And the list as it
is now has actually has anonymous ciphers at the start. It starts
with:
AECDH-AES256-SHA SSLv3 Kx=ECDH Au=None Enc=AES(256) Mac=SHA1
SRP-AES-256-CBC-SHA SSLv3 Kx=SRP Au=None Enc=AES(256) Mac=SHA1
ADH-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=None Enc=AESGCM(256) Mac=AEAD
ADH-AES256-SHA256 TLSv1.2 Kx=DH Au=None Enc=AES(256) Mac=SHA256
ADH-AES256-SHA SSLv3 Kx=DH Au=None Enc=AES(256) Mac=SHA1
ADH-CAMELLIA256-SHA SSLv3 Kx=DH Au=None Enc=Camellia(256) Mac=SHA1
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD
This specially doesn't make sense for the mandatory list, but
I would say that this doesn't make sense for the opportunistic
list either.
The non-mandatory list (smtpd_tls_ciphers, tls_export_cipherlist)
currently has 103 ciphers.
When changing it from:
aNULL:-aNULL:ALL:+RC4:@STRENGTH
to:
ALL:-aNULL:+RC4:@STRENGTH
This will already reduce the list to 84 ciphers.
And when using:
ALL:!aNULL:+RC4:@STRENGTH
it's reduced to 82.
There are probably a number of other types you might
want to remove. I don't think PSK and SRP are going
to be used much, so you could do this:
ALL:!aNULL:!eNULL:!SRP:!PSK:@STRENGTH
You might also want to consider changing the order, for
instance placing DES near the end, but the worst still
at the end:
ALL:!aNULL:!eNULL:!SRP:!PSK:@STRENGTH:+3DES:+LOW:+EXPORT
Can I suggest that we just change the default cipher list the
postfix sends to the server?
I currently see this in postfix's config:
tls_export_cipherlist = aNULL:-aNULL:ALL:+RC4:@STRENGTH
tls_high_cipherlist = aNULL:-aNULL:ALL:!EXPORT:!LOW:!MEDIUM:+RC4:@STRENGTH
tls_low_cipherlist = aNULL:-aNULL:ALL:!EXPORT:+RC4:@STRENGTH
tls_medium_cipherlist = aNULL:-aNULL:ALL:!EXPORT:!LOW:+RC4:@STRENGTH
tls_null_cipherlist = eNULL:!aNULL
smtpd_tls_ciphers = export
smtp_tls_mandatory_ciphers = medium
The first thing I have to wonder about is why it says:
"aNULL:-aNULL:ALL". That doesn't seem to make sense to
me. You start with the anonymous ciphers, you remove
them, but non permanent, and then you add ALL, which
which add them again, and you just end up with "ALL".
(But the order seems to be different, I don't really
understand.)
The "+RC4" shouldn't change much either, since that just
reorders things (and doesn't add anything), and then you
reorder the whole thing with @STRENGTH.
Please not that openssl's default (DEFAULT) is ALL:!aNULL:!eNULL
where the ! permanently deletes those from the list and can't be
added later again.
I really see no good reason to have anonymous ciphers in the list
since they are vulnerable to a MITM attack. And the list as it
is now has actually has anonymous ciphers at the start. It starts
with:
AECDH-AES256-SHA SSLv3 Kx=ECDH Au=None Enc=AES(256) Mac=SHA1
SRP-AES-256-CBC-SHA SSLv3 Kx=SRP Au=None Enc=AES(256) Mac=SHA1
ADH-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=None Enc=AESGCM(256) Mac=AEAD
ADH-AES256-SHA256 TLSv1.2 Kx=DH Au=None Enc=AES(256) Mac=SHA256
ADH-AES256-SHA SSLv3 Kx=DH Au=None Enc=AES(256) Mac=SHA1
ADH-CAMELLIA256-SHA SSLv3 Kx=DH Au=None Enc=Camellia(256) Mac=SHA1
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD
This specially doesn't make sense for the mandatory list, but
I would say that this doesn't make sense for the opportunistic
list either.
The non-mandatory list (smtpd_tls_ciphers, tls_export_cipherlist)
currently has 103 ciphers.
When changing it from:
aNULL:-aNULL:ALL:+RC4:@STRENGTH
to:
ALL:-aNULL:+RC4:@STRENGTH
This will already reduce the list to 84 ciphers.
And when using:
ALL:!aNULL:+RC4:@STRENGTH
it's reduced to 82.
There are probably a number of other types you might
want to remove. I don't think PSK and SRP are going
to be used much, so you could do this:
ALL:!aNULL:!eNULL:!SRP:!PSK:@STRENGTH
You might also want to consider changing the order, for
instance placing DES near the end, but the worst still
at the end:
ALL:!aNULL:!eNULL:!SRP:!PSK:@STRENGTH:+3DES:+LOW:+EXPORT
Kurt Roeckx
Nov 12, 2013, 2:10:02 PM11/12/13
to
On Sun, Nov 10, 2013 at 01:37:34AM +0100, Kurt Roeckx wrote:
> > http://www.ietf.org/mail-archive/web/tls/current/msg10471.html
>
> Can I suggest that we just change the default cipher list the
> postfix sends to the server?
>
> I currently see this in postfix's config:
> tls_export_cipherlist = aNULL:-aNULL:ALL:+RC4:@STRENGTH
> tls_high_cipherlist = aNULL:-aNULL:ALL:!EXPORT:!LOW:!MEDIUM:+RC4:@STRENGTH
> tls_low_cipherlist = aNULL:-aNULL:ALL:!EXPORT:+RC4:@STRENGTH
> tls_medium_cipherlist = aNULL:-aNULL:ALL:!EXPORT:!LOW:+RC4:@STRENGTH
> tls_null_cipherlist = eNULL:!aNULL
>
> smtpd_tls_ciphers = export
> smtp_tls_mandatory_ciphers = medium
I guess it's important to also show:
> > http://www.ietf.org/mail-archive/web/tls/current/msg10471.html
>
> Can I suggest that we just change the default cipher list the
> postfix sends to the server?
>
> I currently see this in postfix's config:
> tls_export_cipherlist = aNULL:-aNULL:ALL:+RC4:@STRENGTH
> tls_high_cipherlist = aNULL:-aNULL:ALL:!EXPORT:!LOW:!MEDIUM:+RC4:@STRENGTH
> tls_low_cipherlist = aNULL:-aNULL:ALL:!EXPORT:+RC4:@STRENGTH
> tls_medium_cipherlist = aNULL:-aNULL:ALL:!EXPORT:!LOW:+RC4:@STRENGTH
> tls_null_cipherlist = eNULL:!aNULL
>
> smtpd_tls_ciphers = export
> smtp_tls_mandatory_ciphers = medium
smtp_tls_exclude_ciphers =
smtp_tls_mandatory_exclude_ciphers =
And from the manpage:
The underlying cipherlists for grades other than "null"
include anonymous ciphers, but these are automatically
filtered out if the Postfix SMTP client is configured to
verify server certificates. You are very unlikely to need
to take any steps to exclude anonymous ciphers, they are
excluded automatically as necessary. If you must exclude
anonymous ciphers at the "may" or "encrypt" security
levels, when the Postfix SMTP client does not need or use
peer certificates, set "smtp_tls_exclude_ciphers = aNULL".
To exclude anonymous ciphers only when TLS is enforced, set
"smtp_tls_mandatory_exclude_ciphers = aNULL".
I'm a little confused by this. I can understand that for
smtp_tls_security_level=may that you might want to allow
anonymous ciphers, since you're happy to send it to anybody or not
encrypted at all. But I'm not sure what the encrypt level really
means. It uses the mandatory values, but does that just accept any
certificate it sees? Does it check the CA-path? The hostname? I
have a feeling it only does some of those things at the verify
level. So I have to wonder what that level gets you more than the
may level other than a different list of acceptable ciphers.
I'm going to assume that if you set the level to fingerprint,
verify or secure that it excludes aNULL itself, even if that's
nowhere in the config file.
> The first thing I have to wonder about is why it says:
> "aNULL:-aNULL:ALL". That doesn't seem to make sense to
> me. You start with the anonymous ciphers, you remove
> them, but non permanent, and then you add ALL, which
> which add them again, and you just end up with "ALL".
> (But the order seems to be different, I don't really
> understand.)
With OpenSSL 1.0.0 and later the cipherlist may start with an
"aNULL:" prefix, which restores the 0.9.8-compatible ordering
of the aNULL ciphers to the top of the list when they are
enabled. This prefix is not needed with previous OpenSSL
releases.
> You might also want to consider changing the order, for
> instance placing DES near the end, but the worst still
> at the end:
> ALL:!aNULL:!eNULL:!SRP:!PSK:@STRENGTH:+3DES:+LOW:+EXPORT
aNULL:-aNULL:ALL:+RC4:!SRP:!PSK:!SEED:!MD5:!CAMELLIA:@STRENGTH:+3DES:+LOW:+EXPORT
I had to exclude CAMELLIA to get a reasanable list again with all
those anonymous ciphers.
I also wonder why so many people have complained about this. I
assume that they run at the may level in which case it should just
retry without encryption, and they shouldn't see any problems?
Scott Kitterman
Nov 11, 2016, 1:40:02 AM11/11/16
to
On Tue, 12 Nov 2013 19:52:19 +0100 Kurt Roeckx <ku...@roeckx.be> wrote:
> On Sun, Nov 10, 2013 at 01:37:34AM +0100, Kurt Roeckx wrote:
> > > http://www.ietf.org/mail-archive/web/tls/current/msg10471.html
> >
> > Can I suggest that we just change the default cipher list the
> > postfix sends to the server?
> >
> > I currently see this in postfix's config:
> > tls_export_cipherlist = aNULL:-aNULL:ALL:+RC4:@STRENGTH
> > tls_high_cipherlist = aNULL:-aNULL:ALL:!EXPORT:!LOW:!MEDIUM:+RC4:@STRENGTH
> > tls_low_cipherlist = aNULL:-aNULL:ALL:!EXPORT:+RC4:@STRENGTH
> > tls_medium_cipherlist = aNULL:-aNULL:ALL:!EXPORT:!LOW:+RC4:@STRENGTH
> > tls_null_cipherlist = eNULL:!aNULL
> >
> > smtpd_tls_ciphers = export
> > smtp_tls_mandatory_ciphers = medium
For what it's worth, this is now a bit different (3.1.3):
> On Sun, Nov 10, 2013 at 01:37:34AM +0100, Kurt Roeckx wrote:
> > > http://www.ietf.org/mail-archive/web/tls/current/msg10471.html
> >
> > Can I suggest that we just change the default cipher list the
> > postfix sends to the server?
> >
> > I currently see this in postfix's config:
> > tls_export_cipherlist = aNULL:-aNULL:ALL:+RC4:@STRENGTH
> > tls_high_cipherlist = aNULL:-aNULL:ALL:!EXPORT:!LOW:!MEDIUM:+RC4:@STRENGTH
> > tls_low_cipherlist = aNULL:-aNULL:ALL:!EXPORT:+RC4:@STRENGTH
> > tls_medium_cipherlist = aNULL:-aNULL:ALL:!EXPORT:!LOW:+RC4:@STRENGTH
> > tls_null_cipherlist = eNULL:!aNULL
> >
> > smtpd_tls_ciphers = export
> > smtp_tls_mandatory_ciphers = medium
tls_export_cipherlist = aNULL:-aNULL:HIGH:MEDIUM:LOW:EXPORT:+RC4:@STRENGTH
tls_high_cipherlist = aNULL:-aNULL:HIGH:@STRENGTH
tls_low_cipherlist = aNULL:-aNULL:HIGH:MEDIUM:LOW:+RC4:@STRENGTH
tls_medium_cipherlist = aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH
tls_null_cipherlist = eNULL:!aNULL
smtpd_tls_ciphers = medium
smtp_tls_mandatory_ciphers = medium
Are people still having this problem?
Scott K
0 new messages