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/
