A Debian bug report [1] reported that newer versions of Epiphany no longer verify certificates for HTTPS connections. This was previously reported upstream [2] and has been fixed in Git [3],[4]. This has been fixed in the upstream version as provided by Fedora 13 (2.30.2), but still affects Fedora 12's version (2.28.2). [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=564690 [2] https://bugzilla.gnome.org/show_bug.cgi?id=600663 [3] http://git.gnome.org/browse/epiphany/commit/?id=3e0f7dea754381c5ad11a06ccc62eb153382b498 [4] http://git.gnome.org/browse/epiphany/commit/?id=f3ed2a94694b698bb3cb38bb08a741364fe2df9b
Created epiphany tracking bugs for this issue Affects: fedora-12 [bug 636934]
Testing with the latest epiphany in F13 (epiphany-2.30.2-1.fc13, webkitgtk-1.2.4-1.fc13), it shows broken padlock icon in address and status bar, but does not prevent page loading or require user to click through to proceed. This should not be considered a complete fix for the issue, rather only a partial mitigation. Is there any setting that can be used to enable strict checking?
I'm basing the affects on the upstream fix. I guess the question is was there ever strict checking in epiphany before? Did it prevent page loads or click throughs before? If not, then it is an acceptable fix for the issue (not ideal, but then we're looking at an enhancement/"hardening"). If it _did_ require that before, then I would agree with you (but no idea as I've not tried it). Do you have a demo cert or site that you're using to test with?
Ludwig had a look at couple of epiphany versions. His mail mentions gecko-based versions raised popup in case of certificate verification issues: http://thread.gmane.org/gmane.comp.security.oss.general/3521/focus=3531 You should be able to test with any site that uses self-signed certificate, or one from CA you don't trust. https://www.cacert.org may be a good candidate. Site cert is issued by their own CA which does not appear in most system CA bundles by default.
Ok, tried it here with one of my servers that has a CN mismatch. Epiphany on F13 shows a tiny little red x on a broken padlock (or so it seems) that indicates broken security, and page loads. Epipahny on F12 shows a perfectly formed padlock, indicates high security, and page loads. Epiphany on F11 shows the same interrupted page that firefox does ("secure connection failed"). I would agree that the "fix" in the new Epiphany is definitely not sufficient compared to what it used to have (unless you looked at the URL bar, you would never know about the mismatched CN at all, and that icon is really small).
Regardless of the icon size, learning about SSL certificate problem only after bad things may have happened is too late.
Also see bug #643224 for a variation of this in F13.
(In reply to comment #6) > Regardless of the icon size, learning about SSL certificate problem only after > bad things may have happened is too late. I agree, but that should be a different bug/CVE. If one is created, please CC me.
This is still valid for Fedora 14.
This is still valid for Fedora 18. Debian also has filed an issue regarding a similar outcome of not verifying SSL certificates properly: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702976
SSL is working fine for me in Epiphany 3.6, and from reading the comments in the Debian bug it looks like only the redirection trick is the problem? (I think SSL *was* somehow broken very recently in Epiphany 3.4, though, which rejected absurdly many sites as invalid where other major browsers did not. Epiphany 3.6 seems fine....)
Testing on Fedora 19 with Epiphany 3.8.2, the behaviour is the same as noted in comment #5. Given the age of this bug and the fact that there is a (albeit super tiny and in a totally non-standard place) notification of a web site mismatch, I'd suggest closing this as fixed. Clearly the Epiphany developers believe that having a tiny little open lock with an even smaller exclamation mark is sufficient to alert people to the mismatch. I suppose a CVE cannot be assigned for "too small notification" or some such, so I believe this is fixed because at least now there is an alert of some sort.
It is a serious UI issue; see https://bugzilla.gnome.org/show_bug.cgi?id=708847 for discussion.
I agree 100%, but that's not what this bug is about. If you need a bug about the UI in epiphany, please feel file a bug (although it seems like upstream has a bug open and we'd just take their fix when/if it comes out). Since Epiphany does better handling of SSL cert checking than it used to, regardless of ridiculous, the flaw that this bug was opened for, is fixed. It never claimed it was fixed _well_.
(In reply to Vincent Danen from comment #12) > Testing on Fedora 19 with Epiphany 3.8.2, the behaviour is the same as noted > in comment #5. Given the age of this bug and the fact that there is a > (albeit super tiny and in a totally non-standard place) notification of a > web site mismatch, I'd suggest closing this as fixed. If browser shows certificate verification error but still proceeds in communicating with the site without prompting user, it's badly broken and pretty much unusable for any https use. Broken padlock icon with exclamation mark can not be considered a fix for this if mitm attacker gets all user's cookies / authentication credentials / ... as a side effect.
(In reply to Tomas Hoger from comment #15) > (In reply to Vincent Danen from comment #12) > > Testing on Fedora 19 with Epiphany 3.8.2, the behaviour is the same as noted > > in comment #5. Given the age of this bug and the fact that there is a > > (albeit super tiny and in a totally non-standard place) notification of a > > web site mismatch, I'd suggest closing this as fixed. > > If browser shows certificate verification error but still proceeds in > communicating with the site without prompting user, it's badly broken and > pretty much unusable for any https use. > > Broken padlock icon with exclamation mark can not be considered a fix for > this if mitm attacker gets all user's cookies / authentication credentials / > ... as a side effect. That seems to me to require a second CVE then. There is an upstream "fix" for "newer versions of Epiphany no longer verify certificates for HTTPS connections" (which it does). Epiphany verifies it. It displays the difference. What it does with that verification is incredibly stupid but is NOT the same flaw. It doesn't matter if it's "unusable for any https use" or not. It's a different flaw. I have no idea why you re-opened this. It's a different flaw and clearly no fixes to upstream exist, so it would be better to file a bug upstream, with a new CVE, to get some traction. Re-opening this just means keeping this bug open for a flaw that's fixed, to point out that it could be fixed better, and also requires another CVE. Just my $0.02. If you like open bugs I guess I can't stop you from re-opening it again, but I think we're looking at two different flaws here. (As an aside, if you feel that the fix upstream published is incomplete, then another CVE would need to be assigned anyways, but this bug could remain open as an incomplete fix, but as I stated in comment #12: "I suppose a CVE cannot be assigned for "too small notification" or some such, so I believe this is fixed because at least now there is an alert of some sort." Keep the bug open if you like though...
FWIW: the particular issue originally reported in this bug was fixed over a year ago. (I swear it was fixed in 3.6, but Vincent says it wasn't. Whatever: it's fixed now.) But if you're really planning to keep this bug open until TLS in Epiphany is trustworthy, or to file CVEs, allow me to add some links.... Upstream bugs discussing the fact that untrusted pages are loaded: https://bugzilla.gnome.org/show_bug.cgi?id=542454 https://bugzilla.gnome.org/show_bug.cgi?id=708847 Particularly serious issues: https://bugzilla.gnome.org/show_bug.cgi?id=639764 (claims evil TLS content is secure) https://bugzilla.gnome.org/show_bug.cgi?id=666808 (claims non-TLS content is secure) Related issues: https://bugzilla.gnome.org/show_bug.cgi?id=618429 (not a vulnerability) https://bugzilla.gnome.org/show_bug.cgi?id=628298 (add HSTS support) https://bugzilla.gnome.org/show_bug.cgi?id=633366 https://bugzilla.gnome.org/show_bug.cgi?id=721179 (should treat EV certs differently) https://bugzilla.gnome.org/show_bug.cgi?id=721180 (claims trusted website is untrusted)
(In reply to Michael Catanzaro from comment #17) > FWIW: the particular issue originally reported in this bug was fixed over a > year ago. (I swear it was fixed in 3.6, but Vincent says it wasn't. > Whatever: it's fixed now.) But if you're really planning to keep this bug I don't believe I said that. From my point of view this bug is fixed. It is Tomas who re-opened this, not me.
(In reply to Vincent Danen from comment #18) > I don't believe I said that. You said the bug was valid for Fedora 18 (with Epiphany 3.6) in comment #10, but I believe Fedora 18 was unaffected. It doesn't really matter anymore. > From my point of view this bug is fixed. It > is Tomas who re-opened this, not me. Yup.
(In reply to Vincent Danen from comment #16) > That seems to me to require a second CVE then. There is an upstream "fix" > for "newer versions of Epiphany no longer verify certificates for HTTPS > connections" (which it does). I think the disagreement here is what we consider fix. I do not consider fix that does not abort connection before transferring data as fix for missing SSL certificate verification issue.
(In reply to Tomas Hoger from comment #20) > (In reply to Vincent Danen from comment #16) > > That seems to me to require a second CVE then. There is an upstream "fix" > > for "newer versions of Epiphany no longer verify certificates for HTTPS > > connections" (which it does). > > I think the disagreement here is what we consider fix. I do not consider > fix that does not abort connection before transferring data as fix for > missing SSL certificate verification issue. I suppose that's the argument you're going to have to make with upstream. If upstream claims it's fixed, but there is a valid reason for that not being the case, upstream really should be told (arguing in this bug whether you agree with upstream's definition of "fix" or not is somewhat pointless). Regardless, if upstream released a version claiming it was fixed, and it wasn't, then there is still a need for a second CVE, right? I mean, that part is a no-brainer and something we can agree upon. Also, note that the description for this CVE from the dictionary is: Epiphany 2.28 and 2.29, when WebKit and LibSoup are used, unconditionally displays a closed-lock icon for any URL beginning with the https: substring, without any warning to the user, which allows man-in-the-middle attackers to spoof arbitrary https web sites via a crafted X.509 server certificate. Is the "unconditional display of a closed-lock icon" part fixed? If so, then, again, it would require a second CVE. Which would require a second bug. And probably someone telling upstream about it. That's my $0.02.
(In reply to Tomas Hoger from comment #20) > I do not consider > fix that does not abort connection before transferring data as fix for > missing SSL certificate verification issue. That's fixed in Epiphany 3.14. (In reply to Vincent Danen from comment #21) > Is the "unconditional display of a closed-lock icon" part fixed? This was fixed a couple years ago. I think this report can be closed?
Fedora 20 still has Epiphany 3.10, which does not block access to sites with bad certificates. Is there a plan to have F20 version updated?
(In reply to Tomas Hoger from comment #23) > Fedora 20 still has Epiphany 3.10, which does not block access to sites with > bad certificates. Is there a plan to have F20 version updated? No, it would break so many sites that I don't want to do that in a stable release. :( Backporting the nice "do you want to load the page anyway" feature would not be possible without a major webkitgtk version update, from 2.2 to 2.4. (That might be a good idea anyway, since webkitgtk 2.4.8 fixes several CVEs, but we've never done it in a stable release before.) So we'd need to treat bad certs as an insurmountable transport error. Then we would also need to patch glib-networking to reorder unordered certificate chains, many sites with otherwise-good chains would be blocked -- way too many sites. Then we would still have some sites that can be accessed, but on which images and CSS would be blocked because they're served from different hosts with a different certificate, so the browser would appear to be broken. But if, knowing all that, you disagree and want it changed anyway, I can do a F20 update. It's a simple one-line change to turn certificate validation failures into transport errors. But I predict that users would be displeased. FYI: Midori to this day handles invalid certs the same was as Epiphany used to. Not sure if you're aware of that.
(In reply to Michael Catanzaro from comment #24) > Backporting the nice "do you want to load the page anyway" feature would not > be possible without a major webkitgtk version update, from 2.2 to 2.4. Thank you for this clarification, it's good to understand the reason the fix is only in F21+. I agree that enabling without a way for user to click through is likely to cause issues. A user setting to globally enable / disable hard fail may be alternative with worse user experience. > Then we would still have some sites that can be accessed, but on which images > and CSS would be blocked because they're served from different hosts with a > different certificate, so the browser would appear to be broken. Those sites are expected to be broken in any other certificate checking browser I'd assume. > But if, knowing all that, you disagree and want it changed anyway, I can do > a F20 update. It's a simple one-line change to turn certificate validation > failures into transport errors. But I predict that users would be displeased. I'm not going to try to force such change given that there are reasons it's not enabled in F20. > FYI: Midori to this day handles invalid certs the same was as Epiphany used > to. Not sure if you're aware of that. Right, I know that. I don't believe Fedora had any WebKitGtk based browser with expected certificate checks prior to the Epiphany update to 3.14.