Bug 35836 - SSL certificates: drop sha1 as default hashfunction
SSL certificates: drop sha1 as default hashfunction
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: SSL
UCS 3.2
Other Linux
: P5 enhancement (vote)
: UCS 3.2-3-errata
Assigned To: Felix Botner
Philipp Hahn
:
: 36324 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-09-06 21:37 CEST by Michael Grandjean
Modified: 2014-10-30 14:11 CET (History)
3 users (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Grandjean univentionstaff 2014-09-06 21:37:34 CEST
The default hash function for SSL certificates in UCS is still SHA-1. SHA-1 is considered less secure since researchers proved it's not collision-free in 2005 (https://www.schneier.com/blog/archives/2005/02/sha1_broken.html).

Microsoft will stop accepting SHA-1-based SSL certificates that are valid beyond 2017: http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-deprecation-policy.aspx

Mozilla plans to stop accepting SHA-1-based SSL certificates that are valid beyond 2017: https://bugzilla.mozilla.org/show_bug.cgi?id=942515

Google announced that they start sunsetting SHA-1 with the upcoming Chrome releases (starting with Chrome 39): http://googleonlinesecurity.blogspot.de/2014/09/gradually-sunsetting-sha-1.html

Therefore we should drop SHA-1 as default hash function and choose something stronger. Additionally, it would be nice if this could be configurable through UCR.
Comment 1 Michael Grandjean univentionstaff 2014-09-12 12:21:40 CEST
(In reply to Michael Grandjean from comment #0)
> Additionally, it would be nice if this could be configurable
> through UCR.

In fact there is already a UCR variable: 
> ssl/default/hashfunction: sha1

Nevertheless we should change the default to e.g. sha384.
Comment 2 Felix Botner univentionstaff 2014-10-15 14:27:48 CEST
ssl/default/hashfunction default is now sha384

YAML: 2014-10-15-univention-ssl.yaml
Comment 3 Philipp Hahn univentionstaff 2014-10-23 09:59:03 CEST
OK: r54453

RFC: openssl.cnf
   [CA_default] default_md=sha1
   [req] default_bits=1024
  This file is unused, as a file with the same name is generated by make-certificates.sh each time. IMHO it should be removed from the source code to reduce further confusion.

OK: 2014-10-15-univention-ssl.yaml
  (configurable via [+UCR variable+] ssl/default/hashfunction)

OK: annouce_errata -V 2014-10-15-univention-ssl.yaml

OK: Update: ucr get ssl/default/hashfunction # sha1
FAIL:
  ucr set ssl/default/hashfunction=sha384
  # <http://sdb.univention.de/content/15/50/en/renewing-the-complete-ssl-certificate-chain.html>
  rm -rf /etc/univention/ssl#
  apt-get {--re,}install univention-ssl
  openssl x509 -noout -text -in ucsCA/certs/00.pem | grep "Signature Algorithm"
  #        Signature Algorithm: sha1WithRSAEncryption
  #  Signature Algorithm: sha1WithRSAEncryption
  find -type f -exec grep -r sha {} +
  # ./ucsCA/CAreq.pem:    Signature Algorithm: sha1WithRSAEncryption

  In the [req] section "default_md=..." is missing, as [CA_default] only applies to the CA and not the requester; see "man req"

diff --git a/branches/ucs-3.2/ucs-3.2-3/base/univention-ssl/make-certificates.sh b/branches/ucs-3.2/ucs-3.2-3/base/univention-ssl/make-certificates.sh
index b7d6ba8..6b5c6b9 100755
--- a/branches/ucs-3.2/ucs-3.2-3/base/univention-ssl/make-certificates.sh
+++ b/branches/ucs-3.2/ucs-3.2-3/base/univention-ssl/make-certificates.sh
@@ -134,6 +134,7 @@ emailAddress		= optional
 
 default_bits		= $DEFAULT_BITS
 default_keyfile 	= privkey.pem
+default_md			= ${DEFAULT_MD}
 distinguished_name	= req_distinguished_name
 attributes		= req_attributes
 x509_extensions		= v3_ca
Comment 4 Stefan Gohmann univentionstaff 2014-10-28 22:00:33 CET
(In reply to Felix Botner from comment #2)
> ssl/default/hashfunction default is now sha384

It seems to break the libvirt TLS connection in UCS 4.0: Bug #36324

2014-10-28 03:01:07,817 - uvmmd.node - WARNING - 'qemu://xen4.deadlock0.intranet/system' broken? next check in 0:02:00.000. authentication failed: TLS handshake failed A TLS packet with unexpected length was received.

I've set the hash function again to sha1 in UCS 4.0. If this bug is fixed, please adjust the UCS 4 settings: r55055
Comment 5 Stefan Gohmann univentionstaff 2014-10-28 22:00:54 CET
*** Bug 36324 has been marked as a duplicate of this bug. ***
Comment 6 Felix Botner univentionstaff 2014-10-29 14:39:18 CET
> 
> diff --git
> a/branches/ucs-3.2/ucs-3.2-3/base/univention-ssl/make-certificates.sh
> b/branches/ucs-3.2/ucs-3.2-3/base/univention-ssl/make-certificates.sh
> index b7d6ba8..6b5c6b9 100755
> --- a/branches/ucs-3.2/ucs-3.2-3/base/univention-ssl/make-certificates.sh
> +++ b/branches/ucs-3.2/ucs-3.2-3/base/univention-ssl/make-certificates.sh
> @@ -134,6 +134,7 @@ emailAddress		= optional
>  
>  default_bits		= $DEFAULT_BITS
>  default_keyfile 	= privkey.pem
> +default_md			= ${DEFAULT_MD}
>  distinguished_name	= req_distinguished_name
>  attributes		= req_attributes
>  x509_extensions		= v3_ca

fixed


(In reply to Stefan Gohmann from comment #4)
> (In reply to Felix Botner from comment #2)
> > ssl/default/hashfunction default is now sha384
> 
> It seems to break the libvirt TLS connection in UCS 4.0: Bug #36324
> 
> 2014-10-28 03:01:07,817 - uvmmd.node - WARNING -
> 'qemu://xen4.deadlock0.intranet/system' broken? next check in 0:02:00.000.
> authentication failed: TLS handshake failed A TLS packet with unexpected
> length was received.
> 
> I've set the hash function again to sha1 in UCS 4.0. If this bug is fixed,
> please adjust the UCS 4 settings: r55055

sha256 seems to work, new default is sha256

Updated YAML, see 2014-10-15-univention-ssl.yaml

Merged to 4.0
Comment 7 Philipp Hahn univentionstaff 2014-10-29 18:19:55 CET
OK: UCS-3.2-3: r55085,r55095,r55098
OK: UCS-4.0-0: r55055,r55086,r55096,r55099
OK: openssl.cnf removed
OK: [req]
OK: ucr info ssl/default/hashfunction
OK: annouce_errata -V 2014-10-15-univention-ssl.yaml
OK: piuparts-test 2014-10-15-univention-ssl.yaml
OK: Signature Algorithm: sha256WithRSAEncryption
OK: virsh -c qemu://xen2/system

FYI: 
   openssl x509 -x509toreq -in ucsCA/CAcert.pem -signkey ucsCA/private/CAkey.pem -passin file:password
 still ope sha1WithRSAEncryption, as this doesn't use the openssl.cnf file: init() does the creation in reverse, that is it first generates a certificate and only then generates the request afterwards. Naturally one would first create the request and use that to create the certificate.
 Specifying an explicit "-sha256" on the command-line fixes that.
 As the file ucsCA/CAreq.pem is used never again in UCS (AFAIK it's only used to get the root-UCS-CA signed by some external CA), this is currently of minor importance.
 There is a historical report regarding the wrong algorithm in the Univention forum: <http://forum.univention.de/viewtopic.php?f=11&t=802>
Comment 8 Janek Walkenhorst univentionstaff 2014-10-30 14:11:36 CET
http://errata.univention.de/ucs/3.2/227.html