DSHub towards ADC Secure

[Pietry]

After a long await, here it comes, DSHub ADCS extensions is almost complete. The next release will have it. While working on ADCS my plans changed a lot about the "look and feel " of this feature in DSHub. What I mean is that I tried to have DSHub more user-friendly, and not make ADCS some obscure setting in some obscure file that nobody finds or it looks like it's very well hidden.

As a result, I modified the main GUI page ( the footer of the page, the one that remains fixed during tab navigation ) to show the current status of the ADCS settings. If ADCS is disabled, a red exclamation warning message is shown. Why ? Because in the future, my guess is that all hubs will be running ADCS, and plain ADC will be something more rare than a monkey in a mall. After ADCS is enabled, a green check icon shows that you are secured (at least in some way, I guess...).

If the user clicks the status text or icon, an information message is displayed on what ADCS is about and how it can be enabled. Although there is nothing "wrong" about running your hub in plain ADC, I've chosen this way of representation to encourage ADCS.

The new ADCS tab is a simple step-by-step tutorial on how to enable ADCS on your hub. In a first step , after some explanations and setting up, you get to choose between creating new keys and certificate for your hub or loading old ones ( Toast wanted an option to load them in an universal format , so that third parties may create them... this has to be considered for the future; currently dshub uses java KeyStore format ). After one of this options is chosen, the user may opt to use certificate based logins only ( instead of passwords ) , which is not functional yet . Finally , the user has only to click Enable to restart the hub in secure mode. This tab is also a simple way to enable/disable ADCS at any convenient moment.

The adcs command that is available to a registered user is also a way of configuring your ADC secure hub. Although it has significantly less information about the phenomena, it does basically the same thing. My idea is that a new user will use the GUI first and after that the command. This means that he already has some knowledge about it.

I want to thank people that helped in creating this extension for DSHub, among them is Cyb which helped in fixing an error that was killing me ( he was unsuccessful, but he is worth thanking ), also all my betatesters and people using DSHub

Attached some screenshots with the GUI changes.



Ah, and not to forget I want some feedback about it before the release, maybe comments and ideas. You can get the current svn with a checkout from here

[Pietry]

Since nobody commented i just assume everything is fine and i'm going for a release

[Toast]

Jupp, i havent found anything yet so go for rls

[Cobra]

I want to make sure I understand the difference between ADC and ADCS.

With ADC a password is still not required and login is based on the CID
With ADCS adds the need for the client to possess a certificate signed by the hub.
Both could be set to require being registered.

Do I understand correctly that the only added feature is the certificate requirement?

What is the best process for distributing these certificates? It seems the users will have had to already been on the hub in order to issue the certificate? Is there a way to create them prior in order to avoid allowing not certified users to ever get on in the 1st place?

[Pietry]

With ADC a password is still not required and login is based on the CID

not accurate, dshub lets users in without a password but that doesn't mean ADC requires that. Other hubsofts may require a password at all times.

With ADCS adds the need for the client to possess a certificate signed by the hub.

That's not accurate as well. ADCS means that ADC is running over the SSL/TLS layer. That means that over your TCP/IP connection the messages will be encrypted and decrypted by this layer, and ADC is the same, but running above it. About the certificate signed by the hub part, the ADCS specification does not say anything ( not finished yet anyway ). My initial idea is that user's certificates to be signed by the hub, and i want to see if this system works on DSHub ( not implemented yet ). So actually ADCS means encryption for now.

Both could be set to require being registered.

Well, what's the point in making a certificate for a non registered user ? Make the certificate based on what, since the user is totally anonymous ? ( And no idea who that user is or how to identify it )

Do I understand correctly that the only added feature is the certificate requirement?

No, a set of keys both public and private are used, an encryption algorithm etc so the traffic will be encrypted

What is the best process for distributing these certificates?

No idea, i was still thinking about it.

It seems the users will have had to already been on the hub in order to issue the certificate?

No, but the hub owner who generates the certificate should at least know the user's CID and public key.

Is there a way to create them prior in order to avoid allowing not certified users to ever get on in the 1st place?

After you will create the account in dshub, this will be possible for the specified registered user ( at least my idea for now ... )

[Cobra]

Thanks Pietry, great response

I'm sorry I'm having a hard time grasping this completely
to clarify I understand there is 2 levels of security

ADC does not have encryption between client and hub
ADCS does

and if it gets implemented

ADC does not use certificates
ADCS can but is optional

Would it be possible to create a 'private' group certificate vs client by client

[Pietry]

Hmm, a certificate is actually a public key signed by some issuer. So every client has it's own public key so that means every client must have a different certificate. So I don't think the certificate group is possible...

ADC is not exactly a level of security, ADC is a protocol. It has some security points yes too.
ADCS is the same ADC , only that it runs encrypted and/or with usage of certificates