[Cryptography] Why aren’t we using SSH for everything?

Christoph Anton Mitterer calestyo at scientia.net
Sat Jan 3 23:48:05 EST 2015


On Sat, 2015-01-03 at 14:53 -0800, Tony Arcieri wrote: 
> SSH has a generally weaker model (TOFU) than at least a privately
> maintained X.509 hierarchy (the answer for a stronger/more agile
> approach on the SSH side is X.509-like SSH CAs). Likewise, TOFU
> handles key agility poorly:
I don't see any reason why SSH should be weaker than anything else. In
fact it is not.
No one forces users to blindly trust a remote host key on first
encountering it, that's why there are fingerprints and people should
validate those - if people are stupid and don't validate them, well then
you can't help such folks.

Believing that a strict hierarchical trust model like that of X.509 is
in any way more secure is just plain wrong. In fact the strict
hierarchical model brings all kinds of problems (i.e. ultimate trust in
the root, which can do basically anything). 
And do your really believe that users are more secure with the
gazillions of untrustworthy CAs shipped by nowadays browsers, none of
which the user has verified himself, neither do the usual users receive
their browsers via a secure way.
TOFU as well. Plus trusting players like Mozilla and the CAs, which all
have rather money in their mind than anything else.


> https://d262ilb51hltx0.cloudfront.net/max/800/1*mva2_6fu-3QfdTDfueclEg.png
Well you have the same with X.509 and TLS when you encounter a server
using a cert not signed by one of your trusted CAs.


> There are lots of real world reasons why keys might change. In fact
> key agility is a nice property! SSH makes it hard.
Key management and/or authentication is nothing hard-wired in the SSH
protocol.
In fact there is already a host authentication mechanism in OpenSSH
which kinda CA like (but not X.509) and there is an (unmerged) set of
patches which allows really to use X.509 (GSI SSH).


> I'm sure we've all seen the above warning, been confused about the
> circumstances, but ignored it.
Which typically means badly maintained key files (either by the admin or
the user himself) and stupid used (since ignoring the warning, which
tells that one is possibly attacked doesn't seem that smart).


> Then there's the part where you need to respecify every protocol to
> run atop SSH instead of TLS.
Well but this per se is probably not the reason not to use SSH as a
general crypto tunnel protocol, since one has/had to do the same with
TLS.

(Oh and btw: I don't want to say that SSH should be used for everything,
it's simply not made for this.)


> In terms of overall design, SSH and TLS both failed. SSH did
> MAC-and-encrypt. TLS did MAC-then-encrypt. Both of them are
> effectively legacy protocols that were designed wrong from the get-go.
At least in SSH you have now EtM modes and AEAD algos which make the MAC
completely obsolete.

And legacy protocols? LOL? I don't think that either of the two will get
away soon. 

Cheers,
Chris.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5313 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20150104/2a1a04a6/attachment.bin>


More information about the cryptography mailing list