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 671537 - Option to validate SSL certificates with libsoup
Option to validate SSL certificates with libsoup
Status: RESOLVED FIXED
Product: evolution-data-server
Classification: Platform
Component: general
3.4.x (obsolete)
Other Linux
: Normal critical
: ---
Assigned To: Evolution Shell Maintainers Team
Evolution QA team
: 675378 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2012-03-07 10:15 UTC by André Klapper
Modified: 2013-09-14 16:55 UTC
See Also:
GNOME target: 3.4
GNOME version: ---


Attachments
Patch (2.32 KB, patch)
2012-03-07 10:29 UTC, André Klapper
none Details | Review
proposed eds patch (3.32 KB, patch)
2012-03-14 19:42 UTC, Milan Crha
committed Details | Review
proposed evo patch (9.27 KB, patch)
2012-03-14 19:44 UTC, Milan Crha
committed Details | Review

Description André Klapper 2012-03-07 10:15:24 UTC
.
Comment 1 André Klapper 2012-03-07 10:28:59 UTC
[Forwarded by Marc (CC'ed) to GNOME release-team - Thanks!]

Details from the currently private bug in launchpad.net (see "See Also:" field for the URL) follow:

----
When using a google calendar in evolution, evolution uses HTTPS.
However, certificate correctness is not checked. Using a tool like
sslsniff allows to capture user name and password. Given the calendar is
periodically updated, it is trivial for an attacker to retrieve user
private data when connected to the same local network.

----

Attached is a proposed patch that the reporter Vreixo Formoso has submitted to the bug.
Comment 2 André Klapper 2012-03-07 10:29:54 UTC
Created attachment 209141 [details] [review]
Patch
Comment 3 Matthew Barnes 2012-03-07 12:14:57 UTC
Looks correct in principle, but hard-coding file paths like that is almost always wrong.  Need to check how the certificate DB file path is determined on the mailer side.
Comment 4 Matthias Clasen 2012-03-08 17:21:35 UTC
libsoup has a use-system-cd-database property for that now (name may be wrong)
Comment 5 André Klapper 2012-03-13 14:02:58 UTC
SOUP_SESSION_SSL_USE_SYSTEM_CA_FILE according to the libgdata fix: http://git.gnome.org/browse/libgdata/commit/?id=6799f2c525a584dc998821a6ce897e463dad7840
Comment 6 Milan Crha 2012-03-13 17:45:39 UTC
I had a chat with Dan (the libsoup master) and here are few snippets from it:

<mcrha> the thing is this touches basically half of eds, then some evo modules, then evo-echange and ev-ews as well
<danw> you can't assume that local servers will have certificates signed by a real CA
<danw> so if you're going to do that, you'd need to add "accept this certificate anyway" dialogs
<mcrha> that's true, even like self-signed certs
<danw> and, yes, actually, really we should have done that from the beginning
<mcrha> hehe :)
<danw> and if you do that, the users will just click them away without reading them, so then you're back to no security again really

...

<danw> there is no right solution. ssl is broken
<danw> SOUP_SESSION_SSL_USE_SYSTEM_CA_FILE is definitely right for things like talking to gmail
<danw> other people would say that the right solution is to always use use-system-ca-file, and require the user to add his mail server's CA to the system CA list
<danw> so, ok, the possibilities are:
<danw> 1) keep things as-is, everyone is potentially vulernable to ssl spoofing
<danw> 2) always use use-system-ca-file, lots of people need to manually fiddle with the system CA list, "why is evolution so hard to use?"
<danw> 3) always use use-system-ca-file and also add the "use anyway" dialogs. this is lots of extra work on your part, and 99% of people will click through the dialogs without reading so it's not really especially more secure. However, it will at least it will satisfy the security-conscious users who file bugs about evolution doing #1
<mcrha> I may use 4), if google is involved, do the ssl=true, otherwise let it be as is
<danw> oh, yes, right
<danw> i suppose there's also 2.5) have a checkbox for whether or not to use use-system-ca-file
<danw> per-account

...

<mcrha> though, I do not see into the issue well enough, but what if I'll just use certificate received by a valid authority? Or does this work like ssh, where the fingerprint of the site's cert is stored locally?
<danw> sorry, the default is "accept any certificate that is signed by anyone". if you set use-system-ca-file, then it will reject certs signed by unrecognized CAs
<danw> you would have to store that fingerprint locally yourself
<danw> what you'd need to do for #3 above is to set use-system-ca-file TRUE, and set ssl-strict to FALSE, and then after connecting to a server for the first time, call soup_message_get_https_status(), and if there are problems with the certificate, then pop up the dialog before continuing with the connection. (And cache the user's response for next time.)
<mcrha> we do not have API for that currently
Comment 7 Milan Crha 2012-03-13 17:52:23 UTC
To summarize a bit, the proposed change, though with the cleaner one from libgdata, is Ok for Google server, but as soon as user connects to his/her own server with SSL then he/she will have just bad luck with evolution, according to my understanding of the chat with Dan and lack of API for the question on the eds side (between cal/book backend to its client).
Comment 8 Marc Deslauriers 2012-03-13 17:58:22 UTC
Although I'm not quite familiar with the evolution-data-server internals, could you possibly add a "Accept invalid ssl certificate" checkbox to the connection's settings dialog which would be unchecked by default? This would prevent the user from getting a dialog, but would still allow certain users to disable ssl verification.
Comment 9 Milan Crha 2012-03-14 12:14:16 UTC
Yes, it's basically Dan's 2.5). I'll cook something for it.
Comment 10 Milan Crha 2012-03-14 19:42:14 UTC
Created attachment 209770 [details] [review]
proposed eds patch

for evolution-data-server;

Covering core book/calendar eds backends, which are using libsoup, to set its soup-session to use/not use the certificate checking based on the property set on its ESource.
Comment 11 Milan Crha 2012-03-14 19:44:40 UTC
Created attachment 209771 [details] [review]
proposed evo patch

for evolution;

UI change and new sting addition, an option to CalDAV calendar, On The Web calendar and WebDAV addressbook properties, to set "Ignore invalid SSL certificate". I think the "ignore" word is more describing that user is willing to violate a good habit, rather than fix it properly.
Comment 12 André Klapper 2012-03-18 16:57:54 UTC
Note that on March 19 (tomorrow) there is hardcode freeze for GNOME 3.4 (plus this adds a new string - see https://live.gnome.org/TranslationProject/HandlingStringFreezes ).
Comment 13 Matthew Barnes 2012-03-18 18:14:19 UTC
This needs to wait until 3.5 since the solution involves string and UI changes.
Comment 14 André Klapper 2012-03-19 08:10:55 UTC
You can always ask for an exception and that's what I'd recommend to do here, especially now that libgdata received a fix.
Comment 15 Milan Crha 2012-04-23 10:13:46 UTC
I'd rather not go for gnome-3-4, as this is breaking default behaviour too, which is changed to check for SSL certificates validity if not explicitly rejected doing so by the user.
Comment 16 Milan Crha 2012-04-23 10:45:03 UTC
Created commit 969ea44 in eds master (3.5.1+)
Created commit 12256b4 in evo master (3.5.1+)
Comment 17 Matthew Barnes 2012-05-03 16:05:51 UTC
*** Bug 675378 has been marked as a duplicate of this bug. ***