> 23 aug. 2022 09:44 Lassi Kortela <xxxxxx@lassi.io> wrote:
>
> TLS is widely touted as securing the web. This year I've heard some compelling arguments that this is false advertising.
>
> Here's a good summary of the issues that are readily understandable: http://cryto.net/~joepie91/blog/2015/05/01/on-mozillas-forced-ssl/
>
> I'll omit the deeper issues since they are controversial and require some background; email me if you want to hear about them.
>
> The upshot for Scheme.org is that TLS is a standard which we must support. But that doesn't mean we must _require_ it. I think we should continue to offer plain unencrypted HTTP access. That should be relatively uncontroversial for most of our sites, which host technical content that is readily available to the world from public git repos.

It can be argued that HTTPS as currently deployed doesn't contribute much to either file integrity or protection from eavesdropping, but it's much more difficult to argue that it doesn't contribute anything. Everything else being equal, the cost of HTTPS as compared to plain-text HTTP is low, and I would say that the benefits are non-negligible. Especially domain-validated certificates are extremely easy to illicitly generate given access to networks close to the server, which means that they shouldn't really be trusted that much, but the system is extremely hard to break given only access to the networks close to the client. Also, if a malicious generation of a certificate succeeds, the owner of the host can discover the breach pretty easily.

Before Let's Encrypt, I have even argued for schemes like Better-Than-Nothing Security (RFC 5386), that offer no protection at all from MITM attacks, but prevent passive eavesdropping. HTTPS (as currently deployed) is clearly better than that.

My conclusion would therefore be that while far from good, it is at least better than nothing, which means that it should not really replace any other security mechanisms (the "everything else being equal" disclaimer above), but always use it anyway. TLS library security flaws might change the cost-benefit analysis, but if TLS is required on both server and client anyway for other peers, that isn't a factor.

> However, some of our sites will have a login feature. Currently the only one is Gitea but there will probably be more. Perhaps these should continue to require TLS so that passwords are not sent in the clear?

Passwords in the clear are not good (even if I would argue that passwords over TLS are also in the clear, just encrypted, the server receives them in clear text, but please ignore me on this point).

/Magnus