You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm leaving a quick note here for searchability in case anyone else encounters this issue.
My team reported to me that the SHA1 call from this package throws a panic when the new FIPS module from Go 1.24 is enabled. More specifically, h := sha1.New() still seems to work, as does h.Write(...), but the call to h.Sum(...) will panic.
The solution is to change GODEBUG=fips140=only to GODEBUG=fips140=on. I'm not sure if there's a better long-term solution for those with more stringent compliance requirements.
It seems that RFC-6455 requires the use of SHA-1 to calculate the Sec-Websocket-Accept header, creating a conflict if you want to disallow all functions that aren't FIPS compliant. My understanding is that its use in this context is purely a protocol requirement though, not a cryptographic security feature -- i.e., there's nothing inherently insecure about its use here in the gorilla/websocket package. However, fips140=only mode will cause a panic when SHA-1 is called, regardless of the non-security context.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I'm leaving a quick note here for searchability in case anyone else encounters this issue.
My team reported to me that the SHA1 call from this package throws a panic when the new FIPS module from Go 1.24 is enabled. More specifically,
h := sha1.New()
still seems to work, as doesh.Write(...)
, but the call toh.Sum(...)
will panic.The solution is to change
GODEBUG=fips140=only
toGODEBUG=fips140=on
. I'm not sure if there's a better long-term solution for those with more stringent compliance requirements.It seems that RFC-6455 requires the use of SHA-1 to calculate the
Sec-Websocket-Accept
header, creating a conflict if you want to disallow all functions that aren't FIPS compliant. My understanding is that its use in this context is purely a protocol requirement though, not a cryptographic security feature -- i.e., there's nothing inherently insecure about its use here in thegorilla/websocket
package. However,fips140=only
mode will cause a panic when SHA-1 is called, regardless of the non-security context.Beta Was this translation helpful? Give feedback.
All reactions