Thursday, August 13. 2015
More TLS Man-in-the-Middle failures - Adguard, Privdog again and ProtocolFilters.dll
Comments
Display comments as
(Linear | Threaded)
Hello Hanno!
First, thank you for the research and for reporting it to us back then!
I have some clarifications on that issue.
1. We do not simply use nfsdk, but a fork of it.
2. Also we report all security-related changes made by us back to nfsdk author and it usually works. At least this horrible shared key issue is fixed now.
First, thank you for the research and for reporting it to us back then!
I have some clarifications on that issue.
1. We do not simply use nfsdk, but a fork of it.
2. Also we report all security-related changes made by us back to nfsdk author and it usually works. At least this horrible shared key issue is fixed now.
Also let's return to the main question - what to do if one needs to get to the encrypted traffic?
I know your answer - just don't do this, browser extension. But it's not enough.
Let's take a look at some situations when extension is not an option:
1. The browser does not support extensions. Like Edge.
2. What about apps? For instance, blocking annoying skype ads.
3. Mobile. We have an android app and users are begging for SSL filtering there.
Don't you think there should be some more reliable way to both filter encrypted traffic on the local computer/device and to leave SSL validation to browser?
I know your answer - just don't do this, browser extension. But it's not enough.
Let's take a look at some situations when extension is not an option:
1. The browser does not support extensions. Like Edge.
2. What about apps? For instance, blocking annoying skype ads.
3. Mobile. We have an android app and users are begging for SSL filtering there.
Don't you think there should be some more reliable way to both filter encrypted traffic on the local computer/device and to leave SSL validation to browser?
One thing you can do is SNI-based interception - connections to "clean" websites are passed through without messing with them, while suspicious domains get redirected to an interstitial using a per-device CA.
This way, you aren't reimplementing certificate verification, and software with hardcoded certificate fingerprints can be passed through.
This way, you aren't reimplementing certificate verification, and software with hardcoded certificate fingerprints can be passed through.
We do this already. There is a list of domains for which SSL filtering is disabled by default. Banking websites and some websites with sensitive personal information. Also user can add any domain manually to this list.
tl;dr Dell laptops come preinstalled with a root certificate and a corresponding private key. That completely compromises the security of encrypted HTTPS connections. I've provided an online check, affected users should delete the certificate. It seems
Tracked: Nov 23, 17:39