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@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