Question about package build

[Alireza]

> Here's a recent and very timely Twitter thread that touches on using
> packet fragmentation at various layers to defeat censorship:
> https://twitter.com/endermanch/status/1829648801612906916

Thanks for the link. I could only find him talking about splitting
HTTP into multiple TCP segments which is basically outdated now as
(almost) no one uses plain HTTP.

> As described in this thread, injecting extra fragmentation is AT BEST
> a stopgap solution, exploiting a lack of (or bugginess in) stateful
> session tracking, and nation-level censors WILL eventually prevent it
> from working.

I partially agree with you. For a packet dissection/processing system
that should operate on a very high scale (e.g. nationwide), it is very
difficult to maintain state as it requires lots of resources. I'm not
saying it's not possible to do it but it makes their life harder as
they often have to reassemble packets in order to be able to parse
them. This process is inherently expensive because it involves
buffering packets and waiting for the rest.
That said, it's not a silver bullet; it's just one technique among
many. However, the advantage is that these techniques can be combined
to create a more effective solution.


> Sounds like you've already implemented it for OpenSSL? Does using this
> API actually allow you to successfully bypass the Divar-e-Bozorg and
> establish a TLS handshake with a TLS-based VPN server? 😅
>
> And if so, can you share the code/diff? (Perhaps privately if you prefer.)

I created a draft PR so you can see what I've done so far:
https://gitlab.com/openconnect/openconnect/-/merge_requests/567
I haven't tested it personally yet, but I know this technique is
widely used by people who bypass the Divar-e-Bozorg (which translates
to "Great Wall") using V2Ray-based proxies and even their own custom
censorship circumvention tools, such as
https://github.com/bepass-org/bepass.


> If this technique does actually work for circumventing censorship, I
> think we could make a very good case for adding a similar capability
> to GnuTLS and I'd be happy to help with it :-)


The technique is proven to work:
* See section 7: https://dl.acm.org/doi/epdf/10.1145/3487552.3487858
* This is an amazing blog post specifically about TLS fragmentation:
https://upb-syssec.github.io/blog/2023/record-fragmentation/

I'd love to help and add this capability to GnuTLS!

> You might also be interested in
> https://gitlab.com/openconnect/openconnect/-/merge_requests/297, where
> I added the `--sni` option to aid in
> https://en.wikipedia.org/wiki/Domain_fronting (another anti-censorship
> technique).

Yes I actually saw it and I remember the time it was released I was
happy because it made my life easier. Before that, I had to use the
`--resolve` cli argument to simulate this behavior. Thanks🙂


On Mon, Sep 2, 2024 at 1:15 AM Daniel Lenski <dlenski at gmail.com> wrote:
>
> On Sun, Sep 1, 2024 at 4:10 PM Daniel Lenski <dlenski at gmail.com> wrote:
> >
> > On Sun, Sep 1, 2024 at 1:46 PM Moorko <me at moorko.net> wrote:
> > >
> > > Thanks for your detailed response, Daniel.
> > >
> > > I now realize that I clearly missed the big picture here as I'm relatively new to this domain.
> >
> > No worries! Looks like you're tackling a tricky problem and asking the
> > right questions :-)
> >
> > > > I'm not sure what "flexible" means specifically.
> > >
> > > I'm implementing a TLS handshake fragmentation feature for OpenConnect so that it can better resist internet censorship in Iran (and potentially in other places as well).
> >
> > Ah. We have a tag for Iran-censorship-related issues, definitely
> > peruse these if you haven't already:
> > https://gitlab.com/openconnect/openconnect/-/issues/?label_name%5B%5D=Damet%20Garm
>
> You might also be interested in
> https://gitlab.com/openconnect/openconnect/-/merge_requests/297, where
> I added the `--sni` option to aid in
> https://en.wikipedia.org/wiki/Domain_fronting (another anti-censorship
> technique).
>
> That one also required some careful fine-tuning to handle the change
> in expectations of the server's TLS certificate when built with either
> OpenSSL or GnuTLS.