[Pkg-openssl-devel] syncing up openssl dev efforts, DEfO making custom packages for ECH support

[Hans-Christoph Steiner]

Sebastian Andrzej Siewior:
> On 2023-08-30 19:46:59 [+0200], Hans-Christoph Steiner wrote:
>>
>> Hello, we're part of the DEfO project (https://defo.ie), we are working on
>> implementing the TLS Encrypted ClientHello standard in OpenSSL and things
>> that depend on OpenSSL.  We want to start shipping binary Debian packages of
>> our development fork of OpenSSL so that it is easy for people to try ECH.
>> We currently follow OpenSSL's main branch pretty closely, so I we will
>> probably have to change the Debian packaging to support OpenSSL that (since
>> its currently on 3.1.x from what I can tell).
>>
>> So I'm opening this discussion to figure out how best we can push our work
>> upstream to your package, and sync up with your development efforts.  I'm a
>> DD and have maintained some shared libraries, so I'm familiar with that
>> work, but not so skilled at it.
>>
>> We have received two years of funding from the Open Tech Fund, so we should
>> have time to put into this.  We would also consider contracting with an
>> OpenSSL package maintainer to do this work.
> 
> There is OpenSSL 3.1.x in experimental. I can't upload it unstable
> because of OpenSSH (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035623).
> 
> Once that is resolved and nothing else pops up, then the version from
> experimental can go to unstable. For your packaging efforts, I would
> suggest to take the package from experimental and then rebuild the
> current openssh package against it.

If the package from experimental is close enough to master, then that sounds 
workable.  I sent a ping to that bug since the fix has been released by upstream.

> Now integrating ECH into the Debian package. This will be tough. I would
> need to sync with Kurt on this, too. However, if it is not in upstream
> then it is some out-of-tree that asks to be included. Adding just a
> cipher would be "easier" since it would be isolated piece of code
> without any exported symbols. This however is part of every TLS
> handshake and there critical in terms security and or memory leaks and
> so on.
> 
> Should this be included in the Debian package as of 3.1.x which becomes
> part of Trixie and upstream integrated it into 3.2.x or later then there
> is the question of maintenance and security fixes. Right now, everything
> in the package is from upstream.
> Sould this ECH trigger bugs (either on remote servers or somewhere in
> between like we have this TLS 1.3 disguised as 1.2) then it would be
> nice if people could opt-in for ECH as long as it is not part of an
> official upstream release. So there are bug compatible with everyone
> else.
> 
> So this would be my source of concern.

At this point we're focused on working on getting the RFC done and getting 
things integrated directly in upstream everywhere.  So the short term plan is to 
ship our own binary packages in a PPA.  This lets us work on Debian integration 
and get lots more people testing and running ECH.  The natural path for getting 
this into official Debian packaging will be to go through the existing OpenSSL 
workflow in Debian.  Right now, I'm trying to get parallel development happening 
and more real world testing of the ECH draft protocol, that is why we're not 
waiting for ECH to land upstream in OpenSSL before working on Debian integration 
(FYI we will probably be taking a similar approach with curl, apache, nginx, 
haproxy, and more).

If there is enough interest and the OpenSSL maintainers are willing, we might 
have the bandwidth and/or funding to consider maintaining ECH in Debian's 3.1.x. 
  We'll think about that when we're closer to the Trixie freeze, to see where we 
stand.  We're just getting started on a two year project now.

.hc