I've been contemplating ways to control client access to my
dhRichclient3 CRpcListeners. I would like to make this process as
simple as possible for both server admins and client users.

        1) Can't rely on domain authentication, since not all servers will be
on a domain. My understanding is that "ForceAuthentication" parameter
of the CRpcListener object uses domain authentication only. I may be
wrong that domain authentication is required for ForceAuthentication,
but I would like to avoid asking users for their username & password
if possible. I would like IT/admins to be able to set a server
password and that can be shared by multiple users.

        2) I could do my own user management. I already have a SessionID
system to keep track of licensed users. Connected clients periodically
ping the server with their session ID, and get disconnected if the
session ID isn't alive on the server. This has limitations in regard
to authentication.

                - Anyone can get a SessionID from any of my server apps if they know
the Host/Port just by using my client app. What I mean is, since no
user-level authentication is happening, if 2 different companies use
my server software, then clients from both of those companies could
access both servers anytime.

                - I can code around this by requiring a password (set on each
server) in order to get a SessionID from the server (not a big deal).

                - Obeying the result from the server that the SessionID has expired
is up to the client app. This is fine for my apps (as I can code for
this), but it opens a security hole if someone decides to code an app
that ignores the SessionID expired result.

                - I can code around this security hole by adding a SessionID
parameter to every public sub/function in all of my RPC DLLs. These
subs/functions would have to verify the Session ID on every call. This
could be a lot of extra work and possibly a source of performance
issues, depending on how often subs/functions are called.

           So this is a possible approach, but it seems to me that it
requires more work than it could if there was a way to either:

        1) Add users to the RPCListener (in the way that there is the
RPCServerAdmin user, but we could also add our own). This way access
is controlled once (at connection time), OR

        2) Have a way to ForceEncryption for the listener. If this were
possible, we could:

                1) Have one encrypted and one non-encrypted listener, each with its
own RPC DLL folder (as defined by the RPCDllsFolder parameter of the
StartServer function of the CRpcListener object).

                2) Clients without the correct public key for the encrypted listener
could not connect to the encrypted listener.

                3) Any client could connect to the unencrypted listener and have
access to a single RPC DLL with a method called (for example)
GetServerPublicKey.

                4) The GetServerPublicKey method would require an encrypted password
that would be unique to a particular server installation. If the
correct password is received, the public key would be passed to the
client. Once the client has the public key, they could then re-attempt
connect to the encrypted server and have access to all of the RPC
Dlls.

        The benefits would be (in particular for a ForceEncryption
parameter):

        1) Would only require a single password for server admins to give out
to clients to get on the system (although it would be easy enough to
have a system with multiple passwords to allow for revoking access
from specific clients).

        2)  Wouldn't require passing SessionIDs too all RPC subs/functions,
and require those subs/functions to validate SessionIDs.

        3) A side benefit of a ForceEncryption parameter is that it would
make sure we have always coded for security (and haven't accidentally
left out an .Encryption = True call in one of our client apps).

        Unfortunately, I don't think that there is presently a way to force
encryption server-side, since it appears that the Encryption property
gets set client-side and the Listener will accept connections either
way. Am I correct about this, and if so, is there any chance of such a
parameter being added?

        Or is there a better way to go about this? Thanks in advance for any
ideas and help.

The existing ForceAuthentication-switch already does
what you want IMO.

As soon as you set this to 1 (or True) in the RPCServer.ini,
nobody can log in anymore as long as two conditions are met:

1. The clientside RPCConnection-Object needs an enabled
    Boolean-Switch: RPCConn.ServerAuthentication = True
    (leaving that at False, no matter if UserName/Password is
     provided or not, the connection is immediately disconnected).

2. A valid UserName/Password-combination
    - This can either be the RPCServerAdmin-Account, which
      works independently from serverside defined Win-Accounts,
      the UserName of this account always has to be:
      "RPCServerAdmin" - the default-password is "default"

    - Additionally, by default *any* known Windows-Account
      at the serverside is valid for a successful Login (be it normally
      defined, local non-Domain-Accounts, or full Domain-Accounts.
      So, if you want to restrict that to only a Windows-UserGroup,
      you will have to define the appropriate RPCServer.ini-member:
      AllowedGroup = Administrators
      or
      AllowedGroup = MyRPCUsers
      If you don't want to allow *any* Windows-Authentication, just
      define:
      AllowedGroup = None

So, if you want to prevent any un-authenticated login, you need
to enable:
ForceAuthentication=1
And if you want only *one* valid UserName/Password-pair,
which is able to do a successful Login (programmatically),
then set additionally:
AllowedGroup = None
This way any known WinAccounts at the serverside are not
valid for any authentication-attempt - the only remaining
valid Account is the RPCServerAdmin.

Up to this point, we talked only about Authentication, not
about Encryption, which is working additionally (on top
of the Auth-Process).

On the other hand - if you set the clientside Encryption-
switch to True, then this expects (forces) also the
clientside Authentication-switch.

That means, you can do Authentication with or without
Encryption - but no Encryption without Authentication.

HTH for the moment.

Olaf

Hi Olaf,

Thank you very much for your prompt and informative reply.

I guess that what I wanted to do was:

1) simplify public key distribution to clients,
2) ensure that client connections are using encryption, and
3) ensure that only authorized clients were allowed access to connect
to the server and call RPC subs/functions.

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).  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.

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). 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.

Thanks to your advice, I think I can actually do this in a slightly
different way:

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.

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.

Thanks again for your help and clarifications.

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).

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.

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).

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.

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.

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

So this seems to be working now as expected - if the connection
attempt to the business server fails (bad password or public key),
then my app decides to try to connect to the open (no password or
encryption) credentials server. It then requests the password
(randomly set) and public key of the business server (in an encrypted
byte array that holds a hash of the user-defined server password and
the GMT date and time of the request (to prevent replay attacks)). If
the password & date look good, then the credentials server returns an
encrypted byte array containing the randomly generated business server
password and public key. The client app will then try to connect to
the business server with those credentials.

The only problem that I just thought of with this approach is that I
believe the RPCPublicKey.dh file must be in the same folder as the
dhRichclient3.dll. Since I am currently installing to Program Files,
limited user accounts won't be able to write the download public key
file to that folder (at least on Vista+). Do you think it would make
sense to be able to set the public key as a byte array property of the
cRPCConnection class? This way we could also store the public key in
an encrypted file on the file system, decrypt it at runtime and then
set the property in code. This would also help with the problem of
attackers potentially scouring the FS for an unencrypted public key.

I do think that the odds of an attacker with knowledge of dhRichClient
classes, my application and who to attack (my client base) would be an
extremely rare creature indeed. Maybe I am just being paranoid ;)

I suppose that the only good news about a successful attack either
way, is that one of them wouldn't be my fault :)

I completely agree. I've mostly been experimenting with some ideas to
streamline the connection process, but there is no doubt that strong
passwords that aren't stored anywhere is the most secure way to go.

This is an interesting approach, and I never would have thought of it.
I will give this a try, and thanks a lot for the idea.

I was initially thinking that I could put a function in my unencrypted
RPC dll that would return a boolean set accordingly to whether the
remote callee's IP address was on the same subnet as the IP address of
the listener class. If TRUE, then encryption would be disabled, and if
FALSE then it would be enabled. What I don't know is if there is a way
for an RPC class to know the IP address of the remote callee...Is this
information anywhere in the thread collection perhaps? Or anywhere
else accessible to an RPC DLL?

To be honest, I don't know if that idea would be suitable anyway - I'm
showing limitations in my knowledge here, but I *think* that being on
two different subnets doesn't necessarily mean that you are
communicating over public WAN/Internet (although the worst case
scenario here is that the connection gets encrypted when it doesn't
need to be, so that's not a terrible result). In any case, perhaps
your PING approach is the best one anyway - it certainly would be the
easiest to implement, and sounds foolproof.

Thanks again for your help Olaf.
Jason

Ok, nice "dynamic approach" so far, since you change both from
time to time, the password - and also the RPC-KeyPair (which is
mainly there, to prevent Man-In-The-Middle-Attacks).
But also when you would only change the Password (by a
dynamically generated password-suffix, distributing only the changed
suffix to the clients from your credential-server) you could get a nice
"extra-security" - and that without the hazzle, to deliver the
randomly changed PublicKey-Infos to the clients.

Ah yes - that's another one on my todo-list (for COM-interface-
enhancements for the new version-4) - to offer a separate Property
for the PublicKey-Setting in the cRPCConnection-Class.
You're right, currently it expects the appropriate File in the
Path (beside the Dll) - but that's not satisfying of course -
especially on new deployment-targets (Vista+).

What I could offer *now* is, to compile a new version, which
would allow a dynamic override of the internally hold PublicKey-
Variable over the already existing Password-Property - meaning
your code would look like that then:
RPCConn.Encryption = True 'enables Encryption
RPCConn.PassWord = YourPasswordString & _
           ":$Pub_Key$:" & YourCurrentPubKeyContent

So, if a given Password-String contains ":$Pub_Key$:"
I would just Split on that "delimiter" and set the PubKey
dynamically (internally).
This way I would not have to change the interface-def
and had no risk to brake BinComp on dhRichClient3.

Let me know, what you think about that workaround -
or if the above mentioned alternative idea (to change
only a Password-Suffix) would be sufficient.

;-)

The only "responsibility" one could blame you for, would
be - that you somehow "increased" the "attack-surface"
by compiling in a hardwired password

[Ping-RoundTrip-times]

Since you want to switch that mode (encrypted access or not)
at the clientside, you could just get the ServerIP from the
RPCConnection.Host Property.
In case this is not set to an IP-String, but a ServerHostName -
you can resolve that Name to an IP-String with one of the
TCP-Classes of the RichClient:

Dim TCPClient as cTCPClient
Set TCPClient = new cTCPClient
IPString = TCPClient.GetIP(ServerHostName)

and at this occassion you could determine the local
Client-IP too:
ClientIPString = TCPClient("") '<-- note the empty-string

this would give you two parsable IP-Strings at the
clientside, to determine a matching common subnet
directly at the clientside, before any RPC-connection-
attempt is made.

Olaf

While dreaming about future version key management possibilities,
would it be possible to work from the other direction? What I mean by
this, is that at *client* install time, we can generate a key pair. It
would then be possible for the client to submit its public key to the
server (RPC) at which point a server admin could decide whether or not
to add it to a collection of authorized keys (or this could be
automated with a strong password that could even be unique to a user
and valid for a single use for more security). This would also allow
admins to revoke a single key if they no longer want a particular
client to have access. Don't know if this is possible or not, I'm just
thinking out loud ;)

That would be very helpful indeed, and I would be very grateful if
such a feature could be added.

Thanks for this idea as well! I'm still trying to decide which way to
go, but I appreciate all of your help.
Jason

Possible yes, but I wouldn't want to go there, since the
PublicKey/PrivateKey mechanism is normally thought
to *not* be initiated (the creation-process) at the
clientside (on each Client-machine) in an "automated fashion".
These Keys are always created as pairs - and the
Private-Part of such a Pair shouldn't be "seen" (or known)
anywhere other than on the server-host.

Only the PublicKey-Part of the pair should be distributed
to the clients in question (preferrably on an "as secure
as possible channel").

[dynamic PubKey-Passing as a suffix to a Password]

Ok, done ... please download the updated Bin-package
(now at version 3.20) again from www.thecommon.net/3.html

Usage:
Load the ByteArraycontent of the serverside-created
*Public* Keyfile and transfer it to the clientside per RPC.
Please ensure, that the ReadOut of the serverside Public-
File really is done using Binary-Filemode, reading the
contents into an correctly sized ByteArray directly (please
don't involve Strings/StringConversions for the Content-
Readout, to not mess the Byte-content up).

At the clientside this ByteArray-Content should be passed
into the RPCConnection this way then:

'the order of the Property-Filling is important, ensure that the:
RPCConn.Encryption = True
'...is called before setting the Password-Prop
RPCConn.Password = "ThePassword" & _
                ":$Pub_Key$:" & _
                CStr(ByteArray_of_NewPubKeyContent)

The ordering of the Property-Filling is needed, because
whilst setting RPCConn.Encryption = True, the internal
implemenation of the Encryption-Prop is reading the
Content of the (furthermore required, but later on ignored)
File 'RPCPublicKey.dh' - and I don't want to change
anything in that behaviour, to not break existing RPC-Apps.

Setting the Password-Prop after that ensures, that the (just read)
"older" PK-content is replaced with the "new given one".

Olaf

First off, thanks a lot for adding the possibility to use the server's
public key in the Password property.

I wasn't trying to suggest that private keys ever leave the computer
on which they were created, just that it might be useful for the
client to generate its own key pairs and send out its public key to
the server. The server could use that for a form of authentication
(much in the way that SSH or Git allows me to add public keys to their
authorized keys files). Sorry for not explaining this clearer!

This seems to be working well, as long as the client has a public key
file already (just a warning for anyone else trying this!). Otherwise,
the RPCConn.Encryption = True call raises and error. You can trap the
error, but then I'm not sure if the byte array public key gets used/
encryption gets enabled because the .Encryption property returns False
even though the public key is accepted inside the Password property.
So it seems you must include any old public key in the same folder as
the dhRichclient3.dll folder in order for everything to work smoothly.

Thanks again for adding this feature!
Jason