Facebook in Russia and a diagnostic problem
Around half of the RIPE Atlas probes in Russia cannot complete a TLS session with facebook.com <https://atlas.ripe.net/measurements/39387725/>. (All the remaining tests have been done with the same set of probes, 'type': 'msm', 'value': '39387725'.) They have no problem with YouTube <https://atlas.ripe.net/measurements/39387839>. I also did TLS tests with IP addresses instead of names, same result <https://atlas.ripe.net/measurements/39387985> <https://atlas.ripe.net/measurements/39388031>. There is no lying DNS resolver <https://atlas.ripe.net/measurements/39387902>. But traceroute show no connectivity problem either, we can go to the Facebook AS from Russia <https://atlas.ripe.net/measurements/39388122> <https://atlas.ripe.net/measurements/39388176>. So, I'm a bit lost: what do we observe? It does not look like censorship but not like a connectivy issue (because of depeering by Cogent and Lumen) either.
On Mon, Mar 14, 2022 at 8:13 PM Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
Around half of the RIPE Atlas probes in Russia cannot complete a TLS session with facebook.com <https://atlas.ripe.net/measurements/39387725/>. (All the remaining tests have been done with the same set of probes, 'type': 'msm', 'value': '39387725'.) They have no problem with YouTube <https://atlas.ripe.net/measurements/39387839>. I also did TLS tests with IP addresses instead of names, same result <https://atlas.ripe.net/measurements/39387985> <https://atlas.ripe.net/measurements/39388031>.
There is no lying DNS resolver <https://atlas.ripe.net/measurements/39387902>.
But traceroute show no connectivity problem either, we can go to the Facebook AS from Russia <https://atlas.ripe.net/measurements/39388122> <https://atlas.ripe.net/measurements/39388176>.
So, I'm a bit lost: what do we observe? It does not look like censorship
It is. Facebook is officially blocked in Russia [1] [1] https://rkn.gov.ru/news/rsoc/news74156.htm
but not like a connectivy issue (because of depeering by Cogent and Lumen) either.
-- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
-- SY, Jen Linkova aka Furry
On Mon, Mar 14, 2022 at 10:26:46PM +1100, Jen Linkova <furry13@gmail.com> wrote a message of 37 lines which said:
It is. Facebook is officially blocked in Russia [1]
I know but I was asking *how* it is implemented and it is far from obvious, from the data. Hence my question to network experts: how to explain what the Atlas probes see?
On Mon, 14 Mar 2022 at 13:17, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
On Mon, Mar 14, 2022 at 10:26:46PM +1100, Jen Linkova <furry13@gmail.com> wrote a message of 37 lines which said:
It is. Facebook is officially blocked in Russia [1]
I know but I was asking *how* it is implemented and it is far from obvious, from the data. Hence my question to network experts: how to explain what the Atlas probes see?
Most likely TCP session kill based on the server response (certificate). It could also be a combination of multiple indicators. IP addresses, SNI, TTL, but here it seems more likely to be the first one. This could be proven: put a self-signed cert of www.facebook.com on a server and try to repeat the IP address based check. Lukas
On Mon, Mar 14, 2022 at 6:07 AM Lukas Tribus <lukas@ltri.eu> wrote:
Most likely TCP session kill based on the server response (certificate).
It could also be a combination of multiple indicators. IP addresses, SNI, TTL, but here it seems more likely to be the first one.
This could be proven: put a self-signed cert of www.facebook.com on a server and try to repeat the IP address based check.
This is indeed what I could see last week. For instance, providing a SNI of Instagram.com (1 week ago) would get through, providing an SNI of foo.com would fail verification (expected), providing an empty value for SNI would also fail with client hello read timeout. When no SNI is provided, the default cert is for *.Facebook.com. Asking for Facebook.com against a Cloudflare IP was also showing the read timeout. Request to CF IP with empty SNI would successfully return a cert.
This suggest that either SNI filtering is done on return client hello so it can catch the default cert when no SNI is provided, or that there is a combination of dropping outgoing client hello with specific name + dropping empty SNI to specific ranges, or a combination of both. The CF example makes he believe it is the second option. I will send example probes when I get to a device with a keyboard. Manu
Lukas
-- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
On Mon, Mar 14, 2022 at 10:37 AM Manu Bretelle <chantr4@gmail.com> wrote:
I will send example probes when I get to a device with a keyboard.
Here goes: CF IP/fb SNI: https://atlas.ripe.net/measurements/39191279/ CF IP/no SNI: https://atlas.ripe.net/measurements/39191278/ FB IP/fb SNI: https://atlas.ripe.net/measurements/39241713/ FB IP/foobar.com SNI: https://atlas.ripe.net/measurements/39241798/ FB IP/no SNI: https://atlas.ripe.net/measurements/39191282/ FB IP/instagram SNI: https://atlas.ripe.net/measurements/39191583/
Manu
Lukas
-- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
On 10:09 14/03, Stephane Bortzmeyer wrote:
So, I'm a bit lost: what do we observe? It does not look like censorship but not like a connectivy issue (because of depeering by Cogent and Lumen) either.
They could be dropping return packets after TLS client hello negotiation. Hugo
Op 2022-03-14 om 13:36 schreef Hugo Salgado:
On 10:09 14/03, Stephane Bortzmeyer wrote:
So, I'm a bit lost: what do we observe? It does not look like censorship but not like a connectivy issue (because of depeering by Cogent and Lumen) either.
They could be dropping return packets after TLS client hello negotiation.
If this is purely about observing on how this is done (ie. not about what we can measure with Atlas), I find the things the OONI project does very insightful. For this particular case: https://ooni.org/post/2022-russia-blocks-amid-ru-ua-conflict/ They document the different techniques used and their prevalence hope this helps, Emile
participants (6)
-
Emile Aben -
Hugo Salgado -
Jen Linkova -
Lukas Tribus -
Manu Bretelle -
Stephane Bortzmeyer