Pardon my ignorance, but why not run PPP over stunnel and then UDP over that? No new encapsulation to invent. Performance would be lousy, so it would be stupid to use for some streaming media protocol, but for low-bandwidth UDP-based protocols like NTP, DNS, RADIUS, etc. it might well be useful.
-les
-----Original Message----- From: stunnel-users-bounces@mirt.net On Behalf Of Michal Trojnara Subject: Re: [stunnel-users] UDP End-points
Leigh,
Perhaps I wasn't quite as clear as I intended.. :) I'm not suggesting that SSL over UDP should be done.. I'm suggesting that stunnel could potentially act as a UDP-over-encrypted-TCP gateway.
Okay. Now I understand your idea (I hope). I would have to design a propriatary datagram-over-byte-stream (DOBS) protocol (at least length of UDP packets has to be encoded aside from the content), and then tunnel UDP over DOBS over SSL over TCP.
This is why I don't like it: 1. Such tunneling is not very effective. There's a *huge* protocol overhead. 2. It's not standard. One of the main ideas behind stunnel is its interoperability. 3. I think it's much easier to write such encrypting UDP forwarder from scratch using IPSec-style datagram protocol, than to modify stunnel. 4. It breaks my KISS principle. 8-)
In fact I would really like to find a time (or a sponsor) to develop such UDP encrypting forwarder.
BTW: Maybe it's better to use IPSec or VTUN instead of a proxy?
Best regards, Mike
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wednesday 03 of November 2004 22:18, Les Niles wrote:
Pardon my ignorance, but why not run PPP over stunnel and then UDP over that? No new encapsulation to invent.
PPP over stunnel is not always a good idea since it enables bidirectional traffic for all IP services between the two hosts. Such policy will often bypass firewall rules creating a security hole.
Of course if you don't care about traffic control PPP an option.
Best regards, Mike
-
Les Niles -
Michal Trojnara