There's a trend I've noticed in the past few years. It's tempting when designing new protocols and software (for example, Gemini or Mastodon) to *require* the use of TLS. Privacy is important, and making it non-negotiable in the protocol design is becoming more commonplace.

But TLS is far from perfect. It allows the global certificate authority cabal subvert your privacy, is burdensome over localhost and some LANs, and many overlay networks (Tor, yggdrasil, cjdns) have end-to-end encryption at layer 3, making TLS redundant. Alternative domain name systems also have problems with mandatory TLS.

Perhaps the compromise position is to require that all connections carry *some* level of privacy guarantees. Forcing TLS is a bad idea if you ask me.

If you're trying to "fix the internet" with a protocol like Gemini (a laudible goal!), it would be smart to avoid baking the other problems of the internet into your protocol specification.

I think the Official Recommendation I would make to protocol designers is the following:

In the SECURITY CONSIDERATIONS section of your RFC, add the following text:

All $protocol connections over a public or shared network MUST utilize a form of end-to-end encryption, such as TLS. User agents SHOULD display a visible warning to the user if the connection is not end-to-end encrypted.

I say "SHOULD" here for the user agent because sometimes it's out of scope for it to do the due diligience here, for example with yggdrasil or .onion addresses.

Note that this assumes you're writing an RFC. You're writing an RFC, right? RIGHT?

@sir Clarification: while Gemini does require TLS, it’s not reliant on the CA system. Clients are free to use whichever form of verification they deem appropriate, with TOFU being the suggested approach.

@sir Of course they're not. That's for old boring people. The new hip kids just write a shitty node.js implementation that just everybody should run to 'save the internet'...

@sir TLS is not always end-to-end though. Depending on protocol, the server you're intending to connect to may not be considered an "end". Eg. for ActivityPub it isn't.

@wolf480pl hm, good point. Something to think about more

@sir It'd be nice to have a generic term for what TLS does. "client-to-server" encryption maybe?

@wolf480pl @sir I would say that SSL/TLS IRC between a server an client is encryption in flight. A bouncer that saves logs should apply encryption at rest (using whatever scheme may be applicable for that).

@kline @sir
and an encryption between two clients would be end-to-end... I guess that'd work.

@wolf480pl @kline @sir I would say "transport encryption". At least that was what I used to say.

@BartG95 @kline @sir it technically may not be a transport encryption if it's implemented in layer 3... I'd use the term casually, but I'm afraid in a stanard it may be understood too specifically

@wolf480pl @BartG95 @sir tbh I think trying to wargame meta-standards language is not all that useful. Each standard should seek to solve it's own problems without the need for a standard on how that standard should look.

@kline @BartG95 @sir
ok, but if I'm writing an RFC for a Federated Frobnicator Protocol, and in security considerations I write

"All FFP connections over a public or shared network MUST utilize some form of transport encryption"

and then someone reads it and thinks "TLS is ok, onion... well it operates on transport layer so that's ok as well.... cjdns? well it encrypts stuff in network layer, that's no good, need TLS on top of that"

@wolf480pl right, but im presuming we can at least knock out worries like "Does end to end encryption work in our model?", unlike earlier where we had to word our way around how TLS might be e2e in some places and not others.

@sir why focus on protocol encryption instead of content encryption? would not having protocol encryption be more backwards-compatible, allowing more content-agnosticism? looking at ipfs and requests for encryption in that protocol, it seems to result in removal of its ability to deduplicate. how would gemini fare?

@sir how about only requiring TLS for connections over the public Internet?

Though both this and requirement of "some level of privacy" would be hard to implement in a client. It'd require the client to be aware if any layer 3 encryption schemes are in place.

@wolf480pl I wouldn't even go so far as to say "the public Internet". I would stick with what I said: "public or shared networks"

@sir yeah I only later noticed that other post of yours

@wolf480pl also, you can burden the system operator with fulfilling this promise of the RFC, it doesn't have to be the implementation


I've had to go to great pains to work around mandatory TLS when the network is already behind a reverse-proxy that terminates TLS.

Like, I'm already inside my own isolated network, and in some-cases (service meshes) I'm already inside the instance/container/vm that the server is running on.

But noooo, TLS between NGINX and The Server _on the same node_ is required for "privacy" and "security" reasons.

I think making it the default is okay, but making mandatory is just condescending.

@rozenglass @sir For that reason, in my opinion, a good server should not strictly require TLS connections. It should be configurable, independently from the spec. For example, I'm about to publish a Gemini server library, and I didn't even bother with TLS yet, I just stick stunnel in front of it.

@sir agreed fully. Configuring TLS correctly is way to hard (which version, what suites, are Pins overruled by your system certs, etc.).

At least these days you can pick something like the Noise framework and pick your desired flavor (mutual auth, etc) if you cant go for a full overlay.

@sir If I remember correctly, activitypub is just an API protocol like REST and GraphQL as opposed to a transfer protocol like HTTP.
having TLS on HTTP is just a "band-aid" for an underlying issue that HTTP isn't encrypted by itself.
Many overlay networks have encryption yes, but this comes with it's own issues.

Like you can use HTTP over CjDNS just fine but what if that service also is available over the clearnet? Are you gonna make your server not serve TLS just on CjDNS?

>having TLS on HTTP is just a "band-aid" for an underlying issue that HTTP isn't encrypted by itself.

This doesn't make any sense, TLS is used industry-wide to add privacy to otherwise plaintext protocols and is a much better option than rolling your own encryption for whatever thing you just built

>Are you gonna make your server not serve TLS just on CjDNS?

Yes, and it's not even difficult

> TLS is used industry-wide to add privacy to otherwise plaintext protocols.

Yes, so isn't that a "band-aid" for fixing the underlying issue of not having encryption in the protocol itself?

> is a much better option than rolling your own encryption for whatever thing you just built

So you're complaining about it at first but then say it's better than spinning your own?

> Yes, and it's not even difficult

It's not no, but it's pointless extra hassle.

@finlaydag33k no, it's not a band-aid, it's working by design.

>So you're complaining about it at first but then say it's better than spinning your own?

No, I'm saying that how the connection is encrypted is none of the application-level protocol's business. They shouldn't roll their own OR use TLS.


>no, it's not a band-aid, it's working by design.

it's a band-aid to a certain degree... they noticed issues with HTTP being plaintext then slapped a wrapper around it using TLS.
That's a band-aid.

> They shouldn't roll their own OR use TLS.

So first you're saying Forcing TLS is a bad idea... and then you're saying people shouldn't roll their own but also that they shouldn't use TLS...
How the hell do you want it to be? not rolling their own or not using TLS?

@finlaydag33k I'm talking about PROTOCOLS. The PROTOCOLS should not use TLS. The IMPLEMENTATIONS very well might want to use TLS. The point is that TLS is not a universally correct solution.

@sir So then ehm... If you say protocols shouldn't use TLS... there where the hell do you want to implement them?

(I do agree that TLS is not a universally correct solution though)

@finlaydag33k do you understand the difference between a protocol and its implementation?

@sir Yes, I do.
You don't want protocols to use TLS but you do allow their implementations to do so.
I think you're the one that doesn't know the difference between a protocol and it's implementation.
as well as an understanding of the word "protocol" to begin with.

(no offenses given ofc)

@finlaydag33k and I think you're a fucking moron, no offenses given ofc

@sir Ah yes, the all famous "and I think you're a moron for me not understanding what I am even saying myself"...

Seriously, you do not want protocols to tinker with encryption... but then the implementation of said protocols may?
Imagine how that'd look like if 1 HTTP site used TLS, the other used double-ratched, another one used GPG, another one used HacksMahFiddleDeeDee...
Yea ehm... that's just asking for trouble...

@sir Main problem here is is protocol downgrade attack. If TLS is not enforced there is a number of ways to make typical user connection to switch to open protocol.

What we do need is better TLS. Personally I would like to see better handling of self-signed certificates, CA pinning and some other things.
@alex @sir unfortunately tls in current state is bound to CA system very tightly (surprisingly ?) ), and to make it secure in current stae - first thing - drop ca store completely (controlled by third party), second do not use domain as key unique identity (controlled by third party), without this tls is completely insecure, just false impression of security.
@alex @sir @sss For an average user and their uses it is not really secure against government and corporate actors however it is decent protection against individual malefactors. Better than nothing :)

Making TLS optional doesn't close its vulnerabilities, just opens up even more attack surface.

Yes, it is intentionally made this way. It is sad. Maybe it will get better at some point.
@sir absolutely the same attacks can be performed on onion namespace, etc. there's no universal way of server authentication without third-party servers, in any realization. and this part is always vulnerable.
@iron_bug @sir web of trust model is much more secure than centralized authorities, but it's much harder to use, yes, but c'mon, we are talking about security or user-friendliness ?
@iron_bug @sss there's no (it's not possible theoretically, not just certain realizations) of authentication of a server without using some third party servers. and this will always be a point of possible attack.
@iron_bug @sir @sss it only seems 'safe' to those who did not dig in protocols realizations. who do you trust? IP? can be faked. MAC? can be faked. key? how do you get it? it may be faked. and so on.
there're principally no ways of knowing about some server except of giving keys to certain person, from hands to hands.
@iron_bug @sir @sss and I must note that we're talking about puclic(!) social networks. and this means public users somehow get access to the information on a server. so all so-called 'thrusted networks' go to hell, because they're not applicable in such data model.
@iron_bug @sir web of trust is not related to electronic social networks, in ideal situation it is real meeting of peoples where mitm is physically impossible…

even if used through interenet it is much more resistant than centralized authorities.
@iron_bug @sir @sss people I can meet in person need no way to communicate to via Internet. I can talk to them personally, no problem. the Internet is needed to communicate to remote people that are not accessible directly.
@iron_bug @sir arrange one meeting to exchange keys and sign public keys, if you REALLY need security, it's almost always possible to achieve.
@iron_bug @sir @sss TLS is a session protection. not a mean of person authentication.
@iron_bug @sir tls is no protection if mitm with replaced keys is performed, and certificate authority provide just this possibility.
@sir @iron_bug so you can read CA security as blind trust security.
@iron_bug @sir @sss I have to. because my server is available to uncertain public users group and they somehow should find it (domain name) and have some way to securely get data from it (TLS). this does not imply that they get my personal authentication in any way. this is not possible in principle.
@iron_bug @sir @sss you're just mistaking authentication with session protection level.
@iron_bug @sir there's no way of authentication for public case.
@iron_bug @sir I don't use any tags manually. this is Friendica.
but the question is over, I think.
@iron_bug @sir @sss so the question disappears. we can only use some public authorization means. and in 99.(9)% cases it's safe because nobody needs to break your private server certificates. this is paranoid to think so. and servers in social networks are all equal and there's no need to invent any special ways of authentication. which does not imply they don't need network cryptography at all.
@iron_bug @sir session security means nothing if session itself is hijacked, yes, it is still secure from outside.
@sir @iron_bug i agree with topic starter, it is better to not waste resources on crypto at all and not provide impression of (false) security.
Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!