SSL accept

[Carsten Schultz]

Hi, Peter!

On Wed, Jun 30, 2004 at 09:16:55PM +0200, Peter H|gfeldt wrote:
> On Wed, 30 Jun 2004, Carsten Schultz wrote:
> > I just noticed that a problem I thought had gone away is still there.
> > In November 2003, Alexey Shchepin reported
> > (http://www.erlang.org/ml-archive/erlang-questions/200311/msg00173.html) 
> > 
> > | * ssl:accept locks when when one TCP connection is established, but
> > |   SSL handshake is not finished.  E.g. if Yaws is listen for SSL
> > |   connections on port 443 and someone runs "telnet this.server 443"
> > |   (note that this is not SSL-enabled telnet), then noone will be
> > |   able to retreive web pages via this port until this connection
> > |   will be closed.
> > 
> > Has anything happened in this regard?
> 
> In Nov 3, 2003 in response to Alexey's question I wrote:
> 
> 	In Erlang/OTP SSL you can have several processes, each waiting for
> 	an ssl:accept/N on one and the the same port. That is needed to
> 	obtain acceptable (no pun intended) parallellism. 
> 
> 	That it not practically possible with gen_tcp:accept/N (if you try
> 	it you will get an error return). I think gen_tcp should accept
> 	multiple accepts as well. 
> 
> That is, if you have the very simple approach with only one process
> calling ssl:accept/1 in series, you will get the behaviour described. 
> 
> What you should do is to have several processes in parallel waiting for
> the result of calling ssl:accept/1 (and spawning a new process when a
> return is obtained).
> 
> Also, to avoid an indefinite wait for an accept call, and thus avoid
> that a file descriptor will never be returned, you should use
> ssl:accept/2 with timeout. 

Back then you also wrote :-)

| I also agree that there should be some kind of "pre_accept" that
| returns a "raw" non-SSL socket, to be closed on reasons you have
| mentioned

I really do think that this is the way to go.  Your solution above
does not convince me.  How many accepts should I run in parallel?
What should the timeout be?

Why this is a problem even without malicious client processes is that
it is not unusual to have *user* *interaction* on the client side in
the course of the SSL connect.  To avoid not being able to accept new
connections I would need to have as many parallel accepts as users
simultaneously looking at certificates and pondering whether to trust
them.  I would not know how to obtain a reasonable upper bound on
that.

Nevertheless, your answer pointed me in a direction to partly fix the
problem.

Thanks,

Carsten

-- 
Carsten Schultz (2:38, 33:47), FB Mathematik, FU Berlin
http://carsten.codimi.de/
PGP/GPG key on the pgp.net key servers, 
fingerprint on my home page.