Bugzilla – Full Text Bug Listing
|Summary:||Globus Proxy Certificates should migrate away from MD5|
|Product:||GSI C||Reporter:||Von Welch <firstname.lastname@example.org>|
|Component:||Credentials and Proxies||Assignee:||Joe Bester <email@example.com>|
|Severity:||normal||CC:||firstname.lastname@example.org, email@example.com, firstname.lastname@example.org|
This bug applies to both the C and Java sides of Globus. I assigned it to GSI C arbitrarily. Currently GT Proxy Certificates are signed with MD5-based signatures. While there is not a definitive problem yet, the MD5 hash algorithm is known to be weak and attacks against X.509 certificates are starting to occur (e.g. http://www.win.tue.nl/hashclash/rogue-ca/). GT should migrate from MD5-based signatures on proxy certificates to a SHA-based signature before MD5 is broken to the extent this becomes a problem. The GCS was already migrated from MD5 (see Bug 6263). Questions to be answered: 1) What other software outside of GT would be impacted by this? What hash algorithms are they prepared to accept? VOMS would seem to be one such piece of software. MyProxy and GSI-OpenSSH use GT libraries. 2) Should we migrate to SHA-1 algorithm or SHA-2 (those seem to be the obvious choices)? SHA-1 is starting to show weakness already, but SHA-2 support is not ubiquitous yet and may not be in older versions of OpenSSL. The correct question here is probably: what does not support SHA-2 that we care about? 3) Do we need a method for allowing a deployment to turn off support for a hash algorithm so that deployment could migrate as it sees fit? E.g. a way to specify a list of acceptable algorithms. Even if GT signs using SHA, it's unreasonable to expect a whole deployment to move to SHA at once, hence some period of support for both would seem to be required where MD5 signatures are still accepted. We should also consider introducing randomness into the proxy certificate serial number when we do this. I will explain why in a separate bug report.
(In reply to comment #0) > We should also consider introducing randomness into the proxy certificate > serial number when we do this. I will explain why in a separate bug report. Bug 6614
(In reply to comment #0) > 2) Should we migrate to SHA-1 algorithm or SHA-2 (those seem to be the obvious > choices)? SHA-1 is starting to show weakness already, but SHA-2 support is not > ubiquitous yet and may not be in older versions of OpenSSL. The correct > question here is probably: what does not support SHA-2 that we care about? Quoting from http://email@example.com/msg10143.html Nearly everything I've seen regarding the proposed solutions to this attack have involved migration to SHA-1. SHA-1 is scheduled to be decertified by NIST in 2010, and NIST has already recommended moving away from SHA-1 to SHA-2 (256, 512, etc.). Collision attacks have already been demonstrated against SHA-1 back in 2005, and if history tells us anything then things will only get worse for SHA-1 from here. By not moving directly to at least SHA-2 (until the winner of the NIST hash competition is known), these vendors are likely setting themselves up for similar attacks in the (relatively) near future.  http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html  http://www.cryptography.com/cnews/hash.html
The OpenSSL we ship with 4.0.x does not include the SHA-2 variants. For 4.2.x we use the system-supplied OpenSSL, but it looks like there are API functions in OpenSSL to look up digest methods by name, so we can determine at runtime what is supported by the system without relying on the preprocessor in either case. It looks like the proxy API has hooks for specifying a signing algorithm as an attribute to the GSI-specific structure, but only SHA-1 is allowed in the actual signing code. I propose we add a new environment variable to the security configuration: GLOBUS_GSI_PROXY_DIGESTS with the value being a colon-separated of OpenSSL digest names (default being "SHA256:SHA1:MD5". If a proxy used for authentication is signed by something other than one of those, it will be rejected. If a proxy is signed by one of those and we don't have runtime support for it, it will also be rejected. When the code signs a proxy, it'll use the first one in the list which is supported by the runtime. It can be overridden by setting the proxy handle attribute to a different digest method. Also, add a command-line option to grid-proxy-init to choose the hash by name to explicitly override the environment/default values. There are also some bits in the WS-Security code which use signing, but that will be for another bug if we want to address that.
CoG JGlobus is the relevant module for this on Java GSI. It appears that SHA1 and SHA2 are supported by the libraries used for proxy creation. The current Java API does not allow choosing of the algorithm but uses the signing algorithm from the issuing certificate. Additional API can be added to override this. Quick review of API, I could not find any way to dynamically detect supported algorithms, but need to investigate some more. Like Joe mentions, if support is needed in WS Security, code in wsrf module needs to be modified.
Hi Joe. I am worried that we will get a compatibility mess with your proposal. For example, the OpenSSL on SL4 and SL5 seems not to support SHA2. So if a user has a machine with a more "advanced" OpenSSL library that does support it, and create a proxy with with SHA2-based signature, this proxy will be useless on most of OSG (as an example). Since SHA2 will be the Globus default on that platform, the user will be surprised, at the very least. I think we need to agree on a hash algorithm and make sure we can use it on all the supported platforms. Else, we will get into one of the following scenarios: a) a complete mess (like descried above) b) people will learn to use the common denominator... and once people start putting things like grid-proxy-init -hash md5 in their scripts, it will take forever to change that. My 2c, Igor
I think the right solution here is to do what the Java side already does, namely: The current Java API does not allow choosing of the algorithm but uses the signing algorithm from the issuing certificate. Basically, whatever the algorithm is used to sign the EEC is used for all subsequent proxy certificates. This puts the migration firmly in the hands of the deployers and GT will follow along with any future migration as the CAs migrate to SHA2 (which they presumably won't do until OpenSSL fully supports it). If a deployer doesn't want to trust a particular algorithm, it falls on them to not trust any CA issuing with that algoritm.
That's easy enough to implement. Are the CAs consistent enough in how they have been signing things to make this an effective way to disallow MD5?
In addition to the signature of the certificate itself, the ProxyCertInfo extension is signed. Currently the GSI C code hardcodes SHA1 signatures. I assume this should also match the issuer certificate digest algorithm?
Actually, I misread the code, the other SHA1 hash is used to generate the serial number of the proxy certificate.
(In reply to comment #9) > Actually, I misread the code, the other SHA1 hash is used to generate the > serial number of the proxy certificate. Ah, good. I was concerned there for a moment. We should also take up the serial number under Bug 6614
I committed an implementation of "use issuer's cert signing algorithm" based on the 4.2 branch to the bug_6613_4_2_branch CVS branch. See http://viewcvs.globus.org/viewcvs.cgi/gsi/proxy/proxy_core/source/library/globus_gsi_proxy.c?r1=126.96.36.199&r2=188.8.131.52.2.1&pathrev=bug_6613_4_2_branch http://viewcvs.globus.org/viewcvs.cgi/gsi/gssapi/source/library/accept_delegation.c?r1=1.37&r2=184.108.40.206&pathrev=bug_6613_4_2_branch http://viewcvs.globus.org/viewcvs.cgi/gsi/gssapi/source/library/accept_sec_context.c?r1=1.34&r2=220.127.116.11&pathrev=bug_6613_4_2_branch for the patches. There currently are no test cases for the proxy_core API at all, so we can either rely on the higher-level tests or spend some time writing tests for that API.
The patches I posted yesterday don't address question #3 yet from the original post. Does it make sense to add an environment setting of "hashes I trust"? Current GSI-C proxies are md5 even if the cert is signed with sha1.
(In reply to comment #12) > The patches I posted yesterday don't address question #3 yet from the original > post. Does it make sense to add an environment setting of "hashes I trust"? > Current GSI-C proxies are md5 even if the cert is signed with sha1. Without rendering an opinion, let me lay forth some thinking on the matter. My thinking is that a deployer can with the patch control what hashes they accept by controlling what CAs they accept. If they don't want to accept MD5 hashes, don't accept any CAs that sign EECs with MD5. A couple places where that won't work: 1) A CA that has EECs signed with different hashes. Probably for historical reasons. I know of no such CA today. 2) When there is a mix of patched and unpatched GSI, which can result in a user whose EEC is signed with (e.g.) SHA1 but takes a path through legacy GRAM or SSH and ends up presenting a MD5-signed proxy. E.g. they GSI-SSH to host A with a SHA-1-signed EEC, but using an old SSH client which delegates a MD5-signed PC, and then connect via GSI-SSH to host B.
(In reply to comment #12) > The patches I posted yesterday don't address question #3 yet from the original > post. Does it make sense to add an environment setting of "hashes I trust"? > Current GSI-C proxies are md5 even if the cert is signed with sha1. I propose we go ahead and roll the algorithm inheritance Joe has implemented out as soon as possible. I believe that is a major step forward for C implementation security and the sooner we get it out the better. With regards to a configuration option for "hashes I trust" I propose we consider that as a separate issue (i.e. create another bug for it) and see what feedback and requirements we get from the user community. I think we still have enough time with MD5 we are better off thinking this over a little.
Patch committed to 4.2 and 4.0 branches and trunk, so that the proxy is signed with the same digest that signed the issuing certificate, but there is no strict enforcement that this is the case. Joe
(In reply to comment #4) > CoG JGlobus is the relevant module for this on Java GSI. It appears that SHA1 > and SHA2 are supported by the libraries used for proxy creation. The current > Java API does not allow choosing of the algorithm but uses the signing > algorithm from the issuing certificate. Additional API can be added to override > this. Quick review of API, I could not find any way to dynamically detect > supported algorithms, but need to investigate some more. I'm seeing problems with jglobus when using SHA-2 certificates. PureTLS appears to not support SHA-2. I opened Bug 6730 to track it.