Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Safari forcing HTTPS for some HTTP only sites

I have a strange issue with Safari (7.0.1 on Mavericks 10.9.1). It is similar to a few other issues that folk have posted about here but I am opening a separate post because some of the details are different. Please read to the end before suggesting I try disabling extensions, clear cache etc.


This issue is affecting only one user on one Mac (we have several users and several Macs).


We host our own web-site using OS X Server (Mavericks / Server 3.0). Soem areas of the site support both HTTP and HTTPS access. For example:


Live (public) site


http://www.ourdomain.com (on port 80)

https://www.ourdomain.com (on port 443)


and


Test (internal) site

http://www.ourdomain.com:81

https://www.ourdomain.com:444


and


Intranet (internal)


http://www.ourdomain.com:8080


Most areas of the site do not require HTTPS protection and in particular for the Test site both the htp and the https versions have explicit ports. For the Intranet site there is no HTTPS version. For the live and test sites, a certain sub-set of the site requires user authentication and I have redirects setup to redirect access to just those areas via the HTTPS URL which also enforces user authentication.


This setup all works fine, except for this one user on this one machine and only when they use Safari (Chrome and FireFox are fine)...


They have Safari bookmarks saved for the HTTP URLs and after a while:


1. These bookmarks start referring to tthe HTTPS URLs. The actual bookmarks get changed and the http gets changed to https! In the case of the Test and Intranet sites these URLs are not even valid. So, the bookmarks no longer work. If we edit the bookmarks and change them back to http they immediately revert back to https!


2. If one types the HTTP URL directly into the address bar then Safari ignores the HTTP and instead tries to go to the HTTPS version of the URL.


Basically, there is no way to get Safari to access the HTTP versions of any of these URLs with the resuklt that the Test and Intranet sites are unusable.


This user only has the same extensions as other users have and they all work okay. We have tried disabling extensions but it does not resolve the issue. Doing a full reset of Safari will resolve the issue temporarily but this deletes a lot of stuff, such as History, that the user does not want deleted. And the issue always recurs after a while anyway.


Does anyone have any idea what is causing this behaviour and how to prevent it? It is driving me and the affected user mad!

iMac, OS X Mavericks (10.9)

Posted on Feb 9, 2014 6:09 AM

Reply
Question marked as Best reply

Posted on Feb 9, 2017 8:04 PM

I realize this is an old thread, but I hope this helps someone in the future...


This problem infuriated me for a long time. As you suggest, Safari will cache HTTP Strict-Transport-Security requests from websites and automatically switch to https in the future. This creates a lot of problems when you are running multiple different servers on `localhost`, some of which request it, and others that don't. In my case, it caused connections to my Jupyter notebooks to fail after I had tunneled connections to other sites through ssh.


There are old posts elsewhere on the web that suggest quitting Safari, deleting ~/Library/Cookies/HSTS.plist, and restarting Safari will resolve the issue. This didn't work for me on macOS Sierra because the HSTS settings were being cached and the file would be recreated. In my case, I had to


  1. Quit Safari
  2. In Terminal, `rm ~/Library/Cookies/HSTS.plist`
  3. Immediately reboot before some background service reconstructed the file


I filed a report with Apple suggesting that HSTS not be saved for localhost, which isn't really a domain anyway. Don't know if they will acknowledge.

32 replies
Question marked as Best reply

Feb 9, 2017 8:04 PM in response to lenn4rd

I realize this is an old thread, but I hope this helps someone in the future...


This problem infuriated me for a long time. As you suggest, Safari will cache HTTP Strict-Transport-Security requests from websites and automatically switch to https in the future. This creates a lot of problems when you are running multiple different servers on `localhost`, some of which request it, and others that don't. In my case, it caused connections to my Jupyter notebooks to fail after I had tunneled connections to other sites through ssh.


There are old posts elsewhere on the web that suggest quitting Safari, deleting ~/Library/Cookies/HSTS.plist, and restarting Safari will resolve the issue. This didn't work for me on macOS Sierra because the HSTS settings were being cached and the file would be recreated. In my case, I had to


  1. Quit Safari
  2. In Terminal, `rm ~/Library/Cookies/HSTS.plist`
  3. Immediately reboot before some background service reconstructed the file


I filed a report with Apple suggesting that HSTS not be saved for localhost, which isn't really a domain anyway. Don't know if they will acknowledge.

Aug 18, 2017 11:10 AM in response to MarkChenFrom北京

It's pretty funny all the complaints about a broken Safari or something like that.


Hey guys, this works as designed. HSTS ensures that if a website provider wants to let browsers know that they only serve secure connections he can do that and the browser saves this for the defined time span. There is nothing you can do about this in the long term as long as the website provider sends HSTS headers. Of course you can delete regularly all HSTS caches in Safari. As you might know there is also a HSTS preload list maintained by Google which is hard coded into many browsers including Safari. If the domain is on that list you won't have any chance to connect to an unsecure HTTP connection.

Dec 8, 2017 8:58 AM in response to ithos

The workaround that worked for me for localhost development was to:


* Temporarily set a really short Strict Transport expiration time in the web server.


In nginx


add_header Strict-Transport-Security "max-age=2; includeSubdomains;";


* Open up Safari to go to https://localhost ...


* Remove the Strict Transport directive and restart nginx.


* Open up Safari to go to http://localhost ...

Mar 1, 2014 10:47 PM in response to ChrisJenkins

I thought I was going mad, but apparently I'm not alone! I have the same exact issue as you. The links will automatically change back to HTTPS. If I change the URL manually to be HTTP it still attempts to redirect to an HTTPS URL. If I enter the same URL in another browser it works just fine.


Anyone else encounter this or have any other tips to offer besides resetting the Safari?

Mar 6, 2014 1:44 PM in response to ChrisJenkins

I actually noticed similar 443 behavior on my personal website just the other day.


I only recently started logging dropped packets in ipfilter on my personal VPS and I noticed that in the logs, my own client browser (Safari) would hit my VPS on port 443 when I don't have Apache listening on 443 (https). I have never had 443 (https) enabled on that VPS.


This only happens in Safari. When I launch Chrome and visit my site, there is no attempted 'knock' on port 443 (confirmed in tcpdump on my client machine and in the iptables logging on my VPS).

Mar 10, 2014 8:04 AM in response to alb0806

I experience this exact same behavior since yesterday. Only safari does this, Firefox and Chrome are fine. When I curl my site in the terminal, everything is fine. I thought I was going nuts too! Shared nutsiness is just half the nutsiness, I guess. Very much interested in suggestions, I seem to have exhausted all other means.

Apr 22, 2014 7:14 AM in response to ChrisJenkins

I'm having the same issue and it drives me insane. I'm running a website on http://example.com, a blog on http://example.com/blog, both using HTTP only, and some internal services on https://example.com/service using HTTPS only. It seems Safari tries to use a secure connection for all subfolders on a domain when it has learned that that very domain supports HTTPS traffic. I can verify that Safari changes the bookmark address as well, which is… crazy.


Try the following: Log in using the guest account or a fresh user account and visit your test sites, they should work. Now visit the production sites and afterwards again the test sites. Are you being redirected to the production sites?When doing the same with my slightly different setup I'm being redirect to HTTPS. Safari also changes the protocol to HTTPS when editing bookmarks.


Do you have a link to your bug report so we can support that report and make clear it affects more than one user?

Apr 22, 2014 7:21 AM in response to lenn4rd

I don't think it is possible to link to anApple Bug in Bug Reporter (Apple don't seem keen to share details of their bugs...) but if it helps the bug number is 16270117. I did get a request for more information from them so it seems they are not completely ignoring it but I do not see it fixed in the latest Safari or OS X betas 😟


Chris


Message was edited by: ChrisJenkins

Apr 22, 2014 8:21 AM in response to ChrisJenkins

You're right, I had the public bug trackers of open source projects in mind when I asked. I think Apple probably don't want bugs for their closed source projects to be public because those bugs could disclose vulnerabilities. I found information on that on a question on StackOverflow. When reporting bugs will increase the priority to fix them I'll exactly do that.


Did you have the chance to test your setup against a fresh user or guest account?

Apr 24, 2014 1:33 PM in response to ChrisJenkins

I filed a bug with Apple on tuesday and got a response by Engineering on wednesday. As it turns out my web server was misconfigured and was sending the Strict-Transport-Security header that basically tells the browser to only use HTTPS from now on. Safari did as it was told and also changed the bookmark address to comply with this request within the header.


I removed the configuration for Strict-Transport-Security and using the guest login it now works the way I wanted it to. I had to use the guest login because the header includes a time span for the browser to cache that header; 72 hours in my case. I don't know how to reset this cache item for Safari, so I'll check again in one or two days.


Maybe your web server sends the same header for HTTP and HTTPS connections. You can check via Terminal doing


curl -I https://ourdomain:81 [that's dash capital i]


The output will include the HTTP header information only. Look for a line that reads Strict-Transport-Security. The max-age value is for how long (in seconds) any browser will consider the request for a secure conection valid.

Apr 25, 2014 2:23 PM in response to lenn4rd

I'm going to apologize in advance for my utter lack of knowledge, but I was trying to access a website and Safari is insisting it be done with HTTPS even though it's an HTTP address... are you saying that the problem you found was actually on the website end, and not a 'user error'?


I've never had a problem like this before- I can access pretty much every other site I try, including HTTPS sites, but when I try to access this one I just get a message saying:
Safari can't open the page "https://[web address]/" because Safari can't establish a secure connection to the server "[web address]"


I'm confused and at my wit's end here... any advice/suggestions? (And please bear in mind, any instructions would need to be very detailed, as if you're explaining it to a grandmother who is just opened her first email account... I think I have a little more knowledge than that, but not much.) Any help would be greatly appreciated.

Safari forcing HTTPS for some HTTP only sites

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.