1

One option typically used by organizations to forward a plaintext TCP connection over the network is SSH local and remote port forwarding. SSH binds a port locally and forwards all traffic to the remote machine over SSH.

This is a great solution for a number of reasons, namely that you get message encryption and message authenticity, and you also have somewhat of a guarantee of authorization in that the user must have SSH access to the machine (and root if the port is under 1024).

However, in the case of wanting message encryption and authenticity without wanting authentication per se, I'm not sure of another existing solution off-hand.

What I was able to imagine, however is a server/agent setup which would wrap TLS and do port forwarding where needed. Say that I need to run Redis over the internet (why is beyond the point, if you're asking why, ask for another service that would best fit your imagination). A decent solution would be to run a process on the Redis server which bound to a given port and acted as a TLS proxy. You'd need to run through an entire TLS handshake to connect and transfer data to this proxy.

The second half of the equation would be to run something client-side on the servers which need to connect to Redis. This would again listen on a local port, but forward traffic over TLS to the aforementioned TLS proxy.

Does such a technology exist? I'd like the eventual option of using client-side SSL certificates for authentication, but simply upgrading to TLS over plaintext is a huge benefit in my opinion.

Improve this question
2
  • Have you looked into what stunnel has to offer?
    – gowenfawr
    Sep 21, 2015 at 20:12
  • IIRC stunnel works in a radically different way.
    – Naftuli Kay
    Sep 21, 2015 at 20:16

2 Answers 2

Reset to default
1

You may want to have a look at stunnel, that provides SSL-powered tunnels. Depending how you configure it, it may provide what you look for.

Take care that you do encryption because of possible attackers, and attackers can become active, i.e. try to alter data in transit or masquerade as a genuine server or client. If there is no client authentication then the server cannot be sure of who it is talking to. If you configure stunnel on the server side to use a self-signed certificate, and you setup clients so that they accept whatever certificate the server sends, then your clients may be made to talk to a fake server, and this can end with a nasty Man-in-the-Middle.

So even if you make clients "anonymous" (no client authentication), you will probably still want to authenticate the server, i.e. make the server use a proper certificate that the client validates. (Unless you use the tunnel only to convey a protocol which is itself properly protected, e.g. you do SSH-within-SSL, which is possible but maybe not what you are envisioning.)

Improve this answer
1
  • Yeah, I'd like to pin server certificates where possible and applicable. Again, where applicable I'd use client SSL certificates in conjunction with username/passwords. I've just generally found that the services (eg MySQL) which provide "native" SSL do a terrible job at doing it and lack lots of configuration options relevant to the modern world.
    – Naftuli Kay
    Sep 21, 2015 at 20:20
0

The Azure Service Bus is made to handle this exact scenario. You can forward and proxy any port over 443 to the Azure Datacenter, and consume it on another host.

A variety of authentication scenarios are possible, including anonymous.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .