A lot has been written about the Internet in Cuba over the years. I have read a few articles, from New York Times' happy support for Google's invasion of Cuba to RSF's dramatic and fairly outdated report about censorship in Cuba. Having written before about Internet censorship in Tunisia, I was curious to see if I could get a feel of what it is like over there, now that a new Castro is in power and the Obama administration has started restoring diplomatic ties with Cuba. With those political changes coming signifying the end of an embargo that has been called genocidal by the Cuban government, it is surprisingly difficult to get fresh information about the current state of affairs.
This article aims to fill that gap in clarifying how the internet works in Cuba, what kind of censorship mechanisms are in place and how to work around them. It also digs more technically into the network architecture and performance. It is published in the hope of providing both Cubans and the rest of the world with a better understanding of their network and, if possible, Cubans ways to access the internet more cheaply or without censorship.
- Internet in Cuba
- "Censorship" and workarounds
- Network configuration assessment
Unfortunately, I have been connected to the internet only through the the Varadero airport and the WiFi of a "full included" resort near Jibacoa. I have to come to assume that this network is likely to be on a segregated, uncensored internet while the rest of the country suffers the wrath of the Internet censorship in Cuba I have seen documented elsewhere.
Through my research, I couldn't find any sort of direct
censorship. The Netalyzr tool
couldn't find anything significantly wrong with the connection,
other than the obvious performance problems related both to the
overloaded uplinks of the Cuban internet. I ran an incomplete
OONI probe as well, and it seems there was no obvious censorship
detected there as well, at least according to folks in the helpful
#ooni IRC channel. Tor also works fine, and could be a great way
to avoid the global surveillance system described later in this
Nevertheless, it still remains to be seen how the internet is censored in the "real" Cuban internet, outside of the tourist designated areas - hopefully future visitors or locals can expand on this using the tools mentioned above, using the regular internet.
Usual care should be taken when using any workaround tools, mentioned in this post or not, as different regimes over the world have accused, detained, tortured and killed sometimes for the mere fact of using or distributing circumvention tools. For example, a Russian developer was arrested and detained in 2001 by United States' FBI for exposing vulnerabilities in the Adobe e-books copy protection mechanisms. Similarly, people distributing Tor and other tools have been arrested during the period prior to the revolution in Tunisia.
There is, however, a more pernicious and yet very obvious censorship mechanism at work in Cuba: to get access to the internet, you have to go through what seems to be a state-wide captive portal, which I have seen both at the hotel and the airport. It is presumably deployed at all levels of the internet access points.
To get credentials through that portal, you need a username and password which you get by buying a Nauta card. Those cards cost 2$CUC and get you an hour of basically unlimited internet access. That may not seem like a lot for a rich northern hotel party-goer, but for Cubans, it's a lot of money, given that the average monthly salary is around 20$CUC. The system is also pretty annoying to use, because it means you do not get continuous network access: every hour, you need to input a new card, which will obviously make streaming movies and other online activities annoying. It also makes hosting servers basically impossible.
So while Cuba does not have, like China or Iran, a "great firewall", there is definitely a big restriction to going online in Cuba. Indeed, it seems to be how the government ensures that Cubans do not foment too much dissent online: keep the internet slow and inaccessible, and you won't get too many Arab spring / blogger revolutions.
The good news is that it is perfectly possible for Cubans (or at least for a tourist like me with resources outside of the country) to bypass the captive portal. Like many poorly implemented portals, the portal allows DNS traffic to go through, which makes it possible to access the global network for free by using a tool like iodine which tunnels IP traffic over DNS requests.
Of course, the bandwidth and reliability of the connection you get through such a portal is pretty bad. I have regularly seen 80% packet loss and over two minutes of latency:
--- 10.0.0.1 ping statistics --- 163 packets transmitted, 31 received, 80% packet loss, time 162391ms rtt min/avg/max/mdev = 133.700/2669.535/64188.027/11257.336 ms, pipe 65
Every once in a while, mosh would get stuck and keep on trying to send packets to probe the server, which would clog the connection even more. So I regularly had to restart the whole stack using these commands:
killall iodine # stop DNS tunnel nmcli n off # turn off wifi to change MAC address macchanger -A wlan0 # change MAC address nmcli n on # turn wifi back on sleep 3 # wait for wifi to settle iodine-client-start # restart DNS tunnel
The Koumbit Wiki has good instructions on how to setup a DNS tunnel. I am wondering if such a public service could be of use for Cubans, although I am not sure how it could be deployed only for Cubans, and what kind of traffic it could support... The fact is that iodine does require a server to operate, and that server must be run on the outside of the censored perimeter, something that Cubans may not be able to afford in the first place.
Another possible way to save money with the captive portal would be to write something that automates connecting and disconnecting from the portal. You would feed that program a list of credentials and it would connect to the portal only on demand, and disconnect as soon as no traffic goes through. There are details on the implementation of the captive portal below that may help future endeavours in that field.
It should be mentioned, however, that the captive portal has a significant amount of information on clients, which is a direct threat to the online privacy of Cuban internet users. Of course the unique identifiers issued with the Nauta cards can be correlated with your identity, right from the start. For example, I had to give my room number to get a Nauta card issued.
Then the central portal also knows which access point you are
connected to. For example, the central portal I was connected to
Wifi_Memories_Jibacoa which, for anyone that cares to research, will
give them a location of about 20 square meters where I was located
when connected (there is only one access point in the whole hotel).
Finally, the central portal also knows my MAC address, a unique identifier for the computer I am using which also reveals which brand of computer I am using (Mac, Lenovo, etc). While this address can be changed, very few people know that, let alone how.
This led me to question whether I would be allowed back in Cuba (or even allowed out!) after publishing this blog post, as it is obvious that I can be easily identified based on the time this article was published, my name and other details. Hopefully the Cuban government will either not notice or not care, but this can be a tricky situation, obviously. I have heard that Cuban prisons are not the best hangout place in Cuba, to say the least...
This section is more technical and delves more deeply in the Cuban internet to analyze the quality and topology of the network, along with hints as to which hardware and providers are being used to support the Cuban government.
The internet is actually not so bad in the hotel. Again, this may be because of the very fact that I am in that hotel, and I get a privileged access to the new fiber line to Venezuela, the ALBA-1 link.
anarcat@angela:cuba$ speedtest Retrieving speedtest.net configuration... Retrieving speedtest.net server list... Testing from Empresa de Telecomunicaciones de Cuba (22.214.171.124)... Selecting best server based on latency... Hosted by LIME (George Town) [391.78 km]: 317.546 ms Testing download speed........................................ Download: 1.01 Mbits/s Testing upload speed.................................................. Upload: 1.00 Mbits/s
Latency to the rest of the world is of couse slow:
--- koumbit.org ping statistics --- 122 packets transmitted, 120 received, 1,64% packet loss, time 18731,6ms rtt min/avg/max/sdev = 127,457/156,097/725,211/94,688 ms --- google.com ping statistics --- 122 packets transmitted, 121 received, 0,82% packet loss, time 19371,4ms rtt min/avg/max/sdev = 132,517/160,095/724,971/93,273 ms --- redcta.org.ar ping statistics --- 122 packets transmitted, 120 received, 1,64% packet loss, time 40748,6ms rtt min/avg/max/sdev = 303,035/339,572/965,092/97,503 ms --- ccc.de ping statistics --- 122 packets transmitted, 72 received, 40,98% packet loss, time 19560,2ms rtt min/avg/max/sdev = 244,266/271,670/594,104/61,933 ms
Interestingly, Koumbit is actually the closest host in the above test. It could be that Canadian hosts are less affected by bandwidth problems compared to US hosts because of the embargo.
The various traceroutes show a fairly odd network topology, but that is typical of what I would described as "colonized internet users", which have layers and layers of NAT and obscure routing that keep them from the real internet. Just like large corporations are implementing NAT in a large scale, Cuba seems to have layers and layers of private RFC 1918 IPv4 space. A typical traceroute starts with:
traceroute to koumbit.net (126.96.36.199), 30 hops max, 60 byte packets 1 10.156.41.1 (10.156.41.1) 9.724 ms 9.472 ms 9.405 ms 2 192.168.134.137 (192.168.134.137) 16.089 ms 15.612 ms 15.509 ms 3 172.31.252.113 (172.31.252.113) 15.350 ms 15.805 ms 15.358 ms 4 pos6-0-0-agu-cr-1.mpls.enet.cu (172.31.253.197) 15.286 ms 14.832 ms 14.405 ms 5 172.31.252.29 (172.31.252.29) 13.734 ms 13.685 ms 14.485 ms 6 188.8.131.52 (184.108.40.206) 14.428 ms 11.393 ms 10.977 ms 7 220.127.116.11 (18.104.22.168) 10.738 ms 10.019 ms 10.326 ms 8 ix-11-3-1-0.tcore1.TNK-Toronto.as6453.net (22.214.171.124) 108.577 ms 108.449 ms
Let's take this apart line by line:
1 10.156.41.1 (10.156.41.1) 9.724 ms 9.472 ms 9.405 ms
This is my local gateway, probably the hotel's wifi router.
2 192.168.134.137 (192.168.134.137) 16.089 ms 15.612 ms 15.509 ms
This is likely not very far from the local gateway, probably still in Cuba. It in one bit away from the captive portal IP address (see below) so it is very likely related to the captive portal implementation.
3 172.31.252.113 (172.31.252.113) 15.350 ms 15.805 ms 15.358 ms 4 pos6-0-0-agu-cr-1.mpls.enet.cu (172.31.253.197) 15.286 ms 14.832 ms 14.405 ms 5 172.31.252.29 (172.31.252.29) 13.734 ms 13.685 ms 14.485 ms
All those are withing RFC 1918 space. Interestingly, the Cuban DNS servers resolve one of those private IPs as within Cuban space, on line #4. That line is interesting because it reveals the potential use of MPLS.
6 126.96.36.199 (188.8.131.52) 14.428 ms 11.393 ms 10.977 ms 7 184.108.40.206 (220.127.116.11) 10.738 ms 10.019 ms 10.326 ms
Those two lines are the only ones that actually reveal that the route
belongs in Cuba at all. Both IPs are in a tiny (
/24, or 256 IP
addresses) network allocated to ETECSA, the state telco
inetnum: 200.0.16/24 status: allocated aut-num: N/A owner: EMPRESA DE TELECOMUNICACIONES DE CUBA S.A. (IXP CUBA) ownerid: CU-CUBA-LACNIC responsible: Rafael López Guerra address: Ave. Independencia y 19 Mayo, s/n, address: 10600 - La Habana - CH country: CU phone: +53 7 574242  owner-c: JOQ tech-c: JOQ abuse-c: JEM52 inetrev: 200.0.16/24 nserver: NS1.NAP.ETECSA.NET nsstat: 20160123 AA nslastaa: 20160123 nserver: NS2.NAP.ETECSA.NET nsstat: 20160123 AA nslastaa: 20160123 created: 20030512 changed: 20140610
Then the last hop:
8 ix-11-3-1-0.tcore1.TNK-Toronto.as6453.net (18.104.22.168) 108.577 ms 108.449 ms 108.257 ms
...interestingly, lands directly in Toronto, in this case going later to Koumbit but that is the first hop that varies according to the destination, hops 1-7 being a common trunk to all external communications. It's also interesting that this shoves a good 90 milliseconds extra in latency, showing that a significant distance and number of equipment crossed. Yet a single hop is crossed, not showing the intermediate step of the Venezuelan link or any other links for that matter. Something obscure is going on there...
Also interesting to note is the traceroute to the redirection host, which is only one hop away:
traceroute to 192.168.134.138 (192.168.134.138), 30 hops max, 60 byte packets 1 192.168.134.138 (192.168.134.138) 6.027 ms 5.698 ms 5.596 ms
Even though it is not the gateway:
$ ip route default via 10.156.41.1 dev wlan0 proto static metric 1024 10.156.41.0/24 dev wlan0 proto kernel scope link src 10.156.41.4 169.254.0.0/16 dev wlan0 scope link metric 1000
This means a very close coordination between the different access points and the captive portal system. Finally, note that there seems to be only three peers to the Cuban internet: Teleglobe, formerly Canadian, now owned by the Indian [[!wiki Tata group]], and Telefónica, the Spanish Telco that colonized most of Latin America's internet, all the way down to Argentina. This is confirmed by my traceroutes, which show traffic to Koumbit going through Tata and Google's going through Telefónica.
Accessing http://22.214.171.124/ gives you a status page which allows you to disconnect from the portal. It actually redirects you to https://192.168.134.138/logout.user. That is also a self-signed, but different certificate. That certificate actually reveals the implication of Gemtek which is a "world-leading provider of Wireless Broadband solutions, offering a wide range of solutions from residential to business". It is somewhat unclear if the implication of Gemtek here is deliberate or a misconfiguration on the part of Cuban officials, especially since the certificate is self-signed and was issued in 2002. It could be, however, a trace of the supposed involvement of China in the development of Cuba's networking systems, although Gemtek is based in Taiwan, and not in the China mainland.
That IP, in turn, redirects you to the same portal but in a page that shows you the statistics:
Notice how you see the MAC address of the machine in the URL (randomized, this is not my MAC address), along with the remaining time, session time, client IP and the Wifi access point ESSID. There may be some potential in defrauding the session time there, I haven't tested it directly.
Actualizar redirects you back to the IP address, which
redirects you to the right URL on the portal. The "real" logout is at:
The login is performed against https://www.portal-wifi-temas.nauta.cu/index.php?r=ac/login with a referer of:
Again, notice the information revealed to the central portal.
I ran Nmap probes against both the captive portal and the redirection host, in the hope of finding out how they were built and if they could reveal the source of the equipment used.
The complete nmap probes are available in nmap, but it seems that the captive portal is running some embedded device. It is confusing because the probe for the captive portal responds as if it was the gateway, which blurs even more the distinction between the hotel's gateway and the captive portal. This raises the distinct possibility that all access points are actually captive portal that authenticate to another central server.
The nmap traces do show three distinct hosts however:
- the captive portal (
- some redirection host (
- the hotel's gateway (
They do have distinct signatures so the above may be just me misinterpreting traceroute and nmap results. Your comments may help in clarifying the above.
Still, the three devices show up as running Linux, in
the two last cases versions between
2.4.31. Now, to
find out which version of Linux it is running is way more challenging,
and it is possible it is just some custom Linux distribution. Indeed,
the webserver shows up as
G4200.GSI.2.22.0155 and the SSH server is
OpenSSH 3.0.2p1, which is basically prehistoric (2002!)
which corroborates the idea that this is some Gemtek embedded device.
The fact that those devices are running 14 years old software should be a concern to the people responsible for those networks. There is, for example, a remote root vulnerability that affects that specific version of OpenSSH, among many other vulnerabilities.
Finally, one can note that it is probably trivial to guess card
UIDs. All cards i have here start with the prefix
following digits being
4595, presumably depending on the
"batch" that was sent to different hotels, which seems to be batches
of 1000 cards. You can also correlate the UID with the date at which
the card was issued. For example,
15100357XXX cards are all valid
until 19/03/2017, and
151004595XXX cards are all valid until
23/03/2017. Here's the list of UIDs I have seen:
151004595313 151004595974 151003576287 151003576105 151003576097
The passwords, on the other hand, do seem fairly random (although my sample size is small). Interestingly, those passwords are also 12 digits long, which is about as strong as a seven-letter password (mixed uppercase and lowercase). If there are no rate-limiting provisions on that captive portal, it could be possible to guess those passwords, since you have free rein on accessing those routers. Depending on the performance of the routers, you could be lucky and find a working password for free...
Clearly, Internet access in Cuba needs to be modernized. We can clearly see that Cuba years behind the rest of the Americas, if only through the percentage of the population with internet access, or download speeds. The existence of a centralized captive portal also enables a huge surveillance potential that should be a concern for any Cuban, or for that matter, anyone wishing to live in a free society.
The answer, however, lies not in the liberalization of commerce and opening the doors to the US companies and their own systems of surveillance. It should be possible, and even desirable for Cubans to establish their own neutral network, a proposal I have made in the past even for here in Québec. This network could be used and improved by Cubans themselves, prioritizing local communities that would establish their own infrastructure according to their own needs. I have been impressed by this article about the El Paquete system - it shows great innovation and initiative from Cubans which are known for engaging in technology in a creative way. This should be leveraged by letting Cubans do what they want with their networks, not telling them what to do.
The best the Googles of this world can do to help Cuba is not to colonize Cuba's technological landscape but to cleanup their own and make their own tools more easily accessible and shareable offline. It is something companies can do right now, something I detailed in a previous article.