Opened 2 years ago

Closed 5 months ago

#1981 closed defect (worksforme)

E120171: Error running context: An error occurred during SSL communication

Reported by: martinl Owned by: martin
Priority: blocker Milestone: Sysadmin Contract 2018-I
Component: Systems Admin Keywords: svn, openssl
Cc:

Description

Dear SAC,

since today I am unable to update GRASS SVN repo:

Updating '.':
svn: E170013: Unable to connect to a repository at URL 'https://svn.osgeo.org/grass/grass/trunk'
svn: E120171: Error running context: An error occurred during SSL communication

Could be related to recent changes in Debian regarding OpenSSL (1). Is there anything related to OSGeo server or just my issue? Thanks for clarification. Martin

(1) https://lists.debian.org/debian-devel-announce/2017/08/msg00004.html

Change History (42)

comment:1 Changed 2 years ago by neteler

Your assumption could be right:

https://www.ssllabs.com/ssltest/analyze.html?d=svn.osgeo.org&latest

--> " The server supports only older protocols, but not the current best TLS 1.2. Grade capped to C.

[...]

  • TLS 1.3 No
  • TLS 1.2 No
  • TLS 1.1 No
  • TLS 1.0 Yes"

An upgrade of the server configuration would be a good idea.

comment:2 in reply to:  1 Changed 2 years ago by martinl

Priority: normalcritical

Replying to neteler:

An upgrade of the server configuration would be a good idea.

So I am taking liberty to increase priority. For now I will try to downgrade openssl package on my PC.

comment:3 Changed 2 years ago by strk

It looks like it'd take manually compiling libssl and mod_ssl. Or upgrade to a still supported Debian version (even backports repository has been obsoleted)

comment:4 Changed 2 years ago by strk

Or switch to https://mod.gnutls.org/ ...

comment:5 Changed 2 years ago by strk

It looks like The version of gnutls on that server already supports TLS1.2

$ gnutls-cli -l | grep TLS1.2 Protocols: SSL3.0, TLS1.0, TLS1.1, TLS1.2

And the apache module is available, so could be a viable path to switch to that. Only it might taking tweaking some apache configurations (/etc/apache is under a local git repository though, which should help)

comment:6 Changed 2 years ago by strk

For the record: Ubuntu 17.04 does not ship mod_ssl anymore, but it does ship mod_gnutls.

comment:7 Changed 2 years ago by mlennert

Just a ping, confirming the same issue for me. And yes, this happens after the Debian OpenSSL upgrade.

comment:8 Changed 2 years ago by jef

quick workaround on an affected client:

apt-get build-dep openssl
apt-get source openssl
cd openssl-1.1.0f
sed -i -e "s/disable-tls1 disable-tls1_1/# &/" debian/rules
DEB_BUILD_OPTIONS="nocheck parallel" dpkg-buildpackage -us -uc -b
sudo dpkg -i ../libssl1.1_1.1.0f-4_amd64.deb
Last edited 2 years ago by jef (previous) (diff)

comment:9 Changed 2 years ago by strk

For those like me who receive comments by mail: the suggested workaround is for clients, not server (post-submit edit of trac comments are not notified by mail, the info was added later)

comment:10 Changed 2 years ago by mlennert

Thanks for the workaround. Are there any plans of upgrading the server so it supports 1.2+ ?

comment:11 Changed 2 years ago by martinl

Any chance to get svn server fixed to support 1.2+?

comment:12 Changed 2 years ago by strk

I don't have time to work on it, but if anyone else does I suggest to look at GNU-lts module (is avalable as packaged for the version of OS on that system).

comment:13 Changed 23 months ago by rduivenvoorde

During OSGeo-NL GRASS-intro, we were hit with this one too :-(

comment:14 Changed 23 months ago by strk

Priority: criticalblocker

comment:15 Changed 21 months ago by goatbar

Sigh. Hit the same on a debian testing based distro. :(

svn --version
svn, version 1.9.7 (r1800392)
   compiled Aug 17 2017, 02:50:12 on x86_64-pc-linux-gnu

svn co https://svn.osgeo.org/gdal/trunk/gdal
svn: E170013: Unable to connect to a repository at URL 'https://svn.osgeo.org/gdal/trunk/gdal'
svn: E120171: Error running context: An error occurred during SSL communication

apt-cache show subversion
Depends: libsvn1 (= 1.9.7-2), libapr1 (>= 1.5.0), libaprutil1 (>= 1.3.2+dfsg), libc6 (>= 2.4), libldap-2.4-2 (>= 2.4.7), libsasl2-2

apt-cache show openssl | egrep 'Version'
Version: 1.1.0f-4

comment:16 Changed 21 months ago by robe

I have run into similar issues when using Caddy (for proxying). This just highlights the fact we are desperately in need of upgrading the trac server. The OS is just too old. It's running Debian 6 which at this point is ancient.

comment:17 Changed 19 months ago by martin

In order to resolve this issue I'm planning to upgrade the TracSVN VM this Friday (2018-02-16) to a more recent version of Debian Linux. Outages will occur at some point in the process, reboot will be synced with OSL staff.

Currently the following VM's still run an outdated distro, some of which I'd prepare to upgrade as well:

secure / projects / web / download / tracsvn / wiki

comment:18 Changed 19 months ago by strk

Great news, thank you ! Please make sure to update the VM information on the wiki at the end of the upgrade process.

comment:19 Changed 19 months ago by martin

Upgrade to Debian7 on TracSVN VM is almost complete, please report features which might have gone lost.

comment:20 Changed 19 months ago by martin

Upgrade to Debian7 on Download VM is almost complete, please report features which might have gone lost.

comment:21 Changed 19 months ago by robe

martin,

Not sure if the TracSVN upgrade and ssl changes is related, but I noticed I'm not seeing our bot badges on PostGIS anymore. As I recall I think I saw all of them the day before.

I have a related ticket in our postgis tracker. https://trac.osgeo.org/postgis/ticket/4019

I still see the bot badges on github and gitea and confirm the images are there if called directly.

The net calls for the badges shows they are being cancelled and I get this notice

Request URL:https://debbie.postgis.net/buildStatus/icon?job=PostGIS_trunk
Referrer Policy:no-referrer-when-downgrade
Provisional headers are shown
Origin:https://trac.osgeo.org
Referer:https://trac.osgeo.org/postgis
User-Agent:Mozilla/5.0 (Linux; Android 6.0; Nexus 5 Build/MRA58N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.167 Mobile Safari/537.36
job:PostGIS_trunk

comment:22 Changed 19 months ago by robe

Forgot to mention page badges show. Dronie badges are currently showing for me but not any of the others

https://trac.osgeo.org/postgis

comment:23 Changed 19 months ago by martin

EDIT: I think I figured what you mean and I confirm more badges are available from their respective sources than shown on the "postgis" Trac page. I also confirm the visible result is different depending on which browser you use.

Looking at the page source delivered to the browser I'm unable to identify any syntax or related differences which might be making the difference, will look again later today using a larger screen.

Last edited 19 months ago by martin (previous) (diff)

comment:24 Changed 19 months ago by strk

Problem page is: https://trac.osgeo.org/postgis

Drone badges come from drone.osgeo.org, others come from non-osgeo domains (in case that matters).

comment:25 Changed 19 months ago by martin

Firefox on Linux renders only the alternate text for non-OSGeo-domains, with a quick chat about TLS handshake in the status bar shortly before the Dronie badges show up.

Chromium on Linux renders broken image URLs in every field for non-OSGeo-domains plus the alternate text, but if you open the underlying image in a new tab, it renders correctly.

Therefore I'd go with Sandro's idea, to me this smells like modern browsers refuse to reach out for badges from external sites - but currently I don't know how to "do it right" in this (Trac) context. Assistance is appreciated.

During the Debian update on the TracSVN machine the Trac software saw a minor update as well, because reinstall in Python2.7 was required. In order not to introduce any feature changes, I took the latest release from the same line, which is 1.2.2, together with the plugins listed in https://wiki.osgeo.org/wiki/Trac#Plugins

Now I wonder wether the update from the preceding 1.2.1-dev is making the difference ....

comment:26 Changed 19 months ago by strk

I'd look at the suggested CORS header, maybe it was previously done by Trac, maybe by Apache. We know browsers did not change so the change must be on the server side (we can't get back to check and compare the headers now...)

Do new headers say anything about allowed-origins ?

comment:27 Changed 19 months ago by strk

BTW, this discussion about badges should go in a separate ticket, this ticket was just about SSL

comment:28 Changed 19 months ago by strk

I filed the badges discussion as #2122

comment:29 Changed 19 months ago by strk

Martin Landa: can we close this as fixed now ?

comment:30 Changed 19 months ago by martin

I think one or two VM's (Secure, maybe the Wiki) still require updating, before they or their respective services finally get migrated elsewhere.

May I assume the Web VM is now obsolete ?

comment:31 Changed 19 months ago by martin

Ok, I see, it's still being used.

comment:32 Changed 19 months ago by martin

Owner: changed from sac@… to martin
Status: newassigned

comment:33 Changed 19 months ago by martin

Milestone: Sysadmin Contract 2018-I

comment:35 Changed 19 months ago by martin

The Wiki VM has been upgraded to Debian7 as well, this makes overall maintenance a little bit easier.

I *think* the secret to get a working GRUB on OSGeo's VM's is to install the "grub-legacy" package. Surprisingly there wasn't such thing on the Adhoc VM - maybe it's been upgraded again after the last successful reboot.

comment:36 Changed 19 months ago by martin

The Web VM has now been upgraded to Debian7.

For the sake of backwards compatibility with the old Drupal setup I took care of keeping the old PHP5 packages. Thus, the old web site should behave as it did before. If it doesn't, please report.

Last edited 19 months ago by martin (previous) (diff)

comment:37 Changed 19 months ago by martin

Now there are two Debian6 VM's left:

  • Projects: I think the remaining projects should get migrated over to Osgeo6. The VM might subsequently turn into a reboot-testbed.
  • Secure: Upgrading this one is rather simple, because SLAPD is its only service and it's already in config directory format. Can OSGeo afford a little LDAP hiccup during upgrade ?

comment:38 Changed 19 months ago by strk

How long would such hiccup be ?

comment:39 Changed 19 months ago by martin

From my experience with other VM migrations, I'd say the hiccup would last less than 5 minutes, because there's so little to upgrade on this VM.
Alternatively, we could make the current LDAP directory read-only, set up a read-only clone on Osgeo6, switch the "ldap.osgeo.org" DNS to Osgeo6, upgrade the secure VM, switch the DNS back to the secure VM.

Ideas, votes ?

comment:40 Changed 19 months ago by strk

I find the idea of setting up a read only clone useful in general, we could keep it ready and document how to do it again next time it will be needed, for any reason.

comment:41 Changed 12 months ago by robe

is this still an issue or can we close?

comment:42 Changed 5 months ago by robe

Resolution: worksforme
Status: assignedclosed
Note: See TracTickets for help on using tickets.