I'm still trying to figure out if my 36 month wildcard carts from RapidSSL are going to be distrusted. Their intermediate is signed by GeoTrust which is owned by Symantec, and a blog post says with Chrome 59, certs with a period over 33 months will be distrusted. Chrome Canary on v60 shows them still working.
Symantec CA Response to Google Proposal and Community Feedback
81–90 of 129 posts
Re: Symantec CA Response to Google Proposal and Community Feedback
#82Earlier quoted context omitted.
I think the point there is that if Chrome doesn't trust that CA, then the servers will need to be updated to use a different CA, which will break clients that pinned the old CA.
Iirc you can have certs signed by multiple roots though, right? In which case these sites can just get their cert signed by the pinned symantec root and a real still-valid root. Nobody's stopping symantec from signing new certs, they just won't work in Chrome (and likely other browsers) Or maybe I've misunderstood the situation.
Unfortunately, you can't keep multiple chains in a single X.509 certificate. While you can have a given key signed by multiple CAs, AIUI, this just lets you switch easily, not tell a client about both, and just work if they trust either CA.
Re: Symantec CA Response to Google Proposal and Community Feedback
#83Does anyone else get a blocking "Symantec Connect" and "Loading your community experience" for a good 10 seconds before it loads? Could just be my mobile connection but man is that lame.
I've heard elsewhere in this thread that blocking ads/tracking breaks their site.
Re: Symantec CA Response to Google Proposal and Community Feedback
#84>require these applications to be recoded, recompiled and redistributed. Aka "updated". The entire post is basically "ok how about we be really good from now on and suffer no consequences, cause it'd be really shitty for us if we had to be penalised". They also posture a lot talking about how big their customers are, almost boasting about how inflexible and slow these big companies are, as if that's somehow Google's…
For some reason, technical professionals associated with large organizations seem to actively enjoy pretending that basic upkeep is beyond the means of their organization (or has a poor value proposition). I suspect that it comes from a perverse enjoyment of being "pragmatic" in the face of "idealism" but really they're just saying "My org refuses to pay the costs associated with correctly operating the technologies…
I recall a lot of horror stories from mobile telco providers when the US government proposed to users to take their phone number from one carrier to the next. It was just one terrible prediction after another that involved so many risks and complications.... until they had to do it and then it just worked.
Re: Symantec CA Response to Google Proposal and Community Feedback
#85Earlier quoted context omitted.
You're better off moving your accounts to a local credit union that does security correctly.
Have local credit unions gotten better at this? I left a local credit union a decade ago because they didn't offer online banking at all and when they finally did, the security practices they used were horrible . Memory may not serve perfectly here but I recall they had no EV cert (while common with banks, not everyone had them back then), the login form was provided in-the-clear POSTing to HTTPS and many of the bank…
[deleted]
Re: Symantec CA Response to Google Proposal and Community Feedback
#86Earlier quoted context omitted.
Imagine the embedded device or mobile app connects to a https://api.example.com/.. . and so does their web app. They need to use a new certificate for api.example.com, signed by a different CA root, because when Chrome tries to run the web app it won't trust the old certificate, nor a new cert signed by the old root. So they get a new cert signed by a different root so Chrome works, but then the embedded or mobile ap…
An easier way around this sort of issue is to change their web app to use a different domain, and only put the new certificate from a different CA on that domain. It's not necessary to update every device. Embedded devices => https://api.example.com (Symantec cert) Browsers => https://new-api.example.com (New trusted cert) Another approach is that if the devices are old enough they're probably using a deprecated vers…
You have to have planned for this (or be lucky) though. Some people just put their api on www.example.com; assuming you have clients in the field which have pinned BIG CA, and you've got HSTS preloaded (because you're forward thinking). Unless you can detect Chrome N+1 from your existing clients during the TLS handshake, you have to pick between browsers or existing clients.
If Chrome ships this at the same time as re-enabling TLS 1.3 support, that would be a decent way to target, since presumably very few of your distributed clients are using TLS 1.3.
Re: Symantec CA Response to Google Proposal and Community Feedback
#87Earlier quoted context omitted.
I find it hard to believe you can't imagine any valid scenario where at least one of those scenarios shouldn't be using pubic CAs. I've got personal experience with the first two (embedded devices and mobile apps) having pinned certificates (or limited sets of supported CAs) There's millions of internet-connected set top boxes, tvs, and dvd/bluray players deployed around the world that run with a limited set of suppo…
> There's millions of internet-connected set top boxes, tvs, and dvd/bluray players deployed around the world that run with a limited set of supported CAs. What exactly is the issue? If an embedded device trusts Symantec CA, then connections from the device to its central servers will continue working without interruption. In this example, the device trusts the Symantec CA, and the server presents a certificate signe…
Clients have no way to indicate what CAs they trust, so my infrastructure has to just present a certificate and say "Here I am"
So now if Google go ahead and distrust Symantec CAs, I need to duplicate that infrstructure (or at least the configuration at load balancers, etc) - this leads to all sorts of complexity.
Re: Symantec CA Response to Google Proposal and Community Feedback
#88Earlier quoted context omitted.
I find it hard to believe you can't imagine any valid scenario where at least one of those scenarios shouldn't be using pubic CAs. I've got personal experience with the first two (embedded devices and mobile apps) having pinned certificates (or limited sets of supported CAs) There's millions of internet-connected set top boxes, tvs, and dvd/bluray players deployed around the world that run with a limited set of suppo…
> There's millions of internet-connected set top boxes, tvs, and dvd/bluray players deployed around the world that run with a limited set of supported CAs. What exactly is the issue? If an embedded device trusts Symantec CA, then connections from the device to its central servers will continue working without interruption. In this example, the device trusts the Symantec CA, and the server presents a certificate signe…
You have api.mysite.com which serves both an embedded device as well as your site. To allow the site to be viewed in Chrome, you need a new cert for your API, and so you now have to either update your site to point to a different endpoint, or update your devices to accept the new cert. Sure it might be easier to do the former for some companies, but either way there's certainly a cost.
Re: Symantec CA Response to Google Proposal and Community Feedback
#89Earlier quoted context omitted.
For some reason, technical professionals associated with large organizations seem to actively enjoy pretending that basic upkeep is beyond the means of their organization (or has a poor value proposition). I suspect that it comes from a perverse enjoyment of being "pragmatic" in the face of "idealism" but really they're just saying "My org refuses to pay the costs associated with correctly operating the technologies…
I recall a lot of horror stories from mobile telco providers when the US government proposed to users to take their phone number from one carrier to the next. It was just one terrible prediction after another that involved so many risks and complications.... until they had to do it and then it just worked.
I worked in telecoms at the time. It was a huge pain in the ass, but in the end it was fixable. The company I worked for actually made a nice chunk providing the HLR (home location register) updates needed to get it to work.
Re: Symantec CA Response to Google Proposal and Community Feedback
#90>require these applications to be recoded, recompiled and redistributed. Aka "updated". The entire post is basically "ok how about we be really good from now on and suffer no consequences, cause it'd be really shitty for us if we had to be penalised". They also posture a lot talking about how big their customers are, almost boasting about how inflexible and slow these big companies are, as if that's somehow Google's…
This comment irritates me. 1) The point of the first part of their post is not "we're too big", it's "a move like this would disrupt the lives of an awful lot of people." Even more so, consider what would happen if Google were to update Chrome to not accept these certs. For internal applications, the IT departments of all these companies—which likely total a few hundreds of thousands of users in total—would simply ma…
Unless your software is running on a 30 year old embedded system, located in a submarine, 5KM below the ocean, guarded by tigers, and stuck there for the next decade, it's hard to muster sympathy about how hard updating your software is. If the cost to a company to deploy an update their software is really greater than the cost to just allowing the software fail, then maybe they should just let the software fail and prepare a great story for their users--I'd love to hear it.