Andrew Ayer

Andrew Ayer on 2014-10-23 at 03:07:

OK, so I think you're wrong, but where to start? Mostly, I think you've decided that you want to write Titus in a certain way, and since STARTTLS doesn't allow you to do this, therefore STARTTLS is bad.

titus was the impetus for this blog post, but I had disliked STARTTLS long before I wrote titus, and I present other, unrelated arguments for why STARTTLS is a bad idea.

But an XMPP client (or an MUA) can, trivially, know which services offer TLS. STARTTLS allows clients to discover this trivially, without user interaction, and additionally allows this information to be cached. It's best to think of STARTTLS advertising as - like SASL mechanism advertising - a once-only, account-configuration thing.

This isn't secure, because a MitM can strip the STARTTLS advertisement, so a user has to know, and specify, whether a service supports TLS or not. It's OK for opportunistic encryption, and caching does help, but you don't need STARTTLS for this. The insecure service could advertise the presence of a secure service on a different port, and the client could then reconnect with TLS on that port. This is essentially how HTTP and HTTPS work, when you redirect a HTTP connection to a HTTPS URI.

A key factor in the "different URI" debate is that I have no way of knowing whether https://www.google.co.uk/ is the same service as http://www.google.co.uk/ - the differing scheme actually imposes that a client must assume otherwise

I really don't think that's a practical concern, and it's already a widely-followed convention that these different URIs are the same service. Besides, moving forward we should be phasing out our insecure services, so there will only be one URI anyways.

Finally, while SNI has helped, there are protocols which need application data to select the correct certificate to use.

SNI should definitely handle that, especially if proposals to encrypt the SNI name come to fruition.

It might help, though, to understand that there's lots of other things Titus can't do because of its nature. It can't handle outgoing sessions, it can't handle certificate selection outside SNI, it can't handle client authentication, it cannot let a server note an improper TLS shutdown, it prevents channel binding, and so on. Every one of these things is important.

It's true that titus can't handle these but fortunately they aren't that important. Can you point to a widely-used protocol on the Internet where any of these things are important? (I'll concede outgoing SMTP connections over TLS.)

Many of these things are impossible to implement if Titus is the dumb pass-through it currently is. I shall leave it as a trivial exercise to the reader to figure out an architecture that supports them - and incidentally support STARTTLS - without including a protocol parser.

Any other solution would require modifications to the application. I am actually working on the design of a "libtitus" that would let applications easily initiate titus-secured outgoing connections, or accept incoming connections with client certificates. But modifying applications isn't always possible, and we've got many widely-used Internet protocols which don't typically use client certificates, channel binding, etc. where a dumb pass-through would be completely sufficient if not for the fact that they are needlessly using STARTTLS to immediately upgrade a connection which could have been TLS in the first place.

Reply