I hate to say this Serge, and please correct me if Im wrong, but it honestly seems as though your focus is ever-changing based on any information you're given, where you see an opportunity to adapt it to form a consensus that best serves your narrative, due to your bias against us. I can't help to think this based on your last post, especially since you've now taken the approach of coming at me personally, further validation to anyone reading this forum that everything you've claimed in this dog and pony show stems from personal speculation and nothing more. I believe going forward, its only right for you to preface your messages with "in my opinion" because that's all that's here.
I will continue to support this exercise of good faith and transparency, by
responding in-line to your post below, even though I no longer agree with your
methods and tactics, because I believe its only fair that we set the record
straight, even though you continue to make out-of-context statements.
At the point of its founding (though not currently), TrustCor shared the same
corporate ownership with Measurement Systems,
This is not correct. A "shareholder" (of a "shareholder" or of a "holding
company who is a shareholder") is not the same as an "owner". Please refer back
to my many previous posts on this subject.
a shell corporation created to distribute mobile spyware under the guise of
ad-free app monetization. Measurement Systems is connected to Packet Forensics
(a dba of Vostrom).
Is this a fact that those two companies are connected to one another? I don't
think it’s fair or necessary to make claims about other companies on this
forum. Especially since the only actual association I can find is the one made
by you and your partner. If that's what you're referring to, it’s important to
let the public know that these are only your assumptions and not based on
facts. Then, you leave room for yourself using terms like "connected to" since
you know you can’t factually define any relationship. I guess I’m connected to
you also, by that reasoning.
TrustCor appears to use the same Phoenix datacenter as Vostrom:
https://inflect.com/as/262933
https://inflect.com/search?networks=VOSTROM
This only shows what networks are connected to who and if you look closely
you’ll see dozens or hundreds of connected networks for both these companies
through adjacencies and multiple Internet exchanges. We’re connected to lots of
people through exchanges and it’s no surprise other companies are too.
If this is true that one of our data centers happens to be in the same campus
as one of another company’s data centers, then it should come as no surprise,
and hardly a coincidence, that TrustCor uses a large and popular SOC-2
compliant datacenter operator. In fact, we know of many other CAs that use that
same datacenter as well. Which by the way is only one of our datacenter
locations.
A rogue developer, hired by TrustCor as a contractor to build the MsgSafe
mobile app, embedded Measurement Systems' spyware SDK. This rogue developer had
access to the only unobfuscated version of the SDK that we have seen in the
wild.
We have explained all of this in detail in our previous posts but you seem to
only pull out the content that benefits your narrative. It’s important to note
that the developer was hired by MsgSafe and never had access to any of the
infrastructure used for TrustCor's Certificate Authority. But I encourage
readers to look at the more detailed explanation of this to see just how far
off this is from something noteworthy.
Finding out that someone on your staff went against company policies and
practices and developer's agreements is very upsetting. We'd like to hope that
this wasn't done maliciously by that ex-developer, but I don't think we will
ever know for sure. Instead, all we can do is verify that no further damage was
done - which it wasn't and put additional measures in place to make sure this
type of behaviour does not happen again - which we have.
This version of the SDK was customized to send sensitive user data to a MsgSafe
hostname. This same rogue developer set up a proxy to receive data sent by the
SDK and then forward it on somewhere else. This involved compromising one or
more machines owned by TrustCor. This compromise went undetected by
TrustCor/MsgSafe for 3+ years.
This is not correct. Once again, TrustCor and MsgSafe.io perform their business
functions completely independent of each other. The only machines and network
that this developer had access to were solely used by MsgSafe.io and strictly
for the development of the beta (testing) app. To mistake either of these
things the way you wrote them above makes it seem that you’ve either not
read/understood our previous replies, or you’re intentionally misleading people
reading this.
Since we've made it clear that TrustCor and MsgSafe.io have no shared
resources, I'm not sure how this is even still relevant to the Certificate
Authority side of our business? In addition, this was not "ongoing" for over 3
years like you speculated, this happened over 3 years ago.
MsgSafe offered this app (with the malware SDK) to the public via the Google
Play store as part of a public beta, where it was free for anyone to download
up until earlier this year. MsgSafe publicized its mobile app on social media.
As of this writing, MsgSafe's website still links to the Google Play store
(though the app was removed earlier this year):
This is not correct. The MsgSafe.io beta app was actually a testing beta, which
could not be accessed by anyone via the Google Play store. The only way the app
was accessible was to our employees or via a unique social media link
MsgSafe.io sent out over 3 years ago, and that link only worked for a limited
time. Using that unique social media link, we can tell that less than 1/10th of
1% of MsgSafe.io's users would have had the opportunity to download to test the
app, and the actual number that installed it was much lower. Also, your
statement about the MsgSafe.io website still linking to the Google play store
is completely false. Did you even check this before making this post? In the
screen-shot you shared, the icon labeled "Download on Google Play" does not
direct you to the Google play store, it directs you to
https://www.msgsafe.io/android <https://www.msgsafe.io/android> which actually
takes you to a 404 page on the MsgSafe.io website - it never leaves the
MsgSafe.io website. Had you hovered over this link you would have seen this. Of
course we're not proud of an outdated website and this should be updated, but
that doesn’t make your false claim true.
Despite advertising "end-to-end encrypted email" (see above screenshot, taken
today), MsgSafe does not actually provide end-to-end encryption (E2EE), as the
term is commonly understood. Instead, encryption/decryption is performed by
MsgSafe's servers, giving them the ability to read email contents. (As
background, the FTC went after Zoom for deceptively claiming it offered E2EE,
when it didn't.)
As we have stated before, there are many possible ways to use the MsgSafe.io
platform, one of which is for a user to upload their own public keys and
encrypt using both S/MIME and GPG, or only GPG, or only S/MIME. Since there is
a way to use the MsgSafe.io product that allows for end-to-end encrypted email,
there is no false claim or deception here. Also, if you read the text under the
E2EE heading you’ll see it accurately describes a definition of what you’re
complaining about, again making it not a false claim. You may not agree with
the definition or like it, but we say exactly what it does. We also let the
user configure strong default settings. And even if the user doesn’t configure
stronger settings, the settings are still as capable as other popular email
encryption solutions regardless of what they’re called, and MsgSafe.io's
competitors use similar language on their websites.
Besides its MsgSage business, TrustCor primarily issues certificates for No-IP
customers via some sort of partnership arrangement. While it's been assumed (I
think, unless I'm misreading?) that No-IP is TrustCor's primary customer, no
evidence has been offered that they're actually a customer. That is, does No-IP
pay TrustCor to give away their certificates for free? Or does TrustCor pay
No-IP? I'm not sure this has been answered.
We have answered every question the public has asked. I’ll assume this is your
odd way of adding a new question about what is our relationship with our
customers. I can tell you that all our resellers are on pre-paid plans whereby
they pre-pay to obtain a bulk volume of credit (the more they buy the less they
pay each) for which they can then use and charge (within reasonable limits)
whatever they like and use whatever business mechanisms they like. Some
customers, for example, choose to bundle short-timeframe (less than a year)
certificates with some levels of their products, and also sell full-timeframe
(about a year) certificates for premium $. That’s between them and their
customers and how they choose to market whereas our relationship with them (in
order for them to qualify as a reseller) is already been satisfied when they
place bulk volume pre-paid orders.
In 2010, Packet Forensics was marketing its ability to subvert TLS. It was
assumed they were forging certificates, but beyond that, the specifics have
been cause for speculation.
How is this at all relevant to us? We don't have any relationship to that
company, nor am I willing to comment on any speculations you have against any
company.
Based on that understanding (and again, please let me know if any of that is
incorrect), I personally believe it's possiblethat Rachel may be a victim here,
if she really is the primary TrustCor shareholder (e.g., maybe the company was
given to employees, after it was no longer useful). If TrustCor's private keys
were compromised at its founding or before (e.g., so that Packet Forensics
could sell TLS-interception boxes), the company itself would have little
continued value, so long as it passed its audits (and remained trusted by
browsers and operating systems). It's therefore possible that Rachel had no
awareness of this, and as a result is in the denial phase of realizing that
she's the victim of a scam. This is not a statement of fact, I'm just offering
it as a possibility.
To now theorize and publicly suggest that "I am in a denial phase of realizing
that I am a victim of a scam" is disrespectful and outlandish. I think you're
taking this too far by making claims against me personally and I don't think
its a good representation of your professionalism. You've forced us to be in a
position to defend our company, but putting me in a position to have to defend
myself personally is crossing the line. Would you have made the same assumption
if I were a man?
For the record, I have been with TrustCor since its inception and have
personally bared witness to the initialization and installation of the hardware
baring TrustCor's roots and private keys and can absolutely vouch for the safe
handling of TrustCor's keys and credentials at all times.
Making up storylines without any merit, just because there might be a
far-fetched possibility is just wrong.
TrustCor has always committed to follow industry trends and provide a level of
security, in most cases greater than the baseline requirements to make the
community feel comfortable with our operations. I realize that the information
we have provided in great detail in our previous posts, may be a turnoff to
most because its difficult to read, but we have done everything within reason
and provided as much information as we can to help dissipate and explain any of
these concerns. I'm sorry that our responses don't help to support your claims
against us, but abandoning facts and adopting bias is not right. Maybe you’re
human and you just overreached on anything that could be connected. Maybe
that’s healthy for a security specialist. But like you said, "This is not a
statement of fact, I'm just offering it as a possibility."
- Rachel
Rachel McPherson
VP of Operations
https://www.trustcor.com
[email protected]
+1 (289) 408-9998
--
You received this message because you are subscribed to the Google Groups
"[email protected]" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/C9BAD50B-A066-4749-9734-E7299AEDEBE5%40trustcor.ca.
signature.asc
Description: Message signed with OpenPGP
