Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Add certificate exception in iframe

I have an Iframe that contains a URL that is a self signed https link. In normal case browser ask for add exception of such link but in the iframe it is not allowing to add exception. It is just prompting Error code: sec_error_ca_cert_invalid. Any idea how to prompt for add certificate exception in iframe in case of self signed url's ?

like image 650
Naveen Ramawat Avatar asked May 05 '14 13:05

Naveen Ramawat


2 Answers

First, the difference between prompting for an SSL exception for the root document in a window and a document displayed within an iframe is an important security concern. As you note, the user isn't aware of the URL displayed (or in this case, trying to load) in the iframe. If the browser's exception mechanism were displayed in the iframe, the user would see the browser's address bar displaying the URL of the root document -- on a completely different domain. This could lead to user confusion and, ultimately, an incorrect and unsafe choice from a security perspective.

You should not expect to find a hack/workaround that alters this behavior in modern browsers.

That said, if an iframe will not display the prompt, the simplest workaround is to get a page from the iframe's domain to load as the window's root document and therefore trigger the prompt. Consider the following sequence:

  1. User requests www.example.com/entry
    • Server somehow decides which "dynamic" host to (eventually) load in the iframe, let's call it www.dynamic.example
    • Server REDIRECTs the browser to a well-known URL on the dynamic host: www.dynamic.example/redirect
  2. User's browser requests www.dynamic.example/redirect as a normal page load, as the root document in the browser window.
    • www.dynamic.example is using a self-signed certificate, so the browser displays whatever warning/alert/prompt it usually does for sec_error_ca_cert_invalid
    • This is pretty ugly from a user experience point of view, and if the user declines to add a local exception for the certificate, everything stops here.
    • If you're confident that users will add exceptions for the self-signed cert, then upon doing so ...
  3. User's browser reloads www.dynamic.example/redirect, this time accepting the self-signed cert per the user's instructions.
    • This URL on www.dynamic.example should immediately REDIRECT back to a different, well-known location on www.example.com, let's say: www.example.com/pageWithIFrame
  4. User's browser requests www.example.com/pageWithIFrame
    • This page loads, and contains the iframe that points to something on www.dynamic.example
    • Since the user already accepted www.dynamic.example's self-signed cert, the content in that iframe should be rendered.

This solution uses only HTTP redirects and doesn't necessitate a proxy server or dropping SSL/TLS down to plaintext HTTP. It does, however, require collaboration between your site (www.example.com) and any of the other domains with a self-signed cert. It will not work if that other domain provides no way to redirect back to you (e.g. embedding content without that domain's knowledge).

The same redirect chain works with sites that provide certs signed by a trusted CA, too. In that case, step 2 will transition to step 3 immediately without any need for user intervention.

like image 109
William Price Avatar answered Nov 07 '22 21:11

William Price


Well, other than delivering a customized Chrome/Firefox/Safari that accepts self-signed certificates the only options you have is:

  • to ask the user to add a permanent certificate exception in its web-browser,
  • ask the third party to pay for a valid certificate.

There's nothing you can do HTML/JavaScript-wise to "hack your way through".

Edit

Another option is to set up a proxy server between your application (IFRAME) and the third party server (e.g. Apache HTTP Server as Proxy). It could either:

  1. strip off the SSL, i.e. convert third party HTTPS into local HTTP,
  2. be a fixed-point-HTTPS-URL that a user can white-list.

If your webapp is running in a local Tomcat server (or alike) - e.g. http://tomcat:8080/app/ - the second option can be improved by adding the Apache HTTP Server as a proxy like this:

ProxyPass /app/* http://tomcat:8080/app/*
ProxyPass /3rd/* https://third-party/*

The user would have to access just one URL - your Apache Proxy at default port 80 - http://tomcat/app/.

like image 24
Cebence Avatar answered Nov 07 '22 19:11

Cebence