Hello, I plan to submit the following text for packaging guidelines regarding crypto policies. Are there any comments or suggestions?
Since Fedora 21 (http://fedoraproject.org/wiki/Changes/CryptoPolicy) there are policies for the usage of SSL and TLS cryptographic protocols that are enforced system-wide. Each application being added in Fedora must be checked to comply with the policies. Currently the policies are restricted to applications using GnuTLS and OpenSSL.
* OpenSSL applications: If the application provides a configuration file that allows to modify the cipher list string, ensure that the default is "PROFILE=SYSTEM". Otherwise, if the application doesn't have a configuration file, ensure that there is no default cipher list specified, or that the default list is set as "PROFILE=SYSTEM".
* GnuTLS applications: If the application provides a configuration file that allows to modify the cipher priority string, ensure that the default is "@SYSTEM". Otherwise, if the application doesn't have a configuration file, ensure that it uses gnutls_set_default_priority(), or that the default priority string is "@SYSTEM".
Applications utilizing other cryptographic libraries do not adhere to the system wide crypto policies.
regards, Nikos
Hello, ----- Original Message -----
I plan to submit the following text for packaging guidelines regarding crypto policies. Are there any comments or suggestions?
Not all packagers are intimately familiar with the code, or even programmers at all. Would it be easy to provide something to grep for (e.g. function names) and perhaps even a link to an existing patch as an example of the change that needs to be done? Mirek
On 08/08/14 09:20, Nikos Mavrogiannopoulos wrote:
Hello, I plan to submit the following text for packaging guidelines regarding crypto policies. Are there any comments or suggestions?
Since Fedora 21 (http://fedoraproject.org/wiki/Changes/CryptoPolicy) there are policies for the usage of SSL and TLS cryptographic protocols that are enforced system-wide. Each application being added in Fedora must be checked to comply with the policies. Currently the policies are restricted to applications using GnuTLS and OpenSSL.
- OpenSSL applications: If the application provides a configuration
file that allows to modify the cipher list string, ensure that the default is "PROFILE=SYSTEM". Otherwise, if the application doesn't have a configuration file, ensure that there is no default cipher list specified, or that the default list is set as "PROFILE=SYSTEM".
- GnuTLS applications: If the application provides a configuration file
that allows to modify the cipher priority string, ensure that the default is "@SYSTEM". Otherwise, if the application doesn't have a configuration file, ensure that it uses gnutls_set_default_priority(), or that the default priority string is "@SYSTEM".
Applications utilizing other cryptographic libraries do not adhere to the system wide crypto policies.
regards, Nikos
-- security mailing list security@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/security
What about GNUPG ?
And what will that default be set to ? Because certain ciphers that NIST seems to think are OK, are not OK, as we found out. And who decides which cyphers are good in that context ?
Are we following bettercrypto.org's paper ?
Regards,
Tristan
On Fri, 2014-08-08 at 05:22 -0400, Miloslav Trmač wrote:
Hello, ----- Original Message -----
I plan to submit the following text for packaging guidelines regarding crypto policies. Are there any comments or suggestions?
Not all packagers are intimately familiar with the code, or even programmers at all. Would it be easy to provide something to grep for (e.g. function names) and perhaps even a link to an existing patch as an example of the change that needs to be done?
Right, I've updated the text with more detailed instructions at: https://fedoraproject.org/wiki/User:Nmav/CryptoPolicies
regards, Nikos
On Fri, 2014-08-08 at 10:34 +0100, Tristan Santore wrote:
What about GNUPG ? And what will that default be set to ?
Nothing. It is outside the scope for now. The idea is to extend to all applications we can though, but currently, unless someone contributes an enhancement, it is restricted to TLS/SSL and openssl/gnutls.
Because certain ciphers that NIST seems to think are OK, are not OK, as we found out.
Which ciphers are those? Most probably you are referring to the EC-dual DRBG random generator. I don't believe we ever had that. It was a bad choice for both technical and security reasons.
And who decides which cyphers are good in that context ? Are we following bettercrypto.org's paper ?
We do, by following many recommendations. Not only NIST's, and not only bettercrypto's.
regards, Nikos
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Fri, Aug 08, 2014 at 10:20:29AM +0200, Nikos Mavrogiannopoulos wrote:
Hello, I plan to submit the following text for packaging guidelines regarding crypto policies. Are there any comments or suggestions?
I like it. I wonder what work is being done on other packages (like mod_ssl) to have them point to the system default by... umm... default. I'm sure there are others (postfix) that would similarly benefit from a default conf file update.
- -- Eric
- -------------------------------------------------- Eric "Sparks" Christensen Red Hat, Inc - Product Security
sparks@redhat.com - sparks@fedoraproject.org 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - --------------------------------------------------
On Fri, 2014-08-08 at 09:05 -0400, Eric H. Christensen wrote:
On Fri, Aug 08, 2014 at 10:20:29AM +0200, Nikos Mavrogiannopoulos wrote:
Hello, I plan to submit the following text for packaging guidelines regarding crypto policies. Are there any comments or suggestions?
I like it. I wonder what work is being done on other packages (like mod_ssl) to have them point to the system default by... umm... default. I'm sure there are others (postfix) that would similarly benefit from a default conf file update.
That is the idea. I've filled a small number of bugs (that include mod_ssl) which currently block #1076390 [0]. The plan is to have any issues figured out with this small set, and then fill bugs for most of the packages before F22.
Postfix is a different kind of beast though. It does not typically use TLS, but uses some kind of opportunistic security that allows anonymous ciphersuites. So it's a bit hard to enforce anything there, as man-in-the-middle attacks are possible by design.
regards, Nikos
Am 08.08.2014 um 15:21 schrieb Nikos Mavrogiannopoulos:
Postfix is a different kind of beast though. It does not typically use TLS, but uses some kind of opportunistic security that allows anonymous ciphersuites. So it's a bit hard to enforce anything there, as man-in-the-middle attacks are possible by design
and keep in mind in case of opportunistic TLS if you restrict ciphers and the SMTP client don't support what you offer it falls back to completly plaintext which defeats the intention
for secured and verified SMTP it needs special care
* DANE and DNSSEC which goes far above email only * smtpd_tls_ask_ccert where admins of both sides must work together and also coordinate cert changes
in short: MTA's acting as public MX must not enforce default TLS policies from the distribution shipping the package
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Fri, Aug 08, 2014 at 03:36:51PM +0200, Reindl Harald wrote:
Am 08.08.2014 um 15:21 schrieb Nikos Mavrogiannopoulos:
Postfix is a different kind of beast though. It does not typically use TLS, but uses some kind of opportunistic security that allows anonymous ciphersuites. So it's a bit hard to enforce anything there, as man-in-the-middle attacks are possible by design
and keep in mind in case of opportunistic TLS if you restrict ciphers and the SMTP client don't support what you offer it falls back to completly plaintext which defeats the intention
Falling back to an insecure cipher only provides a false sense of security which isn't any better than plaintext.
- -- Eric
- -------------------------------------------------- Eric "Sparks" Christensen Red Hat, Inc - Product Security
sparks@redhat.com - sparks@fedoraproject.org 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - --------------------------------------------------
----- Original Message -----
From: "Eric H. Christensen" sparks@fedoraproject.org To: "Reindl Harald" h.reindl@thelounge.net Cc: security@lists.fedoraproject.org Sent: Friday, 8 August, 2014 3:44:40 PM Subject: Re: proposed text for crypto-policies in Packaging Guidelines
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Fri, Aug 08, 2014 at 03:36:51PM +0200, Reindl Harald wrote:
Am 08.08.2014 um 15:21 schrieb Nikos Mavrogiannopoulos:
Postfix is a different kind of beast though. It does not typically use TLS, but uses some kind of opportunistic security that allows anonymous ciphersuites. So it's a bit hard to enforce anything there, as man-in-the-middle attacks are possible by design
and keep in mind in case of opportunistic TLS if you restrict ciphers and the SMTP client don't support what you offer it falls back to completly plaintext which defeats the intention
Falling back to an insecure cipher only provides a false sense of security which isn't any better than plaintext.
the alternative is no encryption at all, so it is more secure than plain text
and until most SMTP servers won't have properly configured TLS with certificates, it will have to remain like this
On Fri, 2014-08-08 at 15:36 +0200, Reindl Harald wrote:
Am 08.08.2014 um 15:21 schrieb Nikos Mavrogiannopoulos:
Postfix is a different kind of beast though. It does not typically use TLS, but uses some kind of opportunistic security that allows anonymous ciphersuites. So it's a bit hard to enforce anything there, as man-in-the-middle attacks are possible by design
and keep in mind in case of opportunistic TLS if you restrict ciphers and the SMTP client don't support what you offer it falls back to completly plaintext which defeats the intention
[...]
in short: MTA's acting as public MX must not enforce default TLS policies from the distribution shipping the package
Not really. I'd expect a mail server to always connect with TLS to servers that it has previously connected with TLS to. Otherwise I could always see the plaintext messages by blocking any TLS communication. Nevertheless, this is application policy, and the system policy does not apply here.
regards, Nikos
Am 08.08.2014 um 15:44 schrieb Eric H. Christensen:
On Fri, Aug 08, 2014 at 03:36:51PM +0200, Reindl Harald wrote:
Am 08.08.2014 um 15:21 schrieb Nikos Mavrogiannopoulos:
Postfix is a different kind of beast though. It does not typically use TLS, but uses some kind of opportunistic security that allows anonymous ciphersuites. So it's a bit hard to enforce anything there, as man-in-the-middle attacks are possible by design
and keep in mind in case of opportunistic TLS if you restrict ciphers and the SMTP client don't support what you offer it falls back to completly plaintext which defeats the intention
Falling back to an insecure cipher only provides a false sense of security which isn't any better than plaintext.
that is nonsense - it would be good if people stop to confuse SMTP with HTTP - in case of SMTP there is no warning and dialog in front of a human
* plaintext can read anybody * decrypt a "insecure cipher" needs time and knowledge
you have no choice on the MTA side - you can't enforce encryption on a incoming MX and in case of opportunistic TLS you have *no chance* to defeat a MITM at all
so the only thing you can do is make more harm by implicitly disable encryption at all for incoming mail which otherwise would have been encrypted
that was discussed thousands of times on the postfix list and *please* if you don't agree talk on the postfix list, they guy which wrote most of the TLS code in postfix is the author of that below and explained it often enough http://tools.ietf.org/html/draft-dukhovni-smtp-opportunistic-tls-00
you *can not* enforce ciphers for opportunistic TLS - period because that is the nature of *opportunistic*
whatever you try to enforce that way in defaults will come back as bugreport and howtos "first after you install Fedora on a MTA you need to change the following settings until it is useable as public MX"
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Fri, Aug 08, 2014 at 04:11:51PM +0200, Reindl Harald wrote:
Am 08.08.2014 um 15:44 schrieb Eric H. Christensen:
On Fri, Aug 08, 2014 at 03:36:51PM +0200, Reindl Harald wrote:
Am 08.08.2014 um 15:21 schrieb Nikos Mavrogiannopoulos:
Postfix is a different kind of beast though. It does not typically use TLS, but uses some kind of opportunistic security that allows anonymous ciphersuites. So it's a bit hard to enforce anything there, as man-in-the-middle attacks are possible by design
and keep in mind in case of opportunistic TLS if you restrict ciphers and the SMTP client don't support what you offer it falls back to completly plaintext which defeats the intention
Falling back to an insecure cipher only provides a false sense of security which isn't any better than plaintext.
you *can not* enforce ciphers for opportunistic TLS - period because that is the nature of *opportunistic*
I agree with your assessment, however, ordering the ciphers that are to be used can still be done.
- -- Eric
- -------------------------------------------------- Eric "Sparks" Christensen Red Hat, Inc - Product Security
sparks@redhat.com - sparks@fedoraproject.org 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - --------------------------------------------------
Am 08.08.2014 um 16:30 schrieb Eric H. Christensen:
On Fri, Aug 08, 2014 at 04:11:51PM +0200, Reindl Harald wrote:
Am 08.08.2014 um 15:44 schrieb Eric H. Christensen:
On Fri, Aug 08, 2014 at 03:36:51PM +0200, Reindl Harald wrote:
Am 08.08.2014 um 15:21 schrieb Nikos Mavrogiannopoulos:
Postfix is a different kind of beast though. It does not typically use TLS, but uses some kind of opportunistic security that allows anonymous ciphersuites. So it's a bit hard to enforce anything there, as man-in-the-middle attacks are possible by design
and keep in mind in case of opportunistic TLS if you restrict ciphers and the SMTP client don't support what you offer it falls back to completly plaintext which defeats the intention
Falling back to an insecure cipher only provides a false sense of security which isn't any better than plaintext.
you *can not* enforce ciphers for opportunistic TLS - period because that is the nature of *opportunistic*
I agree with your assessment, however, ordering the ciphers that are to be used can still be done
agreed, with caution below, that is still an issue and 64 is sadly exceeded with defaults and in future versions of openssl that will grow (new cipher types)
[harry@srv-rhsoft:~]$ openssl ciphers -v | wc -l 75
71: RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1
http://www.ietf.org/mail-archive/web/tls/current/msg10554.html The Windows 2003 TLS stack (still used by a non-trivial number of Microsoft Exchange SMTP servers) only looks at the first 64 elements of the cipherlist. If neither RC4-SHA nor RC4-MD5 are among these, it sometimes chooses 3DES (for which it misimplements CBC padding) and fails during data transfer, or if that is suppressed or also too far down the list, just fails the handshake
----- Original Message -----
From: "Reindl Harald" h.reindl@thelounge.net To: security@lists.fedoraproject.org Sent: Friday, 8 August, 2014 4:45:02 PM Subject: Re: proposed text for crypto-policies in Packaging Guidelines
Am 08.08.2014 um 16:30 schrieb Eric H. Christensen:
On Fri, Aug 08, 2014 at 04:11:51PM +0200, Reindl Harald wrote:
Am 08.08.2014 um 15:44 schrieb Eric H. Christensen:
On Fri, Aug 08, 2014 at 03:36:51PM +0200, Reindl Harald wrote:
Am 08.08.2014 um 15:21 schrieb Nikos Mavrogiannopoulos:
Postfix is a different kind of beast though. It does not typically use TLS, but uses some kind of opportunistic security that allows anonymous ciphersuites. So it's a bit hard to enforce anything there, as man-in-the-middle attacks are possible by design
and keep in mind in case of opportunistic TLS if you restrict ciphers and the SMTP client don't support what you offer it falls back to completly plaintext which defeats the intention
Falling back to an insecure cipher only provides a false sense of security which isn't any better than plaintext.
you *can not* enforce ciphers for opportunistic TLS - period because that is the nature of *opportunistic*
I agree with your assessment, however, ordering the ciphers that are to be used can still be done
agreed, with caution below, that is still an issue and 64 is sadly exceeded with defaults and in future versions of openssl that will grow (new cipher types)
[harry@srv-rhsoft:~]$ openssl ciphers -v | wc -l 75
71: RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1
http://www.ietf.org/mail-archive/web/tls/current/msg10554.html The Windows 2003 TLS stack (still used by a non-trivial number of Microsoft Exchange SMTP servers) only looks at the first 64 elements of the cipherlist. If neither RC4-SHA nor RC4-MD5 are among these,
Which wasn't the case since openssl 1.0.1:
$ openssl ciphers -v | cat -n | grep RC4 67 ECDHE-RSA-RC4-SHA SSLv3 Kx=ECDH Au=RSA Enc=RC4(128) Mac=SHA1 68 ECDHE-ECDSA-RC4-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=RC4(128) Mac=SHA1 69 ECDH-RSA-RC4-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=RC4(128) Mac=SHA1 70 ECDH-ECDSA-RC4-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=RC4(128) Mac=SHA1 71 RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 72 RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 73 PSK-RC4-SHA SSLv3 Kx=PSK Au=PSK Enc=RC4(128) Mac=SHA1 74 KRB5-RC4-SHA SSLv3 Kx=KRB5 Au=KRB5 Enc=RC4(128) Mac=SHA1 75 KRB5-RC4-MD5 SSLv3 Kx=KRB5 Au=KRB5 Enc=RC4(128) Mac=MD5
(and is only worse for the ALL cipherstring)
maybe that means that they have been falling back to plaintext since 1.0.1 release but I'd say that admins of Win2003 have much more pressing issues than security of their SMTP connections...
security@lists.fedoraproject.org
-
Eric Christensen -
Hubert Kario -
Miloslav Trmač -
Nikos Mavrogiannopoulos -
Reindl Harald -
Tristan Santore