Hi, I tend to agree at this point that discussing the merits of the claims might be superfluous, because the conduct of the CA's representative is a more urgent issue, but I figured that it would be easy enough to verify how the Msgsafe product works. 1. I visited the MsgSafe home page, which at the time of this email claims "*MsgSafe.io cannot read your email*". 2. I signed up for a free account, specifying a recovery email address. I selected a strong password. 3. During the setup process, I was shown a pair of hex strings of 40 characters each (implying a 160-bit value, the length of a SHA-1 hash) described as S/MIME and GPG fingerprints. I was not prompted to download, upload, or generate any key or secret. 4. A webmail loaded in the browser. I could not find any encryption-related setting having a cursory look through the menus. I might have missed it. I continued with the default setup. (There was an option to forward emails to a different address, optionally encrypted. As I understand it, this involves plaintext arriving on MsgSafe's servers, and then encryption for the forwarding leg.) 5. I sent an email from my regular mailbox to my new MsgSafe address. It appeared in the mailbox. 6. I logged out and closed the browser window, and then opened a fresh "incognito" browser window, which shares no local state with the previous session. 7. I opened the MsgSafe home page, selected Login, then Need Help?, then Reset Password, and typed my username. 8. I received an email at my recovery address. I clicked the link, typed the username again, and a *new* password. 9. I was returned to the login page. I logged in with my username and *new* password. 10. My inbox loaded, showing the email I had sent before resetting the password. A few screenshots collected in the process at https://imgur.com/a/RzsFxoL.
The fact that I could reset my password and access the email archive by only proving control over my recovery address, without providing any secret value, necessarily means that *MsgSafe can decrypt and read my email archive, which contradicts the home page claim*. (This is sometimes referred to as the mud puddle test.) Secure email is a hard product to provide, for many reasons, and products fall on a spectrum in terms of what security properties they provide. We could debate where the line is for what can be honestly described as end-to-end encrypted. As far as I can tell, MsgSafe falls close to a regular mailbox on that spectrum. Regards, Filippo P.S. The signup flow offered me the option to choose what domain I wanted for my address. Amongst the options were @yahooweb.co, @outlookpro.net, and @reddithub.com. The full list is at https://gist.github.com/FiloSottile/cc5c706a78a06a88081cc1e9620ce6fd. 2022-11-29 19:09 GMT+01:00 Rachel McPherson <[email protected]>: > 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 >> <http://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 <http://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 <http://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 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 >> <http://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 *possible*that 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 > > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/C9BAD50B-A066-4749-9734-E7299AEDEBE5%40trustcor.ca?utm_medium=email&utm_source=footer>. > > > *Attachments:* > * signature.asc -- 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/afb893f8-61e1-4fe9-b28a-1cb0bcb8bd49%40app.fastmail.com.
