[tpop3d-discuss] Re: TLS Support

[Chris Lightfoot]

On Tue, Jan 22, 2002 at 08:46:45AM -0700, Ben Schumacher wrote:
    [...]
> 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
> non-auth'd connections.

This is my preferred option.

> 2) We do some sort of solution that requires non-blocking sockets and
> doesn't fork until a socket is auth'd.

This is a possibility, but (as per previous) one I'm wary
of.

> 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
> TLS code.
> 
> Anyway, that's the way I see it. Any other ideas that wouldn't require a
> major rework of the current code?

One possibility would be to have a single process handle
all TLS traffic, though this creates the other sort of
performance problem. The other option is to ignore it;
there's not a lot one can do about denial-of-service
attacks in general, and there's nothing to stop me doing
exactly the same thing to your httpd. tpop3d actually has
a hard limit on the number of pre-authenticated
connections already (2 * max-children, I think) and I
don't think this one's too disastrous.

-- 
 Hey-ey that leg was fine/
 You mean to tell me that this stuff happens all the time?
 (`He Got The Wrong Foot Amputated', `Weird' Al Yankovic)