| Newsgroups |
gmane.network.gnunet.devel |
| Message-ID |
<[email protected]> |
On 3/12/24 10:36, carlo von lynX wrote:
> Moin Martin,
>
> On Tue, Mar 12, 2024 at 06:26:09AM +0000, Martin Schanzenbach wrote:
>> - Hiding in "common" Internet traffic: e.g. if two peers communicate
>> via HTTPS (and assuming we can obfuscate the traffic patterns of the
>> applications in GNUnet), they look like browser/web server to an
>> attacker that may want to censor p2p traffic. The same holds for
>> protocols such as SMTP* and XMPP. Some protocols (such as SMTP or XMPP)
>> may come with significant overhead, but that is the price to pay to
>> obfuscate the traffic.
>>
>> *To be honest I am not sure how "useful" plain SMTP actually is,
>> considering it is commonly run on top of a TLS connection anyway.
>> I think anything running on top of TLS is sufficiently covered with an
>> HTTPS or QUIC connector. Christian (who filed #1923) may have more
>> insights on this.
> I presume it is relevant that at some point we get to throw our
> binary stream into the socket without completely obscene amounts
> of overhead. That's how HTTP and SMTP can be sufficient because
> you can say the next 100k of data are a binary file transfer.
> XMPP cannot do that, so you would always have to encode GNUnet
> streams into base64 or fake XML syntax, which is pretty nuts
> and these days could get detected by AI.
Can't EXI be used to be able to add binary gnunet in there?
> You could at best use some STARTTLS negotiation of XMPP as an
> excuse to switch to a TLS which then delivers GNUnet content,
> but as you point out in your asterisk remark, the "usefulness"
> depends on how frequent unencrypted XMPP still is, much like
> unencrypted SMTP.
Its not common at all.
All xmpp public trafic is encrypted at this point and I would expect
unencrypted to completely fail.
>
> Consider that an observing entity can see the certificates and
> pubkeys used in a TLS negotiation, so if we were to simulate
> SMTP or XMPP we do not just need certificates signed by a credible
> authority, they also need to have the respective bits set. Maybe
> many XMPP sites actually do not care, but XMPP certificates were
> supposed to have a specific XMPP flag set. So it may not be enough
> to simply use a different port number.
>
Regarding XMPP obfuscation of traffic you can use the 443 port nowadays
over websockets. And there is also support for DIRECTTLS and QUIC so
xmpp can look like "normal" http traffic.
Latest work focuses on also moving towards ECH that will encrypt the
whole initial message of the TLS negotiation.
The certificates don't need any specific xmpp "bits" idk when that was
required. But nobody sets any specific bits anywhere in xmpp at least
that is.
MSavoritias