i dont think you understand how this works. they install a root certicicate on your machine and do mitm "attack" so they can scan the urls, and block some attacks (i remember when some forum had embeded a pdf, that had some attack and antivirus blocked it )
also you have installed an application that has a root acces to the pc, if it was mallicius it could do allot more damage. it is ultimately a question of trust.
i created and installed my own root certificate because i dont want clicking on the exception if i open a new incognito window, its especialy anoying for websocket connections.
If you MITM the connection locally it triples the computational cost for both encryption and handshake operations. Then more websites don't use TLS because it's three times as slow for the user.
It also prevents you from using a good cipher suite when the MITM doesn't support it even though the browser and the server both do, again reducing security or performance or both. And it's very easy to screw this up the other way and have the browser show a good secure connection with strong primitives and forward secrecy while the MITM is actually communicating with the server using export ciphers or RC4.
The existence of a trusted root private key on your machine exposes you to KCI of all servers. And key compromise is not even necessary if they use the same root private key for everyone, which has actually happened.
This is not a comprehensive list of the reasons why that is a bad idea.
Compromising TLS is an infection vector. People regularly download programs from trusted websites and run them. Some apps automatically download updates from the vendor's site via TLS.
AV scanners do not have a 100% detection rate. Letting malware be where a trusted program is expected is how you get infected.
> so they can scan the urls, and block some attacks
The purpose of HTTPS is to provide a guarantee that your connection to Google is direct, with no intermediaries, such that (1) only Google knows your search query and (2) you get a guarantee that the received content is from Google.
And you get this guarantee from certificate authorities that have a good reputation and that are in business because they've proven they can keep their shit secure. And when one of them violates that trust, the OS / browser vendors can start to invalidate their certificates. AV companies are bypassing it all.
The blocking of attacks reasoning is kind of bullshit, because Google's Safe Browsing service and browser extensions maintained by a community like uBlock Origin are doing a better job of warning against potentially malicious websites. There are always vulnerabilities to exploit of course, though it's getting harder for those to pop up due to the modern sandboxing of browsers.
However I have yet to see evidence that AV software is doing a better job of catching those, because it's a whack-a-mole game and it's more likely that browser vendors find and fix those vulnerabilities faster than AV companies, because bugs get reported to browser vendors first. And sure, if you have Adobe Reader or Oracle Java installed as plugins in your browser, that's a huge risk, but it's actually easier to uninstall those and browsers have started disallowing plugins. Safari for example is disabling everything by default.
The problem with installing their own root certificate is precisely one of trust. Yes, you allow a piece of software to run with root permissions, for as long as you don't see it do stupid shit, like installing a root certificate, at which point all of that trust should be gone.
And that is because a custom root certificate that doesn't belong to a competent certificate authority cannot be trusted and will increase the attack surface. This is security 101.
"The purpose of HTTPS is to provide a guarantee that your connection to Google is direct, with no intermediaries, such that (1) only Google knows your search query and (2) you get a guarantee that the received content is from Google."
This is a popular misconception, but false. SSL creates an encrypted tunnel so that nothing "in the middle" can penetrate the tunnel (in theory), but there is no contradiction in the two sides of the tunnel delegating out their trust. There better not be, because in practice, there are almost always intermediates now on the real web. It is very common for a WAF or a load balancer to be the thing responsible for the SSL rather than the server generating the response, or you have CDNs or DOS prevention like Cloudflare doing the real work, etc. etc. There is no particular problem with the user doing the same thing. Sure, they can be irresponsible with it... well, so can the HTTPS server side, so, well, yeah? If you're going to declare a particular encryption technique unusably flawed because it could be used incorrectly and insecurely, you're not going to be encrypting very many things.
In fact, the very web connection you are reading this on, if I understand it correctly, was not actually encrypted by YCombinator. It uses a cert they own, but they're not the ones terminating the SSL connection; that's been delegated to a trusted third-party.
Cloudflare et al don't terminate TLS using their own root certificates installed on the client, which means that doesn't expose you to KCI of all servers.
And they don't MITM the TLS connection, they terminate it. The difference being that the performance is better rather than worse (so more people use TLS instead of fewer), the server is aware of this happening so it isn't fooled into thinking the connection is using more secure ciphers than it actually is, there is no third party forcing lowest common denominator security between the three, etc.
There are no intermediaries, AV mitm the traffic because otherwise it cannot scan the content, nor the urls, if it was remote on the AV vendor server then i would understand it but its doing it on you local machine, and you can disable it if you dont want it. If i have a antivirus installed on my pc and get infected with one of those fly byes i would be furious because i was thinking that im protected.
I dont know where do you live but there is a TON of different javascript injections in the wild with ad networks that are not caught by browser vendors or are caught to late. Google does not do deep scan of the page or files it just has a blocklist of urls. If i host my code on another url or change a file slightly only AV is good in this situation.
And remember they have to get it right only one time.
I still don't see why AV should scan websites. Get AD blocker + javascript blocker (with whitelist for trusted sites) and AV to scan local files. MITM'ing TLS makes more troubles and potential dangers than it solves.
>The blocking of attacks reasoning is kind of bullshit
>I have yet to see evidence that AV software is doing a better job of catching those
I wouldn't be so one-sided. Imagine a fresh new variety of ransomware starts spreading. No one can catch it at 0-day, but good AV can catch it at 1-st day (OK, 1-st week) and neither Google nor uBlock or the likes can't.
Do you have any evidence for these claims? What's the concrete mechanism that allows AVs to observe and react to threats earlier than Google? (Since you allow up to 1 week of reaction time, I'll assume that you're not referring to heuristic detection methods.)
With cloud reputation service all AV user base (provided sufficiently large) turn into global sensor network, along with honeypots vendors maintain separately. This allows (at the cost of users' privacy) to detect new emerging threats within hours, then acquire samples, analyze them and deploy new signatures within days.
Google can of course react equally fast. But "signal delay" may be much higher, as users report only URLs they can immediately link to their troubles, e.g. malware that crash browser.
And second, what Google can do now is to block only one attack vector, namely web page.
Thinking rationally, chances are high that Google is seriously considering to enter the AV business. They are in highly advantageous position to do it successfully, with their user base, resources and AI tech.
Google owns VirusTotal, so they either alternatively have a strong set of tagged samples to work with, or an incentive to not disrupt their partnerships with exiting vendors.
Good point. A huge, high quality dataset to train their own AI-based malware detection engine. Someone must be doing this already, at least as a research project.
also you have installed an application that has a root acces to the pc, if it was mallicius it could do allot more damage. it is ultimately a question of trust.
i created and installed my own root certificate because i dont want clicking on the exception if i open a new incognito window, its especialy anoying for websocket connections.