stephenwelshLong term happy customer of LimeLM.
We upgraded our TurboActivate client a few months back (from about version 3.4 to 4.0.9.6). Previously we have been able to activate behind most corporate firewalls without issue. But we recently noticed that even existing instances of our software that had previously activated online with the older TurboActivate version when upgraded could no longer activate online.
After further investigation it turns out that the customer firewalls are inserting additional corporate certificates in the HTTPS connection when attempting to activate to https://wyday.com. So internet connectivity is fine, and for one customer they managed to configure their firewall to stop this behaviour and can now activate.
Therefore we suspect that the more recent version of TurboActivate has implemented some form of certificate validation (i.e. Certificate Pinning: https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning)
We would obviously like to resolve this issue via an update to TurboActivate (i.e. a way to disable Certificate Pinning or use HTTP instead of HTTPS) as we have 1000's of installations and most of them are behind corporate firewalls within large enterprise networks. So asking the each affected customer to go through the complex task of firewall rule updates is not an option.
Can you provide some feedback and options please.
Kind Regards
Stephen Welsh
Hey Stephen,
Nope, we don't currently use certificate pinning. However, the change from 3.x to 4.x is that TurboActivate now *always* uses HTTPS, no matter what. Previously it only preferred HTTPS and only under certain circumstances (the data was still encrypted, but sometimes the encrypted blobs were sent over HTTP).
Long story short, corporations that want to man-in-the-middle connections must properly configure their employees machines to recognize the MITM cert.
stephenwelshSo our recent upgrade of TurboActivate 3.x to 4.x includes a breaking change that impacts 1000+ clients just by upgrading our product.
Is there an option/setting to disable this breaking change, or a fix/setting that can be added to ensure consistent HTTPS connectivity where HTTP did work before. We can provide Wireshark traces with the HTTPS certs.
This issue is holding back the release of our major product upgrade, what assistance/options can you provide.
Kind Regards
Stephen Welsh
Hey Stephen,
This would only be a breaking change for end-users with incorrectly configured machines. Customers that are not MITM connections would not see any problems. And customers that *are* MITM connections, but they also properly register their new "Certificate Authority" on the machines, then they won't see any problems.
The only cases where you would see problems in the new version of TurboActivate are 2 cases:
1. The customer is MITM connections, but has not properly added their "CA" (Certifcate Authority) to the machines they MITM.
2. The customer is MITM connections, *has* correctly added their CA to the machines, but they're also inserting extra junk into the request to the LimeLM servers or the responses from the LimeLM servers.
In case 2 that would fail even in the old version of TurboActivate. Case 1 is a simple fix for end-users. They should be doing it anyway -- that is, if they're MITM all connections from their employees they should be setting up their CA on the machine. If they're not doing that then that implies they disabled TLS checking altogether (which means *anyone* can MITM connections from their corporation). That is a huge security problem for that customer.
Long story short: you won't see any problems with the majority of customers. Occasionally you will see an end-user doing something unbelievably stupid (like disabling TLS verification), but those are outliers, and they should be notified of their problem so they can fix it rather than wallow in ignorance of the security vulnerabilities they opened their corporation up to.
