Heads-up: Some client browsers defaulting to https

[Terri_Kennedy]

I don't know if this is due to new releases of (at least) Firefox and Chrome or some popular extension, but in the last few days I've had user complaints that some of my web pages (served by FreeBSD / Apache) were no longer working properly. The pages in question were various dynamic content, and were sent to the client with links of the form http://www.example.com/content/foo/bar. But a number of clients started requesting those pages as https://www.example.com/content/foo/bar, which my FreeBSD / Apache system was not configured to provide (since the URLs are ephemeral and only ever given to the client browser for immediate use). I didn't see the point in doing SSL for a 200MB video of my race car, for example.

I ended up changing my Apache config to serve the requested pages via SSL instead of 404-ing them, and my users are now happy again. Except for the ones with slow CPUs in their Android tablets, which are stuttering under the additional SSl overhead.

If you have a similar config where not all of your content is identical between the non-SSL and SSL versions, you may run into this as well.

 

[obsigna]

What happens if you put a rewrite rule into the .htaccess file of the directory of your http data, something like:

RewriteEngine on
RewriteCond   %{HTTPS} on
RewriteRule   ^(.*)$ http://%{HTTP_HOST}%{REQUEST_URI}

Are the incriminated browsers freaking out with that, e.g. entering into an endless loop, receiving 301 responses and keeping on insisting on https?

Note, for this to work, the rewrite module must be loaded, and overrides must be allowed for .htaccess files in httpd.conf:

...
LoadModule rewrite_module libexec/apache24/mod_rewrite.so
...
...
<Directory "/path/to/the/http/data">
...
    AllowOverride All
...
</Directory>

 

[drhowarddrfine]

The browsers aren't doing that, the content providers are. I'm assuming those videos are coming from third-parties?

There's a big push on, now, to encrypt all content. All of my client sites now serve everything via https/SSL and you're seeing a lot of sites making the switch. Of course we don't serve videos that way but I can see someone forgetting or not knowing about that.

I didn't see the point in doing SSL for a 200MB video of my race car, for example.

 

[Terri_Kennedy]

The browsers aren't doing that, the content providers are. I'm assuming those videos are coming from third-parties?

Nope, they're here on my FreeBSD boxes. The basic idea is that the user fills out a web form with things like racetrack / date / car number, and my CGI returns a page with links to matching videos in a variety of formats, all hosted on my FreeBSD server. The links I'm sending back are either of the form http://www.example.com/directory/foo/bar.wmv or directory/foo/bar.wmv. But I'm seeing the client then trying to request those via https://, which didn't work as I didn't have SSL access configured for the videos.

There's a big push on, now, to encrypt all content. All of my client sites now serve everything via https/SSL and you're seeing a lot of sites making the switch.

I agree that this is a good idea. But if I give a client a URL and say "this is what you need to send to get the information you requested", I don't expect the browser to change it. And if it does, and gets an error, the browser should try again with the specific URL I gave it, instead of giving the user a confusing "not found" error message.

 

[drhowarddrfine]

Are you saying every request is doing this or only some? Browsers don't change these things on their own. There must be something else in play.

 

[wblock@]

A cynical person might think this is some form of exploit trying to take advantage of unpatched Heartbleed.

 

[asteriskRoss]

I've seen the same behaviour from some browsers. It was particularly annoying as my hosting provider (without telling me) started serving a a "buy your SSL certificate from our affiliate" page to clients accessing my website over TLS, which made it look like my website didn't exist.

The pages in question were various dynamic content, and were sent to the client with links of the form http://www.example.com/content/foo/bar
[...]
But I'm seeing the client then trying to request those via https://, which didn't work as I didn't have SSL access configured for the videos.

Your post implies that you are serving other content both unencrypted and via TLS. Have you checked that you are linking to the videos via a full URL (that is http://www.example.com/content/foo/bar) and not via a relative URL like /content/foo/bar? If clients are already connected via TLS, the relative link would then also be over TLS. Something else to try might be to alias your webserver using a CNAME DNS record (and configuring your webserver if necessary), so that the client browsers think they are connecting to a whole different server and actually honour the URL; something like http://video.example.com/content/foo/bar for videos.

 

[Terri_Kennedy]

I've seen the same behaviour from some browsers. It was particularly annoying as my hosting provider (without telling me) started serving a a "buy your SSL certificate from our affiliate" page to clients accessing my website over TLS, which made it look like my website didn't exist.

Thanks for confirming this.

Your post implies that you are serving other content both unencrypted and via TLS. Have you checked that you are linking to the videos via a full URL (that is http://www.example.com/content/foo/bar) and not via a relative URL like /content/foo/bar?

I believe I've tried it both ways. But I had to do the quick fix of enabling SSL access to the files to make my users happy.

If clients are already connected via TLS, the relative link would then also be over TLS.

The only secure page (for this particular set of files) is an initial login page. After that, all pages are served unencrypted. It may be that the browser decided "I saw a SSL page, therefore I can use SSL for everything", but as I mentioned earlier, that's a faulty assumption.

Presumably the browser authors will be fine-tuning this as they discover more situations where it doesn't work, similar to the way they've been tweaking their "mixed content" blocking.

Something else to try might be to alias your webserver using a CNAME DNS record (and configuring your webserver if necessary), so that the client browsers think they are connecting to a whole different server and actually honour the URL; something like http://video.example.com/content/foo/bar for videos.

Possibly. My web server configuration is rather complicated, with a dozen or so domains being served, some offering both unencrypted and SSL versions of a site and some unencrypted only. I'd rather not fiddle with it more than I have to, and risk instability for other domains.

 

[drhowarddrfine]

The only secure page (for this particular set of files) is an initial login page. After that, all pages are served unencrypted. It may be that the browser decided "I saw a SSL page, therefore I can use SSL for everything", but as I mentioned earlier, that's a faulty assumption.

Bingo!

I'd have to think back to the details but you can't do that. Security measures have been put in lately concerning crossing over from TLS to non-TLS sources, or secure to insecure sites. I'm going to be a bad source for where to look for more info on that cause I just don't recall the details. I'm using SPDY for everyone now and we can't even use sub-domains without an EV certificate.

 

[Terri_Kennedy]

Bingo!

I'd have to think back to the details but you can't do that. Security measures have been put in lately concerning crossing over from TLS to non-TLS sources, or secure to insecure sites. I'm going to be a bad source for where to look for more info on that cause I just don't recall the details. I'm using SPDY for everyone now and we can't even use sub-domains without an EV certificate.

I believe you're thinking of mixed content blocking, which disallows combinations of unencrypted and SSL content on the same page (either as embedded content, frames, or scripts). That normally generates a broken security icon in the address bar, not 404's.

 

[drhowarddrfine]

Yes but I'll repeat. No browser switches to https on its own.