Internet in Cuba
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.
"Censorship" and workarounds
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
article.
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.
The Cuban captive portal
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.
Bypassing the Cuban captive portal
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
Still, it allowed me to login to my home server through SSH using Mosh to workaround the reliability issues.
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.
Private information revealed to the captive portal
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...
Network configuration assessment
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.
Line quality
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.
The line speed I get is around 1mbps, according to speedtest, which selected a server from LIME in George Town, Cayman Islands:
[1034]anarcat@angela:cuba$ speedtest
Retrieving speedtest.net configuration...
Retrieving speedtest.net server list...
Testing from Empresa de Telecomunicaciones de Cuba (152.206.92.146)...
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.
Network topology
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 (199.58.80.33), 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 200.0.16.130 (200.0.16.130) 14.428 ms 11.393 ms 10.977 ms
7 200.0.16.74 (200.0.16.74) 10.738 ms 10.019 ms 10.326 ms
8 ix-11-3-1-0.tcore1.TNK-Toronto.as6453.net (64.86.33.45) 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 200.0.16.130 (200.0.16.130) 14.428 ms 11.393 ms 10.977 ms
7 200.0.16.74 (200.0.16.74) 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
in Cuba:
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 (64.86.33.45) 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.
Captive portal implementation
The captive portal is https://www.portal-wifi-temas.nauta.cu/ (not
accessible outside of Cuba) and uses a
self-signed certificate. The domain name resolves to
190.6.81.230 in the hotel.
Accessing http://1.1.1.1/ 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:
https://www.portal-wifi-temas.nauta.cu/?mac=0024D1717D18&script=logout.user&remain_time=00%3A55%3A52&session_time=00%3A04%3A08&username=151003576287&clientip=10.156.41.21&nasid=Wifi_Memories_Jibacoa&r=ac%2Fpopup
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.
Hitting Actualizar redirects you back to the IP address, which
redirects you to the right URL on the portal. The "real" logout is at:
http://192.168.134.138/logout.user?cmd=logout
The login is performed against https://www.portal-wifi-temas.nauta.cu/index.php?r=ac/login with a referer of:
https://www.portal-wifi-temas.nauta.cu/?&nasid=Wifi_Memories_Jibacoa&nasip=192.168.134.138&clientip=10.156.41.21&mac=EC:55:F9:C5:F2:55&ourl=http%3a%2f%2fgoogle.ca%2f&sslport=443&lang=en-US%2cen%3bq%3d0.8&lanip=10.156.41.1
Again, notice the information revealed to the central portal.
Equipment and providers
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 (
www.portal-wifi-temas.nauta.cu,190.6.81.230) - some redirection host (
192.168.134.138) - the hotel's gateway (
10.156.41.1)
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.21 and 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
running 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.
A note on Nauta card's security
Finally, one can note that it is probably trivial to guess card
UIDs. All cards i have here start with the prefix 15100, the
following digits being 3576 or 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...
Conclusion
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.
Hi, nice post.
I am cuban
so i can support everything said here.
Some years ago, before they make "Nauta" cards available for everyone, you could buy similar cards only in some hotels and at a higher price (starting at $4 for the same time), that system it was even easier to override just using http://your-freedom.net with DNS routing as you describe with Iodine but without need for you own servers on the outside world.
I don't live there anymore, so your post brought me some good memories
All of the public IPs in your article seem to belong to two ASes. 11960 which seems to be ETECSA's interconnect AS
and 27725 which seems to be the Cuban internal ISP AS. This one has two IP blocks, one /20 and one /21
In the RIB for AS11960 it says that they are announcing routes (the "as-out:" entries) to three other ASes (apart from itself and the internal Cuban AS). They're also accepting any route from the same three ASes. They are
So according to the RIB information, they are not peering directly with Telefónica. But that information might be old and not reflect what is done in reality.
From Koumbit the shortest path according to BGP is through Tata like you pointed out, except for the captive portal's IP which passes through Telefónica (AS12956 in the last entry in the next block of output):
If I traceroute to the captive portal IP, I go through Cogent, as expected from the AS path above, then hit diffrent layers of Telefónica IPs that don't resolve and finally end up in Cuba (line 13) where I seem to be going in circles on the same three IPs. After this packets don't get any response, so I'm either hitting TTL=0 or ICMP is blocked. The last point within Telefónica before going to Cuba is 84.16.8.106. Seeing that lines that come afterwards, which show Cuban IPs, are not showing an additional delay, it's probably configured on a router in Cuba or not too far from there. The fact that there's a 60ms delay before reaching that IP is indicating that there's definitely something going on there, though.
Hello, great article! I am currently writing an essay on cuban internet, but I am not as tech-savvy, so I need to ask someone else: Is there a way how a person from outside (Central Europe) can experience Cuban internet censorship from a Cubans point of view? I tried finding a free, even paid VPN servers, Tor nodes, but had no luck. Any ideas o recommendations? Thanks, Jan
And here is an excellent article about the alternative internet in Cuba. It is fascinating to read about self-censorship in that context: I would have thought that those spaces would be revolutionary, where political discussion and dissent would be encouraged rather than censored.
But then "revolutionary" has a different meaning in Cuba, I guess.