STUNNEL security

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!

Who is Participating?
> 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)
carillianAuthor Commented:
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?

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
Protect Your Employees from Wi-Fi Threats

As Wi-Fi growth and popularity continues to climb, not everyone understands the risks that come with connecting to public Wi-Fi or even offering Wi-Fi to employees, visitors and guests. Download the resource kit to make sure your safe wherever business takes you!

carillianAuthor Commented:

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?)

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:)
carillianAuthor Commented:
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?
>  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
carillianAuthor Commented:
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.
> 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.
carillianAuthor Commented:
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.
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.
carillianAuthor Commented:
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.

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.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.