With what is happening in the market place with superfish, there is a “realization” of an old and established method called “HTTPS Local Proxy”.
What is it, well http://en.wikipedia.org/wiki/Proxy_server will explain it in more detail.
*********from Wikipedia**************
Filtering of encrypted data
Web filtering proxies are not able to peer inside secure sockets HTTP transactions, assuming the chain-of-trust of SSL/TLS has not been tampered with.
The SSL/TLS chain-of-trust relies on trusted root certificate authorities. In a workplace setting where the client is managed by the organization, trust might be granted to a root certificate whose private key is known to the proxy. Consequently, a root certificate generated by the proxy is installed into the browser CA list by IT staff.
In such situations, proxy analysis of the contents of a SSL/TLS transaction becomes possible. The proxy is effectively operating a man-in-the-middle attack, allowed by the client’s trust of a root certificate the proxy owns.
*************************************
Hmm…so the local application must install a rootkey so that it can read the encrypted content! Sounds bad right? Well, how else can you check the content for anything malicious in it, unless you decrypt it? Of course you can’t. That means as long as the criminals can have an encrypted channel to your computer they can push down all the malware they want and because you can’t decrypt the content you won’t know. This is also a problem for content filtering products. How can your content filtering product classify a website if its encrypted? Of course it can’t! That’s another reason why it must be decrypted. And that is why these local https proxies are used so that the security product can have access to content to check for malicious activity.
Do I like it? No. Is there any other way of doing it? We are in constant search to improve our user experience and yes there are some other ways but they are yet to be proven as a good working alternative.
So the options are don’t decrypt, allow criminals infect our users….or decrypt and protect the users……
Ok then, who might be using this method in their products?
Well, here is a list of some of these kind of certificates we found (there are hundreds of unique ones we found..)
O=Kaspersky Lab, CN=Kaspersky Anti-Virus personal root certificate
O=Kaspersky Lab ZAO, CN=Kaspersky Anti-Virus personal root certificate
O=Kaspersky Lab ZAO, CN=Kaspersky Anti-Virus Personal Root Certificate
CN=BitDefender Personal CA.000000000000, OU=IDS, O=BitDefender, C=RO
CN=Bitdefender Personal CA.000000000000, OU=IDS, O=Bitdefender, C=US
CN=Bitdefender Personal CA.Net-Defender, OU=IDS, O=Bitdefender, C=RO
CN=BitDefender Personal CA.Net-Defender, OU=IDS, O=BitDefender, C=RO
CN=Bitdefender Personal CA.Net-Defender, OU=IDS, O=Bitdefender, C=US
CN=BitDefender Personal CA.TrafficLight, OU=IDS, O=BitDefender, C=RO
CN=Bitdefender Personal CA.TrafficLight, OU=IDS, O=Bitdefender, C=US
CN=ESET_RootSslCert, O=”ESET, spol. s r. o.”, C=SK CN=ESET SSL Filter CA, O=”ESET, spol. s r. o.”, C=SK
C=CZ, ST=Moravia, L=Brno, O=AVG Technologies cz, OU=Engineering, CN=AVG Technologies
OU=generated by avast! antivirus for SSL scanning, O=avast! Mail Scanner, CN=avast! Mail Scanner Root
OU=generated by avast! antivirus for SSL/TLS scanning, O=avast! Web/Mail Shield, CN=avast! Web/Mail Shield Root
CN=0 Dr.Web for Windows, O=0 Dr.Web for Windows, OU=Certificate for processing secured protocols via Dr.Web NetFilter
ST=CA, L=CU, O=TREND, OU=IWSS, CN=IWSS.TREND
C=” “, ST=Some-State, O=Blue Coat SG600 Series, OU=0214150006, CN=10.52.64.3
C=US, O=Symantec Corporation, OU=Symantec.cloud Web Security Service, CN=Symantec Web Security.cloud CA
C=US, ST=California, L=Mountain View, O=Symantec, OU=Web Security, CN=Symantec SWG CA
As you can see, this method is used widely in the security industry.
Melih