Symantec... Google is real tired of your shit

I dunno... remember it's Symantec so the hate's pretty strong already

 

Well, some bastard is lying.

It's quite clear that Symantec are saying 127 certs. Google are saying 127 originally, expanded to 30k.

Has anyone found specific evidence that the "30K" number is certificates (identified with a thumbprint) vs names on certificates (127 certificates with 30K names listed)? I can't seem to see Google documenting the 30k cases anywhere.

 

I'm to sceptical to believe this is anything other than google throwing their weight around to discredit one of the largest CA's, in anticipation of a market entrance... The issue in question was 2 years ago... but all of a sudden, google now take excessive issue with it?

I've got no love for Symantec... the cert gravy train has rolled on for far to long, but they are far from the only guilty party when it comes to miss-issuing certificates. For Google to specifically discredit Symantec, a scant 2 months after launching Google Trust Services... It's hard not to put 2 and 2 together

 

Alphabet/Google is already extremely profitable, and could quite easily price Symantec out of that market if they felt like it. They wouldn't need pull stunts that run the risk of an anti-trust action.

 

So why single out Symantec, 2 years after the fact.
Will the be doing similar things to all the other Root CA's who have issued dodgy certificates?

If/When google enter the CA market, there anti-trust action will happen. Regardless of what price they come in it... This way, they stand to grab a big chunk of the market (from Symantec customers worried about The most popular browser eroding faith in their brand) while the lawyers sort out the legalities of it.

 

do go making wild claims that Alpha-dataharvester-bet have the largest market share.

From Mozilla Firefox’s Telemetry, we know that Symantec issued certificates are responsible for 42% of certificate validations.

fuck man lrn2read:

if you waddled your lazy ass to the mozilla bugzilla you'd see this issue was only raised 2 months ago: https://bugzilla.mozilla.org/show_bug.cgi?id=1334377
symantec response: https://bug1334377.bmoattachments.org/attachment.cgi?id=8831038

 

Fair call, I did skim the original article, and misread that it was a new issue, in addition to the previous ones.

I'm less sceptical now.

 

One of google's key drivers is to build trust in the web, and consequently trust in their platform. Lots of what google does it to promote and improve overall web security/trust - this in turn benefits them too.

What they are doing with their own CA (AFAIK) is to give them better visibility and control of their own certs, so that its easier to detect and prevent manipulation of their services.

 

So post the symantec debacle who should I be looking to buy SSL certs from now.

Comodo?

 

whoever is cheapest, there all going to screw up one way or another when they outsource their shit.

 

letsencrypt.org then send me your SSL cost money.

 

But I needs EV certs for $Reasons

 

People realise Mozilla are also joining Google in saying this isn't good enough and taking a similar course of action.

EV has a extremely good reason behind it. But like most things isn't always implemented properly. For e-com platforms it should be the norm imo.

 

meh, google act like the internet police nowadays.

 

Yeah, the good reasons are "CA's realised they could make more money by having a higher level certificate" .

 

Whoever is the cheapest then implement your own layer of encryption over your API calls for when they inevitably fuck it up. That's what I did.

 

Implementing your own encryption never ends well .

 

Not implementing from scratch, using a well known proven encryption library, just applying it over your plain text data that is normally encrypted by SSL. So if the SSL is ever broken, at least you don't end up with plain text usernames and user data embedded in cached google pages or whatever the next fuckup does. It's to protect the data from opportunistic sniffing, it isn't to protect the data against an active hacker.

Even if it doesn't work you haven't lost anything as you are still using SSL

 

Let's not forget that a purchased SSL certificate is all about authentication, not encryption.

Your self-signed "snakeoil" cert will give you just as good an encryption layer for your applications. The only time you need an external SSL certificate is when you're dealing with computers and devices you don't own/control.

If it's all internal stuff, either roll your own CA, or trust individual certs manually if a CA is too hard.

 

I think it is an expectation that if you are doing basic http auth and sending password/username in plain text over the net that SSL means opportunistic sniffers won't be able to steal your users credentials (almost always will be shared with fb/gmail etc as well, so if sniffed they could have their identity stolen).

That is the primary reason I used SSL in my case, and then rolled my own at the API/Application layer for when inevitably my SSL gets intercepted/broken or I myself fuck it up, the encrypted string they intercept will not be very useful.