[stunnel-users] older browsers, stunnel and privoxy
kovacsjanosfasz at gmail.com
Fri Dec 21 00:01:08 CET 2018
okay, so that means i should be able to connect to a website's server
with only stunnel, and only its client side, even if i have to specify
the destination IP of the server? i tried that and didnt seem to work
either. i wrote the website's IP address after 'connect', tried to
open the website in browser, and it wasnt working. but maybe i just
did something wrong, thank you for the explanation though
On 12/20/18, Javier <jamilist.stn at gmx.es> wrote:
> On Thu, 20 Dec 2018 14:18:10 +0100
> kovacs janos <kovacsjanosfasz at 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
> 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.
> stunnel-users mailing list
> stunnel-users at stunnel.org
More information about the stunnel-users