- Jan 26, 2020
- 1,628
My friend wrote this to me:
Actually, I’d advise against using HTTPS filtering in any software, be it an antivirus solution (I disabled it in KIS) or in this case a content blocker.
I don’t remember if we discussed it already, but the main problem is: certificate obscuring.
You see, when such a system intercepts HTTPS connections, it basically receives the connection instead of the actual client (e.g. your browser), decrypts it, analyzes it (and filters it if need be), and re-encrypts it with its own self-signed certificate that it injects in the Windows Trusted Root store.
This poses two problems :
• As the certificate is self-signed, it’s not validated by a trusted root authority, rather acting as a root authority. It is generally a bad practice, even though it is a required step in the process ;
• More importantly, you have to trust the application to do the decryption, verifications, and encryption properly. The verification part is crucial: as your browser will display the filtering app’s certificate, it becomes the app’s job to verify the strength of the connection, the certificate chain, etc. of the originating site. It is not an easy task, and browser do it well, but I’ve seen examples of filtering apps not doing it very well at all (for instance, KIS didn’t use to warn of a bad certificate when it did filter secure connections. It does now.) ;
• Lastly, and more problematically, it obscures the origin of the certificate. Say I visit some site, I can see that the HTTPS connection is signed by a certificate by a trusted root, say, GlobalSign. If the next day I visit the same website and the certificate is now run by another emitter, it can raise questions. It can be harmless, but also a sign of a man-in-the-middle attack. However, if a filtering application is used, all I will see is their own “trusted” (self-signed) root, and I won’t notice anything. That, to me, is the worse problem (even more with EV certs, that are supposed to certify also the organization that the certificate belongs to, even if they will, sadly, disappear with time).
As a filtering browser extension, such as uBO or presumably AdGuard’s own extension sees requests before (on the request side) and after (on the response side) the encryption is run, it sees them as clear text anyway and doesn’t need to run this interception process. So to me, it’s actually a security risk, and not needed anyway (just the same, an antivirus would catch the file as it’s downloaded for instance if it was malicious, without having to intercept the HTTPS connection but rather reading the file contents).
*KIS: Kaspersky Internet Security.
Actually, I’d advise against using HTTPS filtering in any software, be it an antivirus solution (I disabled it in KIS) or in this case a content blocker.
I don’t remember if we discussed it already, but the main problem is: certificate obscuring.
You see, when such a system intercepts HTTPS connections, it basically receives the connection instead of the actual client (e.g. your browser), decrypts it, analyzes it (and filters it if need be), and re-encrypts it with its own self-signed certificate that it injects in the Windows Trusted Root store.
This poses two problems :
• As the certificate is self-signed, it’s not validated by a trusted root authority, rather acting as a root authority. It is generally a bad practice, even though it is a required step in the process ;
• More importantly, you have to trust the application to do the decryption, verifications, and encryption properly. The verification part is crucial: as your browser will display the filtering app’s certificate, it becomes the app’s job to verify the strength of the connection, the certificate chain, etc. of the originating site. It is not an easy task, and browser do it well, but I’ve seen examples of filtering apps not doing it very well at all (for instance, KIS didn’t use to warn of a bad certificate when it did filter secure connections. It does now.) ;
• Lastly, and more problematically, it obscures the origin of the certificate. Say I visit some site, I can see that the HTTPS connection is signed by a certificate by a trusted root, say, GlobalSign. If the next day I visit the same website and the certificate is now run by another emitter, it can raise questions. It can be harmless, but also a sign of a man-in-the-middle attack. However, if a filtering application is used, all I will see is their own “trusted” (self-signed) root, and I won’t notice anything. That, to me, is the worse problem (even more with EV certs, that are supposed to certify also the organization that the certificate belongs to, even if they will, sadly, disappear with time).
As a filtering browser extension, such as uBO or presumably AdGuard’s own extension sees requests before (on the request side) and after (on the response side) the encryption is run, it sees them as clear text anyway and doesn’t need to run this interception process. So to me, it’s actually a security risk, and not needed anyway (just the same, an antivirus would catch the file as it’s downloaded for instance if it was malicious, without having to intercept the HTTPS connection but rather reading the file contents).
*KIS: Kaspersky Internet Security.
