The GUI browsers (such as FIrefox) can open a URL but curl timesout

Question

The problem showed itself when I executed apt-get update and it failed when trying to update gitlab-ce repository with following error (although it just did work about a month ago):

W: Failed to fetch https://packages.gitlab.com/gitlab/gitlab-ce/ubuntu/dists/xenial/InRelease  Operation timed out after 0 milliseconds with 0 out of 0 bytes received

then I tried curl to see the same URL and again it failed with following message:

curl -vvv https://packages.gitlab.com/gitlab/gitlab-ce/ubuntu/dists/xenial/InRelease
*   Trying 54.153.54.194...
* Connected to packages.gitlab.com (54.153.54.194) port 443 (#0)
* found 148 certificates in /etc/ssl/certs/ca-certificates.crt
* found 600 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* Operation timed out after 0 milliseconds with 0 out of 0 bytes received
* Closing connection 0
curl: (28) Operation timed out after 0 milliseconds with 0 out of 0 bytes received

but the funny thing is when I try to open the same URL using Firefox from the same system, it just works, although it redirects to another URL, but it works. The redirection target is something such as

https://packages-gitlab-com.s3-accelerate.amazonaws.com/7/8/ubuntu/dists/xenial/InRelease?AWSAccessKeyId=AKIAJ74R7IHMTQVGFCEA&Signature=Dwkp3C7Q2mXBtiPCUiFZhoGzWF8%3D&Expires=1529707236

What can I do to fix the problem and make apt-get update work again.

The result of curl -V:

curl 7.47.0 (x86_64-pc-linux-gnu) libcurl/7.47.0 GnuTLS/3.4.10 zlib/1.2.8 libidn/1.32 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz TLS-SRP UnixSockets

Perhaps add `capath=/etc/ssl/certs/` to your ~/.curlrc? There is also another setting: `cacert=/etc/ssl/certs/ca-certificates.crt`. This may help as I note that you are missing from your output: 'successfully set certificate verify locations:'. — andrew.46, Jun 27 '18 at 00:17
Nothing changed the same thing, just stopped at `ALPN, offering http/1.1` line. — Amir Pashazadeh, Jun 29 '18 at 23:22
Is this a persistent problem? Have you tried resetting your internet connection? — xiota, Jun 30 '18 at 03:26
I've had problems with `curl` and used `wget` instead with success. Have you tried `wget`? — WinEunuuchs2Unix, Jul 01 '18 at 21:34
@xiota I shut-down this computer every night, so the internet connection gets reset every day. And amazingly the problem is solved by itself, without me doing anything. — Amir Pashazadeh, Aug 04 '18 at 23:25
Is it a recurrent problem or completely resolved on its own? — xiota, Aug 05 '18 at 00:11

score 3 · Answer 1 · answered Jun 22 '18 at 22:44

3

I'm not sure why you're getting a timeout. Oddly the tcp connection is successful, but the ALPN extension to TLS is whats causing the timeout. You're not getting an ALPN response. Perhaps its transient? You could try adding the option --no-alpn also. Regardless, for curl to retrieve the file you want, you will need the -L option to follow redirects. The following works for me: curl -vvvL https://packages.gitlab.com/gitlab/gitlab-ce/ubuntu/dists/xenial/InRelease

answered Jun 22 '18 at 22:44

crass

465
3
11

By the way it just waits for a long time (more than 2 minutes) at ALPN line. – Amir Pashazadeh Jun 22 '18 at 23:47
I've added **--no-alpn** and **-L** switches, and everything goes fine, and returned the same result that firefox had shown. So how I configure **apt-get update** to do same thing and disable **alpn** in it? – Amir Pashazadeh Jun 22 '18 at 23:52
As far as I can tell `apt-transport-https` which does the https request doesn't have an option to turn off ALPN. You'd probably have to add that to the C code yourself and recompile. Alternatively you could setup your own SSL proxy, which would also be a pain... – crass Jun 23 '18 at 00:47
The strange thing is everything was okay for more than a year, and I have encountered this problem for about a month. Can I have some problems with my SSL certificates? – Amir Pashazadeh Jun 23 '18 at 05:33
If you do the `curl` without `--no-alpn` what is the verbose output? Its possible that SSL certs are a problem, since ALPN can affect cert selection. However, since its the same cert set as without ALPN, I wouldn't think it would be the problem. – crass Jun 23 '18 at 07:03
Using wireshark could help identify exactly where in the protocol negotiation things are getting fscked. It actually seems like to me that you have something transparently proxying your SSL connection and it doesn't like ALPN. ALPN works for nosklo and I, but not you. The log in your question appears as though curl is sending a TLS ClientHello with ALPN, but never getting a reply back. However, when you do the same without ALPN you do get a reply back. So it seems like something is inspecting and blocking your ClientHello packets with ALPN... – crass Jun 23 '18 at 07:23

score 1 · Answer 2 · answered Jun 22 '18 at 22:44

You're probably experiencing server overload issues. I just tried your curl command and it returned fine:

nosklo@onyx:/tmp$ curl -vvv https://packages.gitlab.com/gitlab/gitlab-ce/ubuntu/dists/xenial/InRelease
*   Trying 54.153.54.194...
* TCP_NODELAY set
* Connected to packages.gitlab.com (54.153.54.194) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: OU=Domain Control Validated; OU=PositiveSSL; CN=packages.gitlab.com
*  start date: Feb 21 00:00:00 2018 GMT
*  expire date: Feb 26 23:59:59 2019 GMT
*  subjectAltName: host "packages.gitlab.com" matched cert's "packages.gitlab.com"
*  issuer: C=GB; ST=Greater Manchester; L=Salford; O=COMODO CA Limited; CN=COMODO RSA Domain Validation Secure Server CA
*  SSL certificate verify ok.
> GET /gitlab/gitlab-ce/ubuntu/dists/xenial/InRelease HTTP/1.1
> Host: packages.gitlab.com
> User-Agent: curl/7.58.0
> Accept: */*
> 
< HTTP/1.1 302 Found
< Server: nginx
< Date: Fri, 22 Jun 2018 22:43:09 GMT
< Content-Type: text/html;charset=utf-8
< Content-Length: 0
< Connection: keep-alive
< Location: https://packages-gitlab-com.s3-accelerate.amazonaws.com/7/8/ubuntu/dists/xenial/InRelease?AWSAccessKeyId=AKIAJ74R7IHMTQVGFCEA&Signature=fTf126FjXAZAHkuzf2LKKLV5O5s%3D&Expires=1529707689
< X-XSS-Protection: 1; mode=block
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< Cache-Control: no-cache
< X-Request-Id: 62f491a7-9ae3-45c1-bb09-21ccfd83c855
< X-Runtime: 0.005186
< Strict-Transport-Security: max-age=31536000
< X-Frame-Options: DENY
< 
* Connection #0 to host packages.gitlab.com left intact

If you still have problems, please show us the results of curl -V

I don't thing so, because the problem is there for more than a month, in different times and hours of the day. But when I try the URL from Firefox from the same computer, it just works. — Amir Pashazadeh, Jun 22 '18 at 22:51
firefox might have cached the results, try pressing F12 to open firefox developer tools and go to network tab, check the response headers for the request there — nosklo, Jun 22 '18 at 22:52
No, it is not cached, and refreshing just works. And it redirects again. — Amir Pashazadeh, Jun 22 '18 at 23:38
Isnt it something about SSL certificates stored on my machine? — Amir Pashazadeh, Jun 22 '18 at 23:38

The GUI browsers (such as FIrefox) can open a URL but curl timesout

2 Answers2