4

I am not sure if this is the right place to ask this, but here it goes.

The government of the country I live in has blocked wikipedia.org. Out of curiosity, I was messing around to maybe ascertain which methods were used etc. After changing my default DNS resolver to Cloudflare (1.1.1.1), I am now able to visit the address https://wikipedia.org using CLI browser lynx. However, I am not able to visit the site from my browser (Safari), nor cURL. The output of command curl https://wikipedia.org/ -vv gives:

*   Trying 103.102.166.224...
* TCP_NODELAY set
* Connected to wikipedia.org (103.102.166.224) port 443 (#0)
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /anaconda3/ssl/cacert.pem
  CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to wikipedia.org:443 
* Closing connection 0
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to wikipedia.org:443 

Questions:

  • From a technical viewpoint, why exactly can't I access https://wikipedia.org?
  • What makes it so that lynx can access the site while cURL can't ? I'm thinking it has to do with CA certificates and ssl, but I can't understand how the government can modify the certificates on my device.

EDIT: Just for clarification, I am not interested in comments on how to circumvent this block or anything; obviously there are numerous ways but they are irrelevant to this question.

EDIT1: Versions

cURL:

curl 7.58.0 (x86_64-apple-darwin13.4.0) libcurl/7.58.0 OpenSSL/1.0.2o zlib/1.2.11
Release-Date: 2018-01-24
Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp 
Features: AsynchDNS IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP UnixSockets HTTPS-proxy

lynx:

Lynx Version 2.8.8rel.2 (09 Mar 2014)
libwww-FM 2.14, SSL-MM 1.4.1, OpenSSL 1.0.2o, ncurses 5.7.20081102
Built on darwin17.0.0 Sep 18 2017 16:36:30
  • 2
    Which version of lynx are you using? How it was compiled (see output of lynx --version). Given that the block seem to be applied when sending the ClientHello my guess is that it is related to TLS SNI extension which contains the hostname in clear and can thus be detected by deep inspection. Older versions of Lynx don't support SNI and thus might be able to pass through (but they would fail with other sides since many of these need SNI today). – Steffen Ullrich May 20 '18 at 17:58
  • I am using the latest stable 2.8.8rel.2 version of lynx, which, according to the site, supports SNI. Lynx Version 2.8.8rel.2 (09 Mar 2014) libwww-FM 2.14, SSL-MM 1.4.1, OpenSSL 1.0.2o, ncurses 5.7.20081102 Built on darwin17.0.0 Sep 18 2017 16:36:30 – mlg556 May 20 '18 at 18:15
  • Could you provide a full packet capture for the connections from lynx and curl (upload to cloudshark.org or provide download) so that one can have a look at the difference? – Steffen Ullrich May 20 '18 at 19:33
  • It is definitely NOT a certificate issue; your curl is failing before the point of even seeing much less checking the server cert. – dave_thompson_085 Jul 15 '18 at 3:39
1

Your government has probably blocked connections to wikipedia.org by looking at the Server Name Indication (SNI) on the https handshake and forcing an error if the domain is on their blacklist.

Your version of lynx is probably not providing the domain server in the TLS SNI extension, while both Safari and curl do. Wikipedia works fine without an explicit server name at TLS layer (it will have provided a wildcard cert *.wikipedia.org, with wikipedia.org as alternative name, so it doesn't need to present a different cert to your client). If your government filters didn't cater that case (or simply didn't want to block everything for which they didn't have a full hostname), such connection would be allowed, with most other clients failing.

According to the lynx changelog I would expect your lynx version to support SNI, though (added on 2.8.7pre.2 for openssl, on 2.8.8dev.15 for GNUTLS). You can easily confirm if it is being provided with a packet dump.

  • An easy way to check this is to try openssl s_client -connect wikipedia.org:443 </dev/null (<NUL: on Windows) with and without -servername wikipedia.org which respectively sends or omits SNI, with no other difference. – dave_thompson_085 Jul 15 '18 at 3:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.