Hi,
> The reason for SSL is that AFAIK most of the suck in it comes from the
> CA system, that is, the huge number of pre-installed unlimited-trust
> entities, that can be completely disabled.
well, it is not just that (but for browsers mostly it is). There were
plenty of attacks on TLS recently so you really want to use TLS 1.2 as
of know. Also choose secure ciphers (same goes for SSH of course).
> - Server accepts only client certs from same CA as its own cert.
You could even use one CA only for servers and one only for clients.
> - Server only accepts connections with client cert!
> - Identification by common name in client cert.
Currently in TLS the client certificate is transmitted in plain text.
You may be okay with that. If you are not okay with that you can run two
TLS handshakes, the second one would be protected by the secure channel
established in the first one. The second handshake would then be used
to check the client certificate.
Or you do not use client certificate but some own stuff inside the TLS
secure channel after the handshake.
Google and some others are working on new concepts for TLS but instead
of just fixing the issue with the plaintext client certificate they
want to do something completely new[1].
You might have heard of mosh[2]. They basically use SSH for
bootstrapping to rely on the already deployed infrastructure and then
in fact use a custom protocol vaguely similar to DTLS. However they do
not simply forward a shell but do more fancy things like keeping track
of input and output with a prediction engine so they can compensate
latency to some extend. Last time I checked it was hardwired to AES128.
So even when your SSH uses a stronger cipher, mosh would still use
AES128 and thus lowering the security level although using SSH
initially for bootstrapping.
[1]
http://tools.ietf.org/id/draft-balfanz-tls-channelid-01.txt
[2]
http://mosh.mit.edu/
Received on Tue Nov 05 2013 - 14:02:36 CET