Re: older browsers, stunnel and privoxy

Peter Pentchev <[email protected]> Thu, 20 Dec 2018 09:54:43 +0200
Newsgroups	gmane.network.stunnel.user
Message-ID	<[email protected]>
On Thu, Dec 20, 2018 at 04:05:06AM +0100, kovacs janos wrote:
[format recovered; top-posting considered harmful]
> On 12/19/18, Ludolf Holzheid <[email protected]> wrote:
> > On Wed, 2018-12-19 16:13:25 +0100, kovacs janos wrote:
> >> so stunnel doesnt rewrite the headers besides the encryption?
> >
> > Yes.
> >
> >> does
> >> that mean only stunnel can receive traffic forwarded by itself,
> >
> > There are other protocols than HTTP, without the need for re-writing
> > contents while encrypting/decrypting, such as e.g. POP3.
> >
> > The peculiarity of HTTP is, it thrives on the links from one resource
> > to another.  If you change the way the resources are retrieved, you
> > have to change their addresses in both, the request you send to the
> > server and the the document you present to the client.
> >
> >> and
> >> can only work if both ends of the tunnel are defined and connected?
> >
> > This depends on the terminology.
> >
> >
> > If 'the tunnel' is the section of the path where the data is
> > encrypted, then yes, both ends of the tunnel must be defined.
> >
> > If 'stunnel works' means actual data flow, then yes, there obviously
> > must be a connection between the tunnel ends.
> >
> >
> > A stunnel process is listening on a configured TCP port for connection
> > requests and, depending on the configuration, may accept any client
> > that reaches the stunnel process.  If 'the tunnel' includes the path
> > from the client to the stunnel process, then no, the client end of the
> > tunnel is not defined beforehand.
> >
> > If a client is accepted, the stunnel process sets up a connection to
> > the configured server (which may be, but does not have to be, a second
> > stunnel process).  If 'stunnel works' means the stunnel process is up
> > and waiting for connection requests, then no, there is no need for a
> > connection for stunnel to work.
> 
> what i mean by stunnel working, is the connection between the browser
> and requested server working through stunnel.
> but if that is true, then the traffic forwarded by stunnel can only be
> received by stunnel, and nothing can be between the two ends at all,
> or it will always give an error.

The connection between a browser and stunnel will work just fine if
stunnel is working in server mode in front of a single server with
a well-known set of hostnames - then stunnel may be configured to
accept TLS/SSL connections from browsers, provide the certificates for
the hostname that the client (the browser) requests, and forward
the connection to the server.

It might also be possible to get stunnel to work in client mode for
a single server or a few servers with well-known hostnames and
addresses: then stunnel will accept a non-encrypted connection from
the browser, establish a TLS/SSL connection to the server (or servers),
encrypt the browser's traffic, and decrypt the server's response.

What is not so easy (and I am not sure it can even be done in general)
is to have stunnel work with an *unknown* set of servers, and that's
basically what you want.  Stunnel is just not written for that purpose -
it is written to make it easy to convert existing services with a well-known
configuration to use encrypted connections.

Also, please note that the Internet is not the same as the World-Wide Web -
as others have pointed out, stunnel may be used not just with a web
browser as a client or with a web server in what in something like
reverse-proxy mode, but also with TLS/SSL versions of IMAP, POP3, SMTP, and
many other protocols, both well-known and custom-made for some application.
The common factor, though, is that it either works as a TLS/SSL server with
a well-known set of hostnames to respond for, or a TLS/SSL client with
a well-known set of hostnames to connect to.  You are trying to use it for
something that it was not designed for.

Hope that helps!

G'luck,
Peter

-- 
Peter Pentchev  roam@{ringlet.net,debian.org,FreeBSD.org} [email protected]
PGP key:        http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13

_______________________________________________
stunnel-users mailing list
[email protected]
https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
signature.asc (application/pgp-signature, 833 B)