Quote:
> I had an idea that I could "cheat" a bit and assume that if a client
> had the public key and was communicating with the RPC Listener,
> then they were also "automatically" authorized users (thus bypassing
> individual username/password authentication).
In some way you could "cheat" there a bit, if you always use
the same RPCServerAdmin (+appropriate password) within
the client-app directly (per "obfuscated strings" within the
clientside code). If the clientside Encryption-property
is compiled in with True, then - on top of that necessity - the
correct Public-Key-File would be required too for a
successful Login (not only the correct RPCServerAdmin-
account-information).
Quote:
> Of course, this would only work if I could ensure that a
> Listener could only allow encrypted connections, and
> that the public key was distributed to the client securely.
That's right - I see now, what you mean - will think about
a serverside ForceEncryption switch in an upcoming version.
But assuming we have a potential attacker, which knows
how to work with the RPCClientConnection-Class - a
successful attempt (leaving the clientside Encryption-Property
at False) would nonetheless require the knowledge about
the current RPCServerAdmin-password.
This could only be retrieved by analyzing your client-binaries.
But you are right - with a serverside ForceEncryption-Flag,
this Hurdle would be higher for such an attacker, since he
would need also the correct Public-Key-File (in addition
to the Admin-password).
But in that case (to achieve any "effect" at all) you would
need to redistribute your Public-Key-Files over a "secure
channel" - and always to the right persons whom you can
trust (that they don't give anybody a chance, to steal their
Public-Key-File).
Hmm - not sure (even with such a ForceEncryption-switch)
what a potential attacker would find more difficult, to somehow
determine the "compiled in" Admin-password - or to seize
such a current Public-Key-File from a machine of an
"lazy user" of the application.
But it would add "another hurdle" of course.
The best approach really would be (without any serverside
enhancements), if the Users would have to "type-something-
in" for a successful Login ("directly from their own mind" ;-) -
no password in no binary anywhere.
Quote:
> The problem then would be simplifying secure public key
> distribution to all clients. One way would be to manually
> copy the public key file to all clients (simple, but time
> consuming).
But probably the most secure way, especially when done
over a "non-publically-watchable-channel" (and TCP/IP
is "sniffable", E-Mails or E-MailServers are too).
Quote:
> Another would be to get the RPC server to pass the
> (encrypted) public key back to a client that provides
> a correct (encrypted) password. The client could then
> log back in with encryption enabled.
That would be an idea - anything that requires a User-
Interaction (e.g. typing in a special password to "activate"
and decrypt the new delivered, yet encrypted Public-Key)
would be good.
Quote:
> 1) Still have 2 listeners, 1 that requires authentication with a
> static password specific to my compiled application (the "credentials"
> server) and 1 that has a randomly generated password for the
> RPCServerAdmin account and only requires and only allows
> authentication on that account (the "business" server). The 2
> listeners would have 2 separate RPC DLLs folders.
> 2) If a client app doesn't have the random business server password,
> it contacts the credentials server. Once connected to the credentials
> server, it RPCs a GetCredentials() method with an encrypted request.
> The encrypted request would include a password that was set by the
> server admin so that it could be supplied to users for the purpose of
> signing in to the server. It would even be possible for admins to
> issue one-time passwords for this purpose.
> 3) The GetCredentials method validates the encrypted request, and if
> everything looks good, it encrypts and returns the business server's
> random password and public key.
> 4) The client decrypts the result, caches the public key and password,
> and then uses them to connect to the business server. The client can
> then RPC business methods.
> While this doesn't 100% guarantee that encryption will be used by
> all client apps, it makes it much less likely to forget to activate
> encryption because after going through the steps to get the business
> server connection credentials, I will likely remember to use the
> public key.
As said, you can already force encryption, if you compile it
into the client-app (there should be no check-box in the client-
GUI, which gives the user a chance, to login without encryption).
Or just automate the decision, in case you want to work without
encryption on purpose.
Quote:
> A side benefit of not always requiring encryption for the business
> listener is that I could even come up with a method to detect if the
> server is on the LAN instead of over the Internet, and then enable/
> disable encryption accordingly.
Good idea - for example the latency of very small "Ping-like"
RPCs could be a good indicator - e.g. if you measure the
shortest roundtrip-time of a series of maybe 3 calls. In a LAN
the typical response-time for "simple RPCs" is below 1msec.
A pinged Server, that is reachable over Internet would have
at least 7-10msec latency (and this is for a very fast internet-
connection with a low hop-count, normally the Web-latencies
are more in the range of 15-30msec).
Or just analyze the IP in question - shouldn't be too hard
to determine "typical LAN-IP-Sets" - or to ask a DNS -
but the Ping-version would be better IMO, since some
business-Routers (-gateways) are normally configured
in a way, that you can use the Public-Internet-IP
successfully from inside a LAN that contains this
Internet-reachable Servermachine (in case you've not
placed the Application on a server of a public hoster).
In that case (if the Router-Gateway reflects the call to
the Public-IP of its "known, also LAN-reachable" Server-
machine, the Ping-based approach would always work.
Olaf