[erlang-questions] DTLS UDP socket reuse / SSL passive API?
Wed Jan 3 15:48:30 CET 2018
Vance Shipley <vances@REDACTED> schrieb am Mi., 3. Jan. 2018 um
> On Wed, Jan 3, 2018 at 2:39 PM, Andreas Schultz
> <andreas.schultz@REDACTED> wrote:
> > I do have a use case that is even more complicated then simply upgrading
> > to DTLS.
> > CAPWAP is runnig unencrypted and DTLS traffic on the same socket. It
> > distinguished between the traffic with a small header in front of the
> > payload packet. I therefore need a demultiplexer on the UDP socket that
> > removes the header and passes the encrypted payload to the DTLS stack.
> I think you're in luck.
> > There is somewhat similar problem when doing EAP-TLS over RADIUS or
> > DIAMETER. The TLS traffic is encapsulated within RADIUS/DIAMETER requests
> > and needs to be passed into the TLS stack and the replies need to
> > encapsultated with RADIUS/DIAMETER.
> SigScale has a pure Erlang implementation of EAP-TTLS over RADIUS
> using the SSL app in OTP in our open source Online Charging System
> (OCS): https://github.com/sigscale/ocs
I have seen that some time ago.
> The current socket abstraction in the SSL app is not prepared to handle
> > and would need invasive changes.
> The existence of the API is hidden in this one sentence of the User Guide:
> "By default SSL/TLS is run over the TCP/IP protocol even though you
> can plug in any other reliable transport protocol with the same
> Application Programming Interface (API) as the gen_tcp module in
Last time I looked at the SSL library in that depth (around 2014) it did
not permit to use of a Pid. The actual socket had to be a Erlang port. Back
then I needed this change to use a Pid as socket replacement:
I also played with EAP based on Erlang SSL back then (
https://github.com/travelping/eradius/commits/eap), but didn't have the
time to properly finish it.
That SSL API restrictions to Erlang ports seem to have changed since then,
at least for the TLS code.
The DTLS code still seems to have the hard coded assumtions that it always
runs over UDP sockets:
The other major restriction was that it required two processes, one for the
socket/transport side and another for the payload side of the SSL library.
Using the same process for both sides would lead to a dead lock when
calling ssl:send. Not sure if that restriction has been lifted.
> Here is our SSL transport callback module:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions