-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
crypto tls panic when pulling container images #191
Comments
I have confirmed that exact same panic also occurs with go v1.21.x. |
Thank you for looking into it! I tried that with a simple TLS client (compiled with the Go compiler built from the sh-5.1$ GOLANG_FIPS=1 OPENSSL_FORCE_FIPS_MODE=1 ./client --server-name fedoraproject.org --address fedoraproject.org:443
2024/05/15 08:12:04 Connected to 152.19.134.198:443 with: VersionTLS13 [TLS_AES_256_GCM_SHA384]
Would it be possible to set a breakpoint in |
I can definitely try the non-boring path. But first, let me share a script that helps reproduce the error in fips enabled env. see attached. You would need a linux amd64 machine (fedora/rh/centos shud work). Please let me know if the script doesn't work in ur env and i would be happy to make necessary modifications to it. Please rm the txt extension, github wont let me attach otherwise. |
@sipasing thanks for opening this issue and for the reproducer! As I mentioned over slack (and @ueno mentioned on this thread) somehow a non-FIPS (non-boring) hash is being selected and passed down into the FIPS module. Setting a breakpoint as @ueno mentioned could be helpful for us to understand how we're getting into this situation. |
Got it. On it. Do u have any preference on gdb or delve ? Or a simple debug print is sufficient ? |
Delve is preferred, a print statement could work as well. |
I added these print statement inside
and i get
right before the panic. For delve, I would need to attach to the go binary and then execute the ctr img pull command ? . working on it. |
To add to previous comment, hmac.go#64 is
|
to find the caller of NewHMAC, I further added another printf inside hmac.go#64
and i get
hmac.go#131 is
|
Delve output
|
Also right before the panic, dlv shows hash from
|
Ah, ok. So given that last comment it seems that the hash is of type |
Overall this is not something we can support. All crypto, including hashes, must be generated by the OpenSSL FIPS module. Upstream Go boringcrypto has the same constraints. I'd suggest to open a bug against the library or application that pulls in minio/sha256-simd and suggest to add Go boringcrypto support via build tags similarly to how it has been implemented in minio-go, for example: |
Thanks for the pointers. I am still investigating ways in which I can manually replace hashes generated by minio/sha256-simd in containerd (the application) with OpenSSL hashes. I kept this ticket open because I wanted to improve on the error messages. Currently there is a panic generated , but maybe we can improve it to also say that the hash is not supported or something to that effect ?? |
When we try to pull container images in fips enabled environments, we see a crypto tls panic.
I see the hashToMD function not able to find a match in the hash.Hash type switch here. and returning nil.
I instrumented a debug print statement inside the hashToMD function.
and i see
h type=*sha256.digest
But before the img pull command I also see cases of
h type=*openssl.sha256Hash
which seems to pass the type switch in hashToMD function. Not sure which type is expected or both.If I skip the type switch and hard code "return cryptoHashToMD(crypto.SHA256)" , the panic disappears.
The code function flow seems to be
ExtractHKDF -> newHKDF -> hashToMD -> h type=*sha256.digest -> no match in type switch.
The text was updated successfully, but these errors were encountered: