We have website where we have applied SSL on subdomain, it works well in normal scenarios but in specific cases the URL shows HTTPS but it not shows secure sign.
We are using single page application with sammy.js so URL contains # in it.
As soon as we hit this URL https://app.testdomain.com/appname/App/#/Dashboards/Dashboard/Index, the secure mark goes away and it shows like unsecured app.
What could be the possible reason?
Related
I have a web application where users can specify a custom website that they host to be displayed in an iFrame on the page.
The problem is, my web app runs in HTTPS where as user's webpages in the iFrames do not have SSL enabled and are in http. This causes their webpage to be blocked from showing for a mixed content security warning.
My idea, was to setup a reverse proxy on my Apache webserver. This reverse proxy would take something like https://example.com/reverse?theirsite=http://example.com
This reverse proxy would need to work for websocket connections as well:
wss:// -> ws://
and
https:// -> http://
Is this the best way to go about displaying a user's insecure webpage in an iFrame on my web app?
<VirtualHost *:443>
# Reverse proxy for iFrames
# https -> http and wss -> ws
# get the SITE querystring for the IP/Port
ProxyPass /proxy {site}
ProxyPassReverse /proxy {site}
</VirtualHost>
Apache would need to take a custom query string and forward it to the insecure site.
Is this the best way?
If you want to provide a way for everyone on the internet to surf for porn anonymously, attack other websites and generally do bad things, then you're spot on. Unfortunately it won't do what you intend.
First, you're going to need some application logic to implement this is - e.g. PHP, Python, Perl, Java....
Then you'll need a way to store mappings between URLs on your site and those of your users.
Then you write some code which listens at the iframe URL to translate a request using the map. When it receives a response from the origin site, it will hen need to re-write any URLs therein to something which will be routed back to your server.
Once you've done all this, you will have something which looks like it works, however anyone with a user account now has the ability to attack your sites security via XSS. So really you need a dedicated vhost within your domain such that each user's content runs within its own origin.
This is not trivial.
I have this one page which has an iframe inside of which a survey page is embedded, unfortunately i'm getting "Your connection is not secure" error inside the iframe. Does anyone know how to fix this issue? By the way, the website is SSL certified, not the page i'm trying include inside the iframe. Also this is a php site not wordpress.
Thanks
You are always going to have this problem when an HTTPS page references non secured content. You options are:
move the page hosting the iframe (and its associated content) outwith HTTPS. Although, in theory a HTTP page should be able to reference HTTPS hosted javascript, CSS and images without emitting warnings, this will probably vary by browser
move the survey page into HTTPS. I am guessing that you don't host this yourself - have you contacted the provider to ask if they can provide the service via HTTPS? Have you considered using a different provider?
proxy the HTTP survey page via your server - this would require some clever configuration on the webserver or terminating the SSL connection in front of a proxy operating in reverse mode for your service and rewriting/forwarding mode for the survey. Basically, if you don't control the infrastructure this is probably a non-starter.
re-implement the survey capability within your own site.
Bear in mind that as soon as your site is exposed outside of HTTPS it becomes vulnerable to more attacks.
.htaccess is not going to help - it overrides the behaviour within a vhost - the HTTP and HTTPS sites will operate in seperate vhosts.
I currently have image content being served on a domain that is only accessible over https. What is the downside of serving an image with an https path on a page accessed over http? Are there any caching considerations? I'm using an HttpRuntime.Cache object to store the absolute image path, which is retrieved from a database.
I assume there is no benefit to using protocol-relative URLs if the image is only accessible over https?
Is there a compelling reason why I should set up a separate virtual directory to also serve the image content over http?
If the content served over HTTPS within the HTTP page isn't particularly sensitive and could equally be served over HTTP, there is no downside (perhaps some performance issues, not necessarily much, and lack of caching, depending on how your server is configured: you can cache some HTTPS content).
If the content server over HTTPS is sufficiently sensitive to motivate the usage of HTTPS, this is really bad practice.
Checking that HTTPS is used and used correctly is solely the responsibility of the client and its user (this is why automatic redirections from HTTP to HTTPS are only partly useful, for example). Although some of it has to do with the technicalities of certificate verification, a lot of the security offered by HTTPS comes from the fact that the user:
expects to be using HTTPS (otherwise they could easily be downgraded),
is able to verify the validity of the certificate: green/blue bar, corresponding to the host name on which they expect to be.
The first point can be addressed by HTTP Strict Transport Security, from a technical point of view.
The second needs used interaction. If you go to your bank's website, it must not only be a site with a valid certificate, but you should also check that it's indeed the domain name of your bank, for example.
Embedding HTTPS content in an HTTP page defeats this, since the user can't check which site is being used, and that HTTPS is used at all in fact. To some extent, embedding HTTPS content from a third party in an HTTPS page also presents this problem (this is one of the problems with 3-D Secure, which may well be served using HTTPS, but using an iframe doesn't make which site is actually used visible.)
Since 1st Oct is coming. I am working on Secure Canvas URL stuff.
My canvas url is like canvas.example.com. I can make this domain and server SSL ready without a problem.
My question is, should every http request made by canvas.example.com also change to https?
e.g. I import some JS, CSS, images from cdn.example.com to my canvas page, should i configure cdn.example.com alos can be accessed via https, or I can just leave this domain alone, still use http to get those content?
thank you very much.
You should make all content served over https or the browser will show warnings.
Facebook policies clearly mention that all the Page Tabs and iFrame Applications shal have an SSL certificate..
Any external content like images and JS included on your site shall also come from secured hostings hence the Https:// else your shall not be complying to FB Policies..
Gives the fact that FB has been very strict on punishing defaulters i dont think any app developer can take risk ..
I recently moved servers and redeveloped the website at the same time. Previously all pages were served via https and I wanted to change this so only cart pages were via https. Also I wanted to clean up the url a bit. Old urls were:
https://secure.mydomain.com/onlinestore/index.php
and I removed the secure prefix and the subfolder so it is now:
http://www.mydomain.com/index.php
Problem is I wanted people who clicked on old links or bookmarks to be redirected to the new page. I got this working with htaccess. However the new SSL only covers the root domain and not the secure subdomain. So if someone clicks an old link it brings up "This Connection is Untrusted" before it can redirect. Works fine if i change https to http.
So what I want to know is if there is anyway I can force http instead of https before it checks the SSL cert.
Hope that makes sense!
The short answer is no. With conventional SSL, your web server doesn't even get to see the URL before certificate negotiation happens. It just sees a connection on port 443 and starts doing SSL negotiation. The browser then sees the mismatched cert and throws an exception.
However, more modern browsers and web servers (see Wikipedia for the list) support a TLS extension called Server Name Identification (SNI), which allows the client to send the hostname it's requesting before the server has to respond with a certificate. At that point you'll need to have certificates for both secure.mydomain.com and www.mydomain.com on that server, and it'll need to be configured to respond with the proper certificate.