From: Theo Buehler Subject: Re: tcpbench + tls To: Jan Klemkow Cc: tech@openbsd.org Date: Tue, 5 Nov 2024 09:28:11 +0100 On Mon, Nov 04, 2024 at 05:59:55PM +0100, Jan Klemkow wrote: > On Fri, Aug 02, 2024 at 11:04:19PM GMT, Jan Klemkow wrote: > > On Fri, Aug 02, 2024 at 10:55:09PM +0200, Jan Klemkow wrote: > > > On Wed, Jul 24, 2024 at 10:34:19AM +0200, Theo Buehler wrote: > > > > On Wed, Jul 24, 2024 at 09:19:47AM +0200, Jan Klemkow wrote: > > > > > On Wed, Jul 24, 2024 at 06:47:27AM +0100, Jason McIntyre wrote: > > > > > > On Tue, Jul 23, 2024 at 07:16:09PM +0200, Jan Klemkow wrote: > > > > > > > This diff adds TLS support via libtls to tcpbench. So, we are able to > > > > > > > measure TLS throughput performance. > > > > > > > > > > > > > > Its based on the tls code of nc(1). But, I just took the essentials > > > > > > > which is needed in the context of tcpbench. We just transfer test data > > > > > > > and have no need for authentication nor key handling. In client mode, > > > > > > > it just accepts every certificate. In server mode, it creates a self > > > > > > > signed certificate on the fly. Thus, its easy to use. > > > > > > > > While I understand the desire of benchmarking TLS and making this as > > > > easy as possible for the benchmarker, I'm not a fan of generating an > > > > (invalid per RFC 5280) certificate on the fly. > > > > > > I would prefer to generate a certificate by default for ease of use. > > > But, I applied all your improvements. > > Here is a version of this diff without on the fly generation of > certificate and key. So, this diff is much smaller and we can do this > afterward. ok