Floating license server for TC

[Sob]

My proposal with certificates includes no standard server, nor anything in TC for communicating with one. There is nothing that someone could make public.

Currently (correct me if I'm wrong) you have licence keys with unique numbers and everyone who buys the licence gets the same type key, no matter if it's single or multi user licence. And the problem here is the multi user one, where the customer needs to have the same licence file on all his computers. And the more computers and more people using them, the bigger change that someone takes it home, then shares it with friends and later it's available to everyone. And you have no other chance than blocking the whole licence.

With certificates you would have the main one and use it to sign licences (certificates) given to customers. It's public part would be hardcoded in TC for verification purposes. Customer then could use the file directly (single licences and tiny companies where everyone can be trusted) or use it to sign sub-licences (bigger companies). There can be even multiple levels, e.g. customer key would be used to sign certificate for individual company branches and each branch could then issue certificates for its users. The licence file for end user could be simple PEM file containing the whole certificate chain (except the first one hardcoded in TC).

It does add some management effort compared to current keys (copy it once and don't ever touch it again), so the licence server seems like logical solution to make it easy again. But I think it's not the best idea. First because of theoretical possibility of public ones. And second, it's another non-standard thing to have in network. If you have network with hundered or more computers, you already have some means for central management. Rather than having each individual TC connnecting to central server, it's easier to use existing infrastructure to update the licences on end user's workstations (either file or registry value, exactly as it's now, except the format/content would be different). For admin it means writing just few scripts to manage the whole thing. Or something can be offered pre-made for standard environments.

It solves just one problem - allows each customer to define how much they want to protect their key from leaking (and later being blocked by you). Nothing more, nothing less. It does not try to implement any kind of global real-time licence enforcement controlled by you as author. Only problems I see are non-technical ones (although I might have missed some, it's not impossible ;). E.g. to clearly define that you tolerate leaked end user keys with expiration of X days and less and won't block the main customer's key in that case.

--
EDIT: Ooops, there is one major technical flaw. Anyone could simply remove the last certificate and it would work just fine. But it could be solved by requiring the last certicate to have CA attribute set to false.

[Sir_SiLvA]

i was asking few times already, how is it worse than way it is now?

Because it would waste ressources on something that wouldnt do anything at all
the devolpement of TC is a 2-man-job so its easier to set a leaked key on a blacklist and send out a new one.

[misiekt]

its easier to set a leaked key on a blacklist and send out a new one.

The fact that somethings easier to do doesn't mean its more efficient. It's just short sighted. I'd rather write script for an hour than repeat some tedious task for 10 minutes, when theres posibility I'm going to do it again in future.

Because it would waste ressources

How much resources adding simple check of defined URL can take? Few mins to put it in, and about an hour to debug and check if its working?
It's just storing key on another media after all.

Probably writing independent loader for TC from scratch, to retrieve key/run TC/delete key, would take few hours. But TC may detect loader, or check key at random, and it had to be tailored into custom installer for each release of TC. Writing loader may be fun, but using it with all maintenance drag of deployment at each TC release puts me off.

[ghisler(Author)]

i was asking few times already, how is it worse than way it is now?

Someone could put the stolen key server online and then each time a key is blocked, use a different one with it. Users could then use official releases registered by always pointing it to the same key server...

[misiekt]

Users could then use official releases registered by always pointing it to the same key server...

Thats true, but its double edged sword. Because if illegal server went down, or before admin of that server upgrade key, they dont have license even if they just want to use same old version of TC. But when they copy key, they have it forever if they are happy with current version.

Its just different kind of inconvinience, any of which is more work than clicking 1,2 or 3. Not to mention security risk of potential exploit from unknown illegal server, instead of key.

Above that its the same like someone is posting new wincmd.key always on the same public location. And if they were admins willing to host public key, and maintain that server, i dont see problem doing that now with loader i mentioned earlier.

And thats only case with most simple form from HTTP authentication with least changes involved.
If there were to be special key for multiseater and dedicated HTTP, i believe you thought about, its enough to simply generate licence for any kind of host id, working only with that machine.
It could be simple converter on ghisler.com, which generates multiseat licence based on current sold key. Automatic conversion would work only once per few months, in case if legit server hardware changed. Or just once, and then support for some time or license upgrade if licence is too old.

Besides, server can have way more limitations than TC, like periodic connection with your site, to check if its legit.

[grim]

would it help if
- TC installation with multilicence-key must be placed is specific domain?
- part of multilicence-key is server who can validate it?

[ghisler(Author)]

TC installation with multilicence-key must be placed is specific domain?

How should this limit be set? On the server? Then the server can be manipulated. On the client? Same.

part of multilicence-key is server who can validate it?

The server can be cracked to bypass this check.