Websites that work for you

We're a small team based in Scotland. We turn small business websites into effective marketing tools.

Contact Us

Interview with DigiCert’s Chief Product Officer on Chrome 68, HTTPS and Symantec

In an exclusive interview with Indivigital, Jeremy Rowley, Chief Product Officer at Digicert, discusses the Chrome 68 update, the acquisition of Symantec's PKI business and why SSL is important for informational websites.
by on 8th October 2018

Earlier this month we sat down with Jeremy Rowley, DigiCert’s Chief Product Officer, to discuss the Chrome 68 update, which marked all non-HTTPS websites as “not secure”, and the future of DigiCert and SSL.

The full transcript of the interview is published below.

Full interview

Indivigital: Do you think the recent Chrome update marking non-HTTPs websites as “not secure” is going to be beneficial for both webmasters and users?

JR: Yes, I think so. It’s obvious why it’s beneficial for sites that conduct financial transactions, or that have login information or anything like that, because you want to keep that information protected.

Even information sites should be encrypted, the reason being we’ve seen a lot of the attacks in recent years come from just information harvesting, related to tracking cookies or information that’s being transmitted to and from sites, attacks that would have been much more difficult had [they] not been able to look at cookies and detect patterns in those, or look at visitor information and detect patterns.

So it’s good to have the information going back and forth encrypted regardless of the site. I think it’s obviously less important for sites that are informational only but it doesn’t hurt now that TLS has become easier to deploy, and there’s a lot of tools out there to help webmasters manage it and administer it.

Indivigital: With regards to implementing HTTPS, do you have any specific examples of problems that aren’t transactional based? Obviously you would need HTTPS for an e-commerce website but are there any particular prominent examples you can think of where problems have been encountered by informational websites that do not have HTTPS?

JR: Yeah, it was either the CRIME or the [inaudible] attack [that] used information that was being sent from non-transactional websites to reverse engineer cookies, and a lot of those threats can be mitigated just by encrypting the data because if you can analyze enough data you can recognize certain patterns in information.

You can also perhaps pull information from those non-transactional websites that are embedded with tracking cookies or things like that, so having that information encrypted makes it more difficult for attackers to gain sufficient information for, say, spearfishing attacks or other similar attacks.

It’s good to have all of that information encrypted because you never know what’s going to be beneficial for an attacker.

They’re going to use the corpus of information to figure out what’s going on with you and who you are – maybe each piece of information by itself is not necessarily a threat but when you take it in aggregate it becomes a threat because then you’ve built a profile about this person, about who they are, and you can use those for all sorts of online attacks.

Indivigital: Looking purely at informational websites, do you think there’s any overhead to implementing HTTPS?

JR: There obviously are going to be some performance issues but it’s going to be in the order of milliseconds, so it’s not noticeable by people. The technology has come far enough along that the speed and performance related to website encryption isn’t a factor anymore.

Indivigital: What are the benefits of free SSL options relative to premium SSL options? If webmasters have free SSL what do you think are the benefits for them to upgrade to “premium”?

JR: Usually it’s the tools that you get as well as you get identity information. There’s really two parts of encryption: there’s identity information that’s provided for the website, where you can have signed information relating to who the controller of that certificate is, that tells you A. who’s responsible for information and B. tries to provide consumers with information about what’s going on, as well as provide information to the browsers about who’s operating a website in case there’s any issue with the site’s operation, or there’s an issue with the site’s security. It provides that kind of information, and contact information, etc., about the site operator.

And then there’s just the encryption component – informational websites don’t generally need identity information associated with it, so the free TLS certs are fine, but generally when people are upgrading to the more premium products it’s because one of two factors: A. they want the identity component embedded in the cert or B. they want the additional management tools that most of the premium packages offer.

For example, DigiCert itself has a free offering to its encryption everywhere programme where people can get free certificates but we also have paid services where you get additional certificate management capabilities.

If you have a lot of sites and need to manage certs across domains – and that comes in handy – we have certificate discovery and automation tools where you can go out and find all of your certificate end points, check them to make sure they’re properly installed, you know on one machine (rather than having to go to each machine and check, or building something yourself).

We also have hosted solutions where you can manage all your certificates across you infrastructure [and networks], in one nice central point.

There’s certainly free TLS options and that works for a lot of people, especially if you’re managing informational sites and you’re just trying to get it on one or two sites, once you start deploying it on scale or en masse then you need something that scales a little better, or you need different systems or different configurations.

The other thing that is a differentiator is the free TLS options don’t offer support with them, and you have to pay for the support package, mostly the premium certificate products are bundled with support…to add that value, which I know we end up seeing a lot of SMBs purchasing a lot of our premium products, even if they are only managing one or two sites, because they want our support, they want someone’s throat to choke [laughs], if something goes wrong, to say “hey, I need you to fix this, I can’t have downtime”.

Indivigital: How difficult is it for a webmaster to setup premium TLS? Is it relatively simple for them to do?

JR: Yes, it is now. It used to be fairly difficult, in fact DigiCert was founded because the CEO was trying to setup a server for a gaming community he ran and couldn’t keep the TLS cert installed, and he thought “man, you’ve got to make it simple for people”.

So he actually started back in 2003, we’ve come a long way since then and now you can…there’s all sorts of automated tools to help, there’s all sorts of online resources, at DigiCert we have no wait times, less than a minute wait times generally, for technical support…it has become a lot easier, especially with the mass number of automated tools, where you put it to your website, it will drop the cert on your website, or on your web server, and they configure it all for you.

And that is one of the main reasons why this push for HTTPS everywhere has gone on, and why Google is shutting it [sites without SSL certificates] down is because most of the reasons not to install TLS are gone.

Performance issues are gone, installation issues are mostly gone, there are still people who run weird Blackberry or old systems out there that need help, but for the most part it’s an automated and easy process.

Indivigital: So it would be fair to say that the barrier to entry that used to exist has disappeared?

JR: Oh for sure. The barrier to using TLS has pretty much gone. Now if you’re one of the web servers that has got a problem that’s not much comfort to you, that other people don’t have a problem, so we still have people that want support packages of course.

Indivigital: Do you think that other browsers will push and take Google’s tact in terms of displaying not secure notifications?

JR: Yes, I do think so. It’s actually something that has been talked about in the [inaudible] forums several times, I don’t have a timeline of when they would push that out, so you would have to talk to them to know exactly if they were going to but speculating they would likely all want to have TLS [inaudible], and probably display warnings to ensure people know that their information is not encrypted.

[The] main reason for that is because when you’re using the web you expect a safe, nice browsing experience – you don’t go on the web thinking I’m going to be breached or my data is going to be compromised, or I hope people don’t think that.

All of the browsers have the same concerns, they want to make sure users know when they’re safe in a way that doesn’t interrupt their browsing experience but also make sure that they know when they shouldn’t be disclosing sensitive information, so negative indicators really help with that.

Indivigital: Do you think there has been an increase in uptake since the Chrome update was announced, in terms of the purchasing of SSL certificates? Have you seen an uptake in the number of sales you’re making since the Chrome announcement?

JR: Yes, we’ve seen an uptake in sales. We ran a crawler before the Chrome deadline and found that about half of the sites out there weren’t encrypted still, we should run that again and see if that has dramatically changed. We’ve definitely seen an uptake in sales but we don’t have any numbers to quantify how much more of the web has moved towards encrypted traffic versus non-encrypted traffic.

Indivigital: What type of benefits can a user derive from implementing HTTP/2? What do you think are the performance benefits of HTTP/2, for which SSL is a defacto standard? Do you think it’s worth users upgrading to SSL to take advantage of HTTP/2?

*This answer has been redacted to provide greater clarity

JR: HTTP/2 is the new standard, they fixed some of the security issues with HTTP, so it’s worth using. I know there’s some hesitancy on the part of people to use HTTP/2 because with new technologies there’s potential backwards compatibility issues that maybe haven’t been worked out, especially if it’s optional if browsers adopt certain things.

I have a hard time recommending it fully because I don’t know if there’s compatibility issues out there.

Indivigital: The only other questions we have are relating to DigiCert’s acquisition of Symantec’s PKI business. Is that something you’re happy to discuss?

JR: Sure, happy to discuss it.

Indivigital: From reading all the coverage, obviously we’re going back quite a bit here, I think DigiCert began handling Symantec’s certificates towards the tail-end of 2017. Is that right?

JR: Yeah, that’s right. We acquired them late October of last year, I think it closed November 1st, and we’ve been doing the transition ever since.

Indivigital: To what extent do you believe the opportunity for DigiCert to acquire Symantec’s PKI business was a consequence of Google’s public criticism of Symantec issued certificates?

JR: That was definitely the catalyst [laughs].

Indivigital: Would you say that that was exclusively the basis for making that opportunity available to Digicert?

JR: Not sure I can comment on that one. Yeah, I don’t think I can. I’m sorry.

Indivigital: We’ll deviate slightly: do you believe that Google’s approach, in the way that it communicated the issue and taking its concerns public, do you believe that approach was justified?

JR: So the issue with the Symantec TLS certs are well documented during the public discussion on the Mozilla mailing list, so you had a series of issues that the browsers were upset about, that they felt they could no longer have confidence in the Symantec website security business and the certs that were issued, so they chose to distrust that.

[This] meant that Symantec had to move to a separate provider, rather than trying to do the arrangements they had agreed on with Google, which was that they’d find a third party to provide the backend services, and for a period of time and they’d transition it back in-house, they decided to strike a deal to sell their business.

I think that’s all I can say about what went on behind the scenes during that time, because A. I don’t want to guess at Google’s motives and B. I can’t comment for Symantec. I can comment for DigiCert though!

Indivigital: I think Symantec is still a shareholder in DigiCert, is that correct?

JR: Yeah, that was part of the acquisition, they got some of the shares, they’re not a majority holder but they got some of the shares.

Indivigital: Do you agree with Symantec’s perspective on it at the time that Google’s claims were “exaggerated” or “misleading”?

JR: I can’t comment on that one. I can say…you can see what Google’s claims were, I know they went back and forth, long story short it doesn’t really matter either because by October…all of those certs have to be replaced.

So, regardless of who said what, or who was right, or what happened in the past, the net result was that we ended up having to replace all of the previously issued Symantec certificates…in ten months, well just under a year. Which was huge because they had a lot of certs, so that’s what we’ve been heads down on, trying to replace all of those.

It was a huge effort but I guess my point is that it doesn’t matter what happened during the dispute what matters more is how much work it was to replace them all [laughs].

Indivigital: Completely agree with that. Our interest in this is from the basis it appeared Google had a significant amount of influence on the course of events, which a lot of people have found interesting considering Google’s position as a third party in the situation.

From what people have been discussing, I think it has been of interest because of the amount of power and influence Google has wielded, or seemingly wielded, over the situation, which is the main motivation for analysing it. I think it’s more looking at Google’s influence on events rather than any particular issue but I completely appreciate it’s a sketchy area for you to comment on.

JR: Yeah, I can comment on that one. The market reports currently show Google has 60% of the browser market, and because they have such a high percent of the market they do have a lot of influence on what happens, and you can see that with some of the unilateral mandates that come out that do change the way we work as individuals on the web, for example, the [inaudible] is a good example of that, who wants to have a warning sign in Google Chrome when it’s 60 percent of the market?

No-one wants that. Same with mandatory CT (certificate transparency) logging, do the certs support mandatory CT logging because it was a great way to better protect users and give more information to researchers and people like that about what’s being issued from certification authorities? [Either way], it was a unilateral project that was done by Google that essentially forced all certificate authorities to log all certs.

Lots of banks and other people are very unhappy about this because it essentially gave people a network. There’s [also] PII (personally identifiable information) in certs sometimes and you couldn’t do any kind of redaction, [so] you had all kinds of issues with privacy, and there were lots of concerns under EU privacy law because you can’t actually delete anything from a log.

If, say, sensitive information got logged, or health information got logged, you couldn’t actually get rid of it.

So there were all these concerns about CT when it first came out, most of them have proven not to be a real problem yet, but it was a unilateral move that shaped the way the industry works. So, there’s definitely enough power there, because of their large user base that they can unilaterally make changes.

Same with the Symantec dates. The Symantec dates were set by Chrome, and the distrust dates were set by Chrome, and there’s no real changing of those dates just because that’s the dates that they have set.

Maybe [inaudible] could have benefit from another month, maybe it was too risky, I have no idea why they set those dates, I can’t comment on that, but it was just a date that was set in the sand by Google, not by the other browsers, and everyone on the web who used the Symantec certs, which was roughly half the web at the time, had to switch over to using DigiCert.

So, definitely a lot of market power, definitely a lot of ability to do new things, and I don’t know if you’re following it very closely but they’re trying to get rid of the domain names, the URL, they’re trying to make it so you just go to Google not

They’re also getting rid of the WWW. They’ve announced that as a test, so lots of things, and I know Google likes people to respond to that stuff and provide feedback, so that’s the best way for people to help influence where things go – if they don’t like something that’s going on let Google know because they actually do like that feedback and they actually do care about it.

Indivigital: Looking at the months after the acquisition, what would you say were your biggest challenges and successes?

JR: The biggest challenge was the sheer magnitude of it. There were more certs than we’ve been told that we needed to replace, so right after the acquisition we began getting lots and lots of requests to replace certs, and it was a lot more than we planned on so we had to quickly scale up…and it took us a month or two months and after that we started seeing regular operations.

Now it’s pretty smooth, we ended up hitting the first distrust date back in April, and didn’t really have any issues. I think we found one or two sites we needed to go and update, one of them happened to be a hotel we were staying at on the date, at the time, on the date it was distrusted by Google, so that was kind of interesting.

The second one, what they call P2 which was in October, and is already in beta, we haven’t seen any issues during the beta release of Chrome, we haven’t seen any giant spikes and we’ve pretty much got everybody validated and had their certs replaced.

There are some people who haven’t replaced their certs…[and] we’ve already contacted them and talked  to them. They tend to either be waiting to the last minute to replace their certs or they’re not intending to replace their certs because they don’t care about trust in Chrome.

You only have to replace your cert if you care about trust in Chrome. The few holdouts that remain fall into one of those two categories.

Indivigital: So, to clarify, there are still customers out there who are using Symantec issued certificates?

JR: Yep, there are people out there still using them, for maybe their internal operations where it’s server to [inaudible] communications, or they are using it internally and they’re using an enterprise version of Microsoft or Apple devices only.

The only ones that have to be done by the October date are where the web server administrator cares about support in Chrome. It’s only Chrome that is shutting off support at that time.

So, the other browsers have their own timelines for distrusting Symantec certs, those ones are not as aggressive and are more flexible, so those two customers who want to continue using Symantec certs after the October date, we haven’t been pushing those publicly as much…because they are further out and almost everybody cares about ubiquity across all browsers so the majority of certs are, we just focus on the October date for those, because we don’t want anybody surprised.

Indivigital: So, overall would you say the transition has been a success?

JR: Yeah, it has been pretty successful.

I think it has been a huge effort to make two systems that didn’t talk to each talk to each other, it has been a huge effort to replace all those certificates due to the sheer number, but overall the first three or so months were fairly rough and painful but after that it has been pretty smooth.

Indivgital: Thanks for your time, Jeremy.

JR: Thanks.


By continuing to use the site, you agree to the use of cookies. Read more

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.