Ask Slashdot: What To Do When Your Certificate Authority Suddenly Revokes Your Cert? 180
Long-time Slashdot reader rastos1 works for a mid-size software company that for many decades has been developing CAD-CAM software for the textile industry. But last weekend their code-signing certificate was revoked -- and they're looking for advice.
On Monday morning we woke up to phones ringing from confused customers unable to launch our software. This has hit mostly Java applications launched from a web page because JRE checks the signature by default using OCSP. But traditional executables and shared libraries also would report invalid signature upon checking.
We reached out, but for half a day we could not get any feedback. Later we got information that some malware was signed with our certificate. Two days and many e-mails and phone calls later, we understand that this is what happened: someone submitted one of our executables to virustotal.com -- a site that runs ~70 antivirus programs on submitted files and reports back whether they flag the uploaded file. Five of their antivirus packages flagged our executable. We tracked down the version and we positively know it was a false positive. There is random guy that wrote a tool that creates a monthly report of files flagged at Virustotal. Sectigo found the report, and, according to their statement, revoked all certificates used to sign executables -- causing major disruption to us and downtime for our customers... There was no attempt to contact us and clarify the situation.
How do you prepare and deal with such scenario? Did you know how little it takes to get your certificate revoked?
They'd bought their certs from the same seller for more than a decade -- and their story has already drawn some interesting comments from long-time Slashdot readers. "False positives are way too common in the anti-virus world today..." argues Z00L00K, adding "you have to cut down all unnecessary players in the chain to a minimum, so the dependency on an external CA is worth reconsidering."
sjames -- Slashdot reader #1,099 -- agrees. "If you must depend on another entity, make sure they're small enough that they would actually care if they lost you as a customer." And Martin S. simply recommends talking to a lawyer, adding "This is a legal problem, not a technology problem."
But what's your advice? Leave your best thoughts in the comments. What should you do when your certificate authority suddenly revokes your cert?
We reached out, but for half a day we could not get any feedback. Later we got information that some malware was signed with our certificate. Two days and many e-mails and phone calls later, we understand that this is what happened: someone submitted one of our executables to virustotal.com -- a site that runs ~70 antivirus programs on submitted files and reports back whether they flag the uploaded file. Five of their antivirus packages flagged our executable. We tracked down the version and we positively know it was a false positive. There is random guy that wrote a tool that creates a monthly report of files flagged at Virustotal. Sectigo found the report, and, according to their statement, revoked all certificates used to sign executables -- causing major disruption to us and downtime for our customers... There was no attempt to contact us and clarify the situation.
How do you prepare and deal with such scenario? Did you know how little it takes to get your certificate revoked?
They'd bought their certs from the same seller for more than a decade -- and their story has already drawn some interesting comments from long-time Slashdot readers. "False positives are way too common in the anti-virus world today..." argues Z00L00K, adding "you have to cut down all unnecessary players in the chain to a minimum, so the dependency on an external CA is worth reconsidering."
sjames -- Slashdot reader #1,099 -- agrees. "If you must depend on another entity, make sure they're small enough that they would actually care if they lost you as a customer." And Martin S. simply recommends talking to a lawyer, adding "This is a legal problem, not a technology problem."
But what's your advice? Leave your best thoughts in the comments. What should you do when your certificate authority suddenly revokes your cert?
Self-sign (Score:3)
EOM
Re: (Score:2)
Na, just get one from a different certificate authority, duh!
Re:Self-sign (Score:5, Informative)
Just fricking install the new cert on your https server and resign everything with your new cert. Next time your users launch the application, customer JRE will see the files have changed, purge them from the cache and re-download them.
Downside: customers will be in for kind of a Windows 10 unexpected update next time they launch the application but this the best I can think of.
Re:Self-sign (Score:5, Interesting)
This won't fix it. I had an unsigned exe get picked up by some small-time Russian antivirus. Before long its signature spread to all the other AV companies including MS and blocked by SmartScreen. There's no appeals process to 500 different AV companies, no recompilation options that cleared it up and guaranteed customers wouldn't associate our software with viruses. The only solution was to pay for a verified identity signature. It's practically extortion.
Re: (Score:2)
I know you don't RTFA, but at least read the fucking summary.
It wasn't malware - it was the application itself. That was flagged as malware by a virus checking tool's false positive.
Re: (Score:2)
java needs code signing cert only for hot content downloaded over the web, as the TFS says the case is. So, please re-read my GP post.
Re: Seconded. (Score:2)
Re: (Score:2)
Of course he's not recommending adding random certificate authorities. What he was recommending is entirely reasonable. If a company keeps their CA keys secured, which they need to do anyway regardless of who signs their CSRs, there's no more potential for abuse than with a regular CA. The advantage of the private CA is that users don't have to regularly accept self-signed certificates every time some minor change is pushed out, which could condition them to accept anything. With the private CA, the cli
Re: (Score:2)
It's been a while, but I did spend some years managing the public key encryption infrastructure for a large university department. We had a recognized third-party certificate authority that signed all our outward-facing services' certificates, but for a lot of internal stuff that changed frequently, it was far easier to roll out our own private CA to all our machines (hundreds) and sign our own certs.
Re: Seconded. (Score:2)
And what says that the existing public CAs are safer?
The issue here is that you can't trust them.
Also if an application is intended to be run by that customer only, then that customer can run their own CA and setting up a private CA and signing would be part of the installation procedure. That would mean a single party responsibility for ensuring that the system works.
Re: (Score:2)
Self-signing your own chain of authority is the only way to avoid this (assuming Java allows that, of course.)
That, of course, defeats the whole purpose of certificates. Anyone can create a self signed certificate for everyone. Therefore a tool that checks that you have a valid certificate will most likely reject self-signed certificates.
Re: (Score:2)
The issue is one of trust, not self signed certs.
A signing certificate is issued by a Certificate Authority and the question when you are checking the signature is "do I trust the CA that issued this signing certificate?" If you trust the CA, you trust the singing cert. When you "self sign" you are making yourself a certificate authority, then you issue a signing cert under that authority.
With that background... How do you suppose the program who's checking certs for you determines if they trust the CA?
Re: (Score:2, Informative)
Not so.
The only difference between self-signed and "paid for" certs is that of trust. Yet realistically? That trust model is absurdly, ridiculously, laughingly broken.
When CAs first started, they were large, monolithic entities that took it seriously. I recall back in the early 2000s, having to provide actual incorporation documentation to even GET a corporate cert signed! They wanted extensive validation to prove we were actually us, prior to issuing said cert.
Now you can still go through that intensiv
Re: (Score:2)
Re: Seconded. (Score:2)
Bullshit. Depending on an authority is a security hole (as this story so clearly demonstrates). For internal apps, it's quite reasonable and common to use self-signed certs, which are the most secure approach if you can get away with it. The primary reason not to do this is if you have an unsolved issue of key distribution. Otherwise, everyone would use self-signed certs.
Certificates (Score:4, Interesting)
Call me clueless about security if you like, but I've never understood why anyone considered certificates a good idea. I dabbled with Java for a little while, but having to self-sign my own Java applications just to run them on my own computer is idiotic.
Smells like bureaucratic snake oil to me.
Re:Certificates (Score:5, Informative)
I agree completely. Best I can tell, the only thing a certificate authority certifies is that your credit card didn't bounce, and the only thing they're an authority on is processing credit cards.
Re: (Score:2)
It's a theoretical consideration. Without certificates, IPv6, regular deprecation of older protocols, and some similar steps, your web operations won't really have sufficient single points of failure and mandatory usability issues to reach Bozo's Limit. Bozo's Limit is the point at which digital communications become more trouble than they are worth and snailmail or turning your computer off and simply and tending your own garden (see http://www.gutenberg.org/files... [gutenberg.org]) becomes an attractive alternative.
Di
Re: (Score:2)
And this is so amazingly shortsighted. You do realize that there's more to the internet than credit cards, and certainly vastly more to security than merely the internet?
Re: (Score:3)
You are very confused. Certificates are a really good idea although you may question the management of certificates authority.
Re: (Score:2)
They COULD have been a really good idea, but the whole thing was perverted to make sure there would be enough opportunities to extort large wads of cash.
A proper system makes the user (or the admin in a corporate environment) the final arbiter of what certs are or are not accepted. Even if the town gossip (based on the incredibly strong evidence of a hunch) says a cert should be revoked.
Most certs out there actually mean "either this is who they say they are or they know the basics of photoshop" as promised
Re: (Score:2)
yeap, I thought that was what I wrote. Sorry if I wasn't clear enough.
For other replies; equally yeap, no need for a cert to establish authenticity or to encrypt. Certs are just a way to trust public keys that somebody else trust so, somebody else basically sign your public key and put everything into a cert; your public key and their signature done with their private key.
Re: (Score:2)
You are talking about the particular web oriented certificate authorities. There's a whole set of applications of certificates that can't make use of the standard web certificate authorities. Ie, we self-sign our certificates that go on devices that are kept on a private network.
So occasionally your internal certs don't get renewed because someone was on vacation, but that doesn't invalidate the concept of PKI. Similarly, if some signer in the middle issues a CRL because of panic of a false positive malwar
Re:Certificates (Score:4, Insightful)
It is.
The whole idea behind any signature is to ensure that the message it's on is:
A. Authentic.
B. Unaltered.
The problem with code signatures is:
A. Most people don't care where the code comes from and don't understand chain of trusts so authenticity means nothing. Most people wouldn't be able to tell the difference between the real developer's signature and a malware author's signature. This is not just a problem for code signatures, but the entire concept of CAs in general. As all CAs rely on blind trust of third parties that most have never even heard of. Using certificates that, for most users, just appear out of thin air and have a giant "trusted" or "untrusted" label on them. There's no thinking nor actual trust involved by the people telling the machine what to do. Any claims of guarantees based on this system are just that: Claims, but no real guarantees. Don't believe me? Check that EULA / ToS. There's probably an indemnification clause in it.
B. An executable file is just a static image of what to load into memory. It's NOT the code that will actually run. ASLR, stack canaries, dynamic libraries, code generation / interpreters, etc. all change that image at runtime. Unlike a static message, verification of a program once is insufficient. As the program can change between each executed instruction, the order of the instructions executed, i.e. the code path, and the inputs the program gets are important. You may not care about a "Upload this to social media" instruction, but you'll definitely care if the instruction before it was "select porn folder." Code signatures only take into account the entire program image at rest. An ideal state. They do not, and cannot without solving the halting problem, take into account every possible code path for every possible input. To say nothing about the length of time that code runs and is therefore vulnerable to attack. The fact that the signed program can contain bugs for exploitation, or intentional backdoors placed there by those who can influence the chain of trust. Or a well timed hardware attack.
Given that A. Very few trusts the authorities, and watches the watchers, and B. Code signatures do not cover the code that is actually running, code signatures are an exercise in futility. Made even worse by creating gatekeepers and political power structures to enforce it. Hackers will still get in regardless of code signature checks. The only things that code signatures do effectively are: A. Give false assurances of safety. and B. Create barriers to entry for the masses through expensive publishing requirements, social stigmas, and walled gardens that can be broken out of with enough effort.
Re: (Score:2)
Right, on the web that is true. The cert basically says "this is from company X". But certificates do a lot more than just that and they're used in many more applications than the web or software patches.
Re:Certificates (Score:5, Informative)
Historically speaking executables have never needed to be code signed. You could compile and run any unsigned application without problems.
In recent years macOS added GateKeeper and Windows added various forms of SmartScreen (initially in MS-IE but since Windows 8 it's been part of Windows Defender), that requires executables to be code signed by a certificate from a "trustworty" certificate authority. The Salemans' Theory is that if you only allow code signed applications to be installed and run on your computer then you can very effectively block out all the viruses and malware.
In the real world that doesn't work, though, because virus and malware authors can code sign their stuff, too. And users often turn off the protections of GateKeeper and SmartScreen so that they can install and use software that hasn't been code signed.
Code signing has become a false promise where only the certificate authorities have benefited. Software developers have to jump through all sorts of hoops to get their certificates and get code signing working. End users have to deal with all sorts of problems when code signing can't be validated or is improperly revoked. Certificate authorities are making money hand-over-fist for doing sweet fuck all and have no punishments imposed upon them when they fuck up.
Re: Certificates (Score:2)
If you only allow signed code to execute you will be able to block competitor programs from being used in your OS.
Re: (Score:2)
And in some applications this is vital. Ie, our customers insist that only our software runs on our devices and that no one has hacked or modified them. We don't really have an "OS" per se. But we sign the devices in manufacturing, we sign the privileges used by the back office to talk to the devices, the customer adds their own signature to make sure other customers aren't overlapping, etc. We can even use this method to ensure that an untrustworthy manufacturer can't stick in malware (ie, in mainland Ch
Re: (Score:2)
It works well in a corporate environment where only specific software is allowed. If the cert doesn't match a pre-approved list set up by the IT department, it doesn't run. Even signed malware will be rejected because it's not on the whitelist.
Re: (Score:2)
Re: (Score:2)
So, basically, using certificates is like installing an elaborate deadbolt lock on your front door to keep termites out? It won't keep the termites out, but it'll keep YOU out if you lose the key or the lock breaks?
Re: (Score:2)
Close, it's like installing the dead bold that has a 50 digit combination... In a door that has a doggy door. All you have to do crawl though by hitting the "ignore" button..
Re: (Score:2)
Sort of, not all doors have doggy doors. If you're on a modern consumer OS, then ya, there are 50 different doggy doors in there. But that's just a subset of systems that are out there.
I'm basically surprised at reading so many of these comments today; it's like soooo many here have never seen any computing outside of Windows or on the web and are assuming certificates are just that thing that happen when you use HTTPS instead of HTTP. And yet despite not knowing much about the issue will still pontificate
Re: (Score:2)
Re: Certificates (Score:2)
If it's a Java applet you have to sign it - since about 10 years or so.
That's one of the things that killed Java applets, other things is the security issues with the Java plugins in web browsers. Most of the security issues with Java has been related to the browser plugins.
Re: (Score:2)
It sounds like a cool way for CAs to print money at everyone else's expense.
Re: (Score:2)
Certs are a chain of trust. It's not a Java thing, it's a security thing. These are vastly better than wifi security for example, if done right. The idea is that if signed with a certificate then it becomes incredibly difficult to modify the software (or contents of whatever is signed). It's easy to modify and tack on a new CRC32 for example; a MD5 signature is harder but then there's no way to know which is the right signature to compare. With a certificate chain basically A is signed by B, B is signed
Re: (Score:3)
"Certificates are the new cookies."
Not really. Cookies are a genuinely useful capability that is (unfortunately) easily abused. As I understand it, cookies record state. Without them you'd probably have to completely define all information required for any transaction in each and every message. OK for checking Wikipedia or quickly determining the radius of the Earth in furlongs. But a real pain for digital commerce and the like. I expect that if cookies were banned, something new and worse would quick
On one thing I agree... (Score:2)
There are too damned many false positives these days. Some of the tools we use flag things as malware that just don't make sense.
Re: (Score:2)
Well, everyone is being too overly cautious these days. Sometimes it makes sense, often it punishes the innocent.
I remember a few years ago when some Windows updates false-triggered some AV software that quarantined some critical Windows system files. I'm trying not to chuckle... oh the irony.
Re: (Score:2)
Before releasing, test on Virus Total yourself duh! If anything found, find what caused it and fix it. It is often faster to fix it yourself instead of going through the loops of proving your software isn't malicious.
Re: (Score:2)
Re: (Score:2)
Move fast or die. That principle has been around for a while I guess. Bitching usually has a high cost/benefit ratio.
Re: (Score:2)
There have been problems with AV for decades.
Bad definition updates that result in the AV system failing "safe" and disabling software or shutting down processes, sucking giant amounts of resources on desktop computers, and generally wasting a bunch of admin time with never-ending version updates and admin console maintenance. And then not stopping critical malware.
Re: (Score:2)
We have one of the newer products at work that supposedly uses AI instead of definitions to catch malware. I can't say how good a job it does of catching legitimate malware - it does have tons of false positives however. I imagine that the detection rate is something they use when they go into a sales presentation.
I have seen all sorts of tools flagged. Various IDEs. Compilers, editors. It just makes no sense that it would identify these things as malware. The irony is that whenever it does flag some
Re: (Score:2)
My sense is that IT departments and MSPs (where I've worked) insist on AV deployment because it's a get-out-of-jail-free card if an infection happens. They can claim they had deployed security software to each system, but the infection was a byproduct of the AV system's failure (and/or the sophistication of the malware).
Usually it's more complicated than that, but in most locations there won't be a complex, third-party security analysis -- it will just be the IT version of "bad spirits" and well, we tried
Re: (Score:2)
Lawyer up (Score:2)
A threatening letter from your lawyer may get them to fix this ASAP. Since your software is specialized and not a mass market product, how about just using self signed certs and helping your customers install them?
Re: (Score:2)
Re:Lawyer up (Score:4, Informative)
A threatening letter from your lawyer may get them to fix this ASAP.
It won't. Certificate authorities have arranged their operating rules such that it's not possible to un-revoke a certificate.
Consider whether you need a public CA at all (Score:4, Interesting)
I'm very much involved in all things relating to PKI...
What do you do? You first get a new certificate. You can't simply have a certificate be un-revoked. The CAB forum (the forum where CAs and Browsers make the rules) wouldn't allow it.
And its getting very hard to go with a smaller CA or reseller, as they are all being bought up by one another. What we are being left with is a few large CAs that control the market. And resellers may not have that much control over revocation.
You should consider whether you need a certificate that is trusted by a publicly trusted root. If its just being used internally by your software where all of the validation happens internally, It might be that you could find a provider that does private label CAs or has a private root. I know of many companies that do just that, because you really don't need every certificate to be publicly trusted. There are lots of B2B applications that simply use certificates for validation between them. They don't care whether the certificate was signed by VeriSign or Symantec or Digicert or any other public root. What matters is that it was signed by a root that you trust.
There are some smaller companies that do private label PKI and will even manage it for you, which makes it fairly easy to transition to from a public CA. Do a search for managed PKI as a service, and look beyond Digicert/Globalsign/Entrust (which are some of the big players).
Re: (Score:2)
companies that do private label PKI and will even manage it for you, which makes it fairly easy to transition to from a public CA.
It's so hard to envision that as a business model. It is so easy to do a private CA. For a public CA, you have to pay for them happening to be trusted by random user's TLS stack, but for private use it seems crazy to be able to make money doing such a trivial thing.
Re: (Score:2)
Yup, we have some private roots. I was even there at a root certificate creation "ceremony" (I brought a sacrificial knife with me but it turns out that was unnecessary). And ceremony wasn't really the wrong word here as we followed certain rituals; the PC is opened up so we can inspect if someone has not added extra hardware beyond the hardware security module, we have a special printer to print out the shards of the key with each shard being processed by a different person, and so forth.
Release an unsigned executable for the time being (Score:2)
There are plenty of unsigned executables out there, you can temporarily release a version that isn't signed until you get your act cleaned up.
In regards to false positives, if you release software, you should be checking that an AV solution doesn't flag your software, generally it means your software is doing something it shouldn't.
It's also possible your cert was actually compromised and you should perhaps invoke those disaster recovery plans. You do have a plan for certification revoking and recreation ri
Re: (Score:2)
Actually, no. Yes, shame on me/us, but we did not have a plan. Do you? Can you share, please? That is what I asked in TFA and one of the reasons I posted the story.
Note that the revocation means that hundreds of customers initially do not really understand what happened. They just pick up the phone and call our support department. That happens roughly at the same ti
Re: (Score:2)
Re: (Score:2)
AV solutions are paranoid. I know at least one would flag an application for binding a network port for listening. Like any server application would have to do.
That's going to bite you. Config, plugins, modules (Score:3)
> I work at a company that does a lot of customization for customers. Every customer is running a very slightly different build of our software.
I've seen that movie before. "Every customer is running a very slightly different build of our software" ends up biting you in the ass, hard. Also as you know it's a PITA even in normal situations.
What to do about it? Solutions in order of preference:
Configuration
Modules
Plugins and hooks
When a customer needs function X added, add function X to the software and
legal (Score:2)
First thing you should do is look at the terms of service or service contract or whatever documentation they have. See if they had an obligation to try to contact you in advance of a revocation, or even had any mention of the practice. You've got a case unless they specifically say they might do it. If they had the obligation, you should win a case. If they don't say anything, you have a harder battle ahead but it's probably doable.
STOP BUYING CERTIFICATES! (Score:4, Interesting)
The commercial CA business is a scam from top to bottom. it would be the same as paying your friend to have them tell you who you can trust, except you are paying a complete stranger to tell you this.
It is just more proof how people will blindly trust a complete stranger more than their own neighbor just because they say "we can be trusted".
Give me money, I will help keep you safe. Thus begins the scam.
At least go to Lets Encrypt and get a Certificate for free.
Self Signed Certificates should have been the ONLY certificates ever created. Everyone should treat certificates as access keys where they are managed just like accounts. If you don't then you are literally trusting a total stranger to tell you who to trust.
Re:STOP BUYING CERTIFICATES! (Score:4, Interesting)
The commercial CA business is a scam from top to bottom. it would be the same as paying your friend to have them tell you who you can trust, except you are paying a complete stranger to tell you this.
That isn't quite right. What you are paying for is for a trusted third party to tell everyone ELSE that you are an upright and honest guy. People you don't know
Ever hear of the Better Business Bureau? Pretty much like that.
The cert provider's stock in trade is trust. If their rep is iron clad then they can extract hundreds of dollars each year from corporations for that shared rep. But to do that their costs can't be zero. For one of them you don't just get a certificate by clicking on the web page. They will ask for and get documentation on the requesting company. Maybe interviews.
Cheap certificates are cheap. When it matters they aren't worth much. When it doesn't matter then they are OK. My web and mail server have cheap certificates ($6/year I think) but then again I don't sign stuff with that.
Re: (Score:2)
That isn't quite right. What you are paying for is for a trusted third party to tell everyone ELSE that you are an upright and honest guy. People you don't know
And how does the CA know that? In real world terms, a CA is like a notary public. You put some papers in front of them, show them your ID, pay them some money, and they attest that you signed the paper. They do not vet the legality or propriety of the document's content. They are not an attorney, or a software engineer, or an architect, or an expert in the topic of that document. They merely attest that you signed it.
CAs retroactively revoking certificates should not be allowed, unless there is a legal
Re: (Score:2)
That isn't quite right. What you are paying for is for a trusted third party to tell everyone ELSE that you are an upright and honest guy. People you don't know
The role of most CAs is attribution not judgment.
Ever hear of the Better Business Bureau? Pretty much like that.
I've heard they are a racketeering scam.
Re: (Score:2)
The IRS should get in on the CA business. If you file and pay taxes for X company at Y address, you can get your your certificate signed. Of course you'll have to submit the public key on IBM punch cards, and scan the Fresno skyline for revocations issued via smoke signal.
Re: (Score:2)
Actually the CA doesn't even have to say that you're upright and honest. They only need to say that you are you and not an imposter.
Re: (Score:3)
The way your browser and your OS is setup says otherwise, unless that is you completely purged every certificate from your OS and applications manually.
Did you get an error message when posting this? If not then you have placed an awful lot of trust in Let's Encrypt as a certificate authority.
LE certs are not for code signing (Score:2)
At least go to Lets Encrypt and get a Certificate for free.
Let's Encrypt issues certificates for TLS, not certificates for code signing. Only web browsers trust Let's Encrypt certificates, not operating system executable loaders. In the context of code signing, at best, Let's Encrypt certificates are good for setting up an HTTPS site from which users may download the self-signed certificate against which your applications are signed, and this might not even work on all operating systems.
Re: (Score:2)
At least go to Lets Encrypt and get a Certificate for free.
Fun example, I was running a site with a let's encrypt certificate. Our security team flagged it as "not using a secure enough CA". Judging from the list of approved CAs, the requirement of being secure enough was charging an appropriately large sum.
Note we were not talking about EV or anything, just a basic cert.
.
Re: (Score:2)
There needs to be a certain amount of due diligence that you are who you say you are - that's a lot of what you are paying for. Otherwise I could claim to be Microsoft or Google and start signing binaries.
Re: (Score:2)
Of course, the anal CA affords no additional protection.
Why not? Because even if *I* don't trust a CA because it's too lax, the browsers *do* trust those CAs. Therefore if an adversary could overcome *any* of the CAs, my selection of rigorous CA buys me nothing.
EVSSL is supposed to be the mechanism of actually showing user that your identity has been more scrutinized, but users as a rule don't *know* whether to expect EVSSL from a site or not, and probably don't even know that's a thing.
Re: (Score:2)
Re: (Score:2)
A certificate authority is a lot like a notary public. They're not supplying any judgement as to the value of what's being signed, they're only authenticating that they did sign it, that you are who you say you are, and that you presented the proper documentation. A CA and a notary public are both neutral parties who exist because people trust them to remain impartial and not lie.
Re: (Score:2)
"Self Signed Certificates should have been the ONLY certificates ever created. "
In the context of code signing it can be useful for software companies to provide their own trust anchors. You as a customer install once then all future updates and products of that vendor can be verified against it from that point forward.
Rather than involving third parties with the power to fool and subvert you involve only the software company you have decided to trust.
Sigh, a self-signed-certificate is absolutely worthless for security. Let's take the typical situation of Alice on her web browser connecting to Bob Discount Online Retailer using SSL.
Self signed or CA? No difference. 443 works fine
Then Charlie the untrusted malicious ISP comes along and intercepts port 443. Oh no, he doesn't have the private key for Bob to pretend to be Bob! Problem for Charlie...except that in the self-signed case, all Charlie does is make up a new self-signed certificate pretending to be for Bob Inc, and presents that certificate to Alice. Alice sees the SSL padlock and off she goes.
While TFA is not about websites / domain validation worth noting that virtually all DV signing these days is completely automated based
Correct, it's now a legal but also a PR issue (Score:5, Interesting)
First of all, this post should have named the company. It's Sectigo.
Secondly, the commenter who said it's a legal issue is half correct. It is now a legal and PR issue. There are only two things that keep any company honest. Two swords of Damocles, if you will. That is a threat against money going out (litigation) and a threat against money coming in (PR). Unfortunately our economic system selects for malfeasance, and only publicity can offset that. I'd actually hire a PR company who has experience with social media, influencing, getting events upvoted, talked about, and spread and then publicly shame Sectigo. Do not talk to them before doing this. Do not issue a warning shot. Just post about what happened. Do it boldly, loudly, and often. No personal attacks - but put in the implications. The company you pay to be your security essentially publicly accused you of malfeasance without talking to you. This is akin to going to a notary to get a document notarized, and then after they apply their stamp they (without talking to you and on skanty evidence) go to other party of that document and revoke their stamp. This is serious. You want to create enough attention that they come to you.
Secondly, if you do contact them, it should be through a lawyer and in the form of a demand letter that they a) explain their actions, b) issue a written apology, and c) issue a written declaration that this won't happen again, and d) make restitution for actual hours spent and costs incurred and that if they do not then you will also go for special damages.
Re: (Score:2)
I fully agree with you. Why do you think I've posted the story on Slashdot? ;-)
Okay, I'm not a PR company, but making decision and hiring a PR company is above my pay grade.
Re: (Score:2)
But what kind of certificate did they buy? If it was just a basic one where the only thing you need to present is proof of being a registered business then they can't really expect much in the way of service when things like this happen. The certificate is literally just saying they did the absolute minimum check necessary to verify the publisher's identity and you get zero support for your money.
If the certificate really is that important to their core business, they should have got an enhanced one that in
Re: (Score:2)
If it was just a basic one where the only thing you need to present is proof of being a registered business then they can't really expect much in the way of service when things like this happen
You're kidding right?
This wasn't a technical support problem. This was a company who set the standard for what was required for a signature, was paid what they asked, and then turned around and summarily revoked it. I can absolutely expect more than what happened. I don't care if it cost 5. I didn't set the price, they did.
Basically what you are describing is legalizing extortion. They have the right to set a low price to sucker you in, and then summarily revoke what they sold you for any reason they w
Re: (Score:2)
Actually they didn't set the standard for what was required. They are resellers, the root authority sets the standard. And the standard is very low, and they need to quickly boot malware off or they will have their signing certs revoked too.
Re: (Score:2)
Sectigo, nee Comodo (Score:2)
What, was Sectigo [duckduckgo.com] the cheapest certificate you could find? Wonder why? Wonder why they had to abandon their old brand?
If your business depends on it, get a quality cert from a quality vendor [digicert.com].
Re: (Score:2)
You have to sign in a way that if the certificate was valid during the time of signing the executable will still work in case the certificate is later revoked, or if it simply expires.
In case you didn't see it, this post [slashdot.org] claims that timestamping is effective against expiration, not against revocation.
Youâ(TM)re basically screwed (Score:2)
Their systems are basically âoeinfallible bots.â Which has the convenient side-effect of flagging a certificate until forever or it works out that it isnâ(TM)t compromised. Donâ(TM)t hold your breath for that though.
The big failure of CA is that there really isnâ(TM)t any (useful) plan or guidance for dealing with a flagged certificate.
Serves the fuckers right. (Score:2)
Re: (Score:2)
Steam will fail if it's been offline too long.
You are all mostly wrong (Score:3)
The trouble is the race to the bottom. No one wants to pay the CAs very much. The most profitable CAs are the ones that do the least work. That includes automating their tests and automating their response to a failed test. At some point the CAs have started charging so little that it is unprofitable to provide even a minimum of customer service. The loss of a customer and even a little bad PR is not worth the cost of better service. You get what you pay for.
Re: (Score:3)
The problem is that most CAs either don't do that much checking or what checking they do is easily fooled. We've seen repeated evidence of that.
Frankly incidents of wrongly-issued certificates and just plain due-diligence failures by CAs are why I'd rather trust a self-issued root certificate obtained directly from the domain owner or software vendor themselves, assuming of course it's got appropriate namespaceConstraints extensions on it so it's valid only for that entity's domains. I still can't trust the
Re: (Score:2)
Now I expect the CA has verified that company X really is company X and that they have real directors and at least a real presence somewhere.
This is almost never true. There are three levels of certificate validation:
1. Domain Validation (DV). Before issuing a DV cert, the CA verifies that the entity it's issuing to controls the domain mentioned in the cert. This is done by asking the entity requesting the cert to modify the domain DNS record, or serve up a particular file from a web server at that domain.
2. Organization Validation (OV). This is what you describe; the CA verifies that the organization exists and is real... oh, and also
False Positives = Heuristics (Score:4, Insightful)
However, just about all programs that look for malware use Heuristics. That's basically looking for things they don't know are actually malware by noticing suspicious activity. The programming on those varies by a HUGE amount. Some programs will trigger on one type of activity, while others won't give a rodents donkey about it even if it's spamming the machine with it.
Heuristics are basically a semi-educated guess. It's used to potentially spot the possible unknown malwares that are out there. After all, there's no such thing as signatures for something that doesn't exist when it comes to malware detection.
Another thing when it comes to heuristics, and that's the user. Some programs allow you to fiddle with the settings on heuristics and make them more sensitive. I've dealt with plenty of people who cranked it up to the max settings and then freaked out when it triggered on freaking everything! Definitely not a smart move for someone to do, but plenty of people who just don't really understand this stuff think computers are some kind of super intelligent thinking machines or something. (Not going to mention the pixie dust.... Gawd I hate what that $#!^@$%&# did to user unrealistic expectations!)
Sure, it might not be because of Heuristics, some vendors of malware detection software include such tiny snippets of code for their signatures that those will trigger on plenty of false positives as well. If you want to go into silly analogs, it's like setting your "gun detector" to trigger on a specific screw in particular model of gun, that is also used in the dahsboards of several different types of cars. It's going to give false positives on those because the creator of the signature made a foolish mistake.
Don't forget, there's only so many ways to make code do simple things, and all code does simple things as a standard building block of those more complex things they do. Fingerprint analysis isn't admissible with only a hundredth of a single fingerprint, and DNA analysts won't declare a match on only 3 base pairs. But some programmers can and do make that kind of mistake.
Yes, I do know far too much about computer viruses, worms, trojans, and many other types of malware, as well antivirus software. There's tons of silly myths, even if they don't seem silly to outsiders of the field, so you're really got to keep an eye out for those and try to keep to official sources rather than random posters on the net like me. (Yeah, I really do know this subject well, but anyone can say that they know stuff they don't, so be careful.)
By the way, how have you verified that your code isn't actually infected? There have been plenty of cases with software and even hardware (with embedded code) coming from the factory already infected. For that matter, the person or people that submitted the sample that failed some of the tests might be the source of the infection, and not your software, if it's not a false positive. Has anyone checked out that possibility yet?
Sounds crazy, but with the computers and companies I've dealt with, if there's an infector going around, the so called "secure computers that can't possibly be infected" are almost always infected. (People assume too much of their "safeguards" are never circumvented, and all it takes is ONE screwup.)
Re:False Positives = Heuristics (Score:4, Interesting)
Yes. I mean, we found in our archives the very same binary as it came out from our build system a the time of release. We found the report on Virustotal on that binary. Compared SHA256 sum that Virustotal keeps. There is a theoretical possibility that our build system is compromised for months, produced infected binaries and nobody noticed. That can be ruled out only by dissecting the binaries and going through with a fine comb. Or doing reproducible builds. We did not do that. I think that because other binaries from the same build/release are not flagged the build system was/is clean.
Same here, Sectigo revoked my certificate. (Score:5, Interesting)
If I had known ahead of time, I would have only signed software after it passes the "test". If anything can be done to get my certificate back, I would appreciate the help. Otherwise, I probably will be self-signing from now on.
This is how we solved this issue 10 years ago (Score:4, Insightful)
The .exe's on the customer side use a pre-launch to check that there are no updates. We use load balancers and version codes in the API requests to route the query to the right set of server via load balancer scripts. If the customer chooses not to use the new code, they are warned this could lead to issues and discuss it with their IT department before proceeding. Their IT department will need to get a code from the vendor to proceed, since we know users are not really to be trusted.
On the cert side, I banged up a script to check them every hour, including revocation. If something goes wrong, a bunch of text messages get fired off. It's the same script that checks for 90, 60, 30, 7, 3 day expiry and finally, a dead cert. That script saved their butts more than once. I'll add it wasn't for my full time employer at that time, it was a long term consulting gig. The only times this didn't work was when someone didn't enter the cert in the database. I hear that's now automated.
This does not solve the problem. It does let you know pretty soon when you get one. The problem these days is that things get pretty tightly coupled. Java for example is just nuts after 7.43 or so on security. This bit Cloud Providers when their hundreds of thousands of Out of Band Management cards on their servers wouldn't work with newer versions of java, and FireFox got pretty high handed on forcing users to not be allowed to override security warnings. My opinion is that these should be allowed to be overridden with a message like "Yeah, we know you think you know what you're doing, but in some cases, this is incorrect. Unless you are a professional with many years of experience, trust us and do not override."
And before people tell me Java 7.43 is ancient and shouldn't be used, yeah. I know. I was working with literally over 300,000 servers at one point. What'cha gonna do, drop everything and spend months updating things, realizing some subset of systems can't be fixed? Are you going to spend 50 million bucks on new servers for one's you just bought? And no, the OOB cards were not accessible to anyone but employees. You think we're nuts?
Just sign the installer (Score:2)
First rule of IT (Score:2)
If you are dependent on a something, you need at least two of them. You should have another certificate authority issue you a second cert (or even use Let's Encrypt, since this is an emergency cert only). Just switch the cert out and problem solved.
Re: (Score:2)
Let's Encrypt don't do code-signing certs, and for good reason.
Code-signing pretty much *requires* a full-chain back to an entity that someone important (like Microsoft, Oracle, etc.) trusts or every single one of your customers will have to make a special exception just for your cert, which they are generally loathe to do on a company-wide, site-wide "execute anything you like" basis that code-signing certs are suppose to guarantee.
You could get a second cert, but I'm not sure that most applications will l
Re: (Score:2)
I had an application flagged as a virus because as part of things it had to do, it opened a port on localhost. One AV vendor decided this one system call is something that is awfully malware-like to do.
Of course, in that case all we had to do was submit the application to the AV vendor and explain the purpose of the port and they white listed it.
Re: Copy Protection (Score:2)
I have myself experienced that my programs randomly have been flagged without even pulling in code examples. A re-ordering of my source code and a recompile have fixed it.
So the signatures used by AV companies are sometimes just a random piece of code - or a checksum of a piece of code - that can happen to anybody.
Re: (Score:2)
and what make them the authorities, and just because somebody like a browser maker or a code library vendor trusts them, why the hell should anybody else???
Through the CA system, the operating system publisher trusts the certificate authority. Further links in the chain of trust are outside the CA racket but may be part of a different racket:
- The PC maker trusts the operating system publisher.
- The retailer trusts the PC maker.
- Home and small business users trust the retailer.
So what method to get home and small business users to trust a developer would you recommend in order to bypass this racket?
Re: (Score:2)
Checksums don't bypass Windows SmartScreen's "not commonly downloaded: recommend deleting" warning unless they're in the form of a digital signature that chains to a trusted root.
How would you solve bankofarnerica? (Score:2)
I think the thing we in the tech community need to do is come up with the most insanely secure connections between any two ponts as possible and make it nearly impossible for a user to get a connection to a server he or she did not intend to. Once a person can be certain he is connecting to the server he intends
What method of "accurate routing" would deter typosquatting? For example, bankofarnerica.com isn't the domain you might expect, as it has RN in the name.
then he should be able to trust that server by virtue of having established a human relationship with the server's owner/operator
How would a newly established developer go about "establish[ing] a human relationship with" prospective users?
Re: (Score:2)
Let's Encrypt DO NOT DO code-signing certificates.
Even if they did, the major manufacturer's (Microsoft, Oracle, etc.) would have to have the Let's Encrypt root cert in their code-signing chains, and they don't (and likely never will).
Mostly because then code-signing becomes pointless because EVERYONE'S code would be signed by a trusted entity for free with no checks, which pretty much kills the point of code-signing in the first place.