carillian
asked on
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!
Steve
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!
Steve
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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 http://sunsite.dk/info/guides/rsync/rsync-mirroring.html
AFAIK ssh requires a login, not shure if you can workaround using sudo.
But have a look at http://sunsite.dk/info/guides/rsync/rsync-mirroring.html
ASKER
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?)
thanks
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:)
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:)
ASKER
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?
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
no, the other way arround: encrypt with otherone's public key and then decrypt with corresponding private key
ASKER
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;
--------------------------
USING PUBLIC KEY CRYPTOGRAPHY FOR AUTHENTICATION
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-priva
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.
--------------------------
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;
--------------------------
USING PUBLIC KEY CRYPTOGRAPHY FOR AUTHENTICATION
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-priva
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.
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.
ASKER
Okay, the document was found here,
http://developer.netscape.com/tech/security/ssl/howitworks.html
and this website says it as well,
http://www.wi-fiplanet.com/tutorials/article.php/1572421
Quote -
The sending station can encrypt data using the private key, and the receiving station decrypts the data using the public key.
http://developer.netscape.com/tech/security/ssl/howitworks.html
and this website says it as well,
http://www.wi-fiplanet.com/tutorials/article.php/1572421
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.
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.
ASKER
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.
Thanks
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.
Thanks
no.
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.
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.
ASKER
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?