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 <[email protected]> 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 <[email protected]> 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
>>
>
