[OT] RFC8890



> 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>

---

Previous in thread (2 of 3): 🗣️ Martin Keegan (martin (a) no.ucant.org)

View entire thread.