[tpop3d-discuss] Re: TLS Support
ben at blahr.com
Tue, 22 Jan 2002 08:46:45 -0700 (MST)
On Mon, 21 Jan 2002, Ben Schumacher wrote:
> > As far as I can see, the best strategy is to have the
> > helper process, connected to the main tpop3d by a
> > socket-pair, forked off as soon as any TLS operation is
> > required; this sidesteps all of the blocking/non-blocking
> > issues. This means that the tpop3d main process must
> > acquire the cryptographic certificate and so forth, and
> > then as soon as an incoming connection is received on a
> > pop3s port, or an existing connection issues the STLS
> > command, we fork the helper process, which calls setuid,
> > discards resources it doesn't need, and goes into a proxy
> > loop like the one in tlsproxyd. This process will exit as
> > soon as it detects EOF or an error on any connected
> > socket, doing a proper TLS shutdown if it is the local
> > side which has closed.
One concern hit me last night while I was thinking about this, by forking
whenever somebody connects to a TLS socket or whenever somebody does an
STLS, we open the possibility for a resource exhaustion attack. Basically,
I could connect a bunch of times to the TLS socket of the POP3 server and
since it forks everytime I connect, it could easily start chewing up
memory. Same problem exists for STLS.
Working through this in my mind, I see two possible solutions.
1) We have a configurable maximum number of fork'd, but non-authenticated
processes. This would work, but it would complicate things quite a bit, as
the software would need some way of keeping track of the fork'd, but
2) We do some sort of solution that requires non-blocking sockets and
doesn't fork until a socket is auth'd.
I'm sure you can see the trend here... the current design, where the
daemon doesn't fork until auth, seems to be the appropriate behavior, we
just need to figure out some way to implement it in conjunction with the
Anyway, that's the way I see it. Any other ideas that wouldn't require a
major rework of the current code?