bootstrapcdn: Accessing maxcdn via https and IPv6 hangs for 6 seconds

Every request of my firefox to netdna/maxcdn.boostrapcdn.com hangs for 5 seconds but only via https and IPv6.

I do not see it this via IPv4 and/or http. I can reproduce it in curl on multiple systems:

$ curl https://maxcdn.bootstrapcdn.com -v --trace-time
11:09:54.576654 * Rebuilt URL to: https://maxcdn.bootstrapcdn.com/
11:09:54.580948 *   Trying 2001:4de0:ac19::1:b:3a...
11:09:54.580998 * TCP_NODELAY set
11:09:54.592772 * Connected to maxcdn.bootstrapcdn.com (2001:4de0:ac19::1:b:3a) port 443 (#0)
11:09:54.593233 * ALPN, offering h2
11:09:54.593255 * ALPN, offering http/1.1
11:09:54.597702 * successfully set certificate verify locations:
  CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
11:09:54.597806 * TLSv1.2 (OUT), TLS handshake, Client hello (1):
11:10:01.172494 * TLSv1.2 (IN), TLS handshake, Server hello (2):
11:10:01.193717 * TLSv1.2 (IN), TLS handshake, Certificate (11):
11:10:01.194679 * TLSv1.2 (IN), TLS handshake, Server key exchange (12):
11:10:01.194929 * TLSv1.2 (IN), TLS handshake, Server finished (14):
11:10:01.195292 * TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
11:10:01.195388 * TLSv1.2 (OUT), TLS change cipher, Client hello (1):
11:10:01.195539 * TLSv1.2 (OUT), TLS handshake, Finished (20):
11:10:01.206750 * TLSv1.2 (IN), TLS handshake, Finished (20):
11:10:01.206826 * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
11:10:01.206899 * ALPN, server did not agree to a protocol
11:10:01.206956 * Server certificate:
11:10:01.207039 *  subject: OU=Domain Control Validated; CN=*.bootstrapcdn.com
11:10:01.207095 *  start date: Oct  3 00:00:00 2017 GMT
11:10:01.207148 *  expire date: Oct 13 23:59:59 2018 GMT
11:10:01.207224 *  subjectAltName: host "maxcdn.bootstrapcdn.com" matched cert's "*.bootstrapcdn.com"
11:10:01.207298 *  issuer: C=GB; ST=Greater Manchester; L=Salford; O=COMODO CA Limited; CN=COMODO RSA Domain Validation Secure Server CA
11:10:01.207360 *  SSL certificate verify ok.
11:10:01.207468 > GET / HTTP/1.1
11:10:01.207468 > Host: maxcdn.bootstrapcdn.com
11:10:01.207468 > User-Agent: curl/7.59.0
11:10:01.207468 > Accept: */*
11:10:01.207468 > 
11:10:01.569831 < HTTP/1.1 200 OK
11:10:01.569912 < Date: Mon, 23 Apr 2018 09:10:01 GMT
11:10:01.569977 < Connection: Keep-Alive
11:10:01.570035 < Accept-Ranges: bytes
11:10:01.570084 < ETag: 1379709728
11:10:01.570138 < Cache-Control: max-age=31536000
11:10:01.570181 < Content-Length: 0
11:10:01.570235 < Content-Type: binary/octet-stream
11:10:01.570296 < X-Cache: MISS
11:10:01.570357 < Access-Control-Allow-Origin: *
11:10:01.570420 < Last-Modified: Fri, 20 Sep 2013 20:42:08 GMT
11:10:01.570485 < 
11:10:01.570552 * Connection #0 to host maxcdn.bootstrapcdn.com left intact

This happens for all hosts maxcdn.bootstrapcdn.com resolves to.

About this issue

Original URL
State: closed
Created 6 years ago
Reactions: 1
Comments: 33 (13 by maintainers)

Most upvoted comments

@jdorfman It is working great now.

yugandhar91 on Jul 4, 2018

Enabled the plug-in using the font in your cdn… load times are back to < 20ms.

Happy fourth everyone!

On Wed, Jul 4, 2018, 12:56 PM Justin Dorfman notifications@github.com wrote:

@yugandhar91 https://github.com/yugandhar91 we disabled IPv6 (again), can you please check and report back?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MaxCDN/bootstrapcdn/issues/1061#issuecomment-402535183, or mute the thread https://github.com/notifications/unsubscribe-auth/APp7wQlGC4g5bm9jfOGSSWC4wrbj2mCJks5uDQHpgaJpZM4Tfhc7 .

sgarringer on Jul 4, 2018

One more experiment from my side:

# ip -6 route get 2001:4de0:ac19::1:b:1a
2001:4de0:ac19::1:b:1a from :: via fe80::d0b7:8eff:fe33:c74e dev enp0s25 proto ra src 2003:eb:4bc9:e0fc:56ee:75ff:fe46:cb56 metric 100 pref medium

If I ping that IP address with a size larger than 1444:

# ping -s 1445 2001:4de0:ac19::1:b:1a
PING 2001:4de0:ac19::1:b:1a(2001:4de0:ac19::1:b:1a) 1445 data bytes
From 2003:eb:4bc9:e0fc:d0b7:8eff:fe33:c74e icmp_seq=1 Packet too big: mtu=1492

The routing cache gets updated with the pmtu:

# ip -6 route get 2001:4de0:ac19::1:b:1a
2001:4de0:ac19::1:b:1a from :: via fe80::d0b7:8eff:fe33:c74e dev enp0s25 src 2003:eb:4bc9:e0fc:56ee:75ff:fe46:cb56 metric 0 
    cache expires 597sec mtu 1492 pref medium

Once the routing cache contains this information I do not see any timeouts accessing that IP address.

adrianreber on Jun 6, 2018

I am facing the same problem. When attempting to connect to maxcdn.bootstrapcdn.com via IPv6 and HTTPS connection hangs for a good 3-5 seconds. curl output is the same as OP’s. The delay is right after * TLSv1.2 (OUT), TLS handshake, Client hello (1). IPv4 works as expected. The IP attempted is 2001:4de0:ac19::1:b:1b but as reported is the same for all the IPv6s the domain resolves to. If you’re still gathering logs I’ll be happy to send them.

foucault on May 16, 2018

@jdorfman output of mtr sent via email

adrianreber on May 4, 2018