mbays mbays at sdf.org
Sat Jun 19 14:23:06 BST 2021
- - - - - - - - - - - - - - - - - - -
TLS 1.3 has compression on board, it's a security
risk in HTTP session hijacking and all HTTP browsers have turned it off.
But this security risk doesn't apply to Gemini or with SMTP or IMAP. This
would be another way to making this compressed gemtext vision work.
If I understand correctly, TLS 1.3 actually *removed* compression.
RFC 8446:
legacy_compression_methods: Versions of TLS before 1.3 supported
compression with the list of supported compression methods being
sent in this field. For every TLS 1.3 ClientHello, this vector
MUST contain exactly one byte, set to zero, which corresponds to
the "null" compression method in prior versions of TLS. If a
TLS 1.3 ClientHello is received with any other value in this
field, the server MUST abort the handshake with an
"illegal_parameter" alert. Note that TLS 1.3 servers might
receive TLS 1.2 or prior ClientHellos which contain other
compression methods and (if negotiating such a prior version) MUST
follow the procedures for the appropriate prior version of TLS.
So TLS compression does not seem to be a viable option (we don't want to downgrade to 1.2, for various reasons).
P.S. here's how one could handle gzipped gemtext in diohsc, causing it to be presented as if it were uncompressed text/gemini:set geminator text/gemini+gzip gzip -dc --------------- next part --------------A non-text attachment was scrubbed...Name: signature.ascType: application/pgp-signatureSize: 195 bytesDesc: not availableURL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210619/9fefe9b1/attachment.sig>