<div dir="ltr"><div class="gmail_quote"><div dir="ltr">Spin off from: Re: [erlang-questions] dtls error when used with chrome webrtc</div><div dir="ltr"><br></div><div dir="ltr">Ingela Andin <<a href="mailto:ingela.andin@gmail.com">ingela.andin@gmail.com</a>> schrieb am Di., 2. Jan. 2018 um 13:30 Uhr:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi!<br><div><div class="gmail_extra"><br><div class="gmail_quote"></div></div></div></div><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote">2017-12-29 12:21 GMT+01:00 Joe K <span dir="ltr"><<a href="mailto:goodjoe2049@gmail.com" target="_blank">goodjoe2049@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px">> Also you may try using external STUN server (check RTCPeerConnection docs) and hope browser starts with DTLS hello.</span><br><div><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px"><br></span></div></span><div><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px">I've tried that, but the browser still sends STUN binding requests to the DTLS process. And it uses the STUN server just to find out it's address.</span></div><span><div><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px">> </span><span style="font-size:12.800000190734863px">It should be quite easy to implement and it would be consistent with ssl:connect/2 and ssl:ssl_accept for TCP sockets.</span></div><div><span style="font-size:12.800000190734863px"><br></span></div></span><div>Will try this now. Thank you.</div></div><div class="m_-8767085732800945564HOEnZb"><div class="m_-8767085732800945564h5"><div class="gmail_extra"><br></div></div></div></blockquote><div><br></div><div><br></div></div></div></div></div><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote"><div>Pleas let us know if this is desirable functionality. So far we reasoned that as UDP is not connection oriented there is not the same interest to reuse</div><div>to underlying sockets as if there is an underlying connection.<br></div></div></div></div></div></blockquote><div><br></div><div>I do have a use case that is even more complicated then simply upgrading UDP to DTLS.</div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>The current socket abstraction in the SSL app is not prepared to handle this and would need invasive changes.<br></div><div><br></div><div>A simplistic workarround would be to forward the DTLS traffic on loopback UDP socket. Hwever that would incure additional latency, signaling overhead and would make detection of failed connections more difficult. I therefore don't want to go there.</div><div><br></div><div>A supported and documented API to pass (D)TLS traffic into the SSL app and get status change events and the decoded payload data back from the SSL app would IMHO help a lot.</div><div>Just some quick idea:</div><div><br></div><div>%% Create a new passive SSL connection of given type, return a opaque identifier.<br></div><div>ssl:create_connection(Protocol :: 'stream' | 'datagram', Opts) -> ssl_connection_id().</div><div><br></div><div>%% Pass received SSL traffic into the connection,</div><div>%% Return error, ok or Data to return on the connection.<br></div><div>ssl:recv(Connection :: ssl_connection_id(), EncData :: binary()) -></div><div>   {error, Error} | ok | {ok, {send, Data :: binary()}}.<br></div><div><br></div><div>%% Pass unencrypted traffic into the SSL app<br></div><div>ssl: send(Connection :: ssl_connection_id(), PlainText :: binary()) -></div><div>  {error, Error} | ok | {ok, {send, EncData :: binary()}}.</div><div><br></div><div>%% The owner of the connection is then getting messages like:</div><div>%% - send encrypted data:<br></div><div>%%     {ssl, Connection :: connection_id(), {send, EncData :: binary()}}</div><div>%% - got plaintext data:<br></div><div><div><div>%%     {ssl, Connection :: connection_id(), {recv, PlainText :: binary()}}</div>%% - connection event:</div><div>%%     {ssl, Connection :: connection_id(), Event :: ssl_connection_event()}</div><div><br></div><div>Wheter ssl:recv and ssl:send return data or use a message to the owner should depend on a mode setting (e.g. active, passive...)</div><div><br></div><div>What do you think? Comments?<br></div><div><br></div>Regards<br></div><div>Andreas</div><div><br></div><div>[...]<br></div></div></div>