💾 Archived View for rawtext.club › ~sloum › geminilist › 006017.gmi captured on 2024-02-05 at 11:04:31. Gemini links have been rewritten to link to archived content

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

Gemini privacy

Phil Leblanc philanc at gmail.com

Tue Mar 9 02:23:06 GMT 2021

- - - - - - - - - - - - - - - - - - -

Hi Nothien,

Length-analysis prevention is not Gemini's job, it's the job of TLS.

And TLS does provide a mechanism to defend against it - padding.

You are perfectly right. The new "record padding" mechanism added toTLS 1.3 [1] is almost perfect for the job. Of course it doesn'tprotect servers which serve few large files, but for the typical smallgmi files, it is perfect.

[1] https://tools.ietf.org/html/rfc8446#section-5.4

Regarding support, It is supported by OpenSSL: see option 'record_padding' [2]

[2] https://www.openssl.org/docs/man1.1.1/man3/SSL_CONF_cmd.html

As TLS 1.3 is not yet mandatory for Gemini, and as several serverowners may not be interested by this privacy issue, I guess thatrecord padding may not be part of Gemini specification. But I think itshould at least belong to a "best practices" document.

A recommended value could be 4,096 (all served files padded duringtransport to the next multiple of 4KB). Servers serving high volumeof very small files (typically 0 to 2KB) could use 1,024 instead.

Thanks again for the suggestion

Phil

On Mon, Mar 8, 2021 at 11:32 PM Phil Leblanc <philanc at gmail.com> wrote:

On Mon, Mar 8, 2021 at 10:35 PM <nothien at uber.space> wrote:

Firstly, most Gemini documents are (intentionally) pretty tiny, fitting

within maybe 1 or 2 KB. This is not so big an issue.

hmmm, with some form of padding yes. But without padding, I am not so sure.

What countermeasures could we propose?

1) and 2) are too complicated (particularly with Gemini's spirit of

being able to implement all major features in an afternoon) and

I have seen many time this argument about complexity. I find it a bit

fallacious (no offense intended!). The client or server is "not

complex" because 99% of the complexity (TLS) is assumed to be already

implemented in a library available everywhere (eg. OpenSSL). We could

say in the same way that a modern HTTP client is not complex - and is

an afternoon project - because LibCurl is available everywhere :-)

3) is just not backward compatible.

My point is not about the protocol. Just what the capsule owner and

server software could do.

Has any server author designed some sort of countermeasure against

length-based attacks? Has it been already discussed?

Length-analysis prevention is not Gemini's job, it's the job of TLS.

And TLS does provide a mechanism to defend against it - padding. This

works better for smaller files as it is then harder to distinguish

between files of similar sizes. I don't know how OpenSSL and other

common TLS libraries handle padding (I've read the TLS 1.3 RFC, and it

seems that currently clients and servers have to opt into using padding,

and the amount of padding and how it varies is implementation-defined),

but we can definitely look into it, and perhaps provide recommendations

for it in the Best Practices document (as seems to be what's happening

with close_notify(), IIRC).

I didn't know about TLS padding. Thanks for pointing it out. I will

definitely look into it.

Has anyone already used it in this sort of context?

Cheers

Phil