April 2014 - security [ARCHIVED] - Fedora Mailing-Lists

by Nikos Mavrogiannopoulos

Hello, For the purposes of the Crypto Policies change proposal [0], I think I've settled to the following three policy levels (inspired by the ENISA levels but with a rename of the good LEGACY level to DEFAULT). Any comments or suggestions are appreciated. As these levels will be a moving target across releases (will provide defaults that reflect the current state of the art), levels of previous fedora releases will be referenced as LEVELNAME-F21. [0]. https://fedoraproject.org/wiki/Changes/CryptoPolicy regards, Nikos The levels and their current settings: =====LEGACY===== A level that may include algorithms with known weaknesses (but not completely broken) which will ensure maximum compatibility with legacy systems. It should provide at least 64-bit security and include RC4, but not MD5 as signature algorithm. MACs: MD5, SHA1+ Curves: All supported Signature algorithms: must use SHA-1 hash or better Ciphers: AES-GCM, AES-CBC, CAMELLIA-GCM, CAMELLIA-CBC, 3DES-CBC, RC4 Key exchange: ECDHE, RSA, DHE DH params size: 768+ RSA params size: 768+ SSL Protocols: All supported (SSL3.0+) =====DEFAULT====== A reasonable default for today's standards. For F21 it should provide 80-bit security and no broken ciphers like RC4. MACs: SHA1+ Curves: All supported Signature algorithms: must use SHA-1 hash or better Ciphers: AES-GCM, AES-CBC, CAMELLIA-GCM, CAMELLIA-CBC, 3DES-CBC Key exchange: ECDHE, RSA, DHE DH params size: 1024+ RSA params size: 1024+ SSL Protocols: All supported (SSL3.0+) =====FUTURE====== A level that will provide security on a conservative level that is believed to withstand any near-term future attacks. That will be an 128-bit security level, without including protocols with known attacks available (e.g. SSL 3.0/TLS 1.0). This level may prevent communication with commonly used systems that provide weaker security levels (e.g., systems that use SHA-1 as signature algorithm). MACs: SHA1+ Curves: All supported Signature algorithms: must use SHA-256 hash or better Ciphers: AES-GCM, AES-CBC, CAMELLIA-GCM, CAMELLIA-CBC Key exchange: ECDHE, RSA, DHE DH params size: 2048+ RSA params size: 2048+ SSL Protocols: TLS1.1+

9 years, 11 months

12
52
0 / 0

[Secure Coding] master: sect-Defensive_Coding-TLS-OpenSSL: Mention "openssl genrsa" entropy issue (564ffc8)

by fweimer＠fedoraproject.org

Repository : http://git.fedorahosted.org/git/?p=secure-coding.git On branch : master >--------------------------------------------------------------- commit 564ffc80149307d0a99724e2689ed3a8816513bf Author: Florian Weimer <fweimer(a)redhat.com> Date: Fri Apr 25 13:47:22 2014 +0200 sect-Defensive_Coding-TLS-OpenSSL: Mention "openssl genrsa" entropy issue >--------------------------------------------------------------- defensive-coding/en-US/Features-TLS.xml | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/defensive-coding/en-US/Features-TLS.xml b/defensive-coding/en-US/Features-TLS.xml index 936910d..f4da007 100644 --- a/defensive-coding/en-US/Features-TLS.xml +++ b/defensive-coding/en-US/Features-TLS.xml @@ -186,6 +186,15 @@ verify</command> result in an exit status of zero. </para> <para> + OpenSSL command-line commands, such as <command>openssl + genrsa</command>, do not ensure that physical entropy is used + for key generation—they obtain entropy from + <filename>/dev/urandom</filename> and other sources, but not + from <filename>/dev/random</filename>. Keys generated by + these tools should not be used in high-value, critical + functions. + </para> + <para> The OpenSSL server and client applications (<command>openssl s_client</command> and <command>openssl s_server</command>) are debugging tools and should <emphasis>never</emphasis> be

10 years

5
9
0 / 0

[Secure Coding] master: TLS: More balanced advice on "openssl genrsa" and /dev/urandom (7f640d9)

by fweimer＠fedoraproject.org

Repository : http://git.fedorahosted.org/git/?p=secure-coding.git On branch : master >--------------------------------------------------------------- commit 7f640d95375def0979c9f6a12c02cd414fe1eb7e Author: Florian Weimer <fweimer(a)redhat.com> Date: Mon Apr 28 15:41:05 2014 +0200 TLS: More balanced advice on "openssl genrsa" and /dev/urandom >--------------------------------------------------------------- defensive-coding/en-US/Features-TLS.xml | 8 +++++--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/defensive-coding/en-US/Features-TLS.xml b/defensive-coding/en-US/Features-TLS.xml index f4da007..5d9e39d 100644 --- a/defensive-coding/en-US/Features-TLS.xml +++ b/defensive-coding/en-US/Features-TLS.xml @@ -190,9 +190,11 @@ genrsa</command>, do not ensure that physical entropy is used for key generation—they obtain entropy from <filename>/dev/urandom</filename> and other sources, but not - from <filename>/dev/random</filename>. Keys generated by - these tools should not be used in high-value, critical - functions. + from <filename>/dev/random</filename>. This can result in + weak keys if the system lacks a proper entropy source (e.g., a + virtual machine with solid state storage). Depending on local + policies, keys generated by these OpenSSL tools should not be + used in high-value, critical functions. </para> <para> The OpenSSL server and client applications (<command>openssl

10 years

1
0
0 / 0

[Secure Coding] master: RPM packaging: X.509 key pair generation (95c2976)

by fweimer＠fedoraproject.org

Repository : http://git.fedorahosted.org/git/?p=secure-coding.git On branch : master >--------------------------------------------------------------- commit 95c297659e14411959ae36ae6a3a29a550c668c0 Author: Florian Weimer <fweimer(a)redhat.com> Date: Fri Apr 25 16:33:08 2014 +0200 RPM packaging: X.509 key pair generation >--------------------------------------------------------------- defensive-coding/en-US/Defensive_Coding.xml | 1 + defensive-coding/en-US/Tasks-Packaging.xml | 131 +++++++++++++++++++++++++++ 2 files changed, 132 insertions(+), 0 deletions(-) diff --git a/defensive-coding/en-US/Defensive_Coding.xml b/defensive-coding/en-US/Defensive_Coding.xml index b8ca3de..7ca3f46 100644 --- a/defensive-coding/en-US/Defensive_Coding.xml +++ b/defensive-coding/en-US/Defensive_Coding.xml @@ -18,6 +18,7 @@ <xi:include href="Tasks-Processes.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> <xi:include href="Tasks-Serialization.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> <xi:include href="Tasks-Cryptography.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + <xi:include href="Tasks-Packaging.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> </part> <part> <title>Implementing Security Features</title> diff --git a/defensive-coding/en-US/Tasks-Packaging.xml b/defensive-coding/en-US/Tasks-Packaging.xml new file mode 100644 index 0000000..95bfbc6 --- /dev/null +++ b/defensive-coding/en-US/Tasks-Packaging.xml @@ -0,0 +1,131 @@ +<?xml version='1.0' encoding='utf-8' ?> +<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +]> +<chapter id="chap-Defensive_Coding-Tasks-Packaging"> + <title>RPM packaging</title> + <para> + This chapter deals with security-related concerns around RPM + packaging. It has to be read in conjunction with + distribution-specific packaging guidelines. + </para> + <section id="sect-Defensive_Coding-Tasks-Packaging-Certificates"> + <title>Generating X.509 self-signed certificates during + installation</title> + <para> + Some applications need X.509 certificates for authentication + purposes. For example, a single private/public key pair could + be used to define cluster membership, enabling authentication + and encryption of all intra-cluster communication. (Lack of + certification from a CA matters less in such a context.) For + such use, generating the key pair at package installation time + when preparing system images for use in the cluster is + reasonable. For other use cases, it is necessary to generate + the key pair before the service is started for the first time. + </para> + <important> + <para> + The way the key is generated may not be suitable for key + material of critical value. (<command>openssl + genrsa</command> uses, but does not require, entropy from a + physical source of randomness, among other things.) Such keys + should be stored in a hardware security module if possible, + and generated from random bits reserved for this purpose + derived from a non-deterministic physical source. + </para> + </important> + <para> + In the spec file, we define two RPM variables which contain the + names of the files used to store the private and public key, and + the user name for the service: + </para> + <informalexample> + <programlisting language="RPM Spec"> +# Name of the user owning the file with the private key +%define tlsuser %{name} +# Name of the directory which contains the key and certificate files +%define tlsdir %{_sysconfdir}/%{name} +%define tlskey %{tlsdir}/%{name}.key +%define tlscert %{tlsdir}/%{name}.crt + </programlisting> + </informalexample> + <para> + These variables likely need adjustment based on the needs of the + package. + </para> + <para> + Typically, the file with the private key needs to be owned by + the system user which needs to read it, + <literal>%{tlsuser}</literal> (not <literal>root</literal>). In + order to avoid races, if the <emphasis>directory</emphasis> + <literal>%{tlsdir}</literal> is <emphasis>owned by the services + user</emphasis>, you should use the code in <xref + linkend="ex-Defensive_Coding-Packaging-Certificates-Owned"/>. + The invocation of <application>su</application> with the + <option>-s /bin/bash</option> argument is necessary in case the + login shell for the user has been disabled. + </para> + <example id="ex-Defensive_Coding-Packaging-Certificates-Owned"> + <title>Creating a key pair in a user-owned directory</title> + <programlisting language="Bash"> +%post +if [ $1 -eq 1 ] ; then + if ! test -e %{tlskey} ; then + su -s /bin/bash \ + -c "umask 077 && openssl genrsa -out %{tlskey} 2048 2>/dev/null" \ + %{tlsuser} + fi + if ! test -e %{tlscert} ; then + cn="Automatically generated certificate for the %{tlsuser} service" + req_args="-key %{tlskey} -out %{tlscert} -days 7305 -subj \"/CN=$cn/\"" + su -s /bin/bash \ + -c "openssl req -new -x509 -extensions usr_cert $req_args" \ + %{tlsuser} + fi +fi + +%files +%dir %attr(0755,%{tlsuser},%{tlsuser]) %{tlsdir} +%ghost %attr(0600,%{tlsuser},%{tlsuser}) %{tlskey} +%ghost %attr(0644,%{tlsuser},%{tlsuser}) %{tlscert} + </programlisting> + </example> + <para> + If the <emphasis>directory</emphasis> + <literal>%{tlsdir}</literal> <emphasis>is owned by</emphasis> + <literal>root</literal>, use the code in <xref + linkend="ex-Defensive_Coding-Packaging-Certificates-Unowned"/>. + </para> + <example id="ex-Defensive_Coding-Packaging-Certificates-Unowned"> + <title>Creating a key pair in a <literal>root</literal>-owned directory</title> + <programlisting language="Bash"> +%post +if [ $1 -eq 1 ] ; then + if ! test -e %{tlskey} ; then + (umask 077 && openssl genrsa -out %{tlskey} 2048 2>/dev/null) + chown %{tlsuser} %{tlskey} + fi + if ! test -e %{tlscert} ; then + cn="Automatically generated certificate for the %{tlsuser} service" + openssl req -new -x509 -extensions usr_cert \ + -key %{tlskey} -out %{tlscert} -days 7305 -subj "/CN=$cn/" + fi +fi + +%files +%dir %attr(0755,%{root},%{root}]) %{tlsdir} +%ghost %attr(0600,%{tlsuser},%{tlsuser}) %{tlskey} +%ghost %attr(0644,%{root},%{root}) %{tlscert} + </programlisting> + </example> + <para> + In order for this to work, the package which generates the keys + must require the <application>openssl</application> package. If + the user which owns the key file is generated by a different + package, the package generating the certificate must specify a + <literal>Requires(pre):</literal> on the package which creates + the user. This ensures that the user account will exist when it + is needed for the <application>su</application> or + <application>chmod</application> invocation. + </para> + </section> +</chapter>

10 years

3
2
0 / 0

[Secure Coding] master: Custom memory allocators: Complete sentence (eff2f5c)

by fweimer＠fedoraproject.org

Repository : http://git.fedorahosted.org/git/?p=secure-coding.git On branch : master >--------------------------------------------------------------- commit eff2f5c71f3cd02e603dcd9e616a332f3490a0db Author: Florian Weimer <fweimer(a)redhat.com> Date: Thu Apr 10 21:10:41 2014 +0200 Custom memory allocators: Complete sentence Also add section ID. >--------------------------------------------------------------- defensive-coding/en-US/C-Allocators.xml | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/defensive-coding/en-US/C-Allocators.xml b/defensive-coding/en-US/C-Allocators.xml index 1bff610..58c89ee 100644 --- a/defensive-coding/en-US/C-Allocators.xml +++ b/defensive-coding/en-US/C-Allocators.xml @@ -140,7 +140,7 @@ </para> </section> - <section> + <section id="sect-Defensive_Coding-C-Allocators-Custom"> <title>Custom memory allocators</title> <para> Custom memory allocates come in two forms: replacements for @@ -176,7 +176,8 @@ allocators. In micro-benchmarks, pool allocators can show huge wins, and size-specific pools can reduce internal fragmentation. But often, utilization of individual pools - is poor, and + is poor, and external fragmentation increases the overall + memory usage. </para> </listitem> </itemizedlist>

10 years

1
0
0 / 0

TCP connections restricted to specific users

by Florian Weimer

Suppose I have a cluster of machines, running an application. The application opens up TCP connections to other machines, without any form of authentication. If nothing else is running on these machines, it is possible to use iptables, perhaps in combination with IPsec, to prevent misuse of these services. If there are other services running the cluster nodes which are supposed to have different privileges, what are my options to preserve this distinction in privileges? If those other services can connect to the TCP port used by the clustered application, it's possible that the (supposedly unprivileged) service takes over the cluster. Would iptables owner match work here? Is there some way to pass on user information with IPsec? -- Florian Weimer / Red Hat Product Security Team

10 years

2
2
0 / 0

Developing a security Bat Signal?

by Matthew Miller

I think we did a pretty good job in responding to CVE-2014-0160, but there's also room for improvement. One particular need is the ability to get in touch with owners of core components, or if they are not available, provenpackagers with particular security expertise -- and in either case, also _testers_ with a security background. Maybe we need to have some sort of (opt-in) Fedora Bat Signal for extra-critical and urgent security issues in core packages. We would promise not to use it unless the internet were actually on fire, as it appears to be in this case, and then have (escrowed somewhere?) private 24/7 contact information (phone numbers, SMS). What do you think? Anyone interested in developing this idea further? -- Matthew Miller -- Fedora Project -- <mattdm(a)fedoraproject.org> "Tepid change for the somewhat better!"

10 years, 1 month

7
13
0 / 0

Re: available crypto policies

by Aaron Zauner

Hi List, > The levels and their current settings: > > =====LEGACY===== > A level that may include algorithms with known weaknesses (but not > completely broken) which will ensure maximum compatibility with legacy > systems. It should provide at least 64-bit security and include RC4, but > not MD5 as signature algorithm. > > MACs: MD5, SHA1+ > Curves: All supported > Signature algorithms: must use SHA-1 hash or better > Ciphers: AES-GCM, AES-CBC, CAMELLIA-GCM, CAMELLIA-CBC, 3DES-CBC, RC4 > Key exchange: ECDHE, RSA, DHE > DH params size: 768+ > RSA params size: 768+ > SSL Protocols: All supported (SSL3.0+) You do state 'but not completely broken' - 768bit/param RSA/DH can nowadays be broken in reasonable time (and money) even by private individuals. As far as I know it is the largest key-length to be factored by an university research project (!). They do not always use the best hardware available for such tasks (I currently work as an HPC engineer in my day job), and I can imagine that Amazon AWS instances might sometimes even perform better than some university setups. There's even a ready-to-factor setup for AWS provided by Nadia Heninger: http://crypto.2013.rump.cr.yp.to/981774ce07e51813fd4466612a78601b.pdf https://www.cis.upenn.edu/~nadiah/projects/faas/ > =====DEFAULT====== > A reasonable default for today's standards. For F21 it should provide > 80-bit security and no broken ciphers like RC4. > > MACs: SHA1+ > Curves: All supported > Signature algorithms: must use SHA-1 hash or better > Ciphers: AES-GCM, AES-CBC, CAMELLIA-GCM, CAMELLIA-CBC, 3DES-CBC > Key exchange: ECDHE, RSA, DHE > DH params size: 1024+ > RSA params size: 1024+ > SSL Protocols: All supported (SSL3.0+) I'd remove SSLv3, there's really no reason to keep it in there, you'll be backwards compatible to OpenSSL releases dating back to the early 2000s. SSLv3 has various protocol flaws. All larger web companies I know of and security people are nowadays using 2048bit keys since 1024bit is too close to a real world (for nation-state actors, that is) factorable quantity. Is there any reason not to bump that up a notch? > =====FUTURE====== > A level that will provide security on a conservative level that is > believed to withstand any near-term future attacks. That will be > an 128-bit security level, without including protocols with known > attacks available (e.g. SSL 3.0/TLS 1.0). This level may prevent > communication with commonly used systems that provide weaker security > levels (e.g., systems that use SHA-1 as signature algorithm). > > MACs: SHA1+ > Curves: All supported > Signature algorithms: must use SHA-256 hash or better > Ciphers: AES-GCM, AES-CBC, CAMELLIA-GCM, CAMELLIA-CBC > Key exchange: ECDHE, RSA, DHE > DH params size: 2048+ > RSA params size: 2048+ > SSL Protocols: TLS1.1+ Algorithm choices seem very reasonable. One must be careful not to allow TLS <1.1 though (BEAST). Possible additions would be ChaCha20, Poly1305 and Ed25519. I'd actually go with TLS1.2+ and 4096bit RSA/DH. It's the future, right? Is there any reason not to (e.g. performance)? Sincerely, Aaron

10 years, 1 month

3
5
0 / 0

Crypto guidelines for Fedora

by Till Maas

Hi, I recently noticed that several packages in Fedora create RSA keys with inappropriate key sizes: dnssec-trigger creates RSA 1536 keys with certificate that is valid for 20 years: https://bugzilla.redhat.com/show_bug.cgi?id=1045689 dropbear-keygen creates by default RSA 1024 keys: https://bugzilla.redhat.com/show_bug.cgi?id=1039311 Some other observations: ssh-keygen on F19 creates RSA 2048 keys by default ENISA recommends to at least RSA 3072 keys: http://www.enisa.europa.eu/activities/identity-and-trust/library/delivera... If e.g. AES-256 is used. RSA 15360 is recommended for long-term usage. Therefore I would like to propose a packaging guideline about which minimum key size software in Fedora should generate by default. It seems to me that requiring RSA 3072 key by default in Fedora is a good initial compromise. I did not notice RSA keys with more than 4096 bits regularly, therefore I am not sure whether using RSA 15360 keys by default is a good idea. What is your opinion? Regards Till

10 years, 1 month

6
12
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

security [ARCHIVED] April 2014