Bug 1034810

Summary:	evolution fails to import calendar with 'SSL handshake failed'
Product:	[Fedora] Fedora	Reporter:	Mildred <mildred-bug.redhat>
Component:	evolution	Assignee:	Matthew Barnes <mbarnes>
Status:	CLOSED UPSTREAM	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	20	CC:	danw, lucilanga, mbarnes, mcrha
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-11-26 20:40:47 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Mildred 2013-11-26 14:37:15 UTC

Description of problem:
When trying to add a web calendar, evolution fails with "Unable to connect to 'CALENDAR-NAME': Cannot open calendar: SSL handshake failed"

Version-Release number of selected component (if applicable): 3.10.2
How reproducible: always

Steps to Reproduce:
1. Add calendar "On the Web" with URI "https://basecamp.com/1788133/calendar_feeds/c744724.ics?token=TlpObVZzMTVrQlBBeWg4Y3JiSFpwdz09LS05Z3JCNGNVL25sczJ3QXZNZVlheTN3PT0%3D--35f00ea56760b54c23e5c8397f7191250d4e24e4-715358"

Actual results: an error is shown, a RESET TCP packet on wireshark
Expected results: no error and no events (the calendar is empty)

Comment 1 Mildred 2013-11-26 14:38:04 UTC

Might be related to https://bugzilla.gnome.org/show_bug.cgi?id=660134

Comment 2 Milan Crha 2013-11-26 20:40:47 UTC

Thanks for a bug report. It's weird, you are supposed to be asked what to do with the certificate, whether you want to ignore the SSL error or reject connection, when the server certificate looks suspicious. Nonetheless, I tried to reproduce this with your URL and I see the same issue, no prompt for a certificate.

Let's deal with this upstream, as this doesn't seem to be Fedora specific. I do not expect this being related to the old 3.2.x bug report from comment #1, thus I created a new bug for it [1]. Please see [1] for any further updates.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=719381

Comment 3 Dan Winship 2013-12-09 16:57:36 UTC

from the upstream bug:

"gnutls-cli -d 9 basecamp.com" shows:

    |<3>| EXT[0x2370310]: Parsing extension 'SUPPORTED ECC/10' (4 bytes)
    |<2>| ASSERT: ecc.c:95
    |<2>| ASSERT: gnutls_extensions.c:206
    |<2>| ASSERT: gnutls_handshake.c:1734
    |<2>| ASSERT: gnutls_handshake.c:2154
    |<2>| ASSERT: gnutls_handshake.c:1383
    |<2>| ASSERT: gnutls_handshake.c:2634
    *** Fatal error: An illegal TLS extension was received.

where:

    92    if (session->security_parameters.entity == GNUTLS_CLIENT)
    93      {
    94        /* A client shouldn't receive this extension */
    95        return gnutls_assert_val(GNUTLS_E_RECEIVED_ILLEGAL_EXTENSION);
    96      }


So, basically, basecamp.com is sending a TLS extension that is only defined for
clients, not servers, and gnutls, being anal like it is, aborts at that point.

File a bug against basecamp I guess?

You can kludge around this by running e-d-s with

    G_TLS_GNUTLS_PRIORITY="NORMAL:%COMPAT:-ECDHE-RSA"

set in the environment, which will keep e-d-s (and any other glib-tls-based
code in that environment) from negotiating elliptic-curve encryption, thus
bypassing the server bug.