My sites run off a subdomain (yyy.example.com), but I'm required to include CSS files from the main domain (example.com). We run a CMS that doesn't let me do any server-side stuff during the preview stage, so I'm stuck sending a page over https that includes a CSS import to http. All my IE users get a mixed content warning because of this.
Is there any client side way for me to prevent this, other than maintaining separate security settings for the domain on every client machine?
Make use of protocol-relative URL's in the CSS links.
Thus so
<link rel="stylesheet" type="text/css" href="//example.com/style.css">
instead of
<link rel="stylesheet" type="text/css" href="http://example.com/style.css">
It will automatically pick the protocol of the parent request, which should work fine for HTTPS as well.
As far as I know, there's no way to avoid that warning. It's there particularly for this purpose: alert you to the fact that even though you believe your page is SSL-encrypted, some of its content isn't. You'll either need to serve the original page over HTTP (not recommended), or serve the CSS file over HTTPS.
There is one proviso .. IE downloads the resources twice it seems.
http://www.stevesouders.com/blog/2010/02/10/5a-missing-schema-double-download/
When you say that you cannot do "server-side" stuff, do you mean that you cannot touch your CMS, or that you do not have root access to your HTTP server?
Because if you do have access to your HTTP server, you could set up a very simple reverse proxy (with mod_proxy if you are using Apache). This would allow you to use relative paths in your HTML, while the HTTP server would be acting as a proxy to any "remote" location. In fact this technique can also be used to mitigate some cross-site scripting issues.
The fundamental configuration directive to set up a reverse proxy in mod_proxy is the ProxyPass. You would typically use it as follows:
ProxyPass /css/ http://example.com/css_dir/
In this case, the browser would be requesting https://yyy.example.com/css/main.css but the server would serve this by acting as a proxy to http://example.com/css_dir/main.css. It will not raise the browser warning, and works fine with SSL.
Related
I use adminer in a docker container.
For testing services, I use the URL mydomain.tld. To address this container directly, I could expose a port and map, for example, port 8081 to the adminer port 8080.
Addressing this container directly via http://mydomain.tld:8081 works without problem, everything is as it should and the Login dialog looks like that:
However, this approach exposes user and password, so it should not be used.
Using the same docker container via https, however, I get a faulty page. In this case the container is called via the address https://mydomain.tld/adm which is forwarded by the web server addressing mydomain.tld at port 443 to the adminer container to serve the request. The approach is straightforward. The result is identical to the former. Why does this not work?
I used nginx as a proxy and connecting to the adminer container was fine. Now I use yaws and pass through the call to the adminer container.
Obviously the js and css files are not applied by the browser, be it Opera, Chrome, UR, Vivaldi, Edge or Firefox, although the source code is correct and fine. No browser shows errors in the console except Firefox (error messages translated by Bing, emphasis by me), but these errors are obviously attributed erroneously:
Stylesheet https://mydomain.tld/adm?file=default.css&version=4.8.1 was not loaded because its MIME type, text/html, is not text/css.
The script of https://mydomain.tld/adm?file=functions.js&version=4.8.1 was loaded even though its MIME type (text/html) is not a MIME type valid for JavaScript.
These error messages are not correct, as can be seen in the source code: The MIME type definitely is text/css, rel is stylesheet and script should be Javascript anyway.
<link rel="stylesheet" type="text/css" href="?file=default.css&version=4.8.1">
<script src='?file=functions.js&version=4.8.1' nonce="ZDA0ODE4Y2ZhZWY1NzkyZTUxNzg3MGZlNTdlNTcxM2M="></script>
Why does Firefox interpret them as text/html (as do probably the other browsers, too)?
Granted, the respective URLs using GET variables do not look like standard files, but they should work nevertheless and they actually do work either way as can be shown by several methods:
As mentioned, the same source code works well when the container is called via html and port 8081.
A click on these links in the HTML source of the https version loads the files without problem in any browser, as it should.
Likewise the developer tools network analysis shows HTTP code 200 for all of them, even in Firefox.
This proves in my eyes that the code received by the browser is OK, no problem here. Either way the source code is identical, except for the path.
I even manipulated the output of the adminer container to provide for the full path, but, as was to be expected, this didn't change a thing, as also proven by the following scenario:
Use the source code of either output in a local file. Here the references cannot be augmented by the browser, so we have to add the full path manually. By switching the path FULL_PATH between the http and https version I can reproduce the behavior from a local file:
<link rel="stylesheet" type="text/css" href="FULL_PATH?file=default.css&version=4.8.1">
<!-- http://mydomain.tld:8081/ works; https://mydomain.tld/adm/ works per click, but not in browser-->
This file is not even https, as it is called from a local file, only one link is.
Why don't the browsers open these files in the https case as would be natural despite developer tools telling all is OK? What is the problem here? Is there a hidden switch preventing to render these files with https?
How can I debug this more intelligently in order to find the reason and a remedy? I ran out of ideas by now.
See also yaws crashes with httpc:request for URL served by docker container for how the html content is produced.
Why does Firefox interpret them as text/html (as do probably the other browsers, too)?
If you look in the "Network" tab of the developer tools, I'm pretty sure that you're going to see that these files are served with a Content-type: text/html HTTP response header, so the browser treats them as HTML instead of CSS and Javascript.
Looking at the Yaws documentation, it seems like your out_adm function needs to return {content, "text/css", Content} or {content, "text/javascript", Content} [{header, {content_type, "text/javascript"}}, {html, Html}] (as per Steve Vinoski's comment) instead of {http, Content} in order to respond with the correct header.
In the end, the workaround was superfluous and the solution was easy: use Yaws with revproxy = / http://adm:8080 in yaws.conf using a new server instruction abc.mydomain.tld.
Nevertheless, there was a lot to learn. Thank you both for your efforts.
I have a website example.com and an SSL certificate for this domain only. No subdomains except www are included. The site is based on Typo3.
On example.com/map is an iframe (note the subdomain):
<iframe src=„https://map.example.com“ width="400" height="300">
This doesn’t work with all browsers. Some browsers show an error (SSL_ERROR_BAD_CERT_DOMAIN) because the subdomain is not covered by the certificate.
The subdomain contains rather complex content which I wouldn’t know how to built in Typo3, that’s why I used an iframe.
Question:
Is there any way to insert the contents of map.example.com into the page example.com/map without purchasing an additional SSL certificate for the subdomain?
Thanks
Pida
I see the following solutions:
Get a certificate for map.example.com
Buy one
Use an ACME client, for example Let's Encrypt
Link: Instead of using an iFrame just link to the site map.example.com
Set up a reverse proxy
Server side include: Write an extension for the website example.com/map which includes the content from map.example.com
Rebuild the solution as TYPO3 extension
It is difficult to say which one fits best for you.
A server side include may be easy in some cases, but in most cases it requires a lot of search an replace for the content which is going to be pasted. It also requires to include asset files (images, javascript, css) either in the TYPO3 template or dynamically by parsing the whole include content.
A reverse proxy is easy to set up in case you have the required software components already installed an the required knowledge. Otherwise it requires some reading and some hours to set up.
I have a website written in Ruby using Ruby on Rail framwork, everything was fine when using HTTP protocol, but when switching to HTTPS protocol.
Some CSS material can not shown, but some of it can.
The font can not be shown, originally the font was designed, but now it is not.
Anyone know what happen?
Without any specific error I assume browser is probably blocking files loading from mixed content, i.e. using both HTTP and HTTPS. Use your browser developer tools network tab to confirm this.
You can use // instead of http:// so that resources load from the relative protocol that the page content is loading from; Can I change all my http:// links to just //?
Also read; How to fix a website with blocked mixed content
I have a web page containing am entry form. HTTPS is enabled via an Apache redirect for all requests matching that page. Unfortunately, because the CSS pulls in external images using 'background-image: url(/images/...)', the browser will generate a warning message that the page contains mixed content.
What's the best way to resolve this issue?
Update 2014.12.17:
Now that SSL is encouraged for everyone and doesn’t have performance
concerns, this technique is now an anti-pattern. If the asset you > need is available on SSL, then always use the https:// asset.
Allowing the snippet to request over HTTP opens the door for attacks
like the recent Github Man-on-the-side attack. It’s always safe to
request HTTPS assets even if your site is on HTTP, however the reverse
is not true.
More guidance and details in Eric Mills’ guide to CDNs & HTTPS.
Source: Paul Irish – The Protocol-relative URL
Here is a very popular solution:
There's this little trick you can get away with that'll save you some headaches:
In HTML
<img src="//domain.com/img/logo.png">
In CSS
div{background: url(//path/to/image.png);}
You should also enable HTTPS for your static resources, and then make sure that the <link> refers explicitly to the HTTPS url for the CSS resource (whose relative urls will then be interpreted relative to the HTTPS base of the CSS file).
You should use full URL for your image:
https://your.domain.com/img/image.png`
or
https://your.domain.com/route/to/img/image.png
This solved my problem some time ago.
I have a direcory for the members area.
All the files within that directory should be treated by https.
All other files outside the specific dir should be treated by http.
How can i automate the redirecting from http and https and vice versa?
Btw, the links are relative.
You can use the SecureWebPages assembly and web.config entries from Switching Between HTTP and HTTPS Automatically: Version 2. It's a nice piece of kit, I've used it in the past to automatically switch login and admin pages to https
Best thing I can think of to cover humans would be to rewrite the urls using javascript. If they are all relative then it shouldn't be too tricky.
I'd note that mixing sites like this have some drawbacks, principally browsers don't like HTTPS pages with insecure HTTP requests involved. A better plan might be to make everything relative and only kick over to https mode once you need to hit the https section.
I can see a few ways to do this using IIS, but those options really depend on how much you can muck with the IIS configuration and what sorts of resources you have.
This sounds like it might best be managed through HTTP server configuration. E.g. mod_rewrite and similar.
Try asking on https://serverfault.com/