[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: certificate problems and 403 Forbidden for svn 0.25.0

From: Tobias Ringstrom <tobias_at_ringstrom.mine.nu>
Date: 2003-07-20 21:51:06 CEST

Garret Wilson wrote:
> Thanks, Tobias, but for me this option is neither easier to use nor more
> secure.

You're very welcome, but I will not let you get away that easily! ;-)

> First, my issue is not the prompting---it's the the failure to check
> out. (I could even temporarily live with multiple prompts on checkout.)

Yup, and that's why I called it a workaround. The bug is real and
needs fixing, but even if it is fixed, my example would be more
secure. I'll explain why below.

> Second, this solution would require me to distribute a separate file to
> each new client who wishes to connect. That's not easier than simply
> fixing the bug once and for all on the client.

If you have lots of users you should probably get a real certificate,
but if that is not an option you can create a small installer that
modifies the servers file as in my example.

The problem is that if you tell all your users to just say yes to all
certificate warnings, they will not notice if the DNS is hacked to
point to another server. They will just say yes to any warning. The
warnings are there for a reason, and in most cases it is a mistake to
ignore it.

If you do not care about securety, I think http is a better choice.

> And in theoretical terms it's not more secure. The whole idea of
> certificate authorities is that they help authenticate certificates. If
> a CA is used, it will recognize, for example, if you've decided to
> revoke the certificate for a site. I don't think this would happen if
> you've hard-configured a certificate on the client.

To handle revocation of certificates, the client must support client
revocation lists, and I don't many clients actually do that. I hope
I'm wrong, though. I have no idea if subversion/neon does it.

> Lastly, I couldn't find "ssl-authorities-file" mentioned anywhere in the
> Subversion book.

That's a bummer. I must confess that I did not look at the book in
this case. I'm used to the book being so good that I was sure that it
did cover this as well. It is described in the servers config file,

I'll try to explaing why I think that it's more secure to use the
ssl-authorities-file directive. If you have a real (not self-signed)
certificate, then the client accepts it because it is signed by one of
the CAs in the openssl list (/usr/share/ssl/cert.pem on my system).
You will not get a warning unless something is *really* wrong.

If you do not want to buy a real certificate you can create a
self-signed one, which I assume is what you've done. Since it is
self-signed it will not be accepted by openssl (unless you put it in
the system CA file), and you get a warning. If you just say yes to
that warning you have no way to detect if your DNS has been hijacked.

The solution is to verify once and for all that the certificate is
authentic, and then put it in the servers file as I demonstrated. If
your DNS is hijacked, the certificate will not match and you will get
a warning. As with a real certificate, a warning now indicates a
severe security problem.

This is why it is more secure, and I hope you agree now.

> I could understand hard-configuring a root CA, but Subversion should
> ship with a base list of authorized CAs, as browsers do.

Subversion uses neon which uses openssl, so the system's standard list
is used -- i.e. it works as it should. I do not know if neon uses
certificate revocation lists.

I have not tested it since I do not have a real certificate, but if it
does not work like that, then it's a bug.

> But again, the real problem here is not the prompting---it's the failure
> to check out. I guess you're saying that the checkout problem stems some
> bug in the prompting, but I haven't yet confirmed whether this is the case.

You could always try my solution and see if the problem goes away.
That should isolate it.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jul 20 21:52:09 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.