a space case for transparent gemtext compression

mbays mbays at sdf.org
Sat Jun 19 14:23:06 BST 2021

* Saturday, 2021-06-19 at 11:34 +0200 - Francis Siefken <fsiefken at gmail.com>:

>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.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210619/9fefe9b1/attachment.sig>

More information about the Gemini mailing list