Chrome's Plan to Distrust Symantec Certificates
security.googleblog.com
security.googleblog.com
The incentive for a mass-market browser is to trust pretty much everything, but I'd prefer to use a browser that is a bit more paranoid.
If a website can't load properly because I don't trust one or more of the CAs, I might want to temporarily "live dangerously" but would be a bit more cautious about typing data into a form, etc.
Browser vendors should not try to create a one-size-fits-all list of trusted CAs, since there is obviously a very different level of trust deserved by various CAs based on the track record of each one.
If I were a state actor intelligence agency, compromising CAs would be toward the top of my list because of the amazing opportunity for man-in-the-middle attacks.
Distrusting Symantec certificates is a great step in the right direction.
I cannot read Mandarin or Turkish, and in the unlikely event I get forwarded to a site from a company targeting citizens from these countries, I'd prefer to just get an SSL exception instead of the 'trusted' page.
That just makes the normal user who wants to buy stuff learn to ignore SSL errors.
I think the @grandalf idea of selectable trust list providers has some merit (although there are some security trade-offs there).
I don't think the automatic mistrust of certificates from "CAs from China, Turkey, Russia" automatically follows from that.
Oh, what's that? Symantec is an American company, headquartered in Mountain View, CA?
I'm not sure a geographically silo'd internet is what we should be going for. i miss the days when the dream of the internet was prefiguring a borderless world.
Then absolutely not. Why should a US company not be allowed to use a Swiss-issued certificate for a .io domain name?
Again, I cannot read Mandarin or Turkish, and likely never ever will. It seems to me that it'd be much more likely that a site, even if run by Chinese or Turks, caters to American customers, should invest in a certificate trusted by a US CA, and similarly for every market they expect to do business in.
And likewise, I don't know why localized versions of browsers for the Chinese market would include trusted certs from Turkey or Brazil.
Seems like its a lot easier to force multinational companies, who already are going to have to invest in huge amounts of research and technology to deal with foreign taxes, currencies, bank accounts, etc., to add to their burden the responsibility for obtaining certs from their customers' local CAs, instead of having every single CA on Earth be trusted by all releases of browsers.
You are free to delete CA's from its trust store.
What Chrome is doing is irreguarless if that cert is in your OS's store it won't trust it.
Keychain for OSX
mmc in windows cmd prompt
Linux has /usr/share/certificates
It depends on the browser -- e.g. Chrome uses the system's CA certs, but Mozilla ships with its own.
But you do; the trusted entity is your browser manufacturer. Given the massive amount of attack surface in the browser, I'm already trusting my browser to make sound security decisions all the time. And I've seen really good work from both the Firefox and Chrome teams on asking hard questions towards CAs; I don't think I can think of a group I'd trust to make better decisions. (Arguably there's the EFF, but I definitely trust the EFF less as a technical body than Mozilla or Google, for the simple reason that the EFF is an advocacy body, not a technical body.)
> The incentive for a mass-market browser ... If I were a state actor intelligence agency
But protecting against intelligence agencies is most effective and important in a mass-market browser, not in a nerd browser. There isn't any sense in a society where nerds as a group have more protection against government dragnet surveillance than everyone else.
If you're a specific nerd working to save the world in a specific way and you're worried about targeted attacks against you personally, you have a threat model that can't be adequately responded to by trusting a subset of CAs. You need to do your important work on a machine that's locked down far more deeply than just by distrusting a few CAs (e.g., you probably want to disable 80% of the web platform to reduce attack surface), and ideally you'd do your less-sensitive work, e.g., reading the news and chatting with friends and listening to music, on a browser that looks as normal as possible to avoid standing out.
2. Create and install own CA certificate
3. Download or create desired server certficates, sign them with own CA and install them
I have not tried 1 but I regularly do 2 and 3. (Usually for monitoring outgoing encrypted traffic.)
Anyway, the idea of your comment is spot on, I think. The process whereby users blindly trust browser authors has serious flaws.
The user should be the one controlling the list of trusted CAs and servers, not a third party such as ad-supported company or organization distributing a web browser.
The more the user (cf. third parties) actively controls what endpoints she will trust, the better.
The system should encourage users to be active in managing what certficates they will trust versus passively letting ad-supported web companies do this for them.
It is the user who has the greatest incentive to make things right in terms of her own security and privacy. Third parties may help, but they ultimately have their own interests to worry about.
No, they really shouldn't. Security is a ridiculously complex arena, and the amount of knowledge you need to make an intelligent setup on this is considerable. For tech-heads, fine, but the vast majority of people are not tech-heads.
If you switched over to this model, we'd end up in the bad old days of Windows XP, where untrained people would advise untrained people to 'just install this package and everything works!' and half the time they'd be installing malware. The right way to do this is 'sensible defaults, that the user can adjust'.
1) Piss off the like, 10,000 technical nerds who care about this, by having sensible defaults. "We should really teach people to fully manage their CA chain! It sucks I have to spend 20 minutes doing this once a year after spending 10,000 hours learning how computers work."
2) Don't piss them off, but in return, get ready for user-blaming whenever someone messes up, and for your users to be 'responsible' for themselves. "If users were EDUCATED and not so stupid, they'd be able to spend 100 hours understanding the CA system and keep themselves secure!!! Not our fault if you install certificates from Brazilian hackers"
I dunno, it's mostly an observation, even if it's something of a false dichotomy, but this always seems to be the way it goes. Technical users simply have vastly different value systems. But honestly, my go-to strategy these days is mostly "whenever most technical people try to give security advice and speak on behalf of most users, almost always: do the exact opposite thing, in order to keep the users secure".
Most of us have some variant of Stockholm Syndrome to some extent.
Speaking more generally, rather than specifically about CA chains, I respectfully disagree with you there.
Imho, what usually happens in a sane world, is that we spend most of the time between these two extremes, in a pendulum as we balance one way, get burned, go back the other way, get burned again and repeat.
Im fine with it being that way until someone releases a true ground breaker and redefines what we are balancing.
>But honestly, my go-to strategy these days is mostly "whenever most technical people try to give security advice and speak on behalf of most users, almost always: do the exact opposite thing, in order to keep the users secure".
I think I understand what you are saying, but that comes across as you cherry picking the bits of a technical persons advice that a layman wouldn't understand. The "exact opposite" is sorta hard to define.
What I see in this thread looks more like an insidious middle: people who think they are experts, but are asking browser providers to do the development to change the entire product and provide a nice friendly UI.
This seems like an area where the old maxim applies that if you have to ask for help, maybe you're not as expert as you think you are.
It's easy enough to remove CAs for one's self, the issue is understanding the possible entanglements that might make some of them less trustworthy or more easily compromised. That requires quite a bit of expertise and judgment.
(Or they'd just switch to a different browser without these problems).
I understand the intent of your suggestion, and you're not wrong in an ideal world, but mass-market security needs to take actual human psychology of non-technical users into account too.
Discussion on Super User (Stack Exchange): https://superuser.com/questions/818065/how-to-know-which-cer...
In any case: scan the hosts in your web history, and follow the cert chains to the various roots.
Not sure if you're asking how or if you're asking whethor or not someone has already implemented something like this that is easy to use.
That's simple SQL query against the Firefox profile sqlite database. No problem.
> and follow the cert chains to the various roots.
Doesn't scale. If it can't be scripted, then it can't be done for tens of sites that I regularly visit, and hundreds more that I come across.
This is an idea that I hear in variations from time to time, yet I think it's utterly wrong and goes against everything we know about IT security UI.
The reason why HTTPS works at scale and is - with all its weaknesses - a crypto success story is because it works automatically. Unlike other things like PGP that ultimately expect from the user to get an understanding of complex concepts like public key cryptography and web of trusts.
What you're trying to do is move HTTPS away from "it just works" to "user has to understand what a CA and a PKI is".
Fortunately none of the relevant actors or browser vendors is moving in that direction, the opposite is happening. HTTPS is becoming the default, it works automatically and the security improvements that are being deployed (mainly CT) are systemic improvements to strengthen the whole system.
If Convergence[1] ever becomes a thing, then I think your proposal makes sense, otherwise not really.
Again -- HTTPS errors are not exactly the epitome of the best UX. You could pop up a dialog saying "We can't seem to verify this site is really x.com. It might be someone else impersonating x.com. What would you like to do? [Ask Google/Microsoft] [Continue] [Cancel]" or something like that. And asking Google/Microsoft would be implemented by checking that the certificate is what they expect (so that we know it's not a MITM), whose public key they have already hopefully known about and pinned.
Note: I just came up with these ideas on the spot. I believe they're much better than the current system but in no way am I suggesting they have no room for further improvement.
Because that's exactly what you're proposing.
1. "Certified by" — what does this mean? Is like a rating thing? A tripadvisor thing for the web?
2. "X" who are they? Do they want my money? Do I need a new one?
3. "Current trusted certifier" oh god, did I choose them? Are they bad now? Did I not pay them money? Has it been hacked? Didn't it do a review of BigWebsite yet maybe? I could just wait I guess.
4. There are three buttons that say "yes"! If I hit "always" what if it was wrong? And "if Google verifies" well that's obviously a scam because my web is Google so it would already know. This is all some kind of scam. I'm out of here.
I honestly don't see why the concept of "This site claims to be WorldBank.com, but we can't verify this. Whom do you trust enough to ask?" requires technical knowledge of any kind. People already understand this is why they have ID cards and background checks -- "I don't know if I can trust this guy; do you trust X to run a background check (or ask him to show an ID card issued by Y)?" is the same exact concept. Why do you think ordinary people fundamentally cannot understand this on the computer when they already understand it (and much more difficult things) just fine in real life?
Also, don't forget that none of this applies to when you choose the default settings. This is only if you choose to distrust some organizations.
They don't do it because they're not employers/landlords/etc. and hence the need never arises, not because they somehow have a complete lack of understanding of the concept.
> and don't have a well-formed mental model of why they're necessary and what the security risks in using them are
They understand why they need to keep their bank passwords safe, and hence they can understand that they shouldn't enter it on someone else's website. They understand what a fake ID or passport is, and they understand why they shouldn't give their ID numbers to random strangers.
The specific examples I used are not the point. I explicitly said they're not perfect; they're just there to get a bigger point across. Look at the larger point. The point is people are already dealing with much more complicated stuff on a daily basis. They understand the concept of lying. They understand that identity theft can wreak havoc on their lives. They understand how to prevent it. So they can handle the concept of what it means to enter their credentials on the wrong site. It's not technical and it's not complicated, and it's not necessary for them to understand how exactly doing the wrong thing might lead to an undesirable result.
If you'd like to convince me that the average person can't understand this concept, at least support your claim by providing a link to a study or something that isn't based on a cherry-picked strawman version of what I've suggested? Surely someone's already looked into this kind of an approach and what you're saying isn't just pure speculation?
But I'm only saying the current UX could become much better, not that they have to switch to my suggested UI by tomorrow. Of course spending some time on user education and transitioning gradually would be a great idea. I was never against that; I'm all for it. So why implicitly rule this out as an impossibility?
Not in my experience - people reuse passwords regularly, and are exceptionally vulnerable to phishing scams, as you should ask anybody working in corporate IT. This is why people actually working in security are very excited about U2F - a U2F-generated token is tied to a specific domain, so password reuse and phishing are both no longer as serious a problem, since a login to scammer.com no longer works as a login to mybank.com.
On top of that, people give their bank passwords to e.g. mint.com on a regular basis, when it's specifically asking for their bank password and they have no reason to trust that website.
> they understand why they shouldn't give their ID numbers to random strangers
Also not in my experience, and the basis of many scams.
People at large are terrible at security. We've been moving towards "automatic security" for a while for a reason. And that's before you get to the phenomena where critical thinking goes out the window as soon as something is on a computer instead of "in real life".
> Surely someone's already looked into this kind of an approach and what you're saying isn't just pure speculation?
Moxie Marlinspike's Convergence would be the closest thing, iirc. Whenever you access example.com, you ask a handful of user-selected notary servers to access example.com and tell you its TLS cert. If all of them match, you're not being MITMed. You don't have to trust any individual notary server, because it's all of them put together that provide the trust.
Of course, trying to figure out a good UX for "my Government and Google say it's fine, but Estonia and Facebook say it's not" in such a way that users aren't going to be severely inconvenienced by a malfunctioning/MITMed notary server but also aren't going to click on "I have no idea what this is just let me see the website" on a MITMed page is hard - probably impossible. Moxie has since given up on it.
And thus crippled and useless against state attackers.
I fail to see the reason why my browser refuses to let me "pin" a CA only for certain sites for example.
Suppose 5% of CAs are compromised. Is that a success? It is if you compare it to everyone using self-signed certs, but it is not if you consider that there are likely broad vulnerabilities that can be silently exploited by some groups/nations.
We don't hear much about man in the middle attacks because we have no reason to be aware of them.
> it just works
The point of my remark is not to suggest that a list of trusted CAs compiled by someone like Bruce Schneier would result in a broken web. If it would, then it's hard to argue that the system is not already broken.
The point is to allow experts to establish authority on the basis of careful (possibly paranoid) stewardship of a list of trusted CAs. Then when an attack is revealed experts who whitelisted that CA lose a bit of credibility, and those who blacklisted it gain some.
As it stands, firms that ship a default list of trusted CAs have an incentive to err on the side of whitelisting, and then claiming "oops we had no idea that CA x was compromised..."
There are clues about the relative trustworthiness of CAs, some of which are simply the governments that have jurisdiction to demand private keys, etc.
https://support.norton.com/sp/en/us/home/current/solutions/v...
was a key component of my debloating efforts back in the XP days.
Oracle snuck it onto my system in a java update and I ended up having to dig through the registry and disk to weed it out. It is malware, plain and simple.
Here’s an interview with the VLC developers, where the VLC developers complain how Google tried to get them to secretly install Chrome with it, and offered enormous amounts of money, but they obviously said no: https://www.youtube.com/watch?v=jWx1P93nS0c&t=48s
It's funny they still mention giving Symantec an opportunity to modernize and redesign its infrastructure when Symantec simply decides to give up: http://investor.symantec.com/About/Investors/press-releases/...
Interestingly, this investor.symantec.com doesn't properly support HTTPS at all (certificate host name mismatch). I guess that speaks volume about how much Symantec itself cares about SSL/TLS and PKI.
In fact, I don't even seem to able to find certificate information in Chrome any more - clicking on the padlock just gives me a bunch of settings and "Learn more" which is some annoying page.
Edit: It's in Developer Tools under "Security"
Does anyone actually look at or care about that?
[1] https://www.troyhunt.com/journey-to-an-extended-validation-c...
Which means that nobody notices the lack of EV on amazoone.com, because, well, it'as Amazon.
What good would that header do? A phishing site (say, "paypaaaaal.com") would simply not set it.
> Or maybe all websites that request certain info (like SSN or credit card) should be required to have EV.
EV certificates are not available to everyone. In particular, they're only available to users in certain countries, and even then only to registered businesses.
Besides, how do you enforce a requirement like that, short of barring users from submitting data that looks like a credit card to a site without an EV certificate? (Which would cause massive and entirely justified outrage, and would be quickly bypassed by phishing sites regardless.)
It would protect against MitM attacks where the attacker has fraudulently obtained a non-EV certificate, such as through CA compromise or a BGP attack, especially since EV certs are required to have CT log entries. I guess since Expect-CT already solves this, Expect-EV may not be that helpful.
>EV certificates are not available to everyone.
I agree this is a problem. EV should be available to anyone anywhere willing and able to prove their legal identity, be it a person or an organization. Then if someone uses EV to phish, they can be held accountable.
>how do you enforce a requirement like that
If this becomes standard, then we can train users to expect EV indicators when asked for payment data. Any site asking for it without EV would automatically become out-of-the-norm.
Users seem to notice but often times there's confusion as to why the address bar is, for lack of a better term, stuttering.
And god help you if your certificate uses a name you don't have any branding for.
It always seem to be German firms that don't just get the internet at all
No. You'll note that Amazon doesn't. They spent a bunch of time trying to figure out if it made a difference for customers. It turns out it doesn't, so they don't bother with the extra expense.
I'm interested in the Amazon study if you have a link, I haven't seen that before.
(Note, I run CertSimple and we specialise in making the verification process for EV faster and much less painful, so I'm biased)
You can make the EV process as smooth and simple as you like, but unless there's good solid business value provided by it (in $$s terms), you've got way more of an uphill struggle ahead.
Note: I'm biased. See bio.
So yes, if you're using Gandi (and I still do myself for things LetsEncrypt cannot be used for, namely things where frequent rotation requires time-consuming manual intervention) you are safe from Symantec's distrust.
In simple terms: DV proves you own your DNS domain and EV proves that your real world entity owns the DNS domain.
Lets Encrypt will only do DV and quite right too. EV costs a far bit more because it should require some proper checks - for example checking Company's House in the UK for a Limited Company's details and matching them up against real people.
You can set a flag in Chrom{ium!e} that will put a link to the cert in the menu that drops down when you click on the green bit, saving you a trip to dev tools. Go to chrome://flags and search for "Show certificate link". Don't know why it isn't the default.
Thanks for this tip! I like to check the certificate, so this will save me some clicks. I also don't know why it's not enabled by default.
It’s incredibly fast, the guy who runs it is nice, great customer service. It just does what you need.
It talks about 'bankofamerica.com.fraud.ru' in the first paragraph, but then discusses how 'fraud.ph' (why did we change TLDs? This should stick to ru or the above should be changed to ph) gets a wildcard cert for '* .com.fraud.com' (we changed TLDs again, to com this time. I assume we're talking about 'fraud.ph' getting a cert for * .com.fraud.ph - or .. we stick with ru)
Sorry, what's a company that needs to show the company name beside the padlock? (Except maybe: Company that has too much money to spend on pointless "premium" security services without any shown benefit.)
For example, I can go grab something like "bannk.com" (notice two 'n's) and get a DV cert for it - because I hypothetically own that name. Now, I can copy the real "bank.com" onto the site and perform a phishing attack. They both appear to be encrypted but the EV'd one has the organization noted, the fake one will not be able to have that legitimacy.
I am not saying the system isn't without its faults (people might not even notice), but it's an extra measure a company can do to keep itself distinguished from phshing websites or copycat services.
on the contrary, I know that the presence of an EV line has helped my mother avoid a pretty decent phishing attempt. Any company holding confidential details or data should have one, its just a shame they are so expensive (which due to their verification is unlikely to come down too far).
It looks like lots of big name sites don't use them. Why do some companies feel they need it, while letting internet giants such as Facebook, Google, Microsoft, etc. get away without it?
Eg anyone could register "bankofanerica.com" and get a DV cert issued for it.
Only Bank of America can get a cert that shows their legal/trading company name.
Well, that's the idea. I'm not aware of any ev misissuance but I don't follow this stuff like a hawk either.
I think routine checks should done to all CAs, they are an important part of how "trust" works on the internet. and I see their importance only growing at this point.
Google should not be the only company trying to enact change in this area.
[edit: so many typos - oops]
Fortunately they're not. Mozilla is involved here as well; just look at [0] and the other *.mozilla.org links in this thread. They also broke the WoSign/StartCom debacle.
The less entities you have to trust, the better.
I understand banks are free to have some kind of direct-transfer mechanism between them, like internet peering, it would just be redundant.
But anyway, I would not trust SWIFT as gatekeepers of banking security. They're a prime example of a business that runs on COBOL written 40 years ago and they're not the paragon of progressive thinking in banking (SWIFT could torpedo Western Union overnight if they really wanted to) and finally, they already have a poor reputation in INFOSEC circles: https://en.wikipedia.org/wiki/2015%E2%80%932016_SWIFT_bankin...
Banks shouldn't be relying on outdated infrastructure providers to do things they aren't good at. The sensible thing (and indeed more or less what happens now) is for banks to choose a best-of-breed CA to issue SSL certs, the same way any other company offering sensitive services over the Internet would do it.
To a certain extent the alternative here is to put all your eggs in all the baskets - if an elephant steps on any one of the baskets the eggs (your security) breaks...
It's much worse to trust a single weak entity for 1/1 of your security.
That said, it's possible SWIFT can be a good CA. But you shouldn't choose them if they do a crap job of it, simply to "reduce the number of entities you trust".
Not to mention that Google has been pushing hard for https on all sites, which is exactly LE's goal.
They're probably the most trustworthy CA on the planet.
If you want to passively monitor encrypted traffic on a massive scale and not get caught (other than via their log - and who is reading that to see if every server they have has been issued a cert unnecessarily, anyway?), LetsEncrypt is awesome. It's plausible to do this without LetsEncrypt, but they made it a lot easier.
As opposed to any other CAs? There are plenty of other CAs that will happily grant a certificate if you prove control of a server that the domain resolves to.
>nothing generated has a password on it, I don't know if I would consider them really trustworthy.
If you have root on the server, can't you just dump the certificate out of memory, even if there's a password on it? short of using a HSM, you need the certificate decrypted so the server can use it.
Passwords provide security for data at rest, a properly hardened server makes it very difficult to dump memory in certain circumstances, and hsm are practically a requirement in some environments.
And finally, say I wanted to use LetsEncrypt, but I wanted to manage the keys myself, and require only private key X could be used to sign Y, and manage it myself. They don't really let me set those requirements at the CA level - it's all on my own host + network security, which IMHO is unnecessarily risky.
CAA records. If you want full control over when issuance happens, you can even set the list of allowed CAs to empty and only change it when you actually want a certificate.
> And finally, say I wanted to use LetsEncrypt, but I wanted to manage the keys myself
If someone can submit a CSR and complete the challenges they get a signed cert, yes, just like with other DV-CAs. LE code (certbot or other clients) doesn't have to touch your private keys, as long as you give them CSRs, as with other CAs.
You absolutely can. Let's Encrypt was one of the first CAs to support CAA (and, IIRC, they supported it when they first launched). CAA is a DNS record that lets you specify which CAs are permitted to issue certificates for your domain.
> And finally, say I wanted to use LetsEncrypt, but I wanted to manage the keys myself, and require only private key X could be used to sign Y, and manage it myself. They don't really let me set those requirements at the CA level - it's all on my own host + network security.
I'm not quite sure what you're saying here. Do you want the ability to issue certificates under your own (constrained) intermediate certificate? That's unfortunately not possible under the current Baseline Requirements unless you get audited as a CA.
If you just want to use your own private key, that's of course possible (in fact, there's no way for Let's Encrypt to generate a key for you). Or is it that you want to limit limit issuance for domain X to key Y? What other CA allows you to do that? And how would you prevent some other CA from issuing a certificate for a different key, even if Let's Encrypt would support such a feature? With that in mind, it becomes clear that in the end it's up to your host and network security again, even with such an agreement in place.
> Do you want the ability to issue certificates under your own (constrained) intermediate certificate?
Look at it this way: currently, if you can send network traffic from some IP space, you can create valid domain certs. This is the equivalent of using a hosts file with a list of IPs to authenticate an ssh connection. Yes, I think an intermediary key, and not simply some arbitrary control of a network, should be required to generate a cert. It seems like CAA, or some extension thereof, could help this become a reality.
There's an CAA extension in the works that will allow you to bind domains to ACME accounts (which are protected by your account key). Let's Encrypt has plans to support it. Is that what you're looking for?
1. Webserver requests cert for xyz.com.
1.1. Generates private key
1.2. Generates csr
1.2. Sends csr to ICA.
2. ICA requests cert for xyz.com.
2.1. ICA generates private key
2.2. Signs Webserver's csr with private key
2.3. Sends signed csr to CA
3. CA issues certificate
3.1. CA looks up CCA record for xyz.com
3.1.1. CCA contains ICA's key fingerprint
3.2. CA verifies signature of Webserver's csr with ICA's key fingerprint
3.3. CA verifies Webserver controls domain xyz.com.
3.4. CA issues cert
This is true for the vast majority of all CAs.
> If you want to passively monitor encrypted traffic on a massive scale and not get caught (other than via their log - and who is reading that to see if every server they have has been issued a cert unnecessarily, anyway?), LetsEncrypt is awesome.
Wouldn't you rather pick a CA that doesn't log all certificates publicly? (At least while that's still possible - i.e. till early next year.) If you're doing this on a massive scale with a CA that logs publicly, there is absolutely no way you're not getting caught.
Certificate Transparency Monitoring is fairly easy to set up, by the way. Even Facebook runs a public monitor you can use.
You can generate and handle the private key entirely yourself, without ever having LE code touch it if you want. You only need to generate CSRs from it.
And you now more than ever have tools to control this if you worry about it: CT logs (that you don't have to check yourself, thanks to free services that alert you about each new certificate for your domain) and CAA records
TPMs generally aren't fast enough to do RSA signatures a on busy webserver though, but they're wonderful for protecting VPN certificates (tools for managing this are built into windows Group Policy, I imagine it's very painful on Linux)
Distrusting Symantec is not an arbitrary action as some people seem to believe.
When they start issuing illegitimate certificates.
RIP RapidSSL wildcard
They are? It seems pretty clear to me. Symantec's old infrastructure will be distrusted in Chrome beta in September 2018. At that point, no certificates issued by Symantec's old root certs (including those issued after June 1, 2016) will be trusted.
However they didn't say when they would do that.
LE wildcard certs will only be DNS validated and not using a web server (for obvious reasons, when you think about it)
I'm not sure what it says that Google doesn't trust the company that operates the registry for .com
Don't read too much into Alphabet/Google using other gTLDs instead of .com, like https://abc.xyz or https://blog.google -- that's separate work done by separate people on a separate team.
On the other hand, I’m positively surprised by how well DENIC (.de) handles it all.
If you are a site operator with a certificate issued by a Symantec CA prior to June 1, 2016, then prior to the release of Chrome 66, you will need to replace the existing certificate with a new certificate from any Certificate Authority trusted by Chrome.
Also, they provided several Q&A-style responses as well:
https://bug1334377.bmoattachments.org/attachment.cgi?id=8831...
https://bug1334377.bmoattachments.org/attachment.cgi?id=8836...
https://bug1334377.bmoattachments.org/attachment.cgi?id=8838...
I've always hated the concept of certain chrome extensions having full access to all the pages I visit in the browser but sometimes its necessary. Ad blockers are way too high on the list of potential attack targets, close second would be web development extensions like editthiscookie.
There needs to be a way for webpages to indicate that they don't want any external scripts running on the page. Even a setting in chrome would be really helpful. I don't want external scripts to be running on my bank website, or when I'm working with my stock exchange website. Right now I'm making do with multiple chrome profiles but that doesn't cut it. There needs to be some initiative in this regard from major browser vendors.
I was so concerned about this potentially ticking time bomb, in fact, that I sent an email about this to a prominent person on Chrome's security team many months ago.
I did not receive a reply.
Workarounds : Disable add-ons in incognito mode, and conduct your important business there..
Or use a second chrome profile with no extensions for confidential stuff..
I don't imagine an ad blocker needs the ability to send data over the network.
I also don't expect it should need to alter cookies or local storage, though perhaps there's a random counterexample somewhere?
Most importantly of all, I think disable forced auto-update of extensions would help. It would make things a lot safer if users had control over when their extensions were updated. That way a malicious version could be taken down without having affected too many people.
They tried to trademark LetsEncrypt:
https://news.ycombinator.com/item?id=11964583
https://news.ycombinator.com/item?id=11973232
Bad OCR led to certificates being issued to the wrong people:
https://news.ycombinator.com/item?id=12761248
They created their own Superfish-like adware:
There should be a standard to pin EV-ness. That way you know all certificates for your site have been issued by an audited process and not by dns hijacking.
“distrust” alone only communicates not trusting, true. But the word isn't alone, it is in the phrase “plan to distrust”, which communicates that the not-trusting is a change from the status quo that will occur in the future.
Not necessarily. "Plan to distrust" would be consistent with "a company has announced that they're going to start issuing certificates; we won't trust them". You and I know that Symantec is a major CA which is currently trusted by Chrome, but that isn't implied by the headline.
http://legaltimes.typepad.com/files/garner-transcripts-1.pdf
(IIRC Apple is on that exception list too.)
https://chromium.googlesource.com/chromium/src/+/master/net/...
And the blog post states:
> This will affect any certificate chaining to Symantec roots, except for the small number issued by the independently-operated and audited subordinate CAs previously disclosed to Google.