860752 - self signed certificate can't be accepted in iframe

Status: RESOLVED WONTFIX

(Firefox :: Security, defect)

Description

[jeff deifik]

User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; InfoPath.2; .NET4.0C; .NET4.0E)

Steps to reproduce:

My ISP has a self signed https certificate.
Logging into my ISP's squirrelmail via https, when I click on 'Junk Mail', the browser says the connection isn't trusted and displays a button that shows can show detail. Unfortunately, there is no way to add an exception for the self signed certificate, therefore I can't see the junkmail folder.

I suspect it is related to the use of iframes, because the exception option seems to
work when iframes are not involved.

A workaround is not to use https, which is very bad for security.
Another workaround is to use a different browser, which also is very bad.


Actual results:

There is no way to add an exception for the self signed certificate, therefore the junkmail folder is inaccessable.


Expected results:

There should be an option to view the certificate and accept it as being valid. It worked wirh all firefox's up to 18, but broke with firefox 19.

This is not specific to my ISP, my browser, or my OS. It has been replicated on a different computer, with a different ISP.

Comment 1

[Loic]

Do you know a public website to reproduce the issue?
Or a guest account with limited rights to test?

It would help to debug.

Comment 2

[jeff deifik]

Unfortunate I do not know of a public website to reproduce the issue.

I did demonstrate the bug to a Firefox developer at the SCALE (southern california linux expo) Feb 23 2013, and he reproduced it with his squirrel mail account. Unfortunately, he did not submit a bug report, and I don't know his name :-(

Comment 3

[Loic]

As you are able to reproduce privately the issue, can you run the tool mozregression to find a possible regression range, please.
See http://harthur.github.io/mozregression/ for details.

The 1st Firefox 19 nightlies started in October 2012:
mozregression --good=2012-10-01

Comment 4

[jeff deifik]

I am able to reproduce the issue.

That is one super groovy tool.

moznightly --date=2011-12-06 works ok
moznightly --date=2011-12-07 is broken.

Comment 5

[Alice0775 White]

(In reply to jeff deifik from comment #4)
> I am able to reproduce the issue.
> 
> That is one super groovy tool.
> 
> moznightly --date=2011-12-06 works ok
> moznightly --date=2011-12-07 is broken.

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=fafaf614791f&tochange=658fad825c36

Comment 6

[Alice0775 White]

Most suspicious cset:
  290d329672e5	Jared Wein — Bug 633691 - Removed the ability to add exceptions to framed certerrors. r=gavin

Comment 7

[Jared Wein [:jaws] (please needinfo? me)]

The ability to override certificate errors in subframes was deliberately removed in bug 633691 due to the risk of click-jacking.

You should be able to right-click on the frame and choose This Frame -> Show Only This Frame. When that page loads you can then override the certificate error.

It should be noted that since the certificate is self-signed, using HTTPS does not improve the security of the connection. Since the certificate is self-signed, it is not possible to verify the identity of the server that you are communicating with, hence invalidating any potential value that the encrypted connection can bring.

Comment 8

[ar.cameron]

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #7)
> The ability to override certificate errors in subframes was deliberately
> removed in bug 633691 due to the risk of click-jacking.
> 
> You should be able to right-click on the frame and choose This Frame -> Show
> Only This Frame. When that page loads you can then override the certificate
> error.
> 
> It should be noted that since the certificate is self-signed, using HTTPS
> does not improve the security of the connection. Since the certificate is
> self-signed, it is not possible to verify the identity of the server that
> you are communicating with, hence invalidating any potential value that the
> encrypted connection can bring.

Isn't it the case that once you confirm a security exception for the self-signed certificate, that it will be essentially pinned and accepted until/if the certificate changes in the future?  This does provide security if you can verify the cert via a secure side-channel, for as long as the cert does not change.