Michal Trojnara mentioned:
On 2004-11-02, at 02:02, Red Phoenix wrote:
Establishing a SSL connection over UDP would be pretty tough, but has anyone thought about the possibility of allowing the 'listen' and 'destination' points to be UDP ports, with the main comms routed over TCP? This would effectively accomplish what most UDP requestors need.
It's not as easy as you think. SSL requires a stream of data as a transport. It's much more than a simple UDP forwarder.
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.
For example: (For the moment, lets focus on syslog data):
Pre-stunnel: Server 1 Sends syslog messages to UDP port 514 on Server 2.
Server1 and Server2 both then install stunnel: Server1: Syslog messages are redirected to localhost UDP port 514 (rather than Server2 UDP port 514). Server1: Stunnel listens on UDP port 514, and sends encrypted data to Server2 on TCP port 12345 Server2: Stunnel listens on TCP port 12345, decrypts the data, and sends to localhost UDP port 514.
This way, stunnel acts as the UDP to TCP (encrypted) to UDP gateway - in a similar way that it can currently act as a pure TCP -> TCP (encrypted) -> TCP gateway.
Regards,
Leigh.
Pre-stunnel: Server 1 Sends syslog messages to UDP port 514 on Server 2.
Server1 and Server2 both then install stunnel: Server1: Syslog messages are redirected to localhost UDP port 514 (rather than Server2 UDP port 514). Server1: Stunnel listens on UDP port 514, and sends encrypted data to Server2 on TCP port 12345 Server2: Stunnel listens on TCP port 12345, decrypts the data, and sends to localhost UDP port 514.
This way, stunnel acts as the UDP to TCP (encrypted) to UDP gateway - in a similar way that it can currently act as a pure TCP -> TCP (encrypted) -> TCP gateway.
Could it be done? Sure. But it'd be a lot of coding.
If I send a UDP packet of 102 bytes, then stunnel needs to have some way to talk to stunnel on the other end and say "this is one 102 byte UDP packet". So you've got some "udp packet size" protocol to encode both Stunnel processes.
If you didn't, here's what would happen. You'd send two UDP packets, size 50 and size 52 bytes. It wouldn't know what to do with the data - was it one 102 byte packet? Was it a 100 byte packet and a 2 byte packet? How can you tell?
You'd need to have some new mechanism like this:
debug=7 cert=/path/to/stunnel.pem
client = yes
[syslog-ish] accept_udp = localhost:514 connect = remotehost:12345
and on the Stunnel server
debug=7 cert=/path/to/stunnel.pem
client = no
[syslog-ish] accept = 12345 connect_udp = remotehost:12345
The accept_udp and connect_udp settings would trigger Stunnel to do 'UDP packet byte counting' inside the SSL session so it could recreate the packets on the remote end correctly.
Yes, it could be possible. But today it's not. If you wanted to write the code, by all means do so. ;-)
right now
On Tue, 2 Nov 2004 17:00:14 -0800, Brian Hatch bri@stunnel.org wrote:
If I send a UDP packet of 102 bytes, then stunnel needs to have some way to talk to stunnel on the other end and say "this is one 102 byte UDP packet". So you've got some "udp packet size" protocol to encode both Stunnel processes.
Good point. If I step outside the 'syslog event' mindset for a moment, and think of arbitrary (potentially binary) data where I don't have control the UDP packet size of the sender, this becomes more obvious.
Yes, it could be possible. But today it's not. If you wanted to write the code, by all means do so. ;-)
Fair enough. I'm going to have to write something anyway (even though my requirements are much smaller/simpler, there are a few shared bits).
If it's going to be quicker to wrestle something into stunnel than start from scratch, I'll zap a patch out.
Thanks Brian.
Regards,
Leigh.
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
-
Brian Hatch -
Michal Trojnara -
Red Phoenix