Seeking info on browser certificate issuer

#1

We have an enterprise anti-virus running - BitDefender (BD). Recently a weird thing happened and I’m trying to understand what happened and how it works. A website that we developers used to be able to go to suddenly generates a “blocked” message in Chrome. But when we go to it in Firefox it works fine.

More details:

Firefox prompted to install a certificate from BD and I canceled the prompt. Chrome never prompted and apparently automatically got the cert installed. That would explain the blocking in one and not the other, but I’m struggling to understand how a certificate affects individual software applications like that. The BD cert is listed as a trusted root cert in the Windows cert store on my machine.

Now in Chrome I can go to https://unsplash.com (a stock photo site). Click the padlock and it shows a SAN cert that was issued …by BitDefender!!! In Firefox the exact same website cert info shows the correct issuer as Globalsign.

So how can BD install a cert that says it issued the TLS certificate for a website? How does that even work? Any clues or better yet links to explanations are gratefully accepted!

Edit: just checked the padlock on this website and get a similar thing:

#2

Hi @mushu

anti-virus-software may create own certificates to break the secure connection.

Standard: User <–> website with SSL - website encrypts, userbrowser decrypts the information.

With anti-virus-software: User <–> anti-virussoftware <–> website with SSL

Website encrypts, anti-virus-software decrypts, checks, encrypts again with an own certificate - userbrowser - decrypts.

It’s the perfect man in the middle - situation. If you install such a root certificate, that’s possible.

Chrome uses the windows Certificate store. So if your Windows accepts the BD root, then Chrome accepts this certificate.

FireFox has it’s own certificate store -> shows a warning.

1 Like
#3

Thanks for explanation, that makes sense. GRRRRRR not happy. I always wondered how anti-virus was able to sniff SSL/TLS traffic…now I know.

1 Like
#4

Just want to add on @JuergenAuer’s response.

For Bitdefender 2019 and beyond, SSL interception is enabled by default and is named “SSL SCAN” in settings.

If you want to, you could disable it and remove those ROOT CAs from the Certificate Store.

Thank you

#5

Good to know. But of course they don’t give “normal” folks access to the AV settings. And since the security folks don’t understand what developers actually do and websites we go to all the time, it will end up a ton of wasted time while we submit dozens and dozens of websites to be whitelisted and wait a long time for them to update the AV policies. Oh well, it’s only money…

#6

If you’re in a situation where you might be able to influence policy about this, you might want to look up research on intercepting proxies (or “middleboxes”) and antivirus interception of TLS. I don’t know anything about this particular product, but there were a number of cases in which researchers found that the proxies or antivirus software failed to properly enforce TLS certificate validation, or used obsolete cryptographic technology (instead of the up-to-date cryptography used by browsers), or processed the decrypted contents of users’ sessions on a computer that was less secure in some regard than the users’ machines. So in some cases, there are organizational security arguments against intercepting TLS this way.

However, this is a huge and ongoing argument in the information security world and different kinds of entities have advocated different positions.

2 Likes
#7

https://www.howsmyssl.com/

Used this website above to check the Chrome and Firefox browsers, where Chrome has the BD cert installed and Firefox doesn’t. Got two different rsults, one that Chrome is a “bad” client and the other that Firefox is a “good” client. Yep.

And then this one: https://www.ssllabs.com/ssltest/viewMyClient.html

Question: I thought OCSP Stapling was controlled by the server, is that incorrect? The results said that Chrome didn’t support OCSP but Firefox did. how can that be? The browser doesn’t control that option, the server does…is that flag stored in the cert itself?

#8

I’m not sure what the site is telling you here. OCSP stapling is controlled by the certificate but has to be enforced by the client, so there’s one question about whether a given site uses a certificate that calls for OCSP stapling and then there’s another question about whether a given client understands that request. (In this regard this is like any other web platform feature; for example, a given web page might or might not use HTML canvas, while a given web browser might or might not support HTML canvas.)

#9

Okay I see. Since I know the latest versions of both Chrome and Firefox support that functionality, then the testing website correctly shows that the BD cert installed in Chrome doesn’t support OCSP but Firefox without that bad cert does. Thanks for the clarification.

#10

Well… OCSP stapling isn’t controlled by the cert - it’s requested by the client and returned (if supported) by the server. It’s true that the cert can contain an extension that instructs the client to reject it if OCSP stapling is absent. However, I’d guess that what SSL Labs is checking for here is the presence of the TLS extension in the client handshake to request a stapled response. So I’d interpret the result to mean that Bitdefender does not request OCSP stapling from the upstream (i.e. real) server.

3 Likes
#11

Sorry, that’s completely right and I should have said “must-staple” rather than “OCSP stapling”!

2 Likes
closed #12

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.