Improve company productivity with a Business Account.Sign Up


STUNNEL security

Posted on 2004-08-05
Medium Priority
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
  • 8
  • 6
LVL 51

Accepted Solution

ahoffmann earned 1500 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
Building an Effective Phishing Protection Program

Join Director of Product Management Todd OBoyle on April 26th as he covers the key elements of a phishing protection program. Whether you’re an old hat at phishing education or considering starting a program -- we'll discuss critical components that should be in any program.


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

Get your problem seen by more experts

Be seen. Boost your question’s priority for more expert views and faster solutions

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.

Join & Write a Comment

This article covers an all-important comparison between Tokenization vs Encryption. Also, read about What Tokenization & Encryption is in detail. Both technologies are used for Cloud data security to prevent cyber crimes.
This article is about building a VRF-Aware site to site VPN tunnels in Cisco CSR1000V router with IOS XE. There are two VRF-Aware Policy Based IPsec VPN tunnels configured on CSR1000V router one with NAT and another without NAT.
With Secure Portal Encryption, the recipient is sent a link to their email address directing them to the email laundry delivery page. From there, the recipient will be required to enter a user name and password to enter the page. Once the recipient …
This video Micro Tutorial shows how to password-protect PDF files with free software. Many software products can do this, such as Adobe Acrobat (but not Adobe Reader), Nuance PaperPort, and Nuance Power PDF, but they are not free products. This vide…

589 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