Joe Orton wrote:
> e.g. I log in to IRC and someone persuades me to checkout some
> funky new code from https://funkycode.org/repos/, and I naively
> hit the "accept permanently" button on my SVN client when prompted
> for this new cert.
>
> To arrange the MITM, the attacker had placed a subjectAltName
> extension on the funkycode.org cert naming svn.webdav.org, and
> then subverts the DNS for svn.webdav.org to point to a server
> hosting trojaned neon code. Then when I "svn co" to make a new
> neon release, I get trojaned code without knowing it.
Fortunately this attack does not work with the current implementation
becuase we do not consider any alternative hostnames for non-CA
trusted certs. If you choose to permanently trust the cert above, you
will get a question when you connect to svn.webdav.org because the
hostname will not match the DN. You can only temporarily accept that
error.
This could be changed. We could consider the altname as well, but than
we would have to show all names in the prompt so that the user will
understand what hosts this cert will be acceptable for. I suspect that
some people will think that this will make it too easy for the user to
create a security problem. Users never read prompts properly. :-)
However, I am not perfectly happy with the current implementation for
mainly one reason. The current system was designed so that Subversion
would behave like a web browser, i.e. you can only temporarily ignore
an expired cert or a cert with wrong hostname. The problem is that in
a browser, temporary means "as long as the browser is open", which can
be a long time. Subversion on the other hand always runs for a quite
short time, and therefore you will see that prompt quite often. The
user experience will thus be that Subversion is much more annoying
than a web browser.
This is not a huge problem because it only happens if the cert date is
wrong or if the hostname does not match, which should never happen in
a perfect world. The reasoning was that there should be some pain
related to the use of such certs, but I'm now thinking that the pain
might be too great.
I suggest the following new behaviour instead. RTP below means
"Reject, accept Temporarily or accept Permanently".
1. If a cert is trusted (because it's CA is trusted), and:
a. the cert date and hostname are correct: The user should
not be bothered with a prompt.
b. the cert date or hostname are incorrect: The user gets
an RTP prompt. If the user chooses to accept the cert
permanently, the user will not be prompted again for
this hostname+port again unless the set of failures
changes.
2. If a cert is not trusted, the user gets an RTP prompt. If the
user chooses to accept the cert permanently, the user will not
be prompted again for this hostname+port again unless the set
of failures changes.
This means that we can remove the two config options
ssl-ignore-invalid-date and ssl-override-cert-hostname.
I'm very interested in what you all think about this alternative
solution. I think this is very close to what you proposed two weeks
ago, Joe.
The voting has begun! :-)
/Tobias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Sep 23 10:16:32 2003