Hi Felipe
Your protocol is vulnerable to active replay attack, for instance the
server (or attacker with stolen TLS cert) could abuse the secrets it
sends to the client to authenticate on your behalf on a third party SSH
server. Client connects to server, server connects to SSH server, server
extracts shared SSH secret, server sends shared SSH secret to client,
client signs it, server signs SSH authentication packet. Never sign a
secret that's not guaranteed to be unique. Never encrypt or sign "raw"
values. My suggestion:
-Server sends Nonce1
-Client generates Nonce2, computes H=hash(nonce1+nonce2), signs H and
sends Nonce2, signature and key.
This protocol is still vulnerable to man in the middle but since you're
already on a secure channel, it's already mitigated. My point was just
that it doesn't really have anything to do with SSH anymore :) I'm
afraid I don't know ready-to-use solutions to avoid having to cook a
custom protocol. On certain distributed architectures I'd recommend
using an authentication server and authentication tokens like oauth, but
it's difficult to say if it applies to your problem.
Aris
Le 30/06/20 à 20:27, Felipe Gasper a écrit :
Hi Aris,
I got a proof-of-concept up of a workflow that uses libssh to do key exchange
and then public key authn on preexisting sockets, then drops the SSH session
entirely, leaving the preexisting sockets up. That may be what we end up doing.
It would be much simpler just to do:
- Server sends a secret.
- Client signs the secret, sends the signature and key.
- Server verifies the signature on the key, and the key’s authz on the account.
… which would seem to thwart replay attacks, but I’m not sure what else we’d be
missing, and we’d be “on the hook” for maintaining basically our own custom
“pseudo-SSH”, which doesn’t sound very appetizing.
TLS client certs would involve setting up a CA or using a commercial one, both
of which sound like workflow problems.
Anyhow, thank you for your response!
-FG
On Jun 30, 2020, at 2:04 PM, Aris Adamantiadis <a...@badcode.be> wrote:
Hi Felipe,
In SSH, all authentication schemes are signature-based. Specifically user
authentication is based on signing the master hash that's derived from key
exchange (i.e. everything that was shared by peers + shared secret). SSH
ensures that the authentication is safe because it's impossible for either
party to replay or precompute that hash. I don't think TLS would let you
extract or derive secrets based on the session's secret. You could craft an
authentication protocol inspired by SSH on top of TLS but you'd have to ensure
that the challenges are immune to replay, but in that case it wouldn't be
simple anymore.
TLS has built-in support for client certificates. It's not very straightforward
but it might be the way to go if you insist on having public key authentication.
Regards,
Aris
Le 30/06/20 à 01:50, Felipe Gasper a écrit :
Hello,
I want to rig up a simple authentication based on SSH keys but over a
preexisting TLS connection.
Since TLS already handles the encryption, would the authentication be
as simple as verifying a decode of a string that the public key encodes?
Is there any prior art for this?
(I realize this isn’t really on-topic for this list, but I’m not sure
where else to ask … ?)
Thank you!
-Felipe Gasper
Ontario, Canada
