STUNNEL security

Posted on 2004-08-05
Last Modified: 2010-04-11
Hi everybody,

I have stunnel 4.x running across win32 in order to access a RSYNC demon across the internet a little more securely.
Question is how secure is this really?  What are the vulnerabilities I should know?

I have setup the server with a newly created server.pem but the client doesn't seem to need a copy of this to access the daemon at the file server.  Am I right in thinking the server must send the public key (is this the same as the certificate) to the client?

I thought the client always required a copy of the public key

Am q. confused as there is maybe too much info on this!

Question by:carillian
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 8
  • 6
LVL 51

Accepted Solution

ahoffmann earned 500 total points
ID: 11729289
> What are the vulnerabilities
AFAIK currently none known

> Am I right in thinking the server must send the public key
yes, but stunnel silently ignores, means accepts, it

> I thought the client always required a copy of the public key
no, the server sends its key, and then the client can accept it and store it

rsync could be considered secure using stunnel
but why do you not simply use SSH instead of stunnel? rsync supports it directly (see -e option)

Author Comment

ID: 11729861
I would like to use linux to host my rsync daemon due to the the advantage of hard-link file system over win 32.
However I am v. reluctant to open up ssh as I am a little unsure how to secure SSH as it does open up another pot of worms and I am v. new to linux and it's security at the mo.  Forcing users to have to communicate through the rsync daemon means I can ensure the rsync daemon is patched appropriately and block any other port at the firewall.

Would you be happy to give users ssh access?
They are able to access the root and read all kind of files which I read I can chroot them and jail them and all kind of stuff but then I read further that it can be broken, etc.  Surely stopping them from having console access directly to the kernel and forcing them to communicate via the daemon is safer?

Anyhow, do you use stunnel yourself?

LVL 51

Expert Comment

ID: 11730400
yes I use stunnel myself, but not for rsync just in its native purpose: human readable SSL ;-)

AFAIK ssh requires a login, not shure if you can workaround using sudo.

But have a look at
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!


Author Comment

ID: 11731074

Soo... given the fact that my rsync daemon is available for public access am I now secure in the form that everything will be encrypted across transport just because I have the correct .pem at the server end & I need nothing more at the client side.  After all, all authentication will hit the rsync daemon, and I want a secure transport.  (how secure can that be?)

LVL 51

Expert Comment

ID: 11733169
unfortunately there is no doc about rsync's protocol, I understand your concern now :-)
see man rsyncd.conf and man sshd
they describe how to use ssh with
  command=rsync --server --daemon
in your authorized_key file
(never tested it, but that should do the trick, according man-pages:)

Author Comment

ID: 11733308
So, stunnel and private key/public key encryption - am I right in reading that somebody with the public key can only read data encrypted with the private key?
If so does that mean that any data sent from my rsync daemon from the server back to the client will be encrypted using the private key and viewable to anybody with a copy of the public key?
LVL 51

Expert Comment

ID: 11733792
>  am I right in reading that somebody with the public key can only read data encrypted with the private key?
no, the other way arround: encrypt with otherone's public key and then decrypt with corresponding private key

Author Comment

ID: 11733965
But still sticking with the stunnel and security,
If I have server.pem at the server and no .pem file at the client will I be getting encrypted traffic in both directions?

If everything time the server sends something to the client, yet the client can decrypt the reply just using the server's public key is this insecure?

See extract below for the document I am reading;


Authentication is the process of verifying identity so that one entity can be sure that another entity is who it claims to be. In the following example involving Alice and Bob, public key cryptography is easily used to verify identity. The notation {something}key means that something has been encrypted or decrypted using key.

Suppose Alice wants to authenticate Bob. Bob has a pair of keys, one public and one private. Bob discloses to Alice his public key (the way he does this is discussed later). Alice then generates a random message and sends it to Bob:

  A->B   random-message

Bob uses his private key to encrypt the message and returns the encrypted version to Alice:

B->A   {random-message}bobs-private-key

Alice receives this message and decrypts it by using Bob's previously published public key. She compares the decrypted message with the one she originally sent to Bob; if they match, she knows she's talking to Bob. An imposter presumably wouldn't know Bob's private key and would therefore be unable to properly encrypt the random message for Alice to check.
LVL 51

Expert Comment

ID: 11734571
> will I be getting encrypted traffic in both directions
yes ('til the end of the tunnel, wher you feed rsync in)

> .. yet the client can decrypt the reply just using the server's public key is this insecure?
the client does not need the server's .pem, the session key is declared automatically between both sites
hence the traffic is secure. A public key is never insecure, 'cause you just can encrypt with it and only the owner of the corresponding private key can decrypt it.

carillian, where did you get this cited text from?
is it a joke, or a contest, or whatelse?
It's nonsense!
Something encrypted can only be decrypted with the corresponding secret (==private) key.
If you encrypt with a public key, then the owner of the corresponding secret key can decrypt it,
if you encrypt with a secret key, then you can only decrypt it with the same key.
If you sign with your secret key, everyone knowing your public key can verify the signature.

Author Comment

ID: 11734651
Okay, the document was found here,

and this website says it as well, 

Quote -

The sending station can encrypt data using the private key, and the receiving station decrypts the data using the public key.
LVL 51

Expert Comment

ID: 11735531
damn, beside a few million others, I've read this more than once.
I did it again, and it's clear now:
  the title is  AUTHENTICATION, but the description uses "encrypt" and "decrypt" wheer it means "sign" and "verify"
Nice, someone needs to inform Netscape :-))

Anyway, in this context: AUTHENTICATION, it's correct (should have read more carefully, shame on me)
but you want encryption, then see my previous comment.
Keep in mind that signing is not encrypting.
LVL 51

Expert Comment

ID: 11746199

Author Comment

ID: 11781739
Okay, i'm still a little unsure please consider the following example and tell me which bit I am misunderstanding

A client with no public/private key connects to a server which has it's own private key - the server sends the public key to the client from here the client can talk to the server encrypted because it has a copy of the public key to encrypt any outgoing conversation.  However the server cannot send anything in encrypted form to the client because the client has no private key nor does can it decrypt with the public key.

LVL 51

Expert Comment

ID: 11781802
As explained earlyer or elswhere:
  the server's public key is used by the client to verify that it is *this* server
  the client's public key (here you user's public key) is used to authenticate the user on the server
when a ssh connection is setup, the ssh protocol enshures that there is no sensitive data unencrypted
server and client exchange (somehow, don't expect a book-size description here) a secret session key (using something like Diffie-Helman), which is then used to encrypt and decrypt *any* traffic in *both* directions.
You can be shure that there is never only one direction encrypted.

Featured Post

Free Tool: Port Scanner

Check which ports are open to the outside world. Helps make sure that your firewall rules are working as intended.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Here's a look at newsworthy articles and community happenings during the last month.
This article provides a convenient collection of links to Microsoft provided Security Patches for operating systems that have reached their End of Life support cycle. Included operating systems covered by this article are Windows XP,  Windows Server…
Sending a Secure fax is easy with eFax Corporate ( First, Just open a new email message.  In the To field, type your recipient's fax number You can even send a secure international fax — just include t…
The Email Laundry PDF encryption service allows companies to send confidential encrypted  emails to anybody. The PDF document can also contain attachments that are embedded in the encrypted PDF. The password is randomly generated by The Email Laundr…

717 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question