3 ms·
> An example would be if you don't have a certificate. Given that letsencrypt exists, I don't see why you wouldn't have a cert. > Maybe you just have a pre-sh
by dagenix 7y ago
> An example would be if you don't have a certificate.
Given that letsencrypt exists, I don't see why you wouldn't have a cert.
> Maybe you just have a pre-shared secret or a kerberos ticket.
The pre-shared secret could be a cert which would work with TLS.
> Or worse, maybe you just have a password, and so need to use a PAKE protocol or something to authenticate the session.
I can't think of a realistic example of such a protocol. What protocol uses PAKE, but doesn't support encryption, but will verify a session id? It seems like using TLS would be simpler.
> Or maybe you are using an RPC protocol, like NFS, that doesn't let you add TLS in a backwards-compatible way, but where the client and server do share some secret file handle.
Such a scenario still requires modifications to the NFS server and client software, which, if done, isn't clear why it would be better than just layering TLS onto the protocol.
- nullc 7y ago> Given that letsencrypt exists, I don't see why you wouldn't have a cert. That makes an enormous number of assumptions-- that you have a domain name, that you accept inbound connections, and that "gee some server connected to my name and got me once" is a remotely acceptable criteria for identity in your application.