Skip to content
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

Handshake Failure: SSL Alert number 40 #69

Closed
ParanoidUser opened this issue Nov 9, 2022 · 7 comments
Closed

Handshake Failure: SSL Alert number 40 #69

ParanoidUser opened this issue Nov 9, 2022 · 7 comments
Milestone

Comments

@ParanoidUser
Copy link

Came across a sporadic SSL handshake failure in one of the parallel job executions. The same job passed from the second attempt after re-running. While it's unclear why higher TLS versions didn't work through in this case, it might be worth configuring OpenSSL to restrict SSLv3 usage on the client side.

image

Error: write EPROTO 140390028728256:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:../deps/openssl/openssl/ssl/record/rec_layer_s3.c:1546:SSL alert number 40

@TWiStErRob
Copy link
Contributor

TWiStErRob commented Nov 29, 2022

I got exactly the same error, many times recently. This is because I added validation just recently to all my repos. I'm about to disable wrapper validation in some cases, because this happens too much in a huge matrix, and if one matrix job fails, I have to rerun the whole matrix. (This is a GitHub missing feature.) (it was implemented sometime in 2023). But the step shouldn't fail in the first place. All steps fire the requests at the same time on Gradle's server, depending on how in sync the runners pick up the job on GitHub Actions, could this be the problem? (DDoS)

Error: write EPROTO 140558040758208:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:../deps/openssl/openssl/ssl/record/rec_layer_s3.c:1546:SSL alert number 40

TWiStErRob added a commit to TWiStErRob/net.twisterrob.gradle that referenced this issue Nov 29, 2022
@ParanoidUser
Copy link
Author

Hope it will be helpful to someone. As a workaround, I've switched to using gradle-update/update-gradle-wrapper-action which verifies wrapper integrity upon updating (docs).

Pros: keeps Gradle wrapper up-to-date, what yet not supported by Dependabot.
Cons: pushes unsigned commits that may violate action permission policies in your repo.

@TWiStErRob
Copy link
Contributor

Renovate updates wrappers along with version numbers.
Docs don't mention it, but it does update all files, even in multiple projects in one repo.

@bigdaz
Copy link
Member

bigdaz commented Feb 1, 2024

This looks like it should be fixed by #167

@bigdaz bigdaz closed this as completed Feb 1, 2024
@bigdaz bigdaz added this to the v2.1.0 milestone Feb 1, 2024
@TWiStErRob
Copy link
Contributor

Nice, thanks @Marcono1234 and @JLLeitschuh for doing the heavy lifting!

It'll definitely decrease the probability of this happening significantly.

@bigdaz
Copy link
Member

bigdaz commented Feb 1, 2024

@TWiStErRob You'll just need to wait for v2.1.0 (or using the bleeding edge of main :) ).

@TWiStErRob
Copy link
Contributor

No worries, I got them stable by running once in a separate runner. Not the most cost-effective though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants