10 ms·
Symantec Backs Its CA
- leeoniya 10y ago> Symantec will vigorously defend the safe and productive use of the Internet, including minimizing any potential disruption caused by the proposal in Google’s blog post. What they will vigorously defend is disruption to their reputation and their bottom line. What benefit does a business get from Symantec that they do not get from Let's Encrypt? EV?
- eganist 10y agoSupport. And as mockable as that might sound, it comes in handy for businesses with special requirements.
- lomnakkus 10y agoSuch as the issuance of SHA1 signed certificates long after they've been deprecated? /snark (Sorry, I couldn't resist.) EDIT: Apologies, didn't notice the other poster beat me to it.
- DannyBee 10y agoWhy do i feel like support is one of the reason they issued so many certs they should not have?
- mattzito 10y agoWell, you can't do wildcard certs, which is fine for most businesses, but for some it's a non-starter. That doesn't make LE bad, of course, it just means it's not the appropriate tool for all use cases.
- leeoniya 10y agobut certs dont cost anything. you can easily automate the renewal of as many subdomain certs as needed.
- brianwawok 10y agoIf you are a big company and need say 100k wildcard certs (say one per client).. I am pretty sure I can justify spending $50 for a wildcard cert vs a fleet of servers and engineers and monitors to enforce let's encrypt work. Let's encrypt is great but let's not pretend it's the right solution for all websites.
- leeoniya 10y agoLE should charge a small fee for wildcard certs and extended validity periods (up to some reasonable limit). They'd likely cover their operating budget very quickly. What's their stance on wildcard certs with SANs? Is it simply too risky / ripe for abuse?
- mjevans 10y agoAbsolutely no knowledge here, but my /guess/ has been that they don't do more because it would either require more effort or would have soured the cross-signing deal so that they'd be validated by a CA that's already in older operating systems/devices.
- yjftsjthsd-h 10y agoI suspect they will never allow longer validity certs because they want renewal to be automated.
- sandGorgon 10y agoI will a LOT if LE can issue wildcard certificates to me with a 3 year validity. And send me reminder emails when im nearing expiry.
- tyingq 10y agoThere is some time, scripting, etc, cost to integrating lots of certs into a single instance of Apache, nginx, etc. Wildcards certs have value in some settings.
- simcop2387 10y ago
- will_hughes 10y agoA wider set of devices that accept it. If you have a service that serves to a fleet of STBs, TVs, or other embedded devices, they have a fixed set of RootCAs and getting the OEM to update those (and possibly through a ton of different resellers) is a nightmare. While the embedded devices won't be impacted by this announcement (if the deprecation goes ahead), there might be some additional work for anyone that services web browsers AND embedded devices from the same endpoints.
- toast0 10y agoThis is a pretty big deal; Symantec controls many root CAs that are pretty old and widely distributed. If you're supporting embedded devices (or phones) with pretty old root stores, you don't have that many choices, and it can be hard to know what they really are, because documentation of root stores is fairly sparse. Of course, there's not a good way for clients to indicate which root CAs they accept, and so they don't. If you get into the situation where newer devices don't support Symantec certs, and older devices don't support non-Symantec certs, it's time to figure out how to guess if you're talking to a newer or an older device and give appropriate certs. :(
- bubblethink 10y agoLE is not scalable. You can't do wildcards, and you don't want to authenticate every subdomain to LE by having it spawn a http server. You don't even want most of your stuff to face the internet to begin with.
- kosinus 10y agoI've never hit te rate limit on LE. Seems to me you need to be running a public site that gives each user a subdomain, or similar setup, before you run into such issues. You don't need a HTTP server to do authentication, it's also possible to use DNS and TLS SNI. There's certainly no need to spawn a server per domain, even for HTTP. If your implementation is complex enough to require many certs, these problems are already solvable. Either fork over the money for a wildcard cert, or account for the extra work in your planning. The setup we use is to have our own authoritative nameserver for a 'dyn' subdomain, and do DNS auth. We auth a subdomain with LE in less than 10 seconds.
- c3t0 10y ago> This action was unexpected, and we believe the blog post was irresponsible. Problems since Oct 2015 and the action unexpected? see 1) > We hope it was not calculated to create uncertainty and doubt within the Internet community about our SSL/TLS certificates. Symantec took no ownership of the issue. Snarky underhanded remarks are not a professional way to address shortcomings in managing their product. > For example, Google’s claim that we have mis-issued 30,000 SSL/TLS certificates is not true. In the event Google is referring to, 127 certificates – not 30,000 – were identified as mis-issued, and they resulted in no consumer harm. Per Chrome's team an initial set of reportedly 127 certificates has expanded to include at least 30,000 certificates, issued over a period spanning several years see 2) Summary: No ownership and no action plan conveyed in Symantec's 421 word message. 1) https://security.googleblog.com/2015/10/sustaining-digital-certificate-security.html https://security.googleblog.com/2015/10/sustaining-digital-c... 2) https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/eUAKwjihhBs/rpxMXjZHCQAJ https://groups.google.com/a/chromium.org/forum/#!msg/blink-d...
- tyingq 10y agoFrom your 1) link... "23 test certificates had been issued without the domain owner’s knowledge covering five organizations, including Google" Guess that explains part of why this particular CA incident has Google's full attention.
- hackcasual 10y agoI believe the 30,000 is from how many certificates 3rd parties validated for Symantec, without keeping adequate records or controls in place.
- ploxiln 10y agoI think this is it. I think it needs to be worded: "There are 30,000 certificates which no one knows for sure the validity of, and thus need to be revalidated." The 127 merely proved that misissuance was quite possible, and did happen numerous times. EDIT: I think that's really the crux of the issue. These 127 certs which Symantec claims are "harmless" are merely the ones which were stumbled across and obviously very "how is this even possible" wrong. That's why the 30,000 is the "size of the risk". The big "Symantec" problem is that there's no good way to distinguish these 30,000 from the many more certificates issued by Symantec under different brands. For Google it's all-Symantec-or-nothing. So they're coming up with measures that apply to all-Symantec.
- 0x0 10y agoWith Symantec joining the ranks of StartSSL and WoSign, they can hardly claim to be "singled out". PS: It's funny that Symantec's first google hit for "Encryption Everywhere" prompts for my browser's geolocation unsolicited. If your product is trust, maybe you should think a little bit more about how you present your product.
- tajen 10y agoPerhaps StartSSL was a life-size rehearsal of the process, making sure that everything was in order in preparation for Symantec's dismantling. No earlier than this week has Chrome 57 been rolled out. I know that because a customer reported to me that one of my website was distrusted – I had forgotten a StartSSL certificate over there, and sure enough I didn't notice it because I was still on Chrome 56. Sounds like a timely coincidence: If I were Google I would exactly try to distrust a small CA before attacking a bigger monster.
- jwilk 10y agoArchived copy, which doesn't require JS: https://archive.fo/4DAKD https://archive.fo/4DAKD
- Semaphor 10y agoHeh, I thought it was funny that I had to whitelist a google domain (ajax.googleapis.com) for the site to load :D
- guelo 10y agoWow, well with that response now I know for sure never to recommend any Symantec products
- kalleboo 10y agoI've never heard anyone in my life recommend Symantec products.
- robbiet480 10y agoBy blog post do they mean the blink-dev mailing list thread [1] that announced Google's action plan? [1]: https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/rpxMXjZHCQAJ https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUA...
- sparkling 10y agoShort SYMC
- unabridged 10y agoExactly what I'm thinking. Who would give Symantec money? I can't imagine the type of business that would pay them for security.
- technion 10y agoThe irony is everything I've been hearing was that Symantec was on their way back to recovery as a company after somehow selling off the woefully under-performing Backup Exec line in order to focus on the security market. Which really is SEP and their SSL lines.
- jupp0r 10y agoSadly, security is often reduced to compliance. Nobody ever got fired for buying IBM ....
- hackcasual 10y agoThe TL;DR of this whole thing * Root CA practice allows delegating validation to 3rd parties * However, the Root CA must accept all responsibility for any mis-validation the 3rd parties do. No throwing them under the bus * Symantec delegates validation to 4 different companies to serve local markets * Said companies fail to adequately validate domain ownership * Symantec attempts to throw them under the bus Further compounding the issue is that there is no way to separate the certificates that had more rigorous validation than the ones validated by these 4 companies
- angry_octet 10y agoIt seems 2017 is the year that blustery ignorance of facts became fashionable. Thankfully they can deny deny deny and stamp their foot however much they want and it won't matter.
- fooey 10y agoSeems like escalating this fight with Google is pretty much the last thing they should be doing. They need to be proving they can be trusted, not throwing a tantrum.
- orless 10y agoThis is probably intended as damage control, but I think this response will do Symantec more bad than good. No problem description, no explanation of consequences for customers, no acknowledgment of the failure no action plan, no schedule, no options, nothing. As a reader if I'm already aware of the problem, this response provided zero substance to counter Google. If I'm unaware then I'm welcome to google what it's all about, land on the blink-dev post, emotionless and factual. The whole issue is about trust, but so far Symantec does not seem to act responsibly which does not help to re-establish trust. I also wonder what the exact consequences will be (Symantec post fails to explain this). I mean, which big sites will be hit? When? For how many users?
- orless 10y agoA much more interesting document is "Symantec Second Response to Mis-Issuance Questions – February 12, 2017": https://bug1334377.bmoattachments.org/attachment.cgi?id=8836487 https://bug1334377.bmoattachments.org/attachment.cgi?id=8836...
- dionysianstanza 10y agoStraight onto the offensive, as opposed to addressing the quite serious issues and criticisms which face them. Their response speaks volumes.
- draw_down 10y agoWe didn't take the responsibility of being a CA seriously, and now Google is being mean to us. Waah.
- Manishearth 10y ago> Symantec has publicly and strongly committed to Certificate Transparency (CT) logging for Symantec certificates and is one of the few CAs that hosts its own CT servers. Lol. This is like being court-ordered to do community support and then bragging about all the volunteering you do. Symantec was forced by Google to do CT. See https://security.googleblog.com/2015/10/sustaining-digital-certificate-security.html https://security.googleblog.com/2015/10/sustaining-digital-c... , specifically: > Therefore we are firstly going to require that as of June 1st, 2016, all certificates issued by Symantec itself will be required to support Certificate Transparency. (By the end of this year, all CAs will be forced to do CT, but Symantec was forced into this last year, because of the stupid shit they keep doing)
- Manishearth 10y ago(To be clear, they weren't forced to run their own CT log, they just had to have CT set up, however setting up their own log in light of these restrictions is a business decision and not an indication of commitment to CT -- paying someone to run a CT log for them would probably be more expensive. By the end of this year we may see more/cheaper options for CAs who need to log their certs.)
- Buge 10y agoDo CAs have to pay the log providers? From this article it sounds like Google is adding certs to their own log for free. https://www.certificate-transparency.org/faq https://www.certificate-transparency.org/faq Also >Anyone can submit a certificate to a log, although most certificates will be submitted by certificate authorities and server operators. https://www.certificate-transparency.org/how-ct-works https://www.certificate-transparency.org/how-ct-works
- Manishearth 10y agoI was under the impression that there wasn't any "free to use" log out there, at least not for someone with the volume of a CA. I could be wrong / this might have changed since last year.
- wav-part 10y agoJust migrate to DNSSEC/DANE already. CAs have no incentive to mis-issue certs. CAs whole business model is selling trust. Its obvious TLDs (.com/etc) are the one who should validate/issue certs. Regarding TLDs coming under control of Govts, Its solved by independent mirror nameservers run by app devs (Firefox/Chrome/etc) and NGOs (EFF/etc).
- meta_AU 10y agoPitty DNSSEC has its own implementation issues.
- tptacek 10y agoThere has never in the history of the Internet been a time when DNSSEC was less acceptable than it is today. People who don't know much about DNSSEC (reasonable, since nobody really deploys it, and it's a dying protocol) really only need to know one thing about it: it's a tree-structured PKI, just like the CA system, except that the top of the tree is run de jure by world governments. If DNSSEC had been deployed 10 years ago, Muammar Ghaddafi would have been BIT.LY's CA. https://sockpuppet.org/blog/2015/01/15/against-dnssec/ https://sockpuppet.org/blog/2015/01/15/against-dnssec/
- wav-part 10y ago> it's a tree-structured PKI, just like the CA system, except that the top of the tree is run de jure by world governments. Which can be solved by having bit.ly key validated by .ly key + Firefox key + LetsEncrypt key. DNSSEC may have other architectural/mplementational faults but this property is not one of them. I believe this way of certification is the way forword for internet scale web of trust.
- tedunangst 10y agoThat doesn't sound like much of a migration.
- wav-part 10y ago
- natch 10y agoAs I read it Symantec is being tone deaf here about the problem. Throwing around numbers like 127 versus 30,000, they seem to be overlooking the fact that trust flows downward from a small handful of root certs, or certs closer to the root, and that if the root cert or certs and processes around them are not trustworthy, then all the subordinate certs are tainted. They aren't helping themselves any with this kind of post, imho.
- korzun 10y agoSomething, something, WMD's.
- Animats 10y agoSite stuck at "Loading Your Community Experience".
- ganfortran 10y ago> While all major CAs have experienced SSL/TLS certificate mis-issuance events, Google has singled out the Symantec Certificate Authority in its proposal even though the mis-issuance event identified in Google’s blog post involved several CAs. "We are not the only one doing this, why us Google, why us?" What a shitty excuse. Laughable. Big F to Symantec and wish you bankrupt :)
- tajen 10y agoI wish Google were more serious. A proof of deceptive falsification of certificates by a CA should lead to an immediate distrust in browsers, period. The job is on the side of CA companies to run audits at the extent of possible damages, just like in nuclear plants: You just can't do a mistake, and certainly not 127.
- scrollaway 10y agoSo chrome can no longer browse ~30% of the secured web. People instead install a different browser that isn't so "serious", as you put it. Oh and the message that sends to website owners? "Just don't use HTTPS, your SSL certificate could be invalidated with no prior warning for reasons that have nothing to do with you". Easy, right? Just like a nuclear plant.
- tajen 10y agoI don't know, what's best for security? The message is don't use a dodgy provider. Yes it's a pain for customers, but don't forget we're mostly talking about level 2/3 certificates (EV, wildcards), so we're talking about banks and major companies here. They both should and have enough resources to monitor the trustworthiness of their providers. In the current case, Symantec's falsifications has been know for long enough.
- cryptarch 10y agoI do think the "drop it like it's hot" approach could work, but it would require browser vendor coordination, so that Symantic https stops working on all major browsers at the same time/day. And honestly, banks should have the expertise and resources to change certs in a day or two, and if they don't that's on them.
- Grue3 10y agoI'm not aware of the details of this particular case, but now that Google owns its own CA, it being in charge of unilaterally banning other CAs from Chrome is a massive conflict of interest.
- HappyTypist 10y agoGoogle doesn't issue certs commercially, and I can assure you that the team that works on Chrome CA issues isn't concerned about Google's ca
- Grue3 10y agoConsidering I don't trust Google, and Google employees (most likely) went to great length to downvote my concern, forgive me if I'm not very assured by your statement.
- apecat 10y agoSymantec is now a company that operates both as a CA and, having acquired Blue Coat, also as a vendor of TLS intercepting middle boxes that they sell to despots. With this history of mis-issued certs in mind, Symantec's CA business should be kicked to the ground, left bleeding and never be trusted again.