[stunnel-users] older browsers, stunnel and privoxy

[kovacs janos]

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
>>
>
> 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.
> _______________________________________________
> stunnel-users mailing list
> stunnel-users at stunnel.org
> https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
>