Hello Michal,
Just one thought: - if the stunnel on LAN1 joins a group to receive a multicasted stream does it really depend on DTLS's [in]ability to handle the multicasting?
I see it this way - on LAN1 a machine running the (first instance of) stunnel joins a group, i.e. stunnel is told to open a socket with all the relevant socket options. Then, another machine on LAN2 (behind NAT + firewall + internet + firewall + NAT) connects to the first stunnel and tells it's own instance of stunnel to open a socket with all the relevant socket options to emit the (apparently) multicasted stream.
Please comment.
On Sunday 21 of August 2005 15:38, rz1a@mail.ru wrote:
Just one thought:
- if the stunnel on LAN1 joins a group to receive a multicasted
stream does it really depend on DTLS's [in]ability to handle the multicasting?
Yes. The very basic idea of DTLS (and TLS) is to negotiate algorithms and keys, and then use them for data encryption and message authentication. Negotiations like these are not easily scalable to more than two peers.
Best regards, Mike
Hello Michal,
Monday, August 22, 2005, 10:09:55 PM, you wrote: MT> Yes. The very basic idea of DTLS (and TLS) is to negotiate algorithms and MT> keys, and then use them for data encryption and message authentication. MT> Negotiations like these are not easily scalable to more than two peers. This is OK. OpenSSL people explained me that DTLS secures only one pair of peers.
And what about the second part of the question? Is it (or will it ever be) possible to tell the stunnel to join a multicasting group? If it joins - then all the incoming stream could be made available for the (only one) client stunnel connected to it. If the client stunnel could be instructed to open it's output socket in the multicasting mode as well - then any host on the same LAN as the client stunnel will be able to virtually "join" the tunneled stream - and this will solve my current need...
Please comment.
-
Michal Trojnara -
rz1a＠mail.ru