After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 600663 - Certificates not verified
Certificates not verified
Status: RESOLVED FIXED
Product: epiphany
Classification: Core
Component: Backend
2.28.x
Other All
: Normal major
: ---
Assigned To: Xan Lopez
Epiphany Maintainers
Depends on:
Blocks: 542454
 
 
Reported: 2009-11-04 11:07 UTC by Sam Morris
Modified: 2011-01-04 19:07 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Paliative solution while the GIO TLS port is in progress (2.20 KB, patch)
2010-02-18 16:37 UTC, Gustavo Noronha (kov)
none Details | Review
proper patch (4.93 KB, patch)
2010-02-19 17:28 UTC, Gustavo Noronha (kov)
accepted-commit_now Details | Review
Report broken certs through the padlock icon (4.93 KB, patch)
2010-02-21 17:01 UTC, Dan Winship
none Details | Review

Description Sam Morris 2009-11-04 11:07:52 UTC
I just noticed that Epiphany did not throw up a certificate verification error when it should.

You can observe this at <https://bugzilla.samba.org/>. There is no warning or indication of any kind that the certificate presented by the web server has not been signed by an approved CA.

This is really serious. I'm rather annoyed that I've been using 2.28 for some time to connect to my bank, and I could have been MITMd at any point during that time. Not to mention all the other sites I use and now have to change passwords for!
Comment 1 Kjo Hansi Glaz 2009-12-15 15:04:56 UTC
I confirm this major security issue under epiphany-webkit 2.29.3-1 from Debian testing. Certificates are not validated at all, i.e. they are all trusted. As far as I understood this problem comes from :

- libsoup, which doesn't initialize its trusted CA list by default, and trust everybody rather than nobody ;

- libwebkit, which doesn't set the "ssl-ca-file" property when creating a SoupSession object.
Comment 2 Reinout van Schouwen 2009-12-18 21:15:32 UTC
Confirmed; Dan is working on supporting this in libsoup.
Comment 3 Gustavo Noronha (kov) 2010-02-18 16:37:03 UTC
Created attachment 154151 [details] [review]
Paliative solution while the GIO TLS port is in progress

Since our real solution is not going to be ready for 2.30, I am proposing a paliative solution that would at least allow Epiphany to report that a cert is not valid through its padlock icon. To get this patch working you need both these other patches, to soup, and webkit:

https://bugs.webkit.org/show_bug.cgi?id=35093
https://bugzilla.gnome.org/show_bug.cgi?id=610374
Comment 4 Gustavo Noronha (kov) 2010-02-18 16:50:01 UTC
(In reply to comment #3)
> Created an attachment (id=154151) [details] [review]
> Paliative solution while the GIO TLS port is in progress

Oh, btw, this patch needs a bit of work still - it is currently hardcoding the trusted CAs file to Debian's path; will need to figure out how to do this propertly. I'm attaching it so I don't lose it, and so others can look at it.
Comment 5 Dan Winship 2010-02-18 17:22:41 UTC
in the glib tls branch I'm doing this, which we determined at the hackfest worked on Fedora, Debian/Ubuntu, and Mandrake.

AC_MSG_CHECKING([location of system Certificate Authority list])
AC_ARG_WITH(ca-file,
            [AC_HELP_STRING([--with-ca-file=@<:@path@:>@],
                            [path to system Certificate Authority list])])
if test "$with_ca_file" = "no"; then
    AC_MSG_RESULT([disabled])
else
    if test -z "$with_ca_file"; then
        for f in /etc/pki/tls/certs/ca-bundle.crt \
                 /etc/ssl/certs/ca-certificates.crt; do
            if test -f "$f"; then
                with_ca_file="$f"
            fi
        done
        if test -z "$with_ca_file"; then
            AC_MSG_ERROR([could not find. Use --with-ca-file=path to set, or --without-ca-file to disable])
        fi
    fi

    AC_MSG_RESULT($with_ca_file)
    if ! test -f "$with_ca_file"; then
        AC_MSG_ERROR([No such file '$with_ca_file'. Use --with-ca-file=path to set, or --without-ca-file to disable])
    fi
    GTLS_SYSTEM_CA_FILE="$with_ca_file"
fi
AC_SUBST(GTLS_SYSTEM_CA_FILE)
Comment 6 Gustavo Noronha (kov) 2010-02-19 17:06:37 UTC
(In reply to comment #5)
> in the glib tls branch I'm doing this, which we determined at the hackfest
> worked on Fedora, Debian/Ubuntu, and Mandrake.

Awesome! Thanks, Dan!
Comment 7 Gustavo Noronha (kov) 2010-02-19 17:28:09 UTC
Created attachment 154227 [details] [review]
proper patch

Here's the proper patch, adopting danw's proposed configure.ac snippet.
Comment 8 Xan Lopez 2010-02-19 22:08:16 UTC
Comment on attachment 154227 [details] [review]
proper patch

Looks reasonable to me.
Comment 9 Dan Winship 2010-02-21 17:01:28 UTC
Created attachment 154330 [details] [review]
Report broken certs through the padlock icon

updated to reflect the libsoup patch that actually got committed
Comment 10 Gustavo Noronha (kov) 2010-02-22 19:35:22 UTC
Pushed as 3e0f7dea754381c5ad11a06ccc62eb153382b498 to master, though you need the follow-up f3ed2a94694b698bb3cb38bb08a741364fe2df9b that adds the fix Dan Winship posted (oops). I'm not sure whether we should leave this bug open to track the real fix. I think I'll just close it, for now.
Comment 11 Maciej (Matthew) Piechotka 2011-01-04 19:07:59 UTC
(In reply to comment #10)
> Pushed as 3e0f7dea754381c5ad11a06ccc62eb153382b498 to master, though you need
> the follow-up f3ed2a94694b698bb3cb38bb08a741364fe2df9b that adds the fix Dan
> Winship posted (oops). I'm not sure whether we should leave this bug open to
> track the real fix. I think I'll just close it, for now.

in 2.91.4.1 the padlock is undamaged.