Any reason why the SSL application is no longer transport agnostic?

Questions / Help
,
1

It seems the ssl application is no longer transport agnostic.

We had enjoyed using it in our EAP-TTLS implementation. That stopped working with this commit which now imposes the limitation that the transport layer access point be an inet:socket() and not a pid() as we use.

Am I missing something? Is there any chance of getting this working again?

2 Likes
2

Hum … it is sort of accidental that it was possible, and we are not sure that it actual works the way you really want it. We will have to look into this and see what may be a good solution, but we are quite busy with OTP-27 right now so it will not take top priority.

3 Likes
3

That would be appreciated. I am a very patient man.

For anyone interested, the ssl:transport_option() option provides a callback to implement the transport used in ssl:listen/2 and ssl:connect/2,3,4,

callback module must implement a reliable transport protocol, behave as gen_tcp, and have functions corresponding to inet:setopts/2, inet:getopts/2, inet:peername/1, inet:sockname/1, and inet:port/1.

2 Likes
4

I would be interested in this as well. I’ve naively started looking into a pure elixir quic implementation and quic also uses tls (1.3) independently from the underlying transport.

1 Like