Women on Web website censored in Spain

Translation(s):

• Spanish: Women On Web, web censurada en España

• Update (2020-05-07): Fixed links, spelling typos, added Vodafone block page
• Update (2020-05-13): Fix Movistar block pages typos and improve explanation
• Update (2020-05-15): Spanish translation
• Update (2020-05-16): SNI Blocking terminology
• Update (2020-06-10): Add Contributing section, Euskaltel measurements, better rephrase
• Update (2020-10-16): Fixed Euskaltel URL, consistent terminology
• Update (2020-10-27): Fixed WomenOnWeb domain name

Blocked website: womenonweb.org
DPI middlebox vendors: Allot, Fortinet
Blocking methodologies: DNS Manipulation, HTTP Blocking, TLS Interception, TCP resets
Blocked in ISPs: Vodafone (AS12357 and AS12430), Vodafone Ono (AS6739), Orange (AS12479 and AS12715), CSUC (AS13041), MÁSMÓVIL (AS15704), XFERA (AS16299), Telefónica/Movistar (AS3352)

With this article we would like to raise awareness around the increasing level of web censorship and information control that Spanish Internet Service Providers (ISPs) have initiated. We will share all the technical details about the persistent blocking of the Women on Web website by all major Spanish ISPs.

• Introduction
• ISP Networks by Blocking Strategy
  • Summary Table
  • AS/Date Graph
• DNS Manipulation
• Deep Packet Inspection (DPI)
  • HTTP Blocking
  • TLS Interception
  • TCP Reset
• DPI Circumvention
• Conclusion
• Censorship Circumvention
• Previous Coverage
• Acknowledgement
• References
• Contributing
• Contact

Introduction

The Women on Web website womenonweb.org a non-profit organization providing support to women and pregnant people has been blocked by various ISPs all over Spain. The Open Observatory of Network Interference, OONI, a global community measuring Internet censorship, provides tools so that anyone with a network connection can voluntarily contribute their data to global reports. Recent measurements indicate that the Women on Web website has been blocked since the end of January 2020 and is still blocked by the majority of the Spanish ISPs as of the time of this writing, May 2020.

It is not the first time that the Women on Web website has been blocked. OONI published a report in 2019 analysing the confirmed blocking of the Women on Waves and Women on Web websites in Brazil, Iran, Turkey, South Korea, and Saudi Arabia.

This is the first time that we observe Women on Web being blocked in Spain.

In this article we describe how the major ISPs in Spain are blocking womenonweb.org’s website. Spanish ISPs have been blocking this website by means of DNS manipulation, TCP reset, HTTP blocking with the use of a Deep Packet Inspection (DPI) infrastructure. Our data analysis is based on network measurements from OONI data.

ISP Networks by Blocking Strategy

Summary Table

Please find our data analysis (as a CSV file) here.

*Note: After the analysis period of April, we received OONI evidences that Euskaltel was participating in the blocking, together with user complains that confirmed the suspicion. We have added it to the summary tables for visibility without further analysis.

AS/Date Graph

The graph illustrates OONI network measurements from the 1st of January 2020 until the 30th of April 2020 of the websites www.womenonweb.org and www.womenonwaves.org. On the y-axis of the graph the autonomous system (AS) network names of each ISP are listed, and on the x-axis the date of the measurements. The colors of the graph indicate the type of blocking (dns, http-diff, http-failure and tcp_ip), or no blocking indicated in grey. These types of blocking are described in detail in OONI’s Web Connectivity test specification. In the top graph, we see that, from the network measurements, www.womenonwaves.org is not blocked by any ISP in Spain (at least from the ones we have data on); all measurements have the color grey which means no blocking is observed. In the bottom graph, the network measurements of the website www.womenonweb.org are illustrated. Here we see a very different scenario where most ISPs are blocking the website by means of DNS manipulation, TCP reset, and HTTP blocking with the use of DPI.

The website of www.womenonweb.org is being blocked in the following networks: Vodafone (AS12357 and AS12430), Vodafone Ono (AS6739), Orange (AS12479 and AS12715), CSUC (AS13041), MÁSMÓVIL (AS15704), XFERA Móviles (AS16299), Telefónica/Movistar (AS3352). In the following sections we are going to analyze how ISPs are blocking the website.

DNS Manipulation

We have found that the ISPs Orange (AS12715 and AS12479), XFERA (AS16299), Telefónica (AS3352), and MÁSMÓVIL (AS15704) are blocking access to www.womenonweb.org’s website by means of DNS tampering.

The ISPs Telefónica (AS3352) and Orange (AS12715 and AS12479) are blocking the website by hijacking the domain name and pointing its DNS (A record) to the IP address 127.0.0.1. This IP address is assigned for use as the Internet host loopback address and such IP addresses should not appear on any network anywhere (according to RFC 1700).

In a similar way MÁSMÓVIL (AS15704) and XFERA (AS16299) are blocking the website by hijacking the domain name of womenonweb.org to falsely point to the IP address 192.168.1.254, which belongs to a private address space. Typically this is an IP address for a home or small office private network and should never be used for a public web server or an online service as it cannot be routed through the public internet. In any case, this is not the IP address of www.womenonweb.org.

In these two cases of DNS manipulation, a browser visiting the website will not receive a block page or any information on why the website has been blocked and is not accessible. Browswers trying to access the website from Orange and Telefónica may falsely understand that there is a technical problem with the website and not that it has been blocked by their ISP.

Here we show the latest network measurements on all the ISPs, indicating evidence of the blocking of the website womenonweb.org via DNS tampering.

*Note: After the analysis period of April, we received OONI evidences that Euskaltel was participating in the blocking, together with user complains that confirmed the suspicion. We have added it to the summary tables for visibility without further analysis_

Deep Packet Inspection (DPI)

Out of the many techniques ISPs can censor websites, DPI is the basis of the most advanced form of censorship. Usually ISPs are implementing censorship by manipulating the DNS records of the websites in question. Some ISPs, however, use more invasive technologies to censor websites -DPI. DPI technologies are often used by ISPs to perform more intrusive surveillance or to intercept network communications of their users, which is not possible with simpler DNS manipulation.

Special appliances have the ability not only to look into network layer 3 or layer 4 headers but to also look inside the payload of each and every packet. They can distinguish packets going to a server and either stop them from reaching their target, change the server’s response, or even redirect the packets to another server. These devices perform a hostile, active, middle-person attack on every client connecting to the network through them.

During our research we have identified 2 different DPI companies: Fortinet in Telefónica’s network and Allot in Vodafone’s network. Both have been used to actively manipulate users’ network traffic and block the websites of womenonweb.org.

HTTP Blocking

Movistar with Fortinet Overview

AS3352, owned by Movistar (a company owned by Telefónica), has been found to intercept the network communication of its users to display a phony website that displays an HTTP 404 error, i.e., a status code of web servers for announcing that a specific page doesn’t exist. However, this is not the case, since as we see in the control measurements of the OONI Web Connectivity, tests collected at the same time on other networks confirm that the page does exist.

Moreover, if we look at the HTML content of the HTTP response, we can find further evidence that this ISP is using DPI to censor the website www.womenonweb.org. In a comment section of the HTML response listed below, we find the string FGT_HOSTNAME, from which we can infer that this ISP is using a DPI product from Fortinet called Fortigate. This is confirmed by Fortinet’s own help pages. More specifically, the value in this field (FGT_HOSTNAME) mentions also what appears to be the Fortigate unique hostname used by this DPI, namely, RFFBTB1-01.

Searching online for this unique hostname identifier RFFBTB1-01 we can find a support request to Movistar’s community helpdesk with the title ‘Bloqueo de pagina web’ (translated to English as: Block of a website). A user on Movistar’s community helpdesk was asking why the website http://www.argenteam.net/ was being blocked. Reading throughout the post we were able to find verbatim the same block page (ERROR 404 - File not found) as the one found to block the website of Women on Web. Moreover the presence of the hostname (FGT_HOSTNAME: RFFBTB1-01) in Movistar’s helpdesk suggests that other websites are being blocked from Movistar networks with the same methodology.

Additionally the same block page by Movistar has been found in an OONI network measurement from 2018 showing the blocking of thepiratebay.org website.

Movistar Block Page

Movistar uses the following block page to censor access to the website of Women on Web:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
<!--
CATEGORY:
DEST_IP:  67.213.76.19
FGT_HOSTNAME:  RFFBTB1-01
SOURCE_IP:  [REDACTED]
-->
<html>
  <head>
    <title id="3">
      Error 404
    </title>
  </head>
  <body>
    <CENTER>
      <h1>
        ERROR 404 - File not found
      </h1>
    </CENTER>
  </body>
</html>

The complete block page and technical evidence of the blocking can be found in detail in OONI’s network measurement.

Thanks to the measurements taken from different vantage points in the Movistar network, we were able to identify three almost identical block pages with different Fortigate hostnames set as RFFBTB1-01, RFFBTB1-02 and RFFMNO1-01. Additionally the title HTML tag of the block page seems to be a different one per server/hostname id="1", id="3" and id="4". Based on their configuration structure and their hostname naming these are probably different DPI servers operated by the same ISP.

Comparison of all three block pages given by Fortinet’s Fortigate DPI in parallel. In line 6 there are 3 unique Fortigate hostnames. The OONI network measurements revealing Movistar’s block pages with all technical details can be found here, here and here.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

<!DOCTYPE html PUBLIC "-//W3C//DTD | <!DOCTYPE html PUBLIC "-//W3C//DTD | <!DOCTYPE html PUBLIC "-//W3C//DTD
<!--                               | <!--                               | <!--
CATEGORY:                          | CATEGORY:                          | CATEGORY:
DEST_IP:  67.213.76.19             | DEST_IP:  67.213.76.19             | DEST_IP:  67.213.76.19
FGT_HOSTNAME:  RFFMNO1-01          # FGT_HOSTNAME:  RFFBTB1-01          # FGT_HOSTNAME:  RFFBTB1-02
SOURCE_IP:  [REDACTED]             | SOURCE_IP:  [REDACTED]             | SOURCE_IP:  [REDACTED]
-->                                | -->                                | -->
<html>                             | <html>                             | <html>
  <head>                           |   <head>                           |   <head>
    <title id="1">                 #     <title id="3">                 #     <title id="4">
      Error 404                    |       Error 404                    |       Error 404
    </title>                       |     </title>                       |     </title>
  </head>                          |   </head>                          |   </head>
  <body>                           |   <body>                           |   <body>
    <CENTER>                       |     <CENTER>                       |     <CENTER>
      <h1>                         |       <h1>                         |       <h1>
        ERROR 404 - File not found |         ERROR 404 - File not found |         ERROR 404 - File not found
      </h1>                        |       </h1>                        |       </h1>
    </CENTER>                      |     </CENTER>                      |     </CENTER>
  </body>                          |   </body>                          |   </body>
</html>                            | </html>                            | </html>

A few OONI network measurements from Consorci de Serveis Universitaris de Catalunya (CSUC) reveal the same block page with Telefónica, as CSUC apparently uses Telefónica as their upstream ISP.

Vodafone Block Page

Users of the Vodafone ISP (AS12357 and AS12430) are shown the following generic block page when they visit (the HTTP version) of the website womenonweb.org.

This block page is another indication that Vodafone blocks the website.

Vodafone’s block page text in original language (Spanish):

Por causas ajenas a Vodafone, esta web no está disponible

The block page, translated in English, means:

For reasons beyond Vodafone's control, this website is not available

TLS Interception

Vodafone ISP (AS 12357 and AS 12430), like Movistar, is using a technique described in network security a middle-person attack.

Vodafone does not reset the TLS connection during the TLS handshake, like Movistar does. Rather, with AS 12357 and AS 12430, the TLS handshake terminates and the user receives a forged certificate claiming that it belongs to the www.womenonweb.org website.

Several network measurements from the Vodafone ISP (AS 12357 and AS 12430) present a certificate verification failure (ssl_error: error:14007086:SSL routines:CONNECT_CR_CERT:certificate verify failed) indicating that TLS interception is probably being deployed on the network for the website www.womenonweb.org. This error message from the OpenSSL library indicates that the TLS handshake is over and the client is not able to verify the certificate provided by the server.

In further tests using the OpenSSL command line tool, we confirm the TLS interception for connections to Women on Web’s web server, given some conditions that we detail below.

Forged TLS Certificate

Once a TCP connection is established (we don’t have a TCP reset here), browsers wanting to access the HTTPS website send a TLS Client Hello message to the web server as the first step to establish an encrypted and authenticated channel. We reproduce it here with the OpenSSL command line tool:

> openssl s_client -connect 67.213.76.19:443 -servername www.womenonweb.org  < /dev/null |& egrep 'issuer|subject'
subject=CN = www.womenonweb.org
issuer=C = ES, ST = Madrid, L = Madrid, O = Allot, OU = Allot, CN = allot.com/emailAddress=info@allot.com

What the OpenSSL command does:

1. s_client: Uses the integrated TLS client
2. -connect …: Connects to Women on Web IP address on HTTPS port (443)
3. -servername …: Indicates the hostname we want to access
4. < /dev/null: Closes the TLS connection once established
5. |& egrep …: Filters everything out except issuer and subject details from the received server certificate

The result of the previous command clearly shows us a response presenting a forged TLS certificate, claiming to be for www.womenonweb.org (subject’s Common Name), and issued by Allot, which by no means is a recognized Certificate Authority.

As OONI tests do not save the TLS certificates that servers reply, our team uploaded it for public inspection. The forged certificate of Vodafone has an issue date of 27th January 2019, one year before the start of our data analysis that showed signs of blocking.

Matching on SNI

An important detail here is the -servername parameter that we added. It controls the Server Name Indication (SNI) extension of TLS, sent inside the ClientHello message. It is sent unencrypted from the client to the server, and its intended use is to help web servers that host multiple TLS enabled sites (HTTPS) at the same IP address, to be able to reply back a ServerHello message with the certificate corresponding to the desired website, as each site may have its own certificate.

However, this also poses a risk. As the SNI field is sent unencrypted, it is being used by some censoring systems to identify and intercept connections to domains they want to block. Therefore, we tried to repeat the connection leaving the SNI field out, by using the -noservername option of the OpenSSL tool. This is done using the command below:

> openssl s_client -connect 67.213.76.19:443 -noservername < /dev/null |& egrep 'issuer|subject'
subject=CN = womenonweb.org
issuer=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3

The shortened reply shows us a certificate issued for womenonweb.org (notice the lack of www.), and signed by Let’s Encrypt Certificate Authority. Although this output in itself doesn’t demonstrate that the certificate is valid, we downloaded it and verified that it is. In fact, it is the same certificate returned by https://67.213.76.19/ in non-blocked networks. It looks like the web server’s default HTTPS website is womenonweb.org, which only contains a redirect to www.womenonweb.org. It would be interesting to see what would happen if the default HTTPS website had been www.womenonweb.org instead of the one with the content.

Differences with SNI Blocking

The SNI is a field that has a value that will be the domain, for example www.womenonweb.org or womenonweb.org. As we have shown, Allot’s DPI system operating on Vodafone networks is using this SNI field to filter traffic. However, this doesn’t mean that the blocking occurs on every single packet that starts a TLS connection containing an SNI field with the value of the domain to be blocked. Therefore, we observe that in this situation it is a necessary parameter, but not sufficient, for Allot to intercept the communication and effectively block the website.

In a recent OONI blog post, OONI explained that in the case of Iran, any packet containing a banned SNI value was being blocked. We demonstrate that this is not the case with Vodafone based upon experiments with the OpenSSL command, shown in the following sections.

For the purposes of comparing, we chose Wikipedia.org as a well-known webserver that is accessible from Spain. We need a control webserver that is not being blocked, to see what happens if we try to establish a TLS connection to it, but modifying the SNI to indicate the Women on Web’s hostname:

> openssl s_client -connect wikipedia.org:443 -servername www.womenonweb.org  < /dev/null |& egrep 'issuer|subject'
subject=C = US, ST = California, L = San Francisco, O = "Wikimedia Foundation, Inc.", CN = *.wikipedia.org
issuer=C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 High Assurance Server CA

The result matches with that of a valid response from Wikipedia’s web server, hence, we deduce that the DPI system is not intercepting the connection. From this and the previous tests, we can infer that only packets heading to certain IP addresses are inspected looking for a blocked hostname at the SNI field.

It’s worth to say that the experiment that OONI used for the Iran research, named SNI Blocking, didn’t fit our needs. We collaborated with OONI developers and tested a new measurement methodology designed to automatically gather all the information required to analyze this specific blocking scenario.

Domain and Subdomain Variations

Regarding the redirections, both HTTP and HTTPS versions of womenonweb.org, that is, without www. prefix or subdomain, are not blocked at the Vodafone networks that we have analysed. In the case of HTTPS, we don’t see any forged certificate:

> openssl s_client -connect 67.213.76.19:443 -servername womenonweb.org  < /dev/null |& egrep 'issuer|subject'
subject=CN = womenonweb.org
issuer=C = US, O = Let's Encrypt, CN = Let's Encrypt Auhority X3

However, this domain only redirects to https://www.womenonweb.org, which is then intercepted.

Replacement Block Page

Finally, the content that Vodafone presents to us, if we accept the forged certificate, is similar but not identical to the webpage returned in the HTTP version, as explained in the HTTP blocking section above.

Trying to access the HTTP version, unencrypted, we receive:

 > curl http://www.womenonweb.org
<META HTTP-EQUIV="Pragma" CONTENT="no-cache">
<META HTTP-EQUIV="Expires" CONTENT="-1">
<html>Por causas ajenas a Vodafone, esta web no est� disponible</html>

(line feed added manually above for readability)

However, trying to access the HTTPS version, and disregarding the false certificate using the --insecure option, we receive:

curl --insecure https://www.womenonweb.org
<html><body><p>Por causas ajenas a Vodafone, esta web no est� disponible</body></html>

TCP Reset

A TCP reset attack is a way to tamper and terminate an Internet connection by sending a forged TCP reset packet (Wikipedia: TCP reset attack).

The response_never_received and ECONNRESET mean that the other side of the TCP conversation abruptly closed its end of the connection. Indicating a potential TCP reset attack.

It’s worth mentioning that later tests from AS6739 show another blocking strategy, consistently over time, suggesting that between the 16th of March 2020 and the 24th of April 2020, Vodafone moved from a simpler to a more complex strategy, at least at this network (AS6739).

DPI Circumvention

During our research we encountered Qurium’s article about the technical mechanisms used to block the websites related to the Catalan referendum in October 2017. We were able to circumvent the DPI blocking with the exact same method.

Specifically the DPI system keeps its session state for 10 seconds. Thus, by delaying the transmission of the HTTP GET request ("GET / HTTP/1.1") we can successfully circumvent the DPI, since the TCP session is not being tracked after 10 seconds. The following command allows us to circumvent the DPI on the Vodafone ISP (AS 12357 and AS 12430) that uses the DPI infrastructure from Allot.

input () {
  sleep 20
  echo "GET / HTTP/1.1"
  echo "Host: www.womenonweb.org"
  echo
  echo
}

input | nc www.womenonweb.org 80

Another strategy published in 2013 by OONI takes advantage of the HTTP header sanitization process that web servers perform, in contrast to the lack of it in DPI systems.

Adapting the previous command to exploit this strategy also proved successful:

input () {
  echo "GET / HTTP/1.1"
  echo -e "Host: www.womenonweb.org\t"
  echo
  echo
}

input | nc www.womenonweb.org 80

In both cases, upon DPI circumvention the response is an HTTP to HTTPS redirection. This is expected and is a standard practice to redirect users to the HTTPS version of www.womenonweb.org (in an uncensored connection):

HTTP/1.1 302 Found
Cache-Control: no-cache
Content-length: 0
Location: https://www.womenonweb.org/
Connection: close

Conclusion

Our technical analysis of OONI data collected by multiple volunteers during the period January 1st to April 30th of 2020 revealed consistent blocking of Women On Web’s website (www.womenonweb.org). We found evidence of blocking in 9 networks used by 5 major broadband and mobile ISPs in Spain.

We were able to verify the usage of DPI technology from Fortinet and Allot used by Telefónica and Vodafone to block access to the website. Furthermore we have detected 2 different types of block pages in the same networks.

Based on evidence from network measurements analyzed in this article we were able to verify the blocking of Women on Web website by means of DNS Manipulation, HTTP Blocking, TLS Interception and TCP reset.

These methods are by no means exclusive for the censorship of this website, they seem to be used routinely as shown by the regular reports published by OONI.

Censorship Circumvention

Our findings in Spain revealed censorship of the womenonweb.org website with DNS tampering, DPI, TLS interception, HTTP blocking, and TCP resets.

In the case of DNS tampering you may be able to circumvent the censorship and access the website by changing the DNS resolver(s).

However we found that in some networks the ISPs have been deploying DPI blocking and DNS tampering, and in theses cases changing of the DNS resolver(s) may not be adequate to circumvent the censorship.

You can bypass the censorship and blocking of the website with the use of Tor Browser.

Previous Coverage

• [Catalan] Donestech: Censura a l’estat espanyol de la web womenonweb.org
• [Spanish] Freakspot: Censura de sitio web de Women on Web en España
• [Spanish] Ana: Women on Web

Acknowledgement

Contributors and Testers

Many ideas, discoveries, and testing across networks and time must be credited to:

• Hackmeeting mailing list
• Sindominio’s Cafe Chat community
• OONI core and community members
• Calbasi, Benhylau, and many, many friends, mates, relatives, and anonymous testers

Supporting Collectives

This work wouldn’t have been possible without the supporting infrastructure of:

• Sindominio.net
• Indymedia.org
• Riseup.net
• Aktivix.org
• Coletivos.org

Contributing

In this report we have referenced and linked to OONI samples taken by volunteers. It is important to keep taking measurements to be able to detect changes on the censorship methodology, new cases, or even the lifting of blockings.

Thanks to the applications that OONI has developed, testing connectivity is simple. To contribute to the monitoring of Women on Web and Women on Waves sites, click the button below and follow the instructions.

Contact

Team contact: nobloc_at_3msg.es

References

• Fortinet - Security Profiles
• Movistar community helpdesk
• OONI - On the blocking of abortion rights websites: Women on Waves & Women on Web
• OONI - Tab tab, come in!
• OONI - Web Connectivity test
• Qurium - Blocking Techniques Catalunya
• RFC 1700
• Tor
• Wikipedia - TCP reset attack