"New" SSL - a problem (which could be mine) and a suggestion

Steve Davis steven.charles.davis@REDACTED
Tue Aug 18 11:03:13 CEST 2009

I'm adding SSL to an http server, I'm only supporting the new_ssl
implementation, and thus it's alpha quality for at least as long as
the new_ssl implementation remains that way ;). However, be aware that
the following comments apply to *new_ssl* and not "old ssl".

1) A problem: I'm finding that the ssl_accept hands over client
sockets that appear to close out immediately, frequently and
unexpectedly. The real problem is that this issue is intermittent. In
about 50% of cases of a connection I'm getting:

=INFO REPORT==== 18-Aug-2009::03:15:24 ===
SSL: Peer did not send close notify alert.

...but no other error(s) at all (This info report is generated from
the  ssl_connection module in the ssl app).

In about 20% of these unexpected close cases, the socket also errors
out with

Occasionally, ssl:send *silently* but entirely fails.

Since the exact same socket handling code flow is used for the plain
gen_tcp, which doesn't suffer from these issues, I'm suspecting that
it isn't my code here. I'm making appropriate checks later in the
handler to check for closed-out/timed out sockets but these checks are
never reached/triggered.

My question is whether this a known issue? i.e. if not, then I'll have
to find time to pull out a vanilla repro from the server codebase to
effectively bug-report -- that kind of time I am sadly sorely short

2) A suggestion: new_ssl is generally easier to use, however it
suffers from one important API usage issue as old ssl...
In order to use setopts/send/recv/close you need to know the transport
(gen_tcp or ssl) throughout the socket lifetime. This means that
throughout the later handling of the client socket, when you really do
not (and should not have to) care what transport is being used, you
are forced to case check at every turn whether the socket is ssl or

My suggestion is design-level and is that either inet/gen_tcp should
be made aware of the differing transports or that some platform level
abstracted interface to the socket implementation be provided so you
can call socket:set_opts, socket:send, socket:recv, socket:close
without checking which module to invoke. This would improve usability


More information about the erlang-questions mailing list