Adding a certificate exception for non-trusted HTTPS sites is difficult

Bug #181893 reported by Senor Hubris
72
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Epiphany Browser
Expired
Medium
epiphany-browser (Ubuntu)
Fix Released
Low
Unassigned
epiphany-extensions (Ubuntu)
Invalid
Low
Unassigned
xulrunner-1.9 (Ubuntu)
Won't Fix
Undecided
Unassigned

Bug Description

Binary package hint: epiphany-browser

SUMMARY
Epiphany's handling of adding HTTPS certificates is not as streamlined as it could be. Presently users are presented with an error, and they then must click "Or you can add an exception…" then "Add exception..." then they must re-enter the URL with the problem, press "Get Certificate" and "Confirm Security Exception"

Problems with the current solution:
1. it requires a lengthy sequence of steps
2. some of the steps look like doing the same thing twice "I want to add an exception"... "no, I really want to add an exception!"
3. it requires re-entering the problematic URL. Not all users will really understand what this means. Some users will have clicked on a link to get to the page. They then have to copy the URL from the location bar, or realise that it can be selected for copy+paste, which is not entirely obvious.
4. Once you press "Confirm Security Exception", you still are presented with the original error and need to reload the page

Early comments on this bug describe earlier handling, which was far more obscure again.

Please note, you do not need to report each non-working site individually in this bug.

Revision history for this message
Pedro Villavicencio (pedro) wrote :

Thanks for your report, can you give us a url where to test that? thanks.

Changed in epiphany-browser:
assignee: nobody → desktop-bugs
status: New → Incomplete
Revision history for this message
Senor Hubris (launchpad-net-sethdaniel) wrote :

http://thedanielfamily.org/

The above URL will contain a single link. If I click on it with Epiphany I go nowhere. If I use firefox it goes to the correct URL.

Revision history for this message
Lee Maguire (leemaguire) wrote :

I am affected by this bug. (I can't give any URLs as they are for non-public resources.)

Revision history for this message
Allison Karlitskaya (desrt) wrote :

this happens for me too, on hardy.

even going directly to a site with invalid security information (by typing the https:// url into the address bar) doesn't work at all.

it's as if the hook from gecko into epiphany to show the "are you sure?" dialog is broken.

Changed in epiphany-browser:
status: Incomplete → New
Revision history for this message
David Jaša (dejv) wrote :

Confirming on Hardy, too. Yet another URL:
https://intranet.study.fce.vutbr.cz/ (expired certificate)

Revision history for this message
Sebastien Bacher (seb128) wrote :

that seems to be a xulrunner-1.9 issue, opening a task there too

Revision history for this message
Pedro Villavicencio (pedro) wrote :

Confirming, seems to be an Ubuntu specific issue this isn't reproducible with trunk, thanks.

Changed in epiphany-browser:
importance: Undecided → Low
status: New → Triaged
Revision history for this message
FrejSoya (frej) wrote :

This might be related to the about:config bug Which doesn't do anything in epiphany with xr1.9
In both the ssl case and about:config case firefox-3.0 opens a "warning/info dialog embedded as a html page" (Best textual explanation i could figure out)

Revision history for this message
Vincent Untz (vuntz) wrote :

FWIW, this is blocking me from closing freedesktop.org bugs...

Revision history for this message
Alexander Sack (asac) wrote :

as a workaround you can grant permanent certificate exception in firefox and then copy the *.db files from firefox to epiphany profile.

Revision history for this message
Jerome Haltom (wasabi) wrote :

Same problem here.

Revision history for this message
Michael Flaig (mflaig) wrote :

https works for officialy signed and valid ssl certificates.
https does not work for self-signed, expired

As soon as the certificate is not 100% OK, there should be a message about the problem, but you can only see a blank page.
The handling of SSL errors (i.e. self-signed certificates, expired, etc.) has changed in gecko 1.9 (firefox 3). Today you get a fancy html message in firefox instead of a dialog window.

Revision history for this message
Laurent (laurent-goujon) wrote :

Another site: https://bugs.freedesktop.org (self-signed certificate)

Revision history for this message
Germán Poo-Caamaño (gpoo) wrote :

The certificates signed by cacert.org are not valid CA Authorities for gecko 1.9.

Firefox 3.0 show a fancy HTML with 2 buttons where you can add exceptions.
However, gecko 1.9 in Epyphany 2.22.0 doesn't show any buttons.

This is an usability issue, becasue there is no other ways to do it easily.

Revision history for this message
Germán Poo-Caamaño (gpoo) wrote :

Damn it!

It a bit obfuscated the way to add an exception.

Menu: Tools/Manage Certificates

Tab: Servers

Button: Add Exception...

and Fill the form. This means, add the url manually and/or copy/paste it.

Giving so many steps, will end in user changing the browser to use.

There are so many FLOSS projects using this kind of certificates (cacert.org signed or self-signed), that looks a bit strange.

Revision history for this message
Michael Ellerman (michael-ellerman) wrote :

The pretty html is nice, except it doesn't actually help.

It says to add an exception in my "advanced encryption settings" - where are they? I have scrubbed every menu and there is nothing in there, there is no way my mum is going to be able to work this out. This should be a blocker.

Revision history for this message
Mary Gardiner (puzzlement) wrote : Re: [Bug 181893] Re: clicking on an https link when the remote site has invalid credentials does not work
  • unnamed Edit (189 bytes, application/pgp-signature; name="signature.asc")

The specific menu is "Tools" and the menu item is "Manage Certificates". You then press "Add Exception" and re-input the URL. (This information is by no means intended to substitute for better documentation and better handling, I agree that there should be both.)

Revision history for this message
Senor Hubris (launchpad-net-sethdaniel) wrote : Re: clicking on an https link when the remote site has invalid credentials does not work

It should by noted that the Tools -> Manage Certificates menu is not immediately available. You first have to enable the 'Certificates' extension. To do this you must have the epiphany-extensions package installed and then you enable it by navigating to Tools -> Extensions and then select the Certificates extension.

Revision history for this message
Michael Ellerman (michael-ellerman) wrote :

Thanks for the pointer Mary, and thanks Senor for pointing out how actually get a Tools menu, currently I don't have one. All that together constitues a workaround, but not a very good one.

Revision history for this message
Ralf Nieuwenhuijsen (ralf-nieuwenhuijsen) wrote :

Another url that doesn't work:

https://bugs.freedesktop.org/

We can no longer report bugs with epiphany about, for example, compiz.
This is with up-to-date (april 5) hardy

description: updated
description: updated
description: updated
Revision history for this message
Senor Hubris (launchpad-net-sethdaniel) wrote : Re: Adding a certificate exception for non-trusted HTTPS sites is very difficult

With the most recent xulrunner and epiphany this is made easier. Much like Firefox 3 you'll get a webpage that explains that you will need to explicitly set an exception for that site. It now presents you with a button that takes you to the Tools -> Manage Certificates / Servers / Add Exception window. The only thing it doesn't do is automatically fill in the Server Location field automatically.

Revision history for this message
Mary Gardiner (puzzlement) wrote : Re: [Bug 181893] Re: Adding a certificate exception for non-trusted HTTPS sites is very difficult

> With the most recent xulrunner and epiphany this is made easier.

At the moment, with the following versions, Epiphany is much worse, not better:

epiphany-browser: 2.22.1.1-0ubuntu1
epiphany-gecko: 2.22.1.1-0ubuntu1
xulrunner-1.9: 1.9~b5+nobinonly-0ubuntu1
epiphany-extensions: 2.22.0-0ubuntu1
epiphany-browser-dbg: 2.22.1.1-0ubuntu1

If I visit https://bugtrack.alsa-project.org/alsa-bug/ epiphany crashes entirely. I'll report it separately and add the bug number here.

Revision history for this message
Mary Gardiner (puzzlement) wrote :

My complete inability to view any HTTPS site whatsoever (including valid certificates) without crashing Epiphany entirely has been filed as bug 214468.

Revision history for this message
Mary Gardiner (puzzlement) wrote : Re: Adding a certificate exception for non-trusted HTTPS sites is very difficult

Having worked around bug 214468, I've looked at the new version that Senor Hubris pointed out. From the description:

Problems with the current solution:
1. it requires installing epiphany-extensions, which many users need to add especially [NO LONGER TRUE]
2. it requires a lengthy sequence of steps [NO LONGER TRUE, although perhaps having to click on "Or you can add an exception…" and then "Add Exception" is still long]
3. it requires re-entering the URL [STILL TRUE]
4. the lengthy sequence of steps is not spelled out in the error dialog, which refers to 'advanced encryption settings', which does not appear in the menus [NO LONGER TRUE]

I'll update the description accordingly.

description: updated
description: updated
Revision history for this message
Russel Winder (russel) wrote :

I have just had an issue with a broken SSL certificate that I needed to accept as a one-off and found Epiphany to be significantly inferior to Galeon in the way the browser interacts with the user. Can I propose that following the Galeon way of doing things would improve Epiphany -- i.e. put up a small dialog asking the user for permission to connect anyway even though the certificate is formally not acceptable, or not.

I am using Hardy and hence Epiphany version 2.22.2-0ubuntu0.8.04.2

Revision history for this message
Bruce Cowan (bruce89-deactivatedaccount) wrote :

This is not Epiphany's fault, it is XULRunner's (Mozilla's rendering engine).

Revision history for this message
Michael Flaig (mflaig) wrote :

Epiphany required to re-enter the URL when connecting to self signed https sites
This is quite anoying, as epiphany seems to use the same dialog and error message as firefox and firefox gets it right this must be somehow epiphany related. Please look into further, it is still happening in Intrepid Ibex Epiphany

Packages:
--- snip ---
ii epiphany-browser 2.23.91-0ubuntu1 Intuitive web browser - dummy package
ii epiphany-browser-data 2.23.91-0ubuntu1 Data files for the GNOME web browser
ii epiphany-extensions 2.23.91-0ubuntu1 Extensions for Epiphany web browser
ii epiphany-gecko 2.23.91-0ubuntu1 Intuitive GNOME web browser - Gecko version
--- snap ---

Changed in epiphany-browser:
status: Unknown → New
Daniel T Chen (crimsun)
Changed in xulrunner-1.9:
status: New → Confirmed
Daniel T Chen (crimsun)
Changed in epiphany-extensions:
importance: Undecided → Low
status: New → Invalid
Changed in epiphany-browser:
status: New → Invalid
Revision history for this message
Michael Flaig (mflaig) wrote :

Bug still applies also to jaunty version 2.26.0-0ubuntu3 of epiphany.

IMHO there are only 2 ways out of this:
a) fix it in the deb package with a patch by the maintainer
b) close this bug as wontfix ( -> it's what upstream did because of the change to webkit in next release - hopefully)

Revision history for this message
glauber_md (glauber-md) wrote :

Version 2.26.1-0ubuntu1 of epiphany-browser is affected too.
I confirm this bug. The behavior of "Add Certificate Exception" window is not the same as it is in Mozilla Firefox (it does fill the URL in text field automatically).

Changed in epiphany-browser:
importance: Unknown → Medium
status: Invalid → Expired
Revision history for this message
Michael Flaig (mflaig) wrote :

This bug is no longer relevant. Upstream has expired the Bug and is no longer working on the xul version of epiphany since a long while. Would someone please mark it as Wont Fix please?

Revision history for this message
Andrea Corbellini (andrea.corbellini) wrote :

Hi Michael, thank you for the update.

Changed in epiphany-browser (Ubuntu):
assignee: Ubuntu Desktop Bugs (desktop-bugs) → nobody
status: Triaged → Won't Fix
Changed in xulrunner-1.9 (Ubuntu):
status: Confirmed → Won't Fix
Revision history for this message
Rolf Leggewie (r0lf) wrote :

I'm reopening this based on incomplete information. I'm sorry, I can't test the oneiric version at the moment. But the claims in the upstream ticket of this being fixed in trunk and 2.22 are clearly wrong. Things have actually gotten worse with an even less helpful message in 2.30.2.

Whether or not upstream has dropped xul or not seems pretty irrelevant to me. There is still a package called "epiphany-browser" in ubuntu and if the latest version of that exhibits the described problem then it's not fixed. It would be very nice to hear from someone running oneiric what kind of message they get when trying to open https://grid-voms.desy.de:8443/voms/ilc/

Changed in epiphany-browser (Ubuntu):
status: Won't Fix → Confirmed
Revision history for this message
Andrea Corbellini (andrea.corbellini) wrote :

The XUL version of Epiphany is no longer in the archives; since Lucid, there's just the webkit version.

The link you pasted gives me "Server required TLS certificate". This message comes from glib-networking and corresponds to G_TLS_ERROR_CERTIFICATE_REQUIRED which, according to http://developer.gnome.org/gio/2.28/gio-TLS-Overview.html, means: The TLS handshake failed because the server requested a client-side certificate, but none was provided.

What you are seeing looks to me as a different bug, but please correct me if I'm wrong.

Changed in epiphany-browser (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Rolf Leggewie (r0lf) wrote :

Thank you, Andrea, for picking this up.

There may indeed be more than one type of secure connection error at play here. For me this bug is about epiphany not making it easy to deal with those connection errors. Try https://www.support.topnetworks.de/ It's my understanding that the root cause of the insecure connection is an error in the certificate, nothing too serious in this case. It was easy to find this out and add an exception in Firefox whereas it's still impossible or close to impossible to handle these type of errors in epiphany.

Revision history for this message
Andrea Corbellini (andrea.corbellini) wrote : Re: [Bug 181893] Re: Adding a certificate exception for non-trusted HTTPS sites is difficult

Hi Rolf and thank you for your feedback.

On Mon, 2011-07-25 at 18:51 +0000, Rolf Leggewie wrote:
> There may indeed be more than one type of secure connection error at
> play here. For me this bug is about epiphany not making it easy to deal
> with those connection errors. Try https://www.support.topnetworks.de/

For me, Firefox and Chromium and the only that warn me about the
problems with the certificate. Epiphany just displays a small broken
padlock with a red X in the address bar, but nothing prevents me from
browsing the website.

I've also done some tests locally using self-signed, expired and wrong
certificates and all produces the same result. After spending half an
hour trying to figure out why we are seeing different results, I finally
found the answer: I'm using epiphany from the GNOME 3 PPA, which has
version 3.0.4-1ubuntu1~natty1.

Oneiric ships version 3.0.4-1ubuntu1, so I bet the bug is now fixed in
the development version of Ubuntu (although I'll do some tests just to
be sure). So, with your consensus, I'm going to close this bug. Thank
you again for all your feedback.

Revision history for this message
Rolf Leggewie (r0lf) wrote :

Andrea, thank you for your work.

Changed in epiphany-browser (Ubuntu):
status: Incomplete → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.