Hi list,
I'm using stunnel between two machines only, so is there a risk to reuse the server stunnel.pem on the client? (and if it's risky, why?)
JY
On Fri, 2011-02-11 23:40:10 +0100, Jean-Yves F. Barbier wrote:
Hi list,
I'm using stunnel between two machines only, so is there a risk to reuse the server stunnel.pem on the client? (and if it's risky, why?)
I wouldn't want to have our server's private key on a windows netbook of one of our sales people, but if the two machines are in a trusted environment and the file permissions are set properly, I don' see any reason why this could be a problem.
Though I think I understood the concept of PKI, I don't know the first thing about the mathematics used for asymmetric encryption -- maybe using the same key on both ends is a strange corner case I'm not aware of. I don't expect this to be the cases, but I don't know.
As far as I understood, the private key is used at session setup only (for negotiating the session key, which is newly created for each session). This is to reduce the amount of data that could be used to 'guess' the private key. If you use the same key pair on both ends, this doubles this data. However, I don't think this raises the chances of success for guessing the private key to a real-world likelihood.
If I had to set up an SSL-secured point-to-point tunnel, my first idea would be to use different key pairs on both sides (thinking of the point-to-point tunnel as a special case of multi-client tunnels), but I'm not aware of any real reason not to do so.
HTH,
Ludolf
On Sat, 12 Feb 2011 14:16:00 +0100, Ludolf Holzheid lholzheid@bihl-wiedemann.de wrote:
On Fri, 2011-02-11 23:40:10 +0100, Jean-Yves F. Barbier wrote:
Hi list,
I'm using stunnel between two machines only, so is there a risk to reuse the server stunnel.pem on the client? (and if it's risky, why?)
I wouldn't want to have our server's private key on a windows netbook of one of our sales people, but if the two machines are in a trusted environment and the file permissions are set properly, I don' see any reason why this could be a problem.
Fortunately we only use real OS :)
Though I think I understood the concept of PKI, I don't know the first thing about the mathematics used for asymmetric encryption -- maybe using the same key on both ends is a strange corner case I'm not aware of. I don't expect this to be the cases, but I don't know.
As far as I understood, the private key is used at session setup only (for negotiating the session key, which is newly created for each session). This is to reduce the amount of data that could be used to 'guess' the private key. If you use the same key pair on both ends, this doubles this data. However, I don't think this raises the chances of success for guessing the private key to a real-world likelihood.
Hmmm, so it looks like may the entropy may be higher with 2 different keys.
If I had to set up an SSL-secured point-to-point tunnel, my first idea would be to use different key pairs on both sides (thinking of the point-to-point tunnel as a special case of multi-client tunnels), but I'm not aware of any real reason not to do so.
HTH,
Thanks Ludolf, you made me reconsider and I think I'll use 2 différent keys (that was pure lazyness: on an athlonXP-2600+ a dhparam of 4096 bytes is *very* long to calculate.)
JY
On Sat, 2011-02-12 14:32:19 +0100, Jean-Yves F. Barbier wrote:
[..]
Hmmm, so it looks like may the entropy may be higher with 2 different keys.
Yes, but if this was more than a hypothetical problem, there would be a counter for uses of the key and a recommendation to use a new key after a certain number of uses. Think of how many times the web banking servers use their key ...
Don't be too concerned about that.
Ludolf
On Sun, 13 Feb 2011 22:21:10 +0100, Ludolf Holzheid lholzheid@bihl-wiedemann.de wrote:
On Sat, 2011-02-12 14:32:19 +0100, Jean-Yves F. Barbier wrote:
[..]
Hmmm, so it looks like may the entropy may be higher with 2 different keys.
Yes, but if this was more than a hypothetical problem, there would be a counter for uses of the key and a recommendation to use a new key after a certain number of uses.
For my own security, keys are rotated on a monthly basis.
Think of how many times the web banking servers use their key ...
I totally agree with this.
Don't be too concerned about that.
Yes, I am, because it is not the bank interests I protect, but mine!
The advantage of this question is it forced me to read more about openssl, and now I think I'm gonna do it by the rules: separating every parts into different files because the exercice is interesting and also because I'll soon need to configurate a larger network of clients.
However, openssl lacks *real long term* security features (why signing into sha1 instead of sha384 or sha512 when it is quite surely already broken by gov Sces?), and is also somehow suspect (remember the 1 line bug that have lasted for a looong time? After disclosure it was fixed but not a word from the team about it and not a line in the changelog too......)
What I also wouldn't like is somebody record the whole connexion and decode it several years after, once the computer farms power is high enough.
2011/2/13 Jean-Yves F. Barbier 12ukwn@gmail.com
On Sun, 13 Feb 2011 22:21:10 +0100, Ludolf Holzheid lholzheid@bihl-wiedemann.de wrote:
On Sat, 2011-02-12 14:32:19 +0100, Jean-Yves F. Barbier wrote:
[..]
Hmmm, so it looks like may the entropy may be higher with 2 different
keys.
Yes, but if this was more than a hypothetical problem, there would be a counter for uses of the key and a recommendation to use a new key after a certain number of uses.
For my own security, keys are rotated on a monthly basis.
Yes and, of course, you are sure that your random generator is better than the debian one before may 2008...
Think of how many times the web banking servers use their key ...
I totally agree with this.
Don't be too concerned about that.
Yes, I am, because it is not the bank interests I protect, but mine!
The advantage of this question is it forced me to read more about openssl, and now I think I'm gonna do it by the rules: separating every parts into different files because the exercice is interesting and also because I'll soon need to configurate a larger network of clients.
However, openssl lacks *real long term* security features (why signing into sha1 instead of sha384 or sha512 when it is quite surely already broken by gov Sces?), and is also somehow suspect (remember the 1 line bug that have lasted for a looong time? After disclosure it was fixed but not a word from the team about it and not a line in the changelog too......)
Do you REALLY think that a brute force attack is what someone would use to gain access to YOUR data ?
What I also wouldn't like is somebody record the whole connexion and decode it several years after, once the computer farms power is high enough.
ever heard of 'forward secrecy' ? ( http://en.wikipedia.org/wiki/Perfect_forward_secrecy)
On Tue, 15 Feb 2011 22:29:53 +0100, Christophe Nanteuil christophe.nanteuil@gmail.com wrote:
...
For my own security, keys are rotated on a monthly basis.
Yes and, of course, you are sure that your random generator is better than the debian one before may 2008...
This one's only used by other gpms, for openssl I use lava for years.
...
Do you REALLY think that a brute force attack is what someone would use to gain access to YOUR data ?
Depends on the (real) power you can bring up on the table; and brute force is far from being the only possible attack; AND you can't have any idea of what will happen is the near future (new algorythms, new CPU with calculation power multiplied by 1e8, for example) - in this case, attacker just have to record streams and replay them when maths/tech is ready.
It also depends on footprints you leave behind you (web, MLs, foruls, blogs, trash can, etc), as very first step of a serious attack is intelligence.
...
ever heard of 'forward secrecy' ? ( http://en.wikipedia.org/wiki/Perfect_forward_secrecy)
I didn't knew (or remember) it wear this name, but the principle is so obvious...
-
Christophe Nanteuil -
Jean-Yves F. Barbier -
Ludolf Holzheid