Viktor Dukhovni:
>
>
> > On Mar 21, 2018, at 9:46 PM, Wietse Venema <wie...@porcupine.org> wrote:
> >
> > Just like the SMTP conection cache service, the tlsproxy service
> > must not try to do clever things. It receives TLS requirements,
> > does a TLS handshake, and returns TLS session properties that can
> > later be used to create a connection cache index. If it needs to
> > impersonate a delivery agent, then it gets that nanme from the
> > Postfix SMTP client.
>
> I'd like to avoid having to fully instantiate the SSL_CTX for each
> and every connection, SSL_CTX initialization can be expensive.
> Thus, the agent name requirement, and re-use of SSL_CTX built for
> previous clients with the same name.
Currently, the Postfix SMTP client does a bunch of TLS initialization,
once per TLS session.
The tlsproxy service will do exactly the same TLS initialization
once per TLS session. In addition we shuttle some serialized SMTP
client state between SMTP client, tlsproxy process, and scache
daemon. Conceptualy, that serialized state is just another RPC
message.
Cached TLS session:
scache daemon -> tlsproxy -> remote SMTP server
Reused TLS session, or new TLS session:
smtp client -> tlsproxy -> remote SMTP server
Initial SMTP handshake:
smtp client -> remote SMTP server
> All in all this is a non-trivial bit of work...
Meh. Where I work now, we solve harder problems.
Wietse
