GNOME Bugzilla – Bug 600663
Certificates not verified
Last modified: 2011-01-04 19:07:59 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!
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.
Confirmed; Dan is working on supporting this in libsoup.
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
(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.
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)
(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!
Created attachment 154227 [details] [review] proper patch Here's the proper patch, adopting danw's proposed configure.ac snippet.
Comment on attachment 154227 [details] [review] proper patch Looks reasonable to me.
Created attachment 154330 [details] [review] Report broken certs through the padlock icon updated to reflect the libsoup patch that actually got committed
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 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.