1

I'm having this unusual SSL issue with Safari. Basically I have a Debian server running Apache 2 (2.4.10) with OpenSSL 1.0.1t on a private network.

I've set up an SSL virtual host in the normal way and I'm using a web server certificate signed with an intermediate which in turn is signed by a private root certificate installed on all machines using an Apple configuration profile and I've verified the root is installed on the keychain.

In Chrome - this setup works fine. The page loads and the SSL certificate chain is good and Chrome reports no errors and the green padlock.

In Safari (10) - but it happened with v9 as well - and on iOS 10 - all I'm getting is "Safari can't open the page xxx because Safari can't establish a secure connection to the server xxx".

Oddly enough if I restart the Apache server it works in Safari for a couple of seconds - enough to get one page load in - before it fails again.

In cURL on the desktop - Unknown SSL protocol error.

In openssl (s_client -connect) - connected OK with Protocol: TLSv1, Cipher: EDH-RSA-DES-CBC3-SHA.

In nscurl -ats-diagnostics - FAIL on every attempt.

I thought this must be an issue with the Apache configuration so I've stripped out as much as I can that I think might be causing the issue and now in my ssl.conf I have set SSLProtocol to ALL -SSLv3 and SSLCipherSuite to MEDIUM:!aNull and in the .conf file for the vhost I have got SSLEngine on and the only other SSL configuration in there are for the certificate file, intermediate and key.

But still the site stubbornly refuses to open in Safari. What makes it very odd is that Chrome works OK! Any public SSL sites I try to go to in Safari work fine.

Any advice appreciated!

Improve this question
2
  • I suggest you tp take a dump of the network traffic between Safari and Apache first and post it here Commented Oct 12, 2016 at 11:35
  • Thanks for replying.. added more info in an answer below. Commented Oct 12, 2016 at 12:47

4 Answers 4

Reset to default
0

Looking your trace, I think I got it. Seems like the Apache virtualhost replying on IPv6 in port 443 is configured to "speak" HTTP, not HTTPS.

I verified this trying to connect to: https://google.com:80/ (or any other site) while sniffing, and the reply i get is exactly 400 like in your case.

So, check your Apache VirtualHost configuration, or just disable IPv6 in your server if you are not planning to use it.

Improve this answer
3
  • Thanks, I've marked this as the correct answer. It's strange though, as in the vhost configuration file there was <VirtualHost *:443> and my understanding is it should bind to both IPv4 and IPv6 addresses, and inside there is the SSLEngine on directive (unless something else is required). But I don't need IPv6 so I've just set the vhost to <VirtualHost 0.0.0.0:443> to bind only to IPv4. Commented Oct 12, 2016 at 14:08
  • Maybe this can explain it: serverfault.com/questions/703563/… Commented Oct 12, 2016 at 14:19
  • Hmm, maybe this can help if you want to fully solve the issue and enable IPv6: serverfault.com/questions/703563/… Commented Oct 12, 2016 at 14:33
1

Anytime I tell a software, such as you've told Apache, a cipher suite string like MEDIUM:!aNULL it works best for me to test it first with openssl ciphers command. This way you can discover many curious behaviors.

openssl ciphers -v 'MEDIUM:!aNULL' DHE-RSA-SEED-SHA SSLv3 Kx=DH Au=RSA Enc=SEED(128) Mac=SHA1 DHE-DSS-SEED-SHA SSLv3 Kx=DH Au=DSS Enc=SEED(128) Mac=SHA1 SEED-SHA SSLv3 Kx=RSA Au=RSA Enc=SEED(128) Mac=SHA1 IDEA-CBC-SHA SSLv3 Kx=RSA Au=RSA Enc=IDEA(128) Mac=SHA1 IDEA-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=IDEA(128) Mac=MD5 RC2-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC2(128) Mac=MD5 KRB5-IDEA-CBC-SHA SSLv3 Kx=KRB5 Au=KRB5 Enc=IDEA(128) Mac=SHA1 KRB5-IDEA-CBC-MD5 SSLv3 Kx=KRB5 Au=KRB5 Enc=IDEA(128) Mac=MD5 ECDHE-RSA-RC4-SHA SSLv3 Kx=ECDH Au=RSA Enc=RC4(128) Mac=SHA1 ECDHE-ECDSA-RC4-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=RC4(128) Mac=SHA1 ECDH-RSA-RC4-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=RC4(128) Mac=SHA1 ECDH-ECDSA-RC4-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=RC4(128) Mac=SHA1 RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 RC4-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 PSK-RC4-SHA SSLv3 Kx=PSK Au=PSK Enc=RC4(128) Mac=SHA1 KRB5-RC4-SHA SSLv3 Kx=KRB5 Au=KRB5 Enc=RC4(128) Mac=SHA1 KRB5-RC4-MD5 SSLv3 Kx=KRB5 Au=KRB5 Enc=RC4(128) Mac=MD5

What you could deduce from this listing is that, counterintuitively, MEDIUM means you want to exclude HIGH and LOW ciphers. Nowadays, the MEDIUM turns out to be just ancient. You can reasonably expect that any cipher suite which depends on RC4 or MD5 is disabled as insecure by clients. Support for IDEA or SEED could be not very widespread on the clients, as these were never the major ciphers. Support for SHA (old SHA1) would go away in the very near future.

In the openssl ciphers ignore the second column (SSLv3 there doesn't mean you actually use SSLv3, this is just a minimum required SSL level).

I would suggest to use HIGH:-RC4:-MD5:-PSK:-aNULL:-eNULL or, if you want to be super-new/super-secure, use HIGH:-SHA:-RC4:-MD5:-PSK:-aNULL:-eNULL

If you want to use the super-complicated explicit cipher list (like Mozilla's suggested list) be aware that you need to update the list manually with new ciphers from time to time, as you migrate to newer versions of openssl.

If you wish to explicitly give preference to some of the ciphers on Apache, you probably need to SSLHonorCipherOrder off otherwise the client-side ordering will be authoritative.

Improve this answer
0

Using MEDIUM might be problem for modern browsers, because they will forbid many old ciphers.

You may check Mozilla's suggestion about cipher, for example, you can use its "Intermediate compatibility (default)" settings: (it's very long, just copy & paste)

 SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
Improve this answer
0

Thanks for replying. I figured it out in the end by sniffing the connection between Safari and Apache and then Chrome and Apache. The server is on a private network, as I said, and I am using Avahi (zeroconf) to provide name resolution so I can use something like web-server.local and it automatically gets resolved to the correct IP address. Safari was trying to use ipv6 to connect and Chrome was trying to use ipv4.

Wireshark gave me some very unusual results when I tried to connect using Safari - here's a screenshot. It seems like the SSL connection starts being established and then the server sends a 400 error immediately.

Output from Wireshark with Safari

I tried going direct to the IPv4 address in Safari - it worked apart from the obvious certificate mismatch error.

So I disabled IPv6 in Avahi (the zeroconf daemon) and in Apache on the server. Rebooted and it works now.

Any insight as to why it might be behaving like that would be appreciated though!

Improve this answer
1
  • Looking your trace, I think I got it. Seems like the Apache virtualhost replying on IPv6 at port 443 does not speak HTTPS but HTTP. Check your virtual host config, or, if not needed, just disable IPv6 in your server. Commented Oct 12, 2016 at 13:40

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.