On Fri, 2017-11-10 at 11:11 +1100, Damien Miller wrote: > could you please file a bug for this, I'll take a look. Done. The bug is here: https://bugzilla.mindrot.org/show_bug.cgi?id=2799 Hopefully, it will be more understandable with more references. Jakub > > On Thu, 9 Nov 2017, Jakub Jelen wrote: > > > Hello, > > as a follow-up on my mail some time last month where we were facing > > weird issues when authenticating to new OpenSSH servers, I went > > down > > the road to investigate what is really going on there and I found > > out > > that even though all the logs in client and server happily say that > > the > > SHA2 extension is used, under the hood there is just SHA1. This is > > because the different agents are ignoring the flags passed with the > > signature request. This can be simply reproduced with the following > > patch, which dumps the actual hash algorithm used in the signature > > itself: > > > > https://gist.github.com/Jakuje/b1f7161d89472c4b6a3e2024675b0b46 > > > > The issue can be simply reproduced by running ssh-agent from gnome- > > keyring (pageant or others should do the same) and connect to the > > server with the above patch. In the server log, we can notice the > > following messages (where hash_alg=1 is SSH_DIGEST_SHA1): > > > > debug1: Verifying signature with ktype=ssh-rsa and hash_alg=1 > > debug2: userauth_pubkey: authenticated 1 pkalg rsa-sha2-512 > > > > So even though all the current messages say that sha2 is used, > > something else is going on here. Nor client nor server is verifying > > that the signature itself is done using the requested algorithm. > > > > So how to get around that? > > > > The most robust solution would be to use ssh-agent extension > > protocol > > to negotiate these extensions also with the agent. The downside of > > this > > is that current implementations do not know the extension messages > > and > > fail if I remember well the gnome-keyring behavior. This would > > allow us > > to know what signature will be used in advance. > > > > Other thing should be checking what signature we got from agent and > > if > > it is not the one we requested, downgrade the algorithm in the > > authentication packet to reflect the reality (or fail some way?). > > Similar thing should be done also on the server, where the > > verification > > also does not compare authentication header algorithm and the > > algorithm > > in the signature itself. > > > > Is it intentional or did I miss something in my write-up? > > > > This can be considered as a security issue, because all the logs > > say > > that stronger algorithm is used even if it is not true. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
