Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 18 submissions in the queue.
posted by martyb on Friday March 02 2018, @12:04AM   Printer-friendly
from the Danger-Will-Robinson!-Danger! dept.

[Ed note: After this story was submitted, it became known that there was a remote code execution (RCE) vulnerability on the Trustico web site which allowed malicious users to run arbitrary code as root on the server. Story at Ars Technica: Trustico website goes dark after someone drops critical flaw on Twitter. Link to the tweet. As of the time of this writing, the Trustico web site is unavailable. --martyb]

23,000 HTTPS certs will be axed in next 24 hours after private keys leak

Customers of HTTPS certificate reseller Trustico are reeling after being told their website security certs – as many as 23,000 – will be rendered useless within the next 24 hours.

This is allegedly due to a security blunder in which the private keys for said certificates ended up in an email sent by Trustico. Those keys are supposed to be secret, and only held by the cert owners, and certainly not to be disclosed in messages. In the wrong hands, they can be used by malicious websites to masquerade as legit operations.

Unless the affected certificates are replaced in time, visitors to websites using Trustico-sold HTTPS certs will be turned away by their browsers, due to the digital certificates being revoked.

The whole situation is a mess, and possibly the result of a turf war. Here's what we've managed to ascertain.

What is Trustico?

Trustico, based in Croydon, UK, touted SSL/TLS certificates, which are used by websites to encrypt and secure their connections. It resold certs from the Symantec brand umbrella: Symantec, GeoTrust, Thawte, and RapidSSL. This umbrella is now owned and operated by DigiCert.

If you wanted to buy, say, a RapidSSL-issued certificate, you could do so via Trustico. The HTTPS cert ultimately leads back, along a chain of trust, to DigiCert, a root certificate authority trusted by web browsers and other software. In turn, a website presenting the Trustico-sold cert is trusted, its traffic secured using encryption, and the reassuring green padlock is displayed in visitors' browsers.

Why are the certificates being revoked?

According to DigiCert's chief product officer Jeremy Rowley earlier today, Trustico told DigiCert in early February that its resold certificates had been in some way "compromised," and that the certs needed to be mass revoked as a result.

DigiCert staff, we're told, asked Trustico for more information on this security mishap. The reseller replied it had a copy of the private keys, which is usually grounds for revocation, and thus insisted that DigiCert revoke the certificates.

When pressed for evidence, Trustico on Wednesday simply emailed DigiCert 23,000 certificates' private keys as proof it held this information, it is claimed. This forced DigiCert's hand: under the rulebook of standards set by the elders of the certificate security and browser worlds, the Trustico-sold certificates had to be revoked as a precaution within 24 hours. Specifically, the ones with their private keys in the email will be canceled.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 3, Interesting) by fyngyrz on Friday March 02 2018, @02:05PM (2 children)

    by fyngyrz (6567) on Friday March 02 2018, @02:05PM (#646357) Journal

    "Forcing" websites to be encrypted helps the users.

    No. It doesn't. It creates a circumstance where users are scared off of web sites that are entirely innocuous, and creates a completely unnecessary maintenance load for the owner of such innocuous web sites. It pushes traffic to the cert authorities (which is likely 99.99% of the drive for "encryption everywhere" after you get past the absurdist agitprop such as what you're pushing here.)

    then anyone parsing my traffic (either passively or actively) can't tell what I'm looking at.

    There are many ways well outside of the network traffic itself that they can track where you are going. Such tracking can be done at your end or the web site end, and compromises to enable such things are common. Your idea that if the network is safe, that you are safe from traffic surveillance is nonsense. That's without even considering the legal means to go after logs, your computer, etc. This is in addition to the notion that if you're on a web site that provides content that you are "not supposed to viewing", they already know [wikipedia.org] you're on, or have been on, that web site because its IP IDs your comm routing quite outside of any content transfer. No network transaction you engage in goes "below the radar"; and your idea that because the stream is encrypted that people who are concerned with what you're viewing can't know what it is, is completely wrongheaded.

    The more worrisome the content, the more likely the TLAs know exactly what is going on with it.

    Same applies to protecting the users from malicious (including ads and other generally annoying) insertions into the HTML stream by active attackers in the routing path.

    The web site can source malicious ads. Your browser / computer can source malicious ads. You are not protected.

    It is not a major hurdle to go from HTTP to HTTPS for any decent web server.

    You are proceeding from assumptions that are not valid for all sites. Some sites may have years of content, all within content management systems, all with HTTP links in them. These can be "fixed" by auto-forwarding at the destination, but auto-forwarding can also be another vector for taking you somewhere you didn't intend to go. And again, this is another load on web site operators that is entirely unjustified.

    The real problem is the monetary requirement to get certs issued.

    Well, that's certainly "a" problem. There are (time crippled) services available to do so that are presently without cost. If you want to get into an automated cycle with such services (which opens up yet another door for problems, nasty browser scareware, etc.), you can, at present, get a zero-cost cert that won't automatically instigate scareware within the browser. That doesn't count the cost of time and maintenance and security monitoring that comes along with hitching your wagon to such a service, all of which are real-world considerations dipping into limited resources.

    Of course, you can issue yourself a cert for zero dollars, but the unjustified scareware for that has been built into browsers for years based on the falsehood that certs provide certain "identity", so that's really no better than going without as far as scaring people off goes.

    I'm all for a web of trust type model - even amongst CAs, where the browser can display a star rating on "how trusted" the site/cert actually is.

    Oh, good. Let's add more scareware based on effort levels by cert authorities. Which they will of course charge more for. Which will work directly to deepen the "pay us or scare your visitors / customers away" malfuckery. <sarcasm>Great idea.</sarcasm>

    Starting Score:    1  point
    Moderation   +1  
       Interesting=1, Total=1
    Extra 'Interesting' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   3  
  • (Score: 2) by insanumingenium on Friday March 02 2018, @06:51PM (1 child)

    by insanumingenium (4824) on Friday March 02 2018, @06:51PM (#646536) Journal

    No. It doesn't. It creates a circumstance where users are scared off of web sites that are entirely innocuous, and creates a completely unnecessary maintenance load for the owner of such innocuous web sites. It pushes traffic to the cert authorities (which is likely 99.99% of the drive for "encryption everywhere" after you get past the absurdist agitprop such as what you're pushing here.)

    Dismissing everyone who disagrees with you as "absudist agitprop" and then making a quantitative statement (even if obviously not intended to be rigorous) seems rather disingenuous. Might as well say "ignoring people with left feet, shoemakers are maliciously selling 99.99% of people useless left shoes"

    There are many ways well outside of the network traffic itself that they can track where you are going. Such tracking can be done at your end or the web site end, and compromises to enable such things are common. Your idea that if the network is safe, that you are safe from traffic surveillance is nonsense. That's without even considering the legal means to go after logs, your computer, etc. This is in addition to the notion that if you're on a web site that provides content that you are "not supposed to viewing", they already know [wikipedia.org] you're on, or have been on, that web site because its IP IDs your comm routing quite outside of any content transfer. No network transaction you engage in goes "below the radar"; and your idea that because the stream is encrypted that people who are concerned with what you're viewing can't know what it is, is completely wrongheaded.

    This is like claiming that just because a common bulletproof vest doesn't protect you from rifle rife and headshots it is totally useless. Protecting content (not metadata) on the wire from third parties is a totally valid goal. Just because that isn't 100% coverage doesn't make it less laudable.

    Of course, you can issue yourself a cert for zero dollars, but the unjustified scareware for that has been built into browsers for years based on the falsehood that certs provide certain "identity", so that's really no better than going without as far as scaring people off goes.

    Really, you think warning about untrusted certs is "unjustified scareware"? What exactly is the point of certs if you ignore untrusted certs? That said, alarming on unencrypted the same as self-signed certs is going to muddy the waters.

    You have very valid concerns. I would add that another class of people who are going to get royally screwed are devices with web UIs, there is no way a consumer router is going to have a valid cert out of the box, so we are instead going to have to train users to ignore the security warnings, or drive them to an app which will do so for them. Either way everyone is going to lose on that one.

    I would love a different model than centralized authorities, we have seen time and again that they can't be trusted. Sadly web of trust is still waiting on a meaningful large scale implementation, its golden boy is still only used in comparatively small circles. If I am going to use GPG, I tend to have to hand collect a key from my target, and I have had people who really should know better tell me not to bother comparing their fingerprints. As you pointed out web of trust should NOT mean trusting a web of "authorities", that kind of runs counter to the whole idea. Sadly, I have never seem a proposal for a large scale web of trust model that would even come close to replacing the current CA model for HTTPS.

    • (Score: 2) by fyngyrz on Saturday March 03 2018, @01:00AM

      by fyngyrz (6567) on Saturday March 03 2018, @01:00AM (#646740) Journal

      Dismissing everyone who disagrees with you as "absudist agitprop"

      This, from the GP...

      "Forcing" websites to be encrypted helps the users.

      ...is absurdist agitprop.

      If you say that quartz is topaz, I'm not going to call your statement wrong because I disagree with you, I'll call it wrong because it is wrong. Likewise here.

      People are entitled to their own opinions, and the expression thereof. They are not entitled to their own facts. And when they are called on such factual misrepresentation, that's something the caller is entitled to. When they don't like that and protest accordingly, I just laugh.

      I'm laughing now. :)

      TL;DR: There are not multiple valid sides to every discussion, and pretending there are in a case when there aren't is disingenuous. In the case of encryption, there are perfectly valid use cases that balance the costs against the benefits. "Everywhere" is not one of them.