Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Intent to Deprecate and Remove: Trust in Existing Symantec-Issued Certificates

groups.google.com

Post reply on HN
Print view View original

231–240 of 329 posts

Re: Intent to Deprecate and Remove: Trust in Existing Symantec-Issued Certificates

#231

Post by CountSessine »

Shanea93 wrote: post #210
CountSessine wrote: post #194

Earlier quoted context omitted.

Well, just looking at the Bank of America example, they don't seem to use HSTS in their landing page. How widespread is HSTS? How long is the expiry period typically set for (I would guess a long time?) Does anyone still use browser bookmarks? Actually, just thinking about it, it might be even simpler than this. If Bank of America wanted to, couldn't they still host their redirect landing page over SSL with a valid n…

HSTS is currently used by 2.8% of all websites, up from 1.2% this time last year. [1] If people are using Qualys SSL Labs tool to check their "grade", they won't be awarded an A+ grade unless their HSTS max-age is at least 6 months [2], so I'm going to assume the average is somewhere close to that due to how common usage of that tool is. My grandma still uses browser bookmarks, but I have no none-anecdotal source for…

BoA could absolutely do all the things you just mentioned, but all of them are more difficult than simply replacing their certificate using Comodo or some other trusted root CA.

That depends on the design of the site and their business policies. I agree though - for any sensible organization switching certs is going to be easier. But if that was really the case here, why were they asking Symantec for special favours?

Re: Intent to Deprecate and Remove: Trust in Existing Symantec-Issued Certificates

#232

Post by tracker1 »

marcosdumay wrote: post #57
nailer wrote: post #26

Earlier quoted context omitted.

EV certificates have the same level of confidentiality and integrity as DV certs, but they have different authentication - specifically, they tie the certificate to a legal entity rather than a domain name. ie. https://paypal.com-customerservice.ru vs PayPal Inc [US] | https://paypal.com I run https://certsimple.com . We sell EV certs. But you can verify the above pretty easily by checking out the EV guidelines, the…

I'm bookmarking your page for when I need it... But that overlay just before I started reading your landing text is a serious mood-killer. I'm not going to set-up a remainder for when my certificate expires before I read your page.

That and the browser notifications request for every other blog online is starting to really tick me off.

Re: Intent to Deprecate and Remove: Trust in Existing Symantec-Issued Certificates

#233

Post by ce4 »

unethical_ban wrote: post #214
jdavis703 wrote: post #195

Earlier quoted context omitted.

EV actually causes a different "secure" UI to display in the browser. Usually it is the name of the corporate entity that the certificate is issued for. If you don't have EV you only get a padlock.

Oh, I know. But name me a non-IT professional that knows the difference, or would care that their bank has "secure" and not "Bank of America LLC". I think there are groups of smart PKI/UI people discussing how better to design security warnings at various levels of EV/HTTPS/Partial HTTPS/HTTP.

A. EV certs are bought for a reason, the very "green bar". Customers will notice this and won't be happy about it.

B. the 9 month expiration will also make customers unhappy

Both measures will put operational pressure on Symantecs customers and eventually decrease Symantec's market share in the business.

Re: Intent to Deprecate and Remove: Trust in Existing Symantec-Issued Certificates

#234

Post by cpncrunch »

SEJeff wrote: post #182
cpncrunch wrote: post #181

Earlier quoted context omitted.

>Symantec is at the clear disadvantage. I'm not sure how they are at a disadvantage if they have supplied 30% of in-use certificates, and are responsible for 42% of all validations. While I don't condone Symantec's behaviour, I think google is being a bit hypocritical here. Have you ever tried reporting gmail spammers to google?

Sans maybe spear phishers, spam campaigns aren't generally ran by oppressive governments. MiTM certs with bogus certs absolutely are, and could result in jail / death. EFF ftw! https://ssd.eff.org/

I'm simply pointing out that both companies seem to think they can do what they want, due to having such large market share.

Do we know that Symantec is being malicious, or just lazy like Google's response to spam?

Re: Intent to Deprecate and Remove: Trust in Existing Symantec-Issued Certificates

#235

Post by dragonwriter »

TenOhms wrote: post #157

It amazes me how often Symantec is in the news about the same subject, yet they seem to be incapable of learning a lesson from it.

If they were learning lessons from it, they wouldn't be in the news so much for it.

Re: Intent to Deprecate and Remove: Trust in Existing Symantec-Issued Certificates

#236

Post by unethical_ban »

ce4 wrote: post #233
unethical_ban wrote: post #214

Earlier quoted context omitted.

Oh, I know. But name me a non-IT professional that knows the difference, or would care that their bank has "secure" and not "Bank of America LLC". I think there are groups of smart PKI/UI people discussing how better to design security warnings at various levels of EV/HTTPS/Partial HTTPS/HTTP.

A. EV certs are bought for a reason, the very "green bar". Customers will notice this and won't be happy about it. B. the 9 month expiration will also make customers unhappy Both measures will put operational pressure on Symantecs customers and eventually decrease Symantec's market share in the business.

Yes, you are correct, in that Symantec's customers will care.

I am saying the customers of banks don't give a damn about EV or not. It's not in the literature. It's hard enough to train them not to click through; even I as an IT guy would probably not notice the lack of EV unless there were a modal or bubble saying "Hey! This is different!"

Re: Intent to Deprecate and Remove: Trust in Existing Symantec-Issued Certificates

#237

Post by justusw »

newman314 wrote: post #203
sandGorgon wrote: post #59

Earlier quoted context omitted.

we spawn our servers and scale them up and down. We terminate ssl internally to our applications which are on Docker. Letsencrypt is painful on docker. I dont mind paying 40$ per year for a wildcard ssl certificate.

xenolf/lego in DNS mode FTW.

Can confirm, Lego on k8s is really pain-free to use. Following the official documentation meant that I was able to have HTTPS running on our Google Cloud load balancer within 30 minutes.

Re: Intent to Deprecate and Remove: Trust in Existing Symantec-Issued Certificates

#238

Post by MertsA »

interurban wrote: post #175
poizan42 wrote: post #150

Earlier quoted context omitted.

StartCom were blatently lying, I don't think Symantec have stooped that low.

Hard to say which is worse, the intentional lying or the fact that Symantec has repeatedly violated the BR's and root store policies despite the appearance of best efforts not to.

Yeah seriously, every time Symantec slips up it seems like their response is some variant of "lol whoops, we didn't know we weren't supposed to issue certificates for entities other than the owner!"

Re: Intent to Deprecate and Remove: Trust in Existing Symantec-Issued Certificates

#239

Post by williamscales »

cpncrunch wrote: post #234
SEJeff wrote: post #182

Earlier quoted context omitted.

Sans maybe spear phishers, spam campaigns aren't generally ran by oppressive governments. MiTM certs with bogus certs absolutely are, and could result in jail / death. EFF ftw! https://ssd.eff.org/

I'm simply pointing out that both companies seem to think they can do what they want, due to having such large market share. Do we know that Symantec is being malicious, or just lazy like Google's response to spam?

This is a real security issue and spam isn't.

Re: Intent to Deprecate and Remove: Trust in Existing Symantec-Issued Certificates

#240

Post by sjwright »

the8472 wrote: post #118
Sir_Substance wrote: post #68

Earlier quoted context omitted.

>especially around legacy platforms that may have been hardcoded to use certificates from a specific issuer (not that I have ever seen that before, no one would be that foolish right? :/) D'ya know, I would have naively assumed this wasn't technically possible. I shudder not only to think of the code, but also of the thought process that could compel someone to undergo the effort of bricking themselves into this corn…

Hardcoding certificates is actually way too easy. SSL libraries don't necessarily use the system ca store or even know about it. OpenSSL has the option of disabling certifcate validation, providing your own certificate list or pointing to some system-supplied certificates which you need to find first. So in a way you even have to count yourself lucky if the hardcoded one instead of choosing to just disabling validati…

If you're hard coding certificates in your own client software, this issue doesn't affect you.
Post reply on HN