What I don’t understand, and maybe someone can explain it to me, is this: how is an outfit like Let’s Encrypt more trustworthy? I mean, I support the EFF, I use Let’s Encrypt-issued certificates, and I’m very happy with it. But if nefarious outfits can take advantage of Symantec such that they get deemed untrustworthy, what’s to keep the same thing from happening to Let’s Encrypt? What are the “corners cut” that this article talks about?
2 Likes
Hi Ken,
Wasn’t meant to be a slant against this site, the numbers presented were exaggerated. I realize that the members on this site are just commenting on what was already written and know with certainty the posting did not originate here.
Hopefully that reassures you that I wasn’t directing any negativity against the team here.
Kind regards,
Ed
1 Like
Let’s Encrypt uses a set of tools to handle automated certificate generation. Symantec’s woes appear to come from the fact that humans were able to override the usual “generation methods” for certificates using a test tool, and appear to have done this 30k times over several years (so the issue is systemic, not some one-off issue).
Let’s Encrypt uses technology to handle this process. The technology may well be faulty now or at some point in the future. This is why Let’s Encrypt issues 90 day certificates - a breach can, in the worst case, only exist for 90 days. Symantec, on the other hand, issues multi-year certificates, making the pain far, far greater as a result in situations like this.
Because these systems are not automated in the same with Let’s Encrypt is (except for large enterprise customers), Symantec can’t really go and tell people to start renewing certificates every 90 days instead of (at minimum) yearly. Part of that is because Symantec has to consider profit, not public-interest - if they make the process too burdensome, customers will go elsewhere.
As a result, yes, Let’s Encrypt certificates are a better choice, provided you can use their automated tools as recommended to handle auto-renewal every 90 days.
12 Likes
Just once I want one of these kinds of stories to be about a surfboard maker and restaurant owner and see some PR person show up. Then I can finally use my long held-in line about “Surfin’ Turf.”
6 Likes
Let’s not be insulting. His questions are legitimate, regardless of motivation.
12 Likes
Agreed. Mr. Richard has been upfront with his affiliation. That’s a pleasant switch.
Possibly, possibly not.
If I understand this correctly, the RAs involved had been issuing invalid certificates against 3rd party domains for testing purposes in Symantec’s name as CA. In such cases, the CA can contractually delegate the work to the RAs, but the CA remains responsible for the validity of the issued certificates. For whatever reasons - inadequate logging, inadequate auditing, improper and/or inadequate tools and procedures - these certs came to light after Symantec itself had been caught in the same problem, and had made a commitment to fix the problem. This is a simplification, to be sure, but I think it’s an adequate representation of the factual elements of the situation for people (such as myself) who aren’t involved in this end of the industry. (My own background is servers and operating systems - DEC/Compaq/HP in my case.)
Now, given that the quite reasonable presumption that the practices leading to the problem have been going on for a while at Symantec and its licensees, Google’s numbers are, for an organisation responsible for a browser in significant use, conservative. If they know that invalid certificates have been issued by the RAs in the CA’s name, and they know that the CA has done similar in the past themselves, and that the CA is unable or unwilling to produce hard and fast figures for the RAs, and they (Google) have no real way of ascertaining the extent that this has happened previously, then no certs issued on the CA’s behalf by the licensees can be trusted. Google isn’t claiming that all of these are invalid: it’s claiming that it can’t verify which are and aren’t.
I repeat, when representing Google’s interests in the matter (and not coincidentally, ours, the users’), this is conservative. Limiting the number to what has recently been caught is not reasonable. Given the spanner a complete and immediate withdrawal of trust would throw into the works, Google’s phased withdrawal of trust is a reasonable compromise: it gives sites dependent of Symantec certs time to switch; it gives Symantec time to bloody well fix the problem.
Under the circumstances, I think that Google’s assumptions here aren’t unreasonable. I also think that Symantec’s claim that the numbers aren’t any greater than what has been caught, and that there isn’t a significant problem is an extraordinary claim, and, like all such, requires extraordinary proof.
10 Likes
Are Let’s Encrypt issued certificates trusted by default in all of the major browsers?
2 Likes
The Extended Validation certificates are issued manually because they go through a substantial manual process to make sure they are issued only to the people that legally should own them. For all of this, there has not been any indication that any have been issued to malicious parties (I’ve not run down all the links, but they don’t mention that in the google posting, or news stories). And they cost $1500 a year, and turn your adress bar a nice shade of green.
1 Like
Let’s Encrypt is an automated system which proves that you control the domain as part of the certificate-signing process.
By comparison, Symantec admits to having generated certificates for domains not controlled by those who requested or received the certificates. For example, signed certificates covering both “google.com” and “www.google.com” were generated by Symantec back in October 2015, not on behalf of Google.
(Symantec’s position on the above seems to be that these certificates were generated for testing purposes only, never made it out onto the Internet, were generated in violation of company policies, the employees who generated them have been terminated, and everything is hunky-dory again now so please everybody just put down your pitchforks and enjoy your certificates.)
3 Likes
If Google found out about them, then they most certainly did make it out onto the Internet, eh?
3 Likes
Not necessarily. Google says they found out about the certificates’ issuance via the Certificate Transparency Service, which is an append-only log of various certificate activities. CAs are encouraged to add a log entry every time they sign a certificate. And it was in that log that Google found references to the certificates Symantec signed for ‘google.com’ and ‘www.google.com’. It seems likely that Symantec’s signing tools automatically submitted the certificate metadata to Certificate Transparency when the test certificates were signed.
Thus, the certificates themselves could quite plausibly have remained internal within Symantec, whilst proof of their generation was transmitted out onto the Internet for Google to find.
With that said, it’s also possible that Google’s webcrawler came across a publicly-accessible Internet site using the certificate, as Google’s webcrawler does log all certificates it encounters into Google’s own Certificate Transparency log. But I would have expected to see an (even) bigger public outcry if that had been the case; it seems far more likely to me that the certificates did remain internal at Symantec, at least in the case of these testing certificates.
5 Likes
Hi, fellow VMS admin!
Actually, I was on the service side of things dealing specifically with x86 boxes, so pretty much anything but VMS.
WfW? Sure. Linux? Xenix? Sure. Netware? NT? OS/2? Yup, yup and yup.
1 Like
Unless this was BYOD, you know that icon that is labeled “My Computer”? Guess what? It isnt yours. Symantec wasnt necessarily the problem here.
Did you have local admin or did someone install the tools for you? Either one should have probably required someone somewhere to sign off. Maybe the problem was process failure or poor interdepartment communcations?
Was there some kind of exception process that you completed to get these tools installed? If so then the fact that they didnt get added to the exception case config for Symantc for your machine shows a process or communications failure.
As per @ronaldpottol comment later, that does nothing in regards to Extended Validation.
Ultimately as Cory hinted, this is a very old problem known about since the first commercial CAs. Let’s Encrypt does not solve this problem at all and I’ve never understood that the purpose of Let’s Encrypt was to solve the problem of “does this server really belong to who it claims to belong to?”.
1 Like
So that’s why the pawn shop wouldn’t buy it from me.
Actually, it became BMOD for a lot of things, rather than repeatedly jumping through all of the hoops required by my employer and/or our client in order to do my somewhat specialized job.
1 Like
Having dealt with Norton Antivirus for almost two decades now…
No?
11 Likes
This would have been back when DOS was still the main OS to use. Once Windows 95 came out, things started to go downhill from there.
6 Likes
True, you have to go back farther than that. Norton Utilities was freaking useful back in the 80s & early 90s.
10 Likes
+1 for suggesting Let’s Encrypt. I know very little about certs and security (though trying to learn more now that our sys admin was fired), but I’ve just set up our website to use letsencrypt. It’s easy to use and when I had some difficulties and posted a question on the forum, it was answered in less than an hour. (I don’t have any connection to the org except that I am a fan.)
1 Like
