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.
Ludolf