search

GENI-NSF / geni-ch

GENI clearinghouse services
Other
3 stars 6 forks source link

GENI experimenter certificates use SHA-1 signature algorithm #539

Closed tcmitchell closed 6 years ago

tcmitchell commented 7 years ago

The days of SHA-1 are numbered. We should plan a graceful transition to a stronger signature algorithm. SHA-2 is a possibility. It will depend on the capabilities of the OS and libraries.

This can be set in our openssl.cnf file, per this article.

Our current setting is:

default_md  = sha1

That could change to sha2 or sha256, or something else.

nbastin commented 7 years ago

I found this ticket when I was going to file...this ticket.

I'm not sure if there will be side effects to using something other than SHA-1 on the client side, but it would at least be nice to have the option. This is going to cause HIPAA and PCI compliance issues (it only hasn't already because until now they were only checking the server side, but that is likely to change this year, and then we'll be out of compliance).

tcmitchell commented 7 years ago

@nbastin do you have any thoughts or recommendations on which algorithm (SHA-2, SHA-256, ...) should be used to replace SHA-1 for signing the experimenter certificates?

nbastin commented 7 years ago

I think SHA-256 is fine. Given that there are practical attacks (https://eprint.iacr.org/2016/374.pdf) across the entire SHA-2 suite (224/256/384/512), I'm content to leave running analysis of the crypto arms race to other people and just use the things that the compliance bodies require.. :-)

One problem with this across the GENI federation is that that TLS 1.0 pre-dates the SHA-2 ciper suite, and aggregates that don't support TLS 1.2 may or may not have support for SHA-2-based certs. (The TLS 1.0 aggregates also don't satisfy compliance requirements for certain types of research because of the weaknesses in TLS 1.0).

hussamnasir commented 6 years ago

So user certs are now all SHA256 . So i assume this is resolved.