GNOME Bugzilla – Bug 611539
EProxy doesn't use authentication for HTTPS
Last modified: 2010-09-08 17:21:32 UTC
I have managed to get Evolution (gnome-2-28) to work with Google's CalDAV mode if I configure Evolution not to use a proxy in Edit->Preferences->Network Preferences's Proxy Settings. If I choose Manual proxy configuration or Use system defaults (which is to use a proxy) I can't get connected to my Google/CalDAV calendar. Futhermore, e-d-s spins, consuming 100% of a core with the following: [pid 3568] write(2, "\n(process:1642): libsoup-CRITICA"..., 169) = 169 [pid 3568] write(2, "\n(process:1642): libsoup-CRITICA"..., 169) = 169 [pid 3568] write(2, "\n(process:1642): libsoup-CRITICA"..., 169) = 169 [pid 3568] write(2, "\n(process:1642): libsoup-CRITICA"..., 169) = 169 [pid 3568] write(2, "\n(process:1642): libsoup-CRITICA"..., 169) = 169 [pid 3568] write(2, "\n(process:1642): libsoup-CRITICA"..., 169) = 169 [pid 3568] write(2, "\n(process:1642): libsoup-CRITICA"..., 169) = 169 [pid 3568] write(2, "\n(process:1642): libsoup-CRITICA"..., 169) = 169 [pid 3568] write(2, "\n(process:1642): libsoup-CRITICA"..., 169) = 169 [pid 3568] write(2, "\n(process:1642): libsoup-CRITICA"..., 169) = 169 [pid 3568] write(2, "\n(process:1642): libsoup-CRITICA"..., 169) = 169 [pid 3568] write(2, "\n(process:1642): libsoup-CRITICA"..., 169) = 169 [pid 3568] write(2, "\n(process:1642): libsoup-CRITICA"..., 169) = 169 [pid 3568] write(2, "\n(process:1642): libsoup-CRITICA"..., 169) = 169 A stack trace yields the following:
+ Trace 220777
Thread 4 (Thread 0xb5794b70 (LWP 1732))
You can see Thread 4 is where all the spinning is happening.
Maybe this is the reason: In proxy_settings_changed(): (gdb) print *proxy->priv $16 = {uri_http = 0xb7668680, uri_https = 0x980a920, notify_id_evo = 3640655874, notify_id_sys = 3657433091, notify_id_sys_http = 3674210308, ign_hosts = 0x0, ign_addrs = 0x0, use_proxy = 1, type = PROXY_TYPE_MANUAL} (gdb) print *proxy->priv->uri_http $17 = {scheme = 0x6011ba "http", user = 0xb2c4b3f0 "my_username", password = 0xb2c4aa38 "my_password", host = 0xb2c48c70 "proxy", port = 3128, path = 0xb2c48b30 "/", query = 0x0, fragment = 0x0} (gdb) print *proxy->priv->uri_https $18 = {scheme = 0x603990 "https", user = 0x0, password = 0x0, host = 0xb2c4b2d0 "proxy", port = 3128, path = 0xb2c48a70 "/", query = 0x0, fragment = 0x0} Why are the authentication credentials not being populated into EProxy's priv->uri_https scheme but only the http scheme?
Hrm. Additionally, when I disable SSL, so that my proxy credentials work and so that I can see what URLs Evo's caldav is using I see URLs such as: http://my_google_accoung_login_id@www.google.com/calendar/dav/my_gmail_address%40gmail.com/events/ - NONE/- text/html ^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^ 1 1a 2 Which is not right -- for so many reasons: 1. I could be wrong, but I don't think my google id should be prepended to the caldav URL as an account name. I think google's caldav gets the account to be used from what's underlined as "1a" above. 2. Evolution is obviously not using the proxy authentication credentials that exist in the EProxy->priv->uri_http structure because if it was, "my_username" would be showing where 2 is underlining a single "-" above.
libsoup had a bug in its handling of https-via-authenticated-proxies that would make it fail if the proxy closed the connection when returning the "proxy authentication required" error. (Apache doesn't do that by default, so my regression tests were missing that case.) This is now fixed in libsoup master, and will be in 2.30.1. I *think* that will fix this bug, and the stuff in comment 1 and comment 2 is irrelevant. But I'm not sure.
Google calendar requires SSL, and its address is https://%s@www.google.com/calendar/dav/%s/events where both %s are replaced with user's email. You can enable CalDAV debug output, together with a Soup communication logging, by running evolution-data-server/e-calendar-factory with CALDAV_DEBUG=all exported. With respect of credentials used for HTTPS from HTTP proxy settings, I see that the System Proxy settings dialog doesn't allow setting details for HTTPS, but only for HTTP. It seems to be shared for both HTTP and HTTPS, but EProxy changes it only for HTTP part. I'm changing this to share authentication for both HTTP and HTTPS when set.
Created attachment 169409 [details] [review] eds patch for evolution-data-server; Thanks for finding it. I do not know how this could be overlooked for so long.
Created commit 90dcdd3 in eds master (2.31.92+)
I applied this patch to my gnome-2-30 build and it still doesn't seem quite right. When e-d-s tries to connect to a google caldav calendar, these are the entries that show up in the proxy audit log: 1283521291.709 0 <my_ip_addr> TCP_DENIED/407 3542 CONNECT www.google.com:443 - NONE/- text/html 1283521294.067 2358 <my_ip_addr> TCP_DENIED/407 3641 CONNECT www.google.com:443 example@gmail.com NONE/- text/html The first is evolution first trying to connect without authentication and being told it needs to authenticate, which is normal. Notice in the second connection however, that it's using "example@gmail.com" as the account to authenticate to the proxy with. This is wrong. "example@gmail.com" is the google account name. In my calendar configuration for that calendar, I have the URL set to: caldav://www.google.com/calendar/dav/example@gmail.com/events and the Username set to: example@gmail.com
Do you have the libsoup version Dan mentioned in comment #3, please? And when you run e-calendar-factory with CALDAV_DEBUG=all , will it show correct proxy request or not? Note it should show the password unencrypted, maybe some latter in user name and/or password confused the url parser.
*** Bug 612843 has been marked as a duplicate of this bug. ***
(In reply to comment #8) > Do you have the libsoup version Dan mentioned in comment #3, please? I believe I do given the following analysis: $ ps -ef | grep evolution brian 3361 3266 0 06:29 ? 00:00:00 /usr/lib/evolution/2.30/evolution-alarm-notify brian 3566 1 0 06:30 ? 00:00:01 /usr/lib/evolution/e-calendar-factory brian 3609 1 0 06:30 ? 00:00:00 /usr/lib/evolution/e-addressbook-factory brian 7647 1 27 06:54 ? 00:04:13 /usr/bin/evolution $ lsof -p 3566 | grep soup e-calenda 3566 brian mem REG 252,2 294120 278834 /usr/lib/libsoup-2.4.so.1.3.0 e-calenda 3566 brian mem REG 252,2 22208 286738 /usr/lib/libsoup-gnome-2.4.so.1.3.0 $ dpkg -S /usr/lib/libsoup-2.4.so.1.3.0 libsoup2.4-1: /usr/lib/libsoup-2.4.so.1.3.0 $ dpkg -l libsoup2.4-1 | cat Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Description +++-============-=================-===================================================== ii libsoup2.4-1 2.30.2-0ubuntu0.1 an HTTP library implementation in C -- Shared library That all tells me I have 2.30.2 installed, which should include the fix Dan said went into 2.30.1. > And when > you run e-calendar-factory with CALDAV_DEBUG=all , will it show correct proxy > request or not? Not: > CONNECT www.google.com:443 HTTP/1.1 > Soup-Debug-Timestamp: 1283944559 > Soup-Debug: SoupSessionSync 1 (0x83b89a0), SoupMessage 1 (0x83bf4b0), SoupSocket 1 (0x83d8a00) > Host: www.google.com < HTTP/1.0 407 Proxy Authentication Required < Soup-Debug-Timestamp: 1283944559 < Soup-Debug: SoupMessage 1 (0x83bf4b0) < Server: squid/3.1.1 < Mime-Version: 1.0 < Date: Wed, 08 Sep 2010 11:15:59 GMT < Content-Type: text/html < Content-Length: 3057 < X-Squid-Error: ERR_CACHE_ACCESS_DENIED 0 < Vary: Accept-Language < Content-Language: en < Proxy-Authenticate: Negotiate < Proxy-Authenticate: Basic realm="Squid proxy-caching web server" < X-Cache: MISS from localhost < X-Cache-Lookup: NONE from localhost:3128 < Via: 1.0 localhost (squid/3.1.1) < Proxy-Connection: close < < ... > CONNECT www.google.com:443 HTTP/1.1 > Soup-Debug-Timestamp: 1283944559 > Soup-Debug: SoupSessionSync 1 (0x83b89a0), SoupMessage 2 (0x83bf520), SoupSocket 2 (0x83d8a60) > Host: www.google.com > Proxy-Authorization: Basic <base64 encoded gmail_acct:gmail_password> < HTTP/1.0 407 Proxy Authentication Required < Soup-Debug-Timestamp: 1283944561 < Soup-Debug: SoupMessage 2 (0x83bf520) < Server: squid/3.1.1 < Mime-Version: 1.0 < Date: Wed, 08 Sep 2010 11:16:01 GMT < Content-Type: text/html < Content-Length: 3136 < X-Squid-Error: ERR_CACHE_ACCESS_DENIED 0 < Vary: Accept-Language < Content-Language: en < Proxy-Authenticate: Negotiate < Proxy-Authenticate: Basic realm="Squid proxy-caching web server" < X-Cache: MISS from localhost < X-Cache-Lookup: NONE from localhost:3128 < Via: 1.0 localhost (squid/3.1.1) < Proxy-Connection: close < < ... So as you can see, it's populating the google/gmail credentials into the proxy request, not the proxy credentials. Of course, this would all just go away if my gss credentials (which work with firefox and chromium) were used instead of basic auth. But I suppose that's a different bug. :-) > Note it should show the password unencrypted, Yes, but base64 encoded. I had to use the base64 command to decode it and realize it was the google credentials, not the proxy credentials. > maybe some latter > in user name and/or password confused the url parser.
OK, thanks, let's move to bug #615274 for any further investigation. Thanks.