Modify

Opened 3 years ago

Last modified 3 years ago

#1812 new enhancement

GetComponents needs to come with (a selected few) trusted certificates

Reported by: Frank Löffler Owned by:
Priority: minor Milestone:
Component: GetComponents Version: development version
Keywords: Cc:

Description

Most encrypted connections use some form of certificates. We use both ssl for subversion and git. The problem with certificates is that the certificate of the root CA has to be trusted by a client to be able to form a trusted connection. Otherwise users get warnings, and either cannot connect at all, or have to manually approve. We don't want both happening with GetComponents.

Root CA certificates have to be changed from time to time. They have a limited life time. In addition, there is a big movement away from SHA-1 certificates right now, as this has been found weak. The problem with that is that an updated root CA might not have it made to all (or at least most) clients at the time a user might have to trust it. Usually, root CAs are created, but not actually used for some time for that reason. Security problems like SHA-1 interfere with that. All this is nothing we can change.

So, in the light of root CAs possibly faster changing than clients update (and especially supercomputers update slowly in particular), we have to have a mechanism to make GetComponents still work 'out of the box' with these - no matter what the protocol is that actually uses it.

Right now, we only seem to have problems with svn, but in the future we might have the same problem with git (bitbuckets root CA is still using SHA-1).

For Subversion I propose the following. We ship 'too new' certificates with GetComponents (in-source, to still have one file). We then write this to a temporary file during checkout, and use the following option to svn to get it to accept it:

--config-option servers:global:ssl-authority-files=<FILE>

This mechanism was tested manually on one of the problematic machines (stampede), with one of the problematic certs (InCommon).

This only works for svn version 1.6 and newer. Most installations should have that. In case we encounter an older one we could disable trusted cert checking for problematic cases using --trust-server-cert.

Attachments (0)

Change History (6)

comment:1 Changed 3 years ago by Frank Löffler

Before implementing this I would like to have feedback.

comment:2 Changed 3 years ago by Roland Haas

This can be a bit dangerous in case this happens on a user's workstation and they later run svn directly on the command line (eg svn update) and then receive the svn error message. We should output some information that a certificate file was created along with instructions for users to use it.

Instead of an svn option you can set the SSL_CERT_FILE environment variable (in GetComponents before calling svn) and point it to the proper file (works on OSX's svn 1.7 and 1.8 from macports and on my linux workstation). Git supports a sslcainfo option in the http section of its config file so at least for git we can try and see if it allows the system certificates to be supplemented by the ones GetComponents provided on a per repository basis.

The alternative (which I'd prefer) would of course be to get a ssl certificate from a common/old enough root authority that is supported by all systems we care about.

comment:3 Changed 3 years ago by Frank Löffler

Using the environment variable is an interesting idea, but it assumes we can set it for all the future sessions of the user. Otherwise we would be back to square one for a subsequent 'svn update'. Subversion also lets you specify this without environment variable in it's user (or system) wide config files, but I didn't really want GetComponents mess with that. I would rather have the user deal with accepting the certificate if she updates later by hand.

Getting a cert from an old enough root CA might be difficult/impossible. First, the old certs might be insecure (SHA-1), or you simply have to way to specify the chain yourself, or even change the certificate itself, like on a public hosting system.

comment:4 Changed 3 years ago by Roland Haas

The reason I suggested using the environment variable is that this also work with versions of subversion that do not support the servers:global:ssl-authority-files option such as the stock OSX subversion client where I ran into this. I don't know on top of my head if my linux workstation accepted the option. The current version from homebrew accepts the option.

The SSL environment option seems to be actually parsed by openssl and not subversion itself.

Do we still need to worry about pre-1.6 subversion anywhere (any cluster)?

comment:5 in reply to:  4 Changed 3 years ago by Frank Löffler

Replying to rhaas:

The SSL environment option seems to be actually parsed by openssl and not subversion itself.

That's right. As I said, this is not a svn problem. It's either openssl or gnutls complaining, depending on what library clients are using.

Do we still need to worry about pre-1.6 subversion anywhere (any cluster)?

I guess we have to.

comment:6 Changed 3 years ago by Roland Haas

This is connected to #1801. There seems to be nothing to actually review in this ticket.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The ticket will remain with no owner.
Next status will be 'review'.
as The resolution will be set.
to The owner will be changed from (none) to the specified user.
Next status will be 'confirmed'.
The owner will be changed from (none) to anonymous.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.