Safari forcing HTTPS for some HTTP only sites

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?

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.

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).

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.

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?

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?

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.

I'm using nginx and I had added my sites to another configuration and didn't check those extra options nor did I know the header option. So from now on, I'll always double-check when using some configuration.

Did you hear anything back from Apple regarding your bug report?

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.

In my case, yes, the problem was caused by the server that has the web site. However there might be other reasons that are unclear at the moment.

You can check whether the problem is similar to mine by going to URI Valet (just found it on Google) and entering the web address into the first input named URI. Tick the check box Check Server Headers Only, ignore all of the other inputs and click Submit.

You can try with both http and https.

You can see the header information that the server sends back to you under SERVER RESPONSE. If you see a line that reads Strict-Transport-Security you're having the same problem I had. If not there'll likely be a different cause for which I'm afraid I don't have a solution yet.

Thanks so much for the info and simple instructions. I didn't see that line anywhere in there. Ended up downloading Chrome and accessing the site with that instead. I'll see if I can get one of my tech-oriented friends to take a look at it this weekend. Thanks again!

I found out how to delete the Strict Transport Security (HSTS) history from Safari since clearing the browsing history or even completely resetting Safari alone didn't work. As we know, the web server sends a time value along with the HSTS header. Safari stores those sites a file in ~/Library/Cookies/HSTS.plist. Open that file and look for your domains, they might have send that header at some point in the past. If you're domain is not listed, probably the HSTS isn't responsible for redirecting to HTTPS. If it is, you can delete it from the list doing the following:

1. Remove cookies for that domain in Settings > Privacy > Details…

You might also have clear the browsing history and/or reset Safari, unfortunately I'm not sure what worked for me.

2. Close Safari

3. Rename or delete ~/Library/Cookies/HSTS.plist

When you open Safari now and browse to your site it should work. As I said, I can't tell anymore which variation in step 1 did the trick for me. You could also try to let your web server send the HSTS header with a lifetime of 60 seconds for Safari to quickly disregard it.

The HSTS.plist is recreated some time after launching Safari and probably will still contain all the other HSTS sites that it had previously. In my case it has accounts.google.com and twitter.com among others.

No way for me too. While other "minor" browsers, such as Firefox, Chrome and Sleipnir will open the right page, Safari keeps redirecting to https, whatever you'll do: that drove me crazy without absolutely any reason on earth.

Provided that this issue will be fixed in a next release (the one included in Yosemite? I won't believe it), will the issue be persistent for users who experienced it before, like us?