Question about package build

[Moorko]

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.


 > 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). This "fragmentation" can occur at 
two layers:

1. The TLS handshake record layer

2. The TCP layer

I found an API in OpenSSL that allows for modifying the TLS ClientHello 
packet for this purpose: 
https://docs.openssl.org/master/man3/SSL_CTX_set_split_send_fragment/

However, I couldn't find a similar API in GnuTLS.


Performing TCP layer segmentation for ClientHello is possible in both 
OpenSSL and GnuTLS as it is possible in both of them to inject your own 
transport layer `send()` function.

It is possible to implement TLS record fragmentation in GnuTLS, but it 
would require manually handling the entire process within the custom 
`send()` function. This approach feels a bit hacky and might compromise 
code consistency. What do you think? Would the team consider merging 
something like this? It's probably not a feature that would be used by 
most users (since I presume most users don't have censorship problems), 
but it could significantly help those trying to evade censorship.


It was only after I implemented the fragmentation feature that I 
realized Linux distributions wouldn't include this change because by 
default they're using GnuTLS and I only implemented this for OpenSSL. 😅


 > What's the source for this "better performance" claim

It's probably not valid. I haven't run any benchmarks myself, so I 
apologize for making an unverified claim. I read it here: 
https://subscription.packtpub.com/book/security/9781800560345/2/ch02lvl1sec06/comparing-openssl-with-gnutls


Thank you,

Moorko


On 9/1/24 9:09 PM, Daniel Lenski wrote:
> On Sun, Sep 1, 2024 at 8:19 AM Moorko <me at moorko.net> wrote:
>> I noticed that the OpenConnect package available in Linux distributions
>> like Ubuntu and Fedora is built with GnuTLS rather than OpenSSL.
>> Is there a specific reason for this?
> Many such reasons, from my point of view…
>
> 1. Historically, OpenSSL didn't support the
> pre-release/non-standardized version of DTLS used by Cisco in a
> consistent or stable way (even though Cisco's own DTLS implementation
> was clearly built using a specific ancient version of OpenSSL 😵‍💫).
> OpenConnect's BDFL David Woodhouse had to cajole them into
> intentionally supporting it, and then to add tests for it so they'd
> stop breaking it over and over in new releases.
> 2. By contrast, GnuTLS developers have taken a personal interest in
> OpenConnect. In fact, the collaboration and curiosity that resulted
> from implementing Cisco's pre-release version of DTLS in GnuTLS
> largely inspired the development of ocserv 😃,. See
> https://nikmav.blogspot.com/2013/11/inside-ssl-vpn-protocol.html
> 3. The GnuTLS API is well-designed, well-documented, and has fewer
> archaeological layers of legacy cruft.
> 4. The ocserv server is built with GnuTLS, and sometimes it's helpful
> to share code and knowledge between the client and server components.
>
>> As far as I know, OpenSSL is more flexible
> I'm not sure what "flexible" means specifically. OpenSSL is a very
> long-running project and contains several layers of legacy APIs that
> sometimes interact in strange views.
>
>  From my point of view as a longtime OpenConnect developer, most of the
> code that deals with TLS/DTLS/ESP directly is *simpler and more
> maintainable* in its GnuTLS versions than in its OpenSSL versions.
> Compare https://gitlab.com/openconnect/openconnect/-/blob/master/gnutls-dtls.c
> vs. https://gitlab.com/openconnect/openconnect/-/blob/master/openssl-dtls.c
> for instance.
>
> Having worked with OpenSSL quite a bit in other commercial and FLOSS
> projects, I'd say that the "flexibility" of OpenSSL is more often a
> liability than an asset. 🤷🏻‍♂️
>
>> and offers better performance.
> What's the source for this "better performance" claim and how does it
> impact OpenConnect specifically?
>
> Daniel