On Sun, May 08, 2022 at 10:42:52AM +0200, Hiltjo Posthuma wrote: > On Sat, May 07, 2022 at 10:13:40PM +0200, Marc Espie wrote: > > On Fri, May 06, 2022 at 08:13:42AM -0000, Stuart Henderson wrote: > > > On 2022-05-06, Theo Buehler <[email protected]> wrote: > > > > While we could readily make libssl fall back to the legacy stack if > > > > SSL_OP_NO_TICKET is disabled, I don't think this optimization outweighs > > > > the overall benefit of TLSv1.3 - better protocol, cleaner code. > > > > > > Especially when the major beneficiary of this is pkg_add when it > > > searches for updates; the number of connections has been *hugely* > > > reduced with the caching added recently. > > > > I haven't enforced it, but https for pkg_add makes zero sense > > anyway: you don't gain any confidentiality, and the integrity of > > the package is ensured by the signatures. > > > > Note that https for base release makes little sense as well, apart > > from the initial installs. Updates will also rely on signatures, > > so all you gain from https is... exercising tls, and noticing > > connections are slower. > > > > (also: authentication is slow for old time architectures). > > > > I'm still wondering what's the point of https for all this. > > > > The actual HTTP data sent (not just the package data itself) is not > immediately > visible, filterable or changed by a MiTM. They also cannot easily see which > packages are installed or filter errata's, right?
Actually pkg_add is mostly predictable, for debug reasons, and all data *sizes* are still very visible. Knowing you talk to cdn.openbsd.org, just by looking at the packet sizes you can predict what packages are getting installed/updated.
