On Thu, 20 Dec 2018 14:18:10 +0100 kovacs janos kovacsjanosfasz@gmail.com wrote:
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
Hi,
O_o
Really, where did you understand that???!!!
Stunnel is a program to give encryption capabilities to programs that can't establish secure connections. That doesn't mean that at both ends there should be a Stunnel instance running!!!!!
As long as both ends have the same ciphers, that is what the handshake is for, to negotiate the security of connection, it doesn't matter what program handles the secure connection at the end point.
And, again, the proxy can't handle the connection because it doesn't receive what expects: an HTTP header to tell where to redirect the data. And that isn't provided by Stunnel.
Let's see if with a "sketch" you understand it.
1. As client mode, Stunnel listen to 127.0.0.1 port 1256 and connects to somehots:565 (totally invented destination host and port to avoid you any further confusion)
2. Program sends text-plain to 127.0.0.1:1256
3. Stunnel takes it and connects to destination
4. After a handshake with secure connection parameters, encrypts that data and sends to destination
5. Any dialog between destination and Stunnel would be encrypted after this.
6. Responses from destination would be decrypted and send them back in text plain to the program that requested Stunnel to connect.
7. Repeat, except handshake, until there is no need of the connection by the initiating program.
It doesn't do anything else. And it is almost the opposite when running as server.
Did you understand it?
The proxy server is expecting an HTTP header and Stunnel doesn't provide it. End of story.
Regards.