Last update: 10 November 2017
Understanding this article may require from you the basic knowledge about encrypting, TLS protocol and HTTPS.
First, look at this simple diagram that shows the general structure of HTTPS protocol:
AdGuard copies properties of the TLS-connection that your browser uses:
Effectively, it means that if you use a modern, safe browser, it will take all known TLS problems into account and won’t attempt to use unsafe ciphers.
What does AdGuard do when there are any doubts about the certificate’s validity? In such cases, AdGuard entirely ceases filtering of all connections to this domain and leaves the browser in charge of all decisions.
HTTPS filtering in AdGuard has its drawbacks. Almost all of them are scheduled to be eliminated in the nearest upcoming AdGuard versions. Moreover, we are working on a separate certificate validation library, and we want to make it open source.
Below are listed all issues known to us and ETAs for the fixes.
The Internet security community has some controversy regarding how useful OCSP checks are. For example, Chrome developers believe that this approach doesn’t hold water, and they suggest an alternative solution. Moreover, Android doesn’t (and will not) support OCSP revocation checking.
AdGuard’s behavior depends on the platform. AdGuard for Windows uses Microsoft CryptoAPI to perform OCSP checks, and it has all the drawbacks that Chrome developers describe. AdGuard for Android doesn’t perform OCSP checks whatsoever.
ETA: This will be implemented after we complete the development of the new cross-platform filtering engine, which is planned for December 2017 — January 2018.
HPKP (HTTP Public Key Pinning) is a mechanism that allows websites to defend against the unauthorized attempts to intercept the encrypted (HTTPS) connections to them. This standard is not too widespread so far (of the Alexa top1000 websites, less than 1% uses HPKP) due to the high risks of using and sophisticated configuration process. Some experts even go as far as saying that HPKP is de-facto dead. Nonetheless, it remains the only protection mechanism to keep working should it happen the center of certification becomes compromised.
There’s one serious problem with using HTTPS filtering - browsers completely ignore HPKP (because it isn’t used alongside with a local root certificate). This is a common issue for all programs that filter HTTPS. The only possible solution is to implement the HPKP standard within AdGuard.
ETA: Just as with OCSP revocation support, we wait until the new filtering engine development is finished. ETA is December 2017 — January 2018.
Note: Google's "intent to remove" HPKP support adds some controversy and may end up interfering with our plans.
By this moment, the latest stable TLS version is 1.2, dated by 2008. This protocol is pretty safe, provided it is configured correctly. On the other hand, an incorrect configuration leads to various vulnerabilities: POODLE, FREAK, Logjam and others.
New TLS version is still under development, but several browsers and some popular websites and services already support it.
The main advantages to TLS 1.3 are:
Better security is achieved through removing support for older broken forms of cryptography, supported by TLS 1.2.
Currently, the situation with TLS 1.3 support in popular browsers is following:
ETA: There is no unified standard for TLS 1.3 yet, we expect it to be agreed on somewhere around Q1 2018.
If you check HTTPS connection properties in Chrome, you might see the following warning:
The thing is that Adguard maintains two encrypted connections: one with the browser, another with the server. For the browser connection, we use a less strong encryption algorithm to achieve higher speed. It does not make it insecure as this is a local connection, though, it might be unnecessary.
If you’d like to add something, notice any mistakes or want to ask a question, please contact us:
devteam at adguard.com.