Re: OFF-TOPIC: SSH authn over TLS?

[Felipe Gasper <felipe@xxxxxxxxxxxxxxxx>]

Hi Aris,

	Sounds like SSH over preexisting sockets would indeed be the safer path!

	Thank you.

-FG


> On Jun 30, 2020, at 2:59 PM, Aris Adamantiadis <aris@xxxxxxxxxx> wrote:
> 
> 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 <aris@xxxxxxxxxx> 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
>> 
>