Removes usages of SHA1 for non-cryptographic reasons

[Eric Hubbard]

I'm not sure if this can be solved with the current approach. What about cases where protocols demand the usage of SHA-1 for non-cryptographic reasons, for example WebSockets:

https://www.rfc-editor.org/rfc/rfc6455#section-10.8

The WebSocket handshake described in this document doesn't depend on
   any security properties of SHA-1, such as collision resistance or
   resistance to the second pre-image attack (as described in
   [[RFC4270](https://www.rfc-editor.org/rfc/rfc4270)]).

Does that then mean we have to roll a custom SHA-1 code that won't get caught by this patch?

[Simo Sorce]

SHA-1 should work for non-cryptographic reasons, we should be hard-blocking SHA-1 only in signature generation/verification.

[Eric Hubbard]

hmm.. this call: (https://github.com/gorilla/websocket/blob/af47554f343b4675b30172ac301638d350db34a5/util.go#L20)
h := sha1.New()
Seems to take the boringssl branch and panic..

sha_locl.h(128): OpenSSL internal error, assertion failed: Low level API call to digest SHA1 forbidden in FIPS mode!
SIGABRT: abort
PC=0x7fb19ab34ce1 m=14 sigcode=18446744073709551610
signal...

This is when using golang-fips and FIPS mode is enabled in openssl.

[Jeremy Lin]

@Radisovik This probably means you're using a (non-RHEL) OpenSSL that forbids use of the low-level APIs in FIPS mode. This should be resolved whenever golang-fips/openssl#27 gets merged into mainline, as that PR switches to using the (high-level) EVP APIs for hashing.