Why are there unsolicited network calls when installing the 1.11.1-x64 application by Windows Powershell?:
.crl.sectigo.com.
.ocsp.sectigo.com.
.crl.comodoca.com.
.ocsp.comodoca.com.
Related:
It’s windows checking whether the code signing certificate used to digitally sign the installation file is valid or has been revoked. The hostnames are stored in the certificate itself. Skymatic (manufacturer of Cryptomator) has a code signing certificate issued by Sectigo, thus Windows asks Sectigo if the certificate has been revoked.
For example, if you used winget in powershell, the package definition in Microsoft’s repostiory at https://github.com/microsoft/winget-pkgs/blob/0d1b0aa150fbc5b80c004f8834f879b1f6062b26/manifests/c/Cryptomator/Cryptomator/1.11.1/Cryptomator.Cryptomator.installer.yaml#L22C111-L22C111 points to the MSI installation file. It’s the installer file from the cryptomator repository on github that you otherwise may have executed manually (would cause the same check, in case you didn’t use winget). If you download that file, right-click > properties > digital signatures > select the signature > details > view certificate > details you can find that info in the list.
See certificate revocation lists (“crl” in the hostnames) and OCSP (“ocsp” in the hostnames).
I should clarify: why is the end user not overtly informed or provided the option to disable it beforehand? Best practices dictate such actions should be opt in rather than opt out or just assumed.
If that’s your concern, I’d suggest using a different operating system. That’s just how Windows works and it’s the same on macOS. Code signing is kind of “necessary” when distributing apps. Maybe some Linux distro suits your needs better.
There seems to be another breakdown in communication. Why is the end user not overtly inform such connections will be made?
If you would like to discuss distros feel free to post a related thread so that we may discuss what is off topic.
I’d say because it’s outside of cryptomator’s, it’s code and it’s installer’s scope. The same reason why you likely won’t ask every website using https to warn you about the same thing in which case your webbrowser handles crl/oscp checks that may or may not result in such connections depending on the browser’s, not the website’s, implementation.
Cryptomator is a solution to encrypt files in a secure manner. In case you’re trying to get at some self-imposed “threat model” you might have which leads back thinking that Cryptomator should warn about verification by the OS or allow to disable it - I’d argue it’s security theater. If you have privacy concerns over these checks performed by the OS of your choice, you can have a look at whether they can be disabled/prevented where they most likely can - in your environment under your control (e.g. hosts file, firewall, perhaps group policy). That’s not advisable, but you could, if you must.
The installer, to my knowledge, can’t give you an option to disable the verification windows performs for the installer’s own signature (neither can msiexec or winget that execute it by your command), and removing code signing is not an option due to its security impact, so there’s no way for cryptomator to provide anything like an opt-out for this.
@tobihagemann Maybe worth a note in the docs about code signing in relation to How to check installer signatures · Issue #22 · cryptomator/docs · GitHub
Thank you for your comment but it is a non sequitur; this is not a web browser. VeraCrypt, et. al., make no such calls, including its Windows version.
Cryptomator is also a software product openly advertised as “a simple tool for digital self-defense. It allows you to protect your cloud data by yourself and independently.”[1] As a ‘cloud’ is merely some one else’s server(s), transmitting a user’s IP to unknown, unauthorized third parties is highly incongruent if not outright misleading.
Veracrypt makes no such calls, the same way Cryptomator makes no such calls. It’s Windows making them. There are no “unauthorized third parties” involved, as the OS clearly is authorized establish this contact (or you didn’t tell it otherwise) and since it’s a built-in feature based on well-known mechanisms to ensure certificate status and the issuers are “authorized” to confirm if a certificate they issued is valid or not. This is known beforehand.
The following screenshot is an excerpt of a wireshark trace during the MSI install of veracrypt downloaded at https://www.veracrypt.fr/en/Downloads.html. If Windows has no cached CRL/OCSP for them, it connects to Globalsign (URLs stored in the certificates) to verify the status of Veracrypt’s code signing certificate and the issuer certificates above it in the certificate chain. If you run the installer multiple times, you may therefore not see requests every time if they’re already cached. I suppose that’s why you might be under the impression that these calls do not happen with other tools if you’ve examined it the same way for both (and maybe others). Certutil in Windows lets you view and clear the CLR and OCSP request cache if you want to learn more about it.
Screenshot of one of the 3 OCSP requests in the trace. Compare the certificate serial number - it matches the code signing cert of the installer.
I just finish rebooting after upgrading VerCrypt to 1.26.7. No network calls were made. This issue relates to Cryptomator-1.11.1-x64.exe, not the .msi.
I believe you & I are done conversing.
The .exe installer like Cryptomator-1.11.1-x64.exe bundles winfsp together with the same MSI installer available for standalone download in one file, i.e. the .msi file is embedded in it and both are signed with the same certificate.
It doesn’t matter though whether it’s MSI based or not. VeraCrypt Setup 1.26.7.exe, which doesn’t embed their MSI installer is no exception to CRL/OCSP checking. Executing it, Windows makes the requests below if the certificate revocation information isn’t already cached locally. The “extended error information” field in the signing certificate’s details may tell you when it will issue the requests the next time for the specific signing certificate.
Still you assert blindly as if I’ve ever allowed VeraCrypt to hit the wire. Still you do not grasp the fundamental issue, ‘authorised’ or otherwise.
Tell it to the credulous but don’t think for a moment it has any truck with me.
There are a few ways giving you some influence over this by blocking or disabling the checks as touched on above. In Windows, the applications have no say in disabling checks for the digital signatures on them for obvious reasons and they can’t warn you about something that happens before they’re being executed. That is why the end user is not being “overtly informed”.
Frankly speaking, it doesn’t matter if you don’t wish a connection to be established if your system is set to make it happen and executes. Linux wasn’t a bad suggestion in this regard for your fundamental issue if you can’t or don’t want to deal with this in Windows, as it likely gives you more control in this context, or rather doesn’t perform these particular verifications on its own depending on the setup and way to install the application.
Imo for Cryptomator, at best documentation could point out that the binaries and installers are digitally signed (see github link above) and that Windows may open connections because of CRL/OCSP verification - even if this information is unlikely to be of noteworthy value to the vast majority of users and has no bearing on any functionality of Cryptomator. If someone has these questions, the above is the answer.
Yet your “answer” remains demonstrably wrong.
Modern Windows applications can be installed, and are done so daily, without making remote data connections to initiate blind network traffic which broadcasts the end user’s
- Internet protocol address
- Internet service provider
- autonomous system network
- city
- region
- country
- latitude & longitude
- time zone
- date
- time
- operating system
- operating system version
- language
- etc.
to unauthorised, unknown, untrusted third parties to process for their own unstated intentions uncontrolled across international lines.
(Profile - tobihagemann - Cryptomator Community)
Imagine for a moment the sheer staggering audacity required from a mere developer of a simplified single application in a sea of similar software to seriously state to the user should scrap, to technologically tear out, their entire operating system because they expect control over their own device, their own property, for a sole and stand-alone instance. This is considered a reasonable response from them as they dangle the distraction, that red herring, it is “necessary” for the operating system in question as if said developer(s) didn’t choose to implement the installer which in turn initiates the network calls in the first place.
At no point is the end user even informed, via on screen message or otherwise, network communication is happening unbeknownst, in the background, during the install process. How is this not the digital equivalent insinuated in the scenario of being in a bar where “a stranger offers you some of his drink?”[1]
See how such “security first”[2] software developers[3] obstinately overlook how they act as if software can’t be installed without Internet connectivity. Is this entirely acceptable to a so-called co-founder? Should they be considered among the best and brightest or bottom of the barrel for their claimed industry/industries professionalism(s)?
Mere opinion means just so very little given the blind obedience implicit in one professing for faceless, multi-national corporation(s), in this case MSFT, AAPL. Such… people… are demonstrably full of it. They are spectres; ghosts of a glazed existence long happily pacified while being commercialized and commodified.
Thank you both, truly, for showcasing such perversion with your pathos instead of any practiced principles… all while Skymatic UG/GmbH, a purported B2B, encrypted/E2E, zero knowledge, SaaS provider, hides behind a vapid veneer of asserted open source code which is “constantly reviewed and thus continuously improved,”[1] trumpeted in its very premise for asserted credibility using an obsolete and inadequate audit report[4] while ignoring basic transparency guidelines. It wasn’t difficult to push past the all flash, no substance marketing.[5] After all you should… “take the security of your data into your own hands.”[6]
- Encrypt Your Data Securely in the Cloud: How You Can Further Increase Your Data Security Through Open Source, Cryptomator
- Skymatic
- Team • Skymatic
- Audit by Cure53, Cryptomator, 2017 Nov. 27
- Cryptomator Hub
- Cryptomator
Thank you, @countzero, for all your input. I found it very interesting and insightful.
@6c85jz24-brg68s51g-f I’m not sure if you’re actually onto something or just not understand how the operating system works when it comes to code signing verification. First, you mentioned that this happens with the MSI installer (at least, that’s what the topic title suggests), now you claim that the issue only exists with the EXE installer. That confuses me because both the MSI and EXE installers are code signed, as you can see in the build script: https://github.com/cryptomator/cryptomator/blob/develop/.github/workflows/win-exe.yml
I was very serious about my suggestion that you should change the operating system if you dislike how it operates. I admit that I’m making this suggestion based on the most plausible explanation of the situation. But I could be very wrong, since I haven’t actually done my research. (I’m a macOS user, but I’m very certain that Apple is no better. 
) @countzero actually did his research and showed that the VeraCrypt installer does the same. So… why shouldn’t I believe his findings, which he clearly documented with a screenshot? Thank you again, @countzero, for taking the time.
For what it’s worth, you may want to check out Cryptomator’s security target and re-evaluate your own expectations of what you thought Cryptomator’s security target was.
Can anyone show me any documentation of other software that points to this very specific Windows behavior of code signing verification? If yes, I’d like to take a look at it. How is this exclusive to Cryptomator? Or is this actually some peculiarity with the WiX Toolset, which we use to create the installer in the first place? Edit: Makes no sense because code signing is a separate step and has nothing to do with the installer creation.
You and I both know you can push unsigned builds. I’m done giving any insight into your asinine, shoddy software & organisation setup.
You’re in no position to lecture me about infosec while you again blaze that audacity. Try thinking beyond the end of your nose, boy.
QED. All that power inherent of a BSD… & you can’t do a damn thing with it unless you first get on your knees & kiss Cupertino’s ring. At least the logo is pretty, right?
via .exe.
“Research!” Is that what you call it? Sure. Why not; I’ll play along. You should believe his “findings”… as if anyone needed to pull a pcap to do so. I mentioned VeraCrypt in this fashion as I already had deep seated suspicions of what the reaction of such a thread would bring. It’s not like any of you lot can give a straight answer a question that actually matters, isn’t that right, @SailReal ? How’s Issue 63 coming along? When should I look forward to finally being able to recursively upload folders? In another 4 years perhaps? Maybe in in 2034?
No; I’m not taking another red herring. Attempting to minimize in lieu of distracting is worth nothing & I’m not the first to notice this:
If I didn’t have to interface with occasional AAPL devices I wouldn’t even be looking at this ridiculous bitrot.
Took you long enough to suggest that. No, we’re not doing that. End of discussion.