Suppose I have valid HTTPS page https://mydomain.tld (letsencrypt certificate in this case) and I want to display images from some other domain mystatic.tld.
I’m aware that it is not possible to use HTTP content http://mystatic.tld, because browsers will block it.
What about if mystatic.tld is using a self-signed certificate? When opening a web page from that server, most modern browsers will give a warning and require the user the manually accept the security implications afaik. What happens to images embedded inside my original page from mydomain.tld?
Related
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 have a site that can be accessed both through http (http://mysite.com) and https (https://mysite.com). The https version holds secured content, while the http content is for public use. Both contents are on the same server.
Some of the https pages contain some elements such as images that are hosted on the http pages. So when one goes to the https site, IE's security alert pops up saying that the content required contains nonsecure data. knowing that there is no risk anyway, I want to stop that popup. Is this something to be done only through the IE's settings on the client side or do I need to do something about the SSL certificate and configurations? Any guide is highly appreciated.
IE isn't the only browser that will give a popup of that nature. From memory, Firefox and Chrome have similar warnings (like they remove the padlock, or make the https go red in the address bar, instead of green).
The only way you can get it to go away is to only reference https resources in https pages. Have you checked to see what you're referring to doesn't have a secure version? All of the tools I have used generally have an equivalent https:// domain.
Please understand that the alert is there for a reason. The SSL certificate in place protects against man-in-the-middle attacks*. If you load in resources from non-https sources, then the man-in-the-middle protection you otherwise would have, is lost. The user's data may still be encrypted, but it doesn't really matter if the user is sending all his data to an attacker's computer that is decrypting it itself!
You need to remember that HTTPS is an all-or-nothing scheme. As soon as you introduce a non-HTTPS element into your page, you have essentially lost all the security that SSL has to provide.
Please mount your resources (or somehow make them available) on both HTTP and HTTPS URLs and load them accordingly. If you don't you are putting your users at unnecessary risk.
*only if you have a fully valid SSL certificate.
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.)
I'm using gmail from work, but I need to enter a password for a proxy when accesing the first web page. The password is asked from inside the browser. I receive a certificate from the proxy which I must accept in order to make the Internet connection work.
Can my HTTPS connection, between gmail and browser, be tracked in this situation?
Fiddler describes it like this:
Q: The HTTPS protocol was designed to prevent traffic viewing and tampering. Given that, how can Fiddler2 debug HTTPS traffic?
A: Fiddler2 relies on a "man-in-the-middle" approach to HTTPS interception. To your web browser, Fiddler2 claims to be the secure web server, and to the web server, Fiddler2 mimics the web browser. In order to pretend to be the web server, Fiddler2 dynamically generates a HTTPS certificate.
Fiddler's certificate is not trusted by your web browser (since Fiddler is not a Trusted Root Certification authority), and hence while Fiddler2 is intercepting your traffic, you'll see a HTTPS error message in your browser, like so:
tracked? Well even though https encrypts the traffic you still know the ip address of both parties (gmail and the browser). HTTPS doesn't solve this problem, but a different blend of crypto has created The Onion Router(TOR) which does make impossible to locate both servers and clients.
Under "normal" conditions when an attacker is trying to MITM HTTPS your browser should throw a certificate error. This is the whole point of SSL backed by a PKI. HOWEVER in 2009 Moxie Marlenspike gave a killer Blackhat talk in which he was able to MITM HTTPS without warning. His tools is called SSLStrip, and I highly recommend watching that video.
A good solution to SSLStrip was developed by Google. Its called STS, and you should enable this on all of your web applications. Currently sts is only supported by Chrome, but Firefox is working on their supporting this feature. Eventually all browsers should support it.
Yes they can. You can see this for yourself by downloading Fiddler and using it to decrypt https traffic. Fiddler issues its own certificate and acts a man in the middle. You would need to view the certificate in your browser to see whether it is actually issued by gmail.
It seems that the renegotiation is a weak spot in the TSLv1 (see TLS renegotiation attack. More bad news for SSL).
As pointed out by other answers (read also here) for this to work really "in the middle" (i.e. excluding the cases in which the capturing occurs at one of the end-points, inside the browser or inside the web server), some kind of proxy must be set, who speaks to your browser and to the server, pretending to both to be the other side. But your browser (and ssl) is smart enough to realize that the certificate that the proxy sends you ("saying: I am gmail") is illegal, i.e. is not signed by a trusted Root Certification authority. Then, this will only work if the user explicitly accepts that untrusted certificate, or if the CA used by the proxy was inserted into the trusted CA registry in his browser.
In summary, if the user is using a clean/trusted browser installation, and if he refuses certificates issued by untrusted authorities, an man "in the middle" cannot decrypt an https communication.
It cannot be tracked between the gmail webserver and your pc, but once it is inside the pc, it can be tracked. I dont understand how two people claim that https can be tracked with mitm since the whole purpose of https is to prevent such attacks.
The point is that all HTTP level messages are encrypted, and mac-ed. Due to the certificate trust chain, you cannot fake a certificate, so it should not be possible to perform a man in the middle.
The ones who claim it is possible, can you please give details about how and why it is possible and how the existing countermeasures are circumvented?
Iframe from domain with SSLcertificate will be embedded on other site (foo.com).
Must foo.com have SSL cerificate?
If foo.com has SSL certificate, will it be an security error? foo.com has SSL certificate for foo.com, but iframe domain has other SSL certificate.
If foo.com hasn't got SSL certificate, will it be an security error?
No.
You will only get a security error if the embedding site uses SSL, but the iFramed one does not. Whether the sites use different certificates or not, that does not matter.
No. (Isn't this the same question as #1?)
Summary
Having different certificates between the main page and iframed pages is not a problem.
Embedding https:// pages with <iframe /> on a http:// page is not a problem.
However, if you are running a https:// secured page that embeds non-secure pages via http://, then you might get something like this (Internet Explorer):
It depends on the browser and its settings. For example, in IE you can turn this off:
The best way to look at an iFrame is to see it as almost a separate browser. In the case of foo.com not being SSL but the iFramed site being SSL you will not get any errors.
If you switch this around, where foo.com has SSL and the IFramed site doesn't, you can get a security warning about mixed-content from the browser.
It does not matter if the two websites use different SSL certificates. However, if the website that is being iframed is not SSL protected you will get a partially encrypted error message even if the website with the iframe embedded on it is SSL protected. I only know this because this is what I am dealing with right now. My web page was only secured after I took out the iframed website that did not have SSL protection.
While the main website (which contains the iframe) doesn't have to be using SSL, it really should, at least if security is a concern (which is the point of using SSL).
Not doing so prevents the user from checking that the iframe is indeed served securely and from which site it's from, which makes its usage of SSL useless. (Examples here.)