💾 Archived View for rawtext.club › ~sloum › geminilist › 004641.gmi captured on 2023-11-04 at 14:30:01. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
nervuri nervuri at disroot.org
Fri Jan 1 17:44:10 GMT 2021
- - - - - - - - - - - - - - - - - - -
December 31, 2020 9:45 PM, Sean Conner wrote:
Okay, point taken.
Because of this privacy issue, I think browsers should only send client certificates over TLS 1.3 (and newer). This could be part of the spec.
We could also make a coordinated effort to help Gemini software support TLS 1.3 - reach out, send patches, see what's holding developers back. Currently LibreSSL, GnuTLS and wolfSSL all support TLS 1.3, so most (if not all) browsers/servers/proxies/crawlers could probably make the upgrade. Once enough software supports 1.3 and enough servers have switched, the minimum TLS version can be changed in the spec.
Yes, that's a bit of work, but it was less than 5 minutes, and I'm not even a state actor here. Is that enough of a bar for you?
SNI-based surveillance is automatable, making it trivial for third parties to hoard this data at nearly no cost. Even a tiny bit of non-automated work, like what you just did, will deter many (mostly commercial) actors involved in mass surveillance, for whom scalability is what makes it worthwhile. When it comes to targeted surveillance done by state actors, ESNI won't help much (if at all), but this threat model doesn't apply to most people. Let's not fall for the perfect solution fallacy.
Looks like ESNI is being superseded by Encrypted Client Hello (ECH):
https://tools.ietf.org/html/draft-ietf-tls-esni-08https://blog.cloudflare.com/encrypted-client-hello/
Nice.