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 611496 - "security level: broken" for all SSL sites
"security level: broken" for all SSL sites
Status: RESOLVED FIXED
Product: epiphany
Classification: Core
Component: Backend
2.29.x
Other Linux
: Normal critical
: ---
Assigned To: Xan Lopez
Epiphany Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-03-01 16:17 UTC by Sam Morris
Modified: 2011-09-26 17:56 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Sam Morris 2010-03-01 16:17:20 UTC
With 2.29.91, any https site I go through shows up as "security level: broken".

1. I'm not told why. Is it because the certificate presented is not valid yet, or expired, or because the web address does not match that written on the certificate?

2. There is no way to view the certificate presented by the server!

2. The message is not intrusive enough. A failure to validate a certificate is a  hard error and the user needs to be prevented from visiting the page without taking special measures. If user's don't notice that they are being MitM'd then they _will_ give away credentials to the attacker without realising it.
Comment 1 Gustavo Noronha (kov) 2010-03-01 19:44:15 UTC
(In reply to comment #0) 
> 1. I'm not told why. Is it because the certificate presented is not valid yet,
> or expired, or because the web address does not match that written on the
> certificate?

This is likely because you do not have an up-to-date WebKit that is able to handle saving/restoring of soup message flags. Can you make sure you're using 1.1.22? Another possibility is you do not have the CA certificates file in the place Epiphany is expecting it.

> 2. There is no way to view the certificate presented by the server!

True. This needs to be implemented, patches welcome, else this is very likely to only happen for 2.32.

> 2. The message is not intrusive enough. A failure to validate a certificate is
> a  hard error and the user needs to be prevented from visiting the page without
> taking special measures. If user's don't notice that they are being MitM'd then
> they _will_ give away credentials to the attacker without realising it.

2 2's? =D

This is what some browser developers think. I disagree with them, and would prefer to not have something too intrusive when we are able to implement real handling for the certs.
Comment 2 Sam Morris 2010-03-02 10:41:05 UTC
I am using Webkit 1.1.22. Debian compiles epiphany --with-ca-file=/etc/ssl/certs/ca-certificates.crt and that file is present. Running 'gnutls-cli --x509cafile /etc/ssl/certs/ca-certificates.crt -p 443 robots.org.uk' reports that "Peer's certificate is trusted". So it looks like something is wrong with epiphany here.
Comment 3 Sam Morris 2010-03-05 10:45:14 UTC
This is fixed by upgrading libsoup2.4 from version 2.29.90-1 to version 2.29.91-1. I suggest marking that version as a hard requirement in configure.in to prevent users from using the broken version by mistake.

However, I'm still not told _why_ the certificate is invalid; merely 'security level: broken'.

As for the other parts of my bug, the lack of the ability to view the certificates is covered by bug 594856.

I'll file a separate bug requesting a hard failure in the case of a certificate that can't be trusted.
Comment 4 Ionut Biru 2011-09-16 17:05:33 UTC
the problem is still here using:
epiphany 3.1.91.1
libsoup 2.35.90
glib-networking 2.29.18
Comment 5 Dan Winship 2011-09-19 19:40:55 UTC
(In reply to comment #4)
> the problem is still here using:
> epiphany 3.1.91.1
> libsoup 2.35.90
> glib-networking 2.29.18

no, that was a new bug, and it's fixed in libsoup master