-
Notifications
You must be signed in to change notification settings - Fork 18k
x/crypto/ssh: export supported algorithms #61537
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
Comments
I definitely agree the supported algorithms should be somewhere on the godoc, either in the constants block or in the package description, but I am mildly opposed to exposing a list of "supported" algorithms as a slice or the like. First, it encourages enabling all supported algorithms by making it easy, and we have a lot of bad supported algorithms; second, "supported" is a complex state that can depend on when and how they are used. See #46232. Can we see the list of proposed constants? |
Here is the list of proposed constants
|
Do we need both KEXAlgoCurve25519SHA256LibSSH and KEXAlgoCurve25519SHA256? Can we just have KEXAlgoCurve25519SHA256 instead and always negotiate both if enabled, assuming the wire protocol is the same or equivalent? |
we can expose only |
This proposal has been added to the active column of the proposals project |
We could counter this by selecting a sensible default configuration for both client and server. If library users decide to override this default, we should provide them information to let them make informed choices. Maybe the TLS package is a good example: see https://pkg.go.dev/crypto/tls#CipherSuites and https://pkg.go.dev/crypto/tls#InsecureCipherSuites. We could do something like
if we have a clear distinction between secure/insecure algorithms, we could move the server implementation of 'client-only' algorithms out of the test files. |
Any more thoughts on this? What is the proposal we've converged on? |
I think we agree on exporting all supported algorithms as constants but we are not yet sure if exporting or not a list of supported algorithms. Internally we have a list of supported and preferred algorithms and use the preferred ones if no algorithm is explicitly configured. The weird thing for me the first time I used x/crypto as a user was that I had to look at the code to figure out which algorithms are supported and preferred.
We could also change the preferred algorithms so that sha-1 based algorithms are disabled by default |
re. Supported/Preferred vs. Supported/Insecure: following the pattern set by the TLS package will be less cognitive overhead in the long run, for folks that use both TLS and SSH package. I am assuming that the way the TLS package does it hasn't been a problem so far. |
That's fine with me too, the only difference is that if an application wants to check if a user-supplied algorithm is acceptable (crypto/ssh ignores unknown algorithms), it has to look at two lists. But at the same time this approach makes more difficult to enable "insecure" algorithms, which is perhaps what we want to achieve |
nit: |
order matters. The first common algorithm between client and server is selected, see findCommon |
order matters if you set it in ssh.Config, but maybe not for
|
ah ok, do you mean something like |
we can probably address that in your proposal as follows
so your proposal sounds fine. |
note, #58523 should be addressed together (ie in 2 reviews on top of each other) so we don't paint ourselves in an awkward corner with naming. other than that, I think we are in agreement on the general shape of things here. |
Change https://go.dev/cl/531935 mentions this issue: |
Hello, I tried a first implementation. Here are the exported constants
and here the exported struct and methods
|
The bool argument is odd; no one is going to remember at a call site what InsecureAlgorithms(true) does versus InsecureAlgorithms(false). Should we have four methods instead? (InsecureServerAlgorithms, ...)? |
The bool argument is not required, we are also trying to add server-side DHGEX (see CL 532415). I forgot to update this proposal, sorry. Here is the new proposal as implemented in CL 531935
|
There is a casing inconsistency that should be fixed: some names use "Kex" and others use "KEX". They should all use the same casing. |
You're right, do we agree on "KEX"? |
Fixes golang/go#61537 Change-Id: If3478121e3ae445391e3faeceeb889d75e9e3214
Fixes golang/go#61537 Change-Id: If3478121e3ae445391e3faeceeb889d75e9e3214
Fixes golang/go#61537 Change-Id: If3478121e3ae445391e3faeceeb889d75e9e3214
Fixes golang/go#61537 Change-Id: If3478121e3ae445391e3faeceeb889d75e9e3214
Fixes golang/go#61537 Change-Id: If3478121e3ae445391e3faeceeb889d75e9e3214
Fixes golang/go#61537 Change-Id: If3478121e3ae445391e3faeceeb889d75e9e3214
Fixes golang/go#61537 Change-Id: If3478121e3ae445391e3faeceeb889d75e9e3214
Fixes golang/go#61537 Change-Id: If3478121e3ae445391e3faeceeb889d75e9e3214
Fixes golang/go#61537 Change-Id: If3478121e3ae445391e3faeceeb889d75e9e3214
Fixes golang/go#61537 Change-Id: If3478121e3ae445391e3faeceeb889d75e9e3214
Fixes golang/go#61537 Change-Id: If3478121e3ae445391e3faeceeb889d75e9e3214
Fixes golang/go#61537 Change-Id: If3478121e3ae445391e3faeceeb889d75e9e3214
Fixes golang/go#61537 Change-Id: If3478121e3ae445391e3faeceeb889d75e9e3214
Fixes golang/go#61537 Change-Id: If3478121e3ae445391e3faeceeb889d75e9e3214
Fixes golang/go#61537 Change-Id: If3478121e3ae445391e3faeceeb889d75e9e3214
Fixes golang/go#61537 Change-Id: If3478121e3ae445391e3faeceeb889d75e9e3214
Fixes golang/go#61537 Change-Id: If3478121e3ae445391e3faeceeb889d75e9e3214
Fixes golang/go#61537 Change-Id: If3478121e3ae445391e3faeceeb889d75e9e3214
Fixes golang/go#61537 Change-Id: If3478121e3ae445391e3faeceeb889d75e9e3214
Fixes golang/go#61537 Change-Id: If3478121e3ae445391e3faeceeb889d75e9e3214
Fixes golang/go#61537 Change-Id: If3478121e3ae445391e3faeceeb889d75e9e3214
Fixes golang/go#61537 Change-Id: If3478121e3ae445391e3faeceeb889d75e9e3214
Fixes golang/go#61537 Change-Id: If3478121e3ae445391e3faeceeb889d75e9e3214
Fixes golang/go#61537 Change-Id: If3478121e3ae445391e3faeceeb889d75e9e3214
Fixes golang/go#61537 Change-Id: If3478121e3ae445391e3faeceeb889d75e9e3214
Fixes golang/go#61537 Change-Id: If3478121e3ae445391e3faeceeb889d75e9e3214
Fixes golang/go#61537 Change-Id: If3478121e3ae445391e3faeceeb889d75e9e3214
Fixes golang/go#61537 Change-Id: If3478121e3ae445391e3faeceeb889d75e9e3214
Currently KEXs, MACs and ciphers are private, some of them are defined as constants and others as simple strings, for example take a look at the supported ciphers list
I propose defining all supported algorithms as constants and exporting them for better discoverability.
We should also export the list of supported ciphers, KEXs, MACs, host key, public key algorithms and so on, so an application using the library can simply check if an algorithm is supported.
cc @golang/security
The text was updated successfully, but these errors were encountered: