Safari time-out on SSL connection

The site works in Chrome, Firefox, etc but times out in Safari on both macOS Sierra and iOS. Here’s the relevant config settings (left out the standard vhost definition). This was working when I initially did it, but then stopped. I adjusted settings to the below in order to get the SSLlabs up to A+ (it was failing before that).

CentOS6, Apache 2.2

SSLEngine on
SSLProtocol ALL -SSLv2 -SSLv3 -TLSv1
SSLHonorCipherOrder on 
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
SSLCertificateFile /etc/letsencrypt/live/www.patchvault.org/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/www.patchvault.org/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/www.patchvault.org/chain.pem

It appeared to be similar to this issue ([solved] Safari fails to talk to LE-powered website, other browsers are fine) but it DOES work with curl

Although your “SSLCipherSuite” settings allow for:

The system seems to only manage:
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES256-SHA384
ECDHE-RSA-AES128-SHA256

Try adding “:HIGH” just to test Safari access.
If that does display the site, then try: https://www.ssllabs.com/ssltest/viewMyClient.html
from the Safari clients and see which Ciphers are being used.

Thanks, rg305!

Added :HIGH at the end of the chain, and the time out is still occuring. Tried a private window in Safari as well, just to try and ensure that it wasn’t some weird local cache.

The SSLLabs test shows that Safari is using TLS1.2 with spdy and also lists the cipher. :HIGH drops the test quality to an “F” but the test “connects” for either setting. Could this be a mod_pagespeed/spdy issue or is something happening with the handshake (is that the right term?)

Safari 10 / OS X 10.12 R RSA 2048 (SHA256) TLS 1.2 > spdy/3 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS

Well you can remove the test “:HIGH”.
If SSL Labs has no issue with the cert then this problem is not cert related.

Nonetheless, I would rerun both SSL Labs tests.

For the server (https://www.ssllabs.com/ssltest/) and look at:

  1. Supported Named Groups
  2. Everything within the “HTTP Requests” section (near the bottom)

For the client (https://www.ssllabs.com/ssltest/viewMyClient.html)

  1. Ensure that your particular Safari client supports at least one of the “Supported Named Groups” seen on the server.

Most likely the problem will be found somewhere within server line 2 results.
Maybe you can post that entire section here.

From the browser (named groups):
secp256r1, secp384r1, secp521r1

Cert named group:
secp256r1

So that’s covered. Here’s the HTTP REquest dump:

Date	Fri, 21 Jul 2017 01:58:58 GMT.
Server	Apache/2.2.22 (@RELEASE@)
Cache-Control	max-age=0, private, must-revalidate
Vary	Accept-Encoding
Strict-Transport-Security	max-age=15552000; includeSubDomains
X-XSS-Protection	1; mode=block
X-Request-Id	973ba516-6d4a-4ec3-ac06-3cac02f7b183
ETag	W/"54ef5cd78f4c19ae0c92a8e9a1e6c44a"
X-Frame-Options	SAMEORIGIN
X-Runtime	0.025277
X-Content-Type-Options	nosniff
X-Powered-By	Phusion Passenger 5.1.2
Set-Cookie	    _patch_vault_session=QTMvQ29JZVJoY08xZ0x0UzhhZ250VXNZTTZKMGpDc3hvamgxT1NSZ3JnQ0JsNi84N1VYQzBuOFp2SzNJT3FaaFRLNDRiYmZMN0JJZk5lQ01ZSDBxWEFhSkNLb3N6YVIzYWgrTVlmMlcvN2xwOWZ4TFpsRUdNTVE3UmZxeXRweTZvUlVlK1UxTUVSV01kcm9waVduZ05FUXZSYVcrSDdaSG5TQzcyUXgyOVQzY3BsMjlsL292bTZtc2NLenNTSWY0LS1yRTNVQXpLVFljWmpuRkZrV2FYdkxnPT0%3D--0562ffee34fa85b430ad4134bac74d9d551ef248; path=/; secure; HttpOnly
Status	200 OK
X-Mod-Pagespeed	1.12.34.1-0
Cache-Control	max-age=0, no-cache, s-maxage=10
Content-Length	16396
Connection	close
Content-Type	text/html; charset=utf-8

not sure if this even matters but your using HSTS and the cookie ends with “HttpOnly” - maybe Safari doesn’t like that?

Totally different and unrelated mechanisms. HttpOnly only means that the cookie cannot be accessed by JavaScript. It means “HTTP protocol headers as opposed to scripts”, not “HTTP as opposed to HTTPS”.

Thanks for that clarification.
Sadly, that leaves me with no reason why this is failing.
Maybe you can see something we have missed…

In the interim, the only thing for me to add is that from an iPhone with Safari:
https://patchvault.org works (mostly)
https://www.patchvault.org does NOT work - only clue given:
Safari could not open the
page because the server
stopped responding.

The one failure to https://patchvault.org showed:
Cannot Verify Server Identty
The Identity of “patchvault.org” cannot
be verified by Safari. Review the
certificate details to continue.
“Continue”
“Details”
“Cancel”

Details showed:
an untrusted cert for “www.patchvault.org” (not patchvault.org)
with Serial Number:
03 A2 DD 16 99 91 1A
8D A6 DE 17 F6 22 EA
66 C2 4A 25

–hopefully this will help you figure it out–

hi @jathayde

I think maybe you are looking at the wrong areas

A) You seem to have 3 certificates https://crt.sh/?q=%patchvault.org this is a common issue that you should fix as the certificate you are using does not cover patchvault.org
B) You do have a certificate that covers both
C) run certbot certificates to see the certificates you are currently managing (i believe there should be 3)
D) run certbot delete and remove 2 (the one that has only www. version of your site)
E) Update apache config

Generally have multiple versions of the same certificate is a bad idea as it creates confusion and also may get you in to issue with rate limits

Your assets take a while to load. i am on a slow connection however 7 seconds is quite a long time in the modern web world.

I also noticed that you are using SPDY3 https://spdycheck.org/#www.patchvault.org. What version of Safari are you using your devices?

http://caniuse.com/#feat=spdy

Try turning the SPDY settings off and testing with the two browsers you have

Andrei

also I would turn off HTTP to HTTPS rewrite/redirection and then test over HTTP as well. If this fails under that condition then you know you have a core protocol issues rather than an SSL issue

so testing steps

A) Turn off HTTP -> HTTPS rediertion (you should be able to browse to http://patchvault.org)
B) test http://patchvault.org in both safari browsers
C) if issues still persist then turn of all spdy related settings
D) test again
E) If things are still not working you can probably narrow it down to another area

I am not sure how easy it is for you to add a DNS record but i would suggest that while you are setting up that you create a testing version of your website.

I usually have alpha.mydomain.tld and beta.mydomain.tld as well as mydomain.tld and www.mydomain.tld

the alpha and beta are testing and staging and it means I can do troubleshooting against those without affecting production (just a thought)

Andrei

Thanks, Andrei. I’ll look into the 3 certs issue. I’m assuming I’d want to use the cert that covers www and straight up patchvault.org?

As for assets, there’s a large number of productization related tickets in the queue around caching, sprite making, etc. Right now nothing is cached, so it’s going to rails when it should be hitting an eTag’d static file once we’re a little closer to being “real”.

I’m using Safari 10.1.2 on the desktop and the iOS 11 beta on the phone, which do support SPDY. May turn that off just to limit the number of possible issues at this point.

You should remove the “:HIGH” from the SSLCipherSuite line; as shown by the SSL Labs test results = “B” and "DH 1024 bits FS WEAK"
Or append “:!DHE:!SHA1” to bring it back to what I believe you originally intended.

hi @jathayde

I would see how the performance goes over HTTP I would expect the loads to be faster

You have quite large assets being downloaded so it couldn’t be a mobile browser not waiting long enough for your CSS and JS files to load.

It’s a weird problem but my thinking it’s a web related one not an SSL one.

https://discussions.apple.com/thread/7508288?tstart=0

Andrei

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.