[stunnel-users] older browsers, stunnel and privoxy

[kovacs janos]

thank you for the explanation, but if a proxy cant read the traffic
encrypted by stunnel, that means even if the set of possible hostnames
are given, the destination server could not read the request unless
there is another stunnel in front of the server which can receive and
decrypt the request. which i obviously dont have access to

On 12/20/18, Peter Pentchev <roam at ringlet.net> wrote:
> 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 <lholzheid at bihl-wiedemann.de> 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} pp at storpool.com
> PGP key:        http://people.FreeBSD.org/~roam/roam.key.asc
> Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13
>