Re: TLS Support (was- Re: [tpop3d-discuss] Compilation trouble on Solaris)

[Chris Lightfoot]

On Thu, Jan 17, 2002 at 06:07:19PM -0700, Ben Schumacher wrote:
> On Thu, 17 Jan 2002, Chris Lightfoot wrote:
    [...]
> > However, there is a serious problem with TLS, which makes
> > it unsuitable for use in a program such as tpop3d which
> > uses blocking IO: a call to SSL_write may discover that
> > the client has requested TLS renegotiation. This means
> > either that the server could then block on SSL_read, or
> > that all IO must be rewritten to be nonblocking. (The
    [...]
> 
> That would be a problem. However, I did discover another potential DoS
> problem that I introduced with my TLS patch that I missed during my
> initial testing -- something I probably never would have though of if I
> hadn't just run into a similar issue for an OpenSSL TLS product I've been
> building for my job. And I understand fully your reluctance to rewrite as
> non-blocking... aside from security concerns, it would take a major amount
> of rework on the internals of the code.

Yeah. It's probably not an enormous amount of work, it
just means adding a buffer to each connection object and
testing for writeability. Obviously some care would be
needed where this interacts with the send-message code,
which presently relies on blocking behaviour. It might be
a good idea from a robustness perspective, and the main
loop is a mess at present anyway. This doesn't, of
course, mean that I want to rewrite it just for the hell
of it....

> > My thinking is that the best solution is to have tpop3d
> > fork a `helper' process to do the TLS operations. This has
> > another advantage: if the helper process runs as (say)
> > root, a malicious local user cannot then use a debugger to
> > steal valuable cryptographic data from the server process.
> > This is pretty nasty, but is IMO a cleaner solution than
> > the other options.
> 
> While I understand the security concern, I think the impact would be
> limited. While it would allow users to view cryptographic information on a
> tpop3d process that has already done setuid'd to the user in question,
> would this really be all that bad? At worst it would expose information on
> the private key used for the initial key exchange, but this problem could
> probably be mitigated by making sure that memory is free'd or clobbered
> before we change the effective UID of the forked process.

Exactly: my concern is for the server certificate and
private key, not the session keys. Can we safely get rid
of these? Aren't they needed for renegotiation?

> If this solution is the choosen one, however, my suggestion would be to
> run the external process as an unprivileged user that is defined in the
> configuration file. While I have looked at your code and have seen that
> you do very careful bounds checking, I still worry about the possibility
> of buffer overruns and malicious code that might allow some sort of access
> with root privileges.

Unprivileged user is probably a good way to go.

> Wow... a more than I was planning to write, but things just came to me as
> I started typing.
> 
> Any of this make sense to anybody else?

Much. I appreciate your input.

-- 
 ``... the leaders of the world's richest countries and Russia....''
   (BBC news, description of the Genoa G8 summit)