💾 Archived View for gemi.dev › gemini-mailing-list › 000347.gmi captured on 2024-08-19 at 00:20:38. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2023-12-28)

-=-=-=-=-=-=-

[OT] RFC8890

1. Petite Abeille (petite.abeille (a) gmail.com)

Perhaps of interest, courtesy of Mark Nottingham:

The Internet is for End Users 
https://www.mnot.net/blog/2020/08/28/for_the_users
https://tools.ietf.org/html/rfc8890

Link to individual message.

2. Martin Keegan (martin (a) no.ucant.org)

On Fri, 28 Aug 2020, Petite Abeille wrote:

> Perhaps of interest, courtesy of Mark Nottingham:
>
> The Internet is for End Users
> https://www.mnot.net/blog/2020/08/28/for_the_users
> https://tools.ietf.org/html/rfc8890

Thank you for this link. I note that the blog posts references an 
"encrypted client hello proposal", at 
https://tools.ietf.org/html/draft-ietf-tls-esni-07

I thought I had posted to this list my long-standing opinion that TLS/SSL 
effectively forces a choice between confidentiality and anonymity: if you 
want encrypted communications you need to reveal to an eavesdropper the 
identity of any endpoint that wants to be authenticated to another 
endpoint. This has been part of an unease I've had with SSL since it was 
introduced 25 years ago, though until recently it was mainly that the 
overhead of PKI was too high for small-time servers. The overhead is 


Peter Vernigorov wrote on this list recently that SSL is actually a bit 
worse than most people expected: 
gemini://gemi.dev/gemini-mailing-list/messages/002282.gmi

I ran a packet sniffer on some Gemini client (gcat?) and discovered to my 
horror that he was right: the subject identity of the client certificate 
is sent in plain text over the wire: SSL does indeed force the 
deanonymisation of an endpoint wishing to be relied upon in return for 
encrypting the non-metadata content of the communication.

The IETF draft RFC referenced the piece that the OP posted would seem to 
address this issue, which is critical for Gemini, as Gemini places more 
reliance on client certificates than is usual (hitherto) in customary 
Internet applications.

Mk

-- 
Martin Keegan, +44 7779 296469, @mk270, https://mk.ucant.org/

Link to individual message.

3. mbays (a) sdf.org (mbays (a) sdf.org)



> Peter Vernigorov wrote on this list recently that SSL is actually 
> a bit worse than most people expected: 
> gemini://gemi.dev/gemini-mailing-list/messages/002282.gmi
> 
> I ran a packet sniffer on some Gemini client (gcat?) and discovered to my 
> horror that he was right: the subject identity of the client certificate is 
> sent in plain text over the wire: SSL does indeed force the deanonymisation 
> of an endpoint wishing to be relied upon in return for encrypting the 
> non-metadata content of the communication.
> 
> The IETF draft RFC referenced the piece that the OP posted would seem to 
> address this issue, which is critical for Gemini, as Gemini places more 
> reliance on client certificates than is usual (hitherto) in customary 
> Internet applications.

If I understand correctly (I'm not entirely confident, so I'd appreciate 
it if someone who is could confirm), this is already fixed in TLS 1.3.

Meanwhile in TLS <= 1.2, it seems it is possible to deal with the 
problem by sending the client certificate as part of a renegotiation 
after the initial handshake. But I don't know how common that is.

I'm considering having my client require explicit user confirmation 
before sending a client certificate to a TLS <= 1.2 server, or at least 
print a warning.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200829/c531
371f/attachment.sig>

Link to individual message.

---

Previous Thread: [ANN] vanwa.ch - personal website

Next Thread: Announcing slice.breadpunk.club