Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

What is a "Symantec-internal testing process" that leads to Google certs being leaked outside of Symantec? Is some engineer poking around and just used "google.com" as an example? Seems like a pretty serious wtf moment. If I was Google I would be pissed.


If it was leaked externally, it'd be more than just pissing off Google, it'd be justification for removing Symantec's CA certs from browsers. I.e., who knows what other domains Symantec might be "testing" that would go undiscovered because the owners of those domains don't have Google's resources.

But as the other poster says, this probably wasn't leaked at all.


> it'd be justification for removing Symantec's CA certs from browsers

More than half of the CAs have publicly violated trust at some point. The governments of the US and China, who are arguably the biggest threats to HTTPS, still have CAs.

While I agree with you wholeheartedly, it doesn't look like either incompetence or malice vis a vis security are substantial enough justifications for the browser makers to pull the plugs here.


Can you point to USG or Chinese CAs that publicly mis-issued or used certs? CNNIC comes to mind and they've been removed. Which others were you thinking about?


I'm not aware of any; I was just referring to the evident more general contempt for security.


In other words, no USG or remaining China CA has violated the CA guidelines and requirements publicly.


I'm not sure what you are suggesting - that the CA guidelines need to be changed? Instead of the CA system being scrapped?


CNNIC did not mis-use or mis-issue certs, but issued a cert to an Egyptian company which mis-used it, iirc.


Uh, issuing a CA cert to the Egyptian company was the very definition of mis-issuing a cert!


No, the definition of mis-issuing a cert is when you issue a Google cert to someone who isn't Google. Not doing due diligence on what people to whom you've issued a cert are doing with it is a little different.

This is just semantics, though. I think everyone agrees they done bad.


The kind where they used Chrome to browse to an internal testing website? Though using a real website, like Google, instead of a mock is quite wtf. What I'm curious about is whether the fired* Symanted engineers were just scapegoats or had they actually been reckless and unprofessional.

* http://www.symantec.com/connect/blogs/tough-day-leaders


> In addition, we discovered that a few outstanding employees, who had successfully undergone our stringent on-boarding and security trainings, failed to follow our policies. Despite their best intentions, this failure to follow policies has led to their termination after a thoughtful review process. Because you rely on us to protect the digital world, we hold ourselves to a “no compromise” bar for such breaches. As a result, it was the only call we could make.

> As much as we hate to lose valuable colleagues, we are the industry leader in online safety and security, and it is imperative that we maintain the absolute highest standards. At the end of day, we hang our hats on trust, and that trust is built by doing what we say we’re going to do.

Wow.

I have to say that I respect that decision. Without knowing the circumstances, I have to say that willful disregard for security policy while handling materials as sensitive as a CA cert is indeed not something I'd want to see from employees at a CA.


Agreed that the steps taken vis-a-vis these employees may have been the right one if they indeed breached company policy. But I do have an issue with publicizing this so openly, and using this to showoff of how serious "we" are. Even with the best intentions, you will run into bad apples. You still need to have the right controls, preferably automated, to avoid sensitive material to be used for internal purposes. Blogging on how they terminated employees doesn't help to showcase their leadership imho.


There is no basis for respecting a decision stemming from a "no compromise" policy. Such a policy is designed to substitute mechanical action for judgment and discretion.

Cf. the child-porn case also on the front page now (kid has picture of self on phone; https://news.ycombinator.com/item?id=10247764). It's probably also based on some kind of zero-tolerance policy or campaign promise.

Had the announcement merely referred to the "thoughtful review process" (which is good) but not then nullified the meaning of that process with a thoughtless "no compromise" standard (which is silly), then it'd be at least eligible for respect.


Looks like that article got pulled?


Disable HTTPS-Everywhere for the site if you have that installed. Took me quite a while to figure out.


Why does the https redirect to http? Symantec can't afford to give itself a certificate?

the java server pages application that serves the main site has extended validation https://www.symantec.com/index.jsp

but connect doesn't. It seems like https://www.symantec.com/connect/ redirects to http://www.symantec.com/connect/

r.port="https"===o[0]?"443":"80"

Why can't Symantec afford to put ssl on its connect site? It is not like they have to pay anyone for a certificate...


Not even that, the domain already has a certificate, they're forcing a redirect to HTTP on a domain that already has a certificate.


CT audit records are inserted directly by the CA. The blog post doesn't appear to say the certs were leaked outside of Symantec or used in the wild.


It sounds to me that chrome reports to google when it encounters certificate that was not issued by them.

Symantec for some reason created google certificate internally and then someone used chrome


The article mentions that the certificate creation was logged in public logs by Symantec.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: