-
-
Notifications
You must be signed in to change notification settings - Fork 5.7k
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
Secure Defaults for HTTPS/TLS and for Password-Based Key Derivation #10602
Conversation
@@ -128,6 +128,8 @@ func (srv *Server) ListenAndServeTLS(certFile, keyFile string, serve ServeFuncti | |||
func (srv *Server) ListenAndServeTLSConfig(tlsConfig *tls.Config, serve ServeFunction) error { | |||
go srv.awaitShutdown() | |||
|
|||
tlsConfig.MinVersion = tls.VersionTLS12 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be set before when config is creating around here:
gitea/modules/graceful/server.go
Line 123 in c512bfd
return srv.ListenAndServeTLSConfig(config, serve) |
Also it would be better if this could be configured in app.ini so that it could be disable in case when needed to use with older browsers or integrations that do not support TLS 1.2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I intentionally set the restriction here to make sure it's enforced across all TLS connections ever made by Gitea. Given the security issues present in TLS 1.0 and 1.1, it doesn't make much sense to run TLS with vulnerable versions instead of not running it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even vulnerable security is better than no security and I agree that default should be secure by default but it would be still better to allow for users to change it in case they need it for backward compatibility
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, what is the best way to expose this via app.ini
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think same way as password hashing algorithm
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll work on it and follow up with an update, thank you.
Can we just keep the TLS defaults to golang's defaults (but overrideable)? I don't think we want to manually configure that stuff ideally and golang is certainly faster doing those changes than we are. So with all default, one should get TLS 1.2,1.3 in golang 1.14. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for PR :)
Could you split this up into two PRs, one for hash algo change, and another for TLS changes? This allows for reviewing and merging of each specific component and faster merging of a PR without blocking on non-related reviews.
I've fixed the user.yml test case |
So actually #10467 might fix tls version issue |
Guys, it's worth noting that Chrome, Firefox and Safari will all completely drop support for TLS 1.0 and 1.1 this month. In light of this news, is it still worth supporting these protocols in Gitea? I strongly but humbly recommend against it. |
@lafriks I could not find a mention of this feature in the Go 1.14 release notes. What gives you the impression that Go 1.14 will default to a minimum of TLS 1.2? |
It actually might not, you are right, still it should be moved out to separate PR and set in places where tls.Config is initialized not in code later on |
According to https://caniuse.com/#feat=tls1-1 there are still 2.44% users worldwide whose browser does not support TLS 1.1 or higher, so it should at least be an option, but probably not be the default. |
This comment has been minimized.
This comment has been minimized.
@olekukonko please use other communication methods for offtopic comments |
This comment has been minimized.
This comment has been minimized.
This should be splitted as two PRs. |
@@ -128,6 +128,8 @@ func (srv *Server) ListenAndServeTLS(certFile, keyFile string, serve ServeFuncti | |||
func (srv *Server) ListenAndServeTLSConfig(tlsConfig *tls.Config, serve ServeFunction) error { | |||
go srv.awaitShutdown() | |||
|
|||
tlsConfig.MinVersion = tls.VersionTLS12 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@KAepora can you remove this from this pull and resolve confilct
then I think this is ready to mrege
and pleace make a second pull for tlsConfig.MinVersion = tls.VersionTLS12
Looks like @KAepora has deleted their branches so I've remade these PRs and split them. |
Hello,
I represent Symbolic Software, an applied cryptography consultancy that has been a happy Gitea user for quite some time 😄I am submitting this pull request which provides two important changes to the default configurations of TLS and of password hashing in Gitea.
All changes made in this pull request have been fully tested.
Changes to TLS
Currently, Gitea allows TLS 1.0 and TLS 1.1 for HTTPS connections. These versions of TLS have long been deprecated due to security vulnerabilities, and are also no longer necessary for wide browser compatibility. The change I propose in this pull request sets TLS 1.2 as the minimum TLS version, with additional support for TLS 1.3.
On SSLLabs, we can see the difference. Before my changes:
After my changes:
Changes to Password-Based Key Derivation
Currently, Gitea uses
pbkdf2
as the default password hashing function. In this pull request, I replace that withargon2
as the default, for the following reasons:pbkdf2
is uniquely vulnerable to GPU and ASIC-based attacks thatargon2
andscrypt
are much less vulnerable against.pbkdf2
is vulnerable to acceleration attacks and to a host of other attacks thatargon2
andscrypt
are not vulnerable to.Therefore, given the above and especially given that
argon2
is a well-specified, formally studied design that has won the Password Hashing Competition, I think using it as the default instead ofpbkdf2
makes complete sense.Thank you very much for your work on Gitea, we are huge Gitea fans and look forward to perhaps contributing more in the future.