TLS increasingly exists in three different worlds

March 12, 2020

I recently wrote about how browsers are probably running the TLS show now, and then recently realized that that is only somewhat true. In practice, I think that TLS now increasingly exists in at least three different worlds that are at least somewhat disconnected from each other, and what's true for one world may not be entirely true for the others.

The first world is web TLS, which is dominated by browsers. This is the familiar world of public HTTPS, with public Certificate Authorities, requirements for certificate transparency, and so on. The browsers increasingly are calling the shots here and they're pushing for things like short certificate lifetimes, aggressively moving away from old TLS versions, and so on. Due partly to the presence of Javascript in browsers, this world faces some unusual security problems; an attacker can plausibly cause someone else's client to make thousands or millions of connections to a server, for example, in an attempt to crack the session encryption and extract something useful from it.

The second is non-web public TLS, where TLS is used for protocols like IMAP, SMTP (with STARTTLS), and so on. This world still uses public CAs, but it has a lot more old clients and servers and is a lot slower to deprecate old TLS and SSL versions, move to shorter certificate lifetimes, and so on. At the same time it doesn't face some of the threats that web TLS does, as attackers have far less power to manipulate the behavior of victims in convenient ways. A victim IMAP client may reconnect repeatedly, but an attacker isn't likely to persuade it to uses carefully controlled variations of the connection.

(Non-web public TLS is going to get dragged along on short certificate lifetimes by web TLS, though.)

The third world is internal TLS, where TLS is used inside an organization or a service to encrypt connections and often to authenticate them (and sometimes it's used between organizations). Internal TLS frequently uses client certificates and usually doesn't use public CAs, and that's about all you can say about it in general; actual practices no doubt vary widely across people using it. The reason these practices can vary widely is that each separate use of internal TLS operates in a closed, captive environment where it doesn't really have to care what other people think.

There is overlap between these three worlds, as well as the differences that I sketched here. Everyone wants good connection security and for weak ciphers and protocol vulnerabilities to be weeded out. Web TLS and non-web public TLS both care a lot about Certificate Authorities being trustworthy, but web TLS has been driving the show on this. There are probably interests and positions shared only by non-web TLS and internal TLS, but I can't think of any right now.


Comments on this page:

I actually use stunnel TLS to wrap NFSv4 running over TCP.

My writeup is the top hit on a google search of "encrypt NFS."

I've used stunnel for lots of other things.

Just in case the "optional link" doesn't work:

https://www.linuxjournal.com/content/encrypting-nfsv4-stunnel-tls

By Chris at 2020-04-13 16:13:39:

The overlapping point in non-web public TLS and internal TLS appears to be that the clients speak only outdated versions of TLS, i.e. just TLSv1.0.

Written on 12 March 2020.
« Some notes on the state of DNS over HTTPS in Firefox (as of March 2020)
Sensible heuristics for when to use DNS over HTTPS can't work for us »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Thu Mar 12 00:34:30 2020
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.