Verifing Server
Author
Hey Guys,
I am looking to verify the server that the client is connecting to. I am trying to remove the threat of DNS/IP spoofing. I know this is a worst case situation ... but if I can give my clients (read: customers) peace of mind, that's one more point for my team [smile].
Here are a few things I want to avoid though:
A third-party (ie: Verisign)
Stored secretes in the client/server
- Eric
Verifying identity is, in general, not possible without a trusted third party (e g Verisign authority).
If you can get away with storing a secret on the server, and a public key on the client, then you can implement a protocol that uses public key cryptography, which goes something like:
- client generates cryptographically strong challenge
- server encrypts challenge using private (secret) key
- client decrypts server response using public key and verifies
The client now knows that the other end has possession of the private key. If you can avoid compromise of that key, you can "prove" that the other end is legit -- assuming that you can trust the public key that you have on disk.
In general, though, you really want to use a pre-existing, well tested, open source library to do these things, to avoid the many pitfalls that can get you, both algorithmically and in implementation. Cryptography is hard, and even a small slip-up can totally invalidate your entire scheme -- witness WEP security for 802.11, which was invalidated because (simplified) the clear text of first byte of each packet is always known.
If you can get away with storing a secret on the server, and a public key on the client, then you can implement a protocol that uses public key cryptography, which goes something like:
- client generates cryptographically strong challenge
- server encrypts challenge using private (secret) key
- client decrypts server response using public key and verifies
The client now knows that the other end has possession of the private key. If you can avoid compromise of that key, you can "prove" that the other end is legit -- assuming that you can trust the public key that you have on disk.
In general, though, you really want to use a pre-existing, well tested, open source library to do these things, to avoid the many pitfalls that can get you, both algorithmically and in implementation. Cryptography is hard, and even a small slip-up can totally invalidate your entire scheme -- witness WEP security for 802.11, which was invalidated because (simplified) the clear text of first byte of each packet is always known.
Author
Quote:Original post by hplus0603
In general, though, you really want to use a pre-existing, well tested, open source library to do these things...
Good example... what would be a proven library that does this?
I am looking for something that would be used for the initial login procedure (max 10 challanges between the two). After that, its all irrelavant data (chatting... setting up games... etc etc).
- Eric
OpenSSL comes to mind -- although you'll need to configure it with a certificate authority that's not Verisign, to comply with your stated requirements :-)
Author
Quote:Original post by hplus0603
OpenSSL comes to mind -- although you'll need to configure it with a certificate authority that's not Verisign, to comply with your stated requirements :-)
Well, I am trying to remove the third-party from the picture, because that is just another 'party' that I have to verify (and we get into a never ending recursive loop). Or is this something I should not worry about?
<paranoia>
Take for example if someone would to get in-between the client and the internet (which could be a case on a public network)... couldn't they spoof anyone, including my server and Verisign?</paranoia>
How are these problems solved?
ok, you need to log on.
This makes it a whole lot easier.
You ask for a random string.
You have your username + password.
md5 the random string ^ the md5(username ^ password).
The server has to do the same, of cource. (which is easier, since you just store the md5 of the up, and then xor it with the string you sent, before md5ing it.
The problem is, you have to do it to each and every one....
This is, assuming you want to be completely discrete from both sides...
You can speed it up a bit...
From,
Nice coder
This makes it a whole lot easier.
You ask for a random string.
You have your username + password.
md5 the random string ^ the md5(username ^ password).
The server has to do the same, of cource. (which is easier, since you just store the md5 of the up, and then xor it with the string you sent, before md5ing it.
The problem is, you have to do it to each and every one....
This is, assuming you want to be completely discrete from both sides...
You can speed it up a bit...
From,
Nice coder
Author
Quote:Original post by Nice Coder
ok, you need to log on.
This makes it a whole lot easier.
You ask for a random string.
You have your username + password.
md5 the random string ^ the md5(username ^ password).
The server has to do the same, of cource. (which is easier, since you just store the md5 of the up, and then xor it with the string you sent, before md5ing it.
The problem is, you have to do it to each and every one....
This is, assuming you want to be completely discrete from both sides...
You can speed it up a bit...
From,
Nice coder
This will not work. Lets say you have this situation:
Client<-->Hacker<-->ServerWhen the client asks for a random string... the hacker will provide it to them... and when the client re-challanges with a login user name... the hacker just decrypts and runs... while the Server is never touched (the hacker could even request the random string from the Server and re-encrypt the clients code to the Server... and proxy the challanges back with out the client/server ever knowing what was up).
Typically, you'll ship a trusted public key with the actual executable. When the server sends its signature, encrypted by the trusted private key, you can decrypt it using the trusted public key, and make sure it matches. If someone gets a copy of the private key, they can spoof server identity -- that requires a server break-in. If someone can replace the public key on the client disk, they can spoof identity -- that requires a client compromise.
Thus, assuming machines can't be compromised (hah!), you can guard against DNS/identity spoofing using public-key cryptography.
The reason a third party needs to be involved on the web is that you can't cache certificates for every site under the sun on your machine -- instead, you cache the certificate for Verisign, and whatever else your chain of trust is.
Thus, assuming machines can't be compromised (hah!), you can guard against DNS/identity spoofing using public-key cryptography.
The reason a third party needs to be involved on the web is that you can't cache certificates for every site under the sun on your machine -- instead, you cache the certificate for Verisign, and whatever else your chain of trust is.
Quote:Original post by pDK
Well, I am trying to remove the third-party from the picture, because that is just another 'party' that I have to verify (and we get into a never ending recursive loop). Or is this something I should not worry about?
I think you've largely missed the point of how verisign et al work. If you don't trust verisign, you can't use online banking, for instance - everyone else trusts them, so you should too (this is the short, easy, answer :)).
Quote:
<paranoia>
Take for example if someone would to get in-between the client and the internet (which could be a case on a public network)... couldn't they spoof anyone, including my server and Verisign?</paranoia>
No, they couldn't.
1. There is no communication with verisign involved; it (openssl etc) uses the verisign certs that were installed by your operating system! Your online banking *already* trusts your entire bank account to this, so...
2. If there WERE any comms with anyone on the net needed to check your identity, they would use the same strict encrypted routines to verify their own identity.
I think the reason to avoid Verisign is simply that getting an authenticated certificate is fairly expensive. Thus, if you can use your own certificate as CA for your own uses, you'll save money. Verisign and their delegates charge $995 for a single year certificate. Thawte "only" charges $449.
Also, if you want to support certificate revocation, you have to connect to the third party to check certificate authenticity (this connection, in turn, is of course verified using the installed root certificate).
WIth your own certificate, OpenSSL is a free solution that guarantees spoof-free communication, assuming the server and client themselves are not compromised. But if that happens, there's nothing that'll help you.
Also, if you want to support certificate revocation, you have to connect to the third party to check certificate authenticity (this connection, in turn, is of course verified using the installed root certificate).
WIth your own certificate, OpenSSL is a free solution that guarantees spoof-free communication, assuming the server and client themselves are not compromised. But if that happens, there's nothing that'll help you.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
