The difference between blocking websites and deep packet inspection (DPI) would be, to use an analogy, the difference between not delivering post (blocking) and opening envelopes and resealing them (DPI). Legislative measures vary between the two aforementioned cases depending on the jurisdiction since the act of blocking a website is censorship whereas the act (even implicit) of inspecting secure traffic constitutes a privacy violation. Furthermore, many websites are interactive, ie: a contact form, a login form (possibly a backend protected bycredentials) such that the act of decrypting the HTTPs connection would, in such cases, disclose credentials and private information in plain text.

Some of the lists containg domains used to perform HTTPs requests are meant to be used as blacklists but the purpose of the document is to find out which websites present a certificate by FortiGate. Blacklists are used for the purpose of censorship for many institutions where traffic is denied to various websites based on certain institutional polices. However, the websites mentioned here are accessible but with a certificate that has been re-written by FortiGate thereby performing a Man-in-the-Middle (MITM) attack by decrypting and re-encrypting the traffic between the browser and the destination website (citing from the FortiGate documentation "It is very similar to man-in-the-middle attack.").

In other words, the purpose is to determine to which websites traffic from browsers may be monitored and not to debate institutional policy on domains that have been banned. Similarly, the list of domains that FortiGate performs a man-in-the-middle attack on are not listed or accessible to the personel of IFIN-HH such that a user browsing these websites will not know that the traffic may be monitored. Browsers from different vendors (such as Firefox) do present a warning but sometimes it is possible to proceed and connect anyway in spite of the browser warning.

Whilst the MITM attack is implicit (indentically similar, to paraphrase the FortiGate documentation) due to FortiGate presenting a different certificate other than the certificate of the website requested by the user it cannot be directly assumed that the traffic is additionally actively being monitored (or altered, or used in any illicit way, for that matter).

Decrypting HTTPs traffic can be used to filter encrypted content by first decrypting the request, applying content filters (ad blockers, malware / virus scanners, etc.) and then re-encrypting the traffic to be delivered to the browser.

The official FortiNet website mentions content filtering as the reason to decrypt HTTPs traffic but given that some websites are filtered and some are not as well as the reputation of the websites on the list below it does seem like a selection and not a policy that applies to all websites with the purposes of thrwarting off malware. For instance, why is traffic to being intercepted but traffic to not? From a technical standpoint, both websites could be infected with malware.

In cases where websites are blocked, FortiNet / FortiGuard seems to:

  1. intercept the HTTPs traffic,
  2. inject a warning that the website violates company policy,
  3. re-encrypt the traffic and deliver it to the browser using a FortiNet certificate.

Unfortunately, just like browsers, applications that perform HTTP requests, some of which may include credentials will still have the payload decrypted by FortiGuard thereby possibly disclosing sensitive information. In fact, as per the HTTP(s) protocol the "Host" header sent to request a given website is only sent after an SSL connection is established.

Solutions to Content Filtering

  1. Currently, FortiGuard seems to run in intercept and transparent mode such that a connecting client (browser or other application) dos not know what the traffic is intercepted. Since FortiGuard is running in a transparent intercept setup, there is no other way to perform content filtering other than to decrypt the traffic.
  2. One solution that would not constitute a privacy violation and would not require an MITM attack would be to use Web Proxy auto-discovery and drop all outbound traffic not occuring over the proxy. In doing so, the browser would treat a gateway such as FortiGuard as a proxy and would issue explicit requests for websites via the CONNECT method. Based on the CONNECT request the gateway could filter traffic and enforce blacklists without having to decrypt HTTP traffic.

The main difference is that in the current case (1.) an application does not know that HTTPs is being intercepted by fortiGuard and could leak information (ie: laptop with a closed browser, opening the browser and reloading the website whilst sending a GET or POST request will leak all data to FortiGuard) whereas by configuring FortiGuard as a proxy in case (2.) would reject the traffic until the browser (or application) configures FortiGuard as a proxy server. The only problem would be that using the second method (2.) all website data will be encrypted such that no content filtering can take place.

Bypassing FortiGuard Blacklists

The FortiGuard block can be bypassed by issuing requests to the IP address rather than the domain name and then setting the "Host" HTTP header value to the domain name.


Using Firefox and an addon that can manipulate HTTP headers, accessing Human Rights Watch by making an HTTPs request to the IP address instead of the domain will bypass the FortiGuard block.


When accessing via the IP address, the HTTPs certificate is legitimate indicating that FortiGuard has not decrypted the request.

interestingly, some websites do not display pictures and inspecting the images will reveal an absolute link to the image such that the browser will have to make subsequent requests using the domain name instead of the IP address and, due to FortiGuard, the browser fail to retrieve the images.

An option might be to use a proxy such as Squid, to be placed in front of FortiGuard and perform some HTML rewriting in order to change all domain names to IP addresses for all links on the retrieved webpage.

Quick Testing

The following notes use the Human Rights Watch website as an example but multiple websites are affected.

List of Affected Websites

These files were generated using the following command:

cat sites.txt | while read domain; do echo "exit" | openssl s_client -showcerts -servername $domain -connect $domain:443 > censorship/$domain.txt 2>&1; done 

where "sites.txt" is a file containing domains.

Human Rights

Using a list from George Washington University found online the following websites have been found to be affected:

and all the other extracted domains in the list were unaffected.


Using lists from Université Toulouse 1 Capitole meant to be used with DANSGuardian, the following press websites seem to be affected:


Based on the politics list from Shalla Secure Systems meant to be used with DANSGuardian/SquidGuard, several are banned by FortiGuard, such as ANTIFA, ATAC, Audre Lorde Project and some right-wing or communist party or organizaiton websites. Similarly as in the previous cases, some are banned, others are not even if they apparently match more or less the same profile.



In cases where some websites that have HSTS configured, such as, visiting the website first from outside the insitute and then from within the institute leads to errors since FortiGuard presents its own certificate that does not match the HSTS policy.

In such case, Google Chrome reports:

An application is stopping Chrome from safely connecting to this site 'Fortinet' wasn’t installed properly on your computer or the network: Try uninstalling or disabling 'Fortinet' Try connecting to another network NET::ERR_CERT_AUTHORITY_INVALID Help improve Chrome security by sending URLs of some pages that you visit, limited system information and some page content to Google. Privacy Policy 'Fortinet' isn’t configured correctly. Uninstalling 'Fortinet' usually fixes the problem. Applications that can cause this error include antivirus, firewall and web-filtering or proxy software. 

since the machine does not have the self-signed certificate installed and the CA is unrecognized.


Censorship is to security as much as obscurity is to security: FortiGuard fails to enforce the established blacklist even if user privacy rights are violated by decrytping SSL traffic. A simpler option by configuring FortiGuard as a standard, well-established and well-declared proxy for the network would not have violated any user privacy rights and would still have allowed the blacklist to be enforced.