SSL_SESSION_set1_ticket ?

[Jakob Bohm]

On 03/04/2019 22:16, Jeremy Harris wrote:
> On 02/04/2019 17:03, Viktor Dukhovni wrote:
>> Does the server have a temporally stable ticket decryption key?
>> Is this Exim?  Is the server's SSL_CTX persistent and shared
>> across multiple connections?
> Ah, right.  Unlike GnuTLS, the STEK is tied to the SSL_CTX and,
> as you say, Exim initialises that fresh per connection.
> Rearchitecting that is more effort than it's worth spending
> on TLS 1.2, I think.

As an Exim user (can already be seen in my mail headers), I always
wondered about the weird way that Exim (according to the docs/spec)
tries to reinit TLS for each message on a connection.

It seemed very much contrary to protocol, unlike the simple
approach of running TLS in one process, piping the plaintext
(E)SMTP stream to/from a succession of message processing processes,
which can be reforked without breaking the stream and without
ability to steal TLS keys through any security vulnerabilities.

When a non-TLS ESMTP process sends or receives the STARTTLS
command, it can exit with a magic exit code causing the non-TLS
parent process to fork a TLS process and spawn fresh ESMTP
processes.  Alternatively non-TLS ESMTP processes could run
through a dummy TLS process that can be instructed out-of-band
to start TLS negotiation at the right time.

This (could provide better batching of connection overhead than
session tickets, as it saves even the TCP SYN packets while
lowering load on the remote servers and all intervening
stateful firewalls.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded