Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Add missing arrow. Fix italics.

...

Let's say that you have an HTTPS server, but your client can't speak HTTPS for some reason. If you set up stunnel on the *client* side, you can connect locally to the stunnel server and have it establish a secure-connection to the remote server running HTTPS. Like this:

...

Let's take another example: you have clients that are HTTPS-capable, but the service you are running can only support HTTP for some reason, and you want to secure it. Set up stunnel on the *server*, then have your remote clients connect to *it* and tunnel to localhost. Like this:

No Format
  client -> remote_host:443 (stunnel)
  stunnel -> localhost:8080 (httpd)

As far as the client is concerned, it's using HTTPS to communicate with remote_host:443, but really it's connecting to remote_host:8080. (Yes, there are some issues with URLs and redirects but that's out of scope for this discussion.)

So what if the underling protocol doesn't support TLS at all? Well, then you have to set up stunnel on *both sides* of the tunnel, like this:

...

No Format
  sslVersion = all
  options = NO_SSLv2
  options = NO_SSLv3
  client = yes
  
  [ajp13s]
  accept=localhost:8009
  connect=remote_host:8010

...

No Format
  sslVersion = all
  options = NO_SSLv2
  options = NO_SSLv3
  client = no
  
  [ajp13s]
  accept=8010
  connect=localhost:8009

...