You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Tom Martin <to...@hotmail.com> on 2004/12/21 01:11:38 UTC

Feature request: Disable ssl prompting in "servers" for better security

Hello!

Background:

We've encountered the following security problem in our company.
Our repository (containing sensitive data) lives on an dynamic IP.
Now, one developer connected to a wrong (out-of-date) IP,
and for accident at this time there was a different host having this IP.
The svn client (TSVN) popped up the "fingerprint has changed" warning;
but it seems that many developers (as in this case) simply
click "ok" onto such buttons not taking such a warning seriously.
This seems to be a wide-spread behaviour especially for windows-users
using GUI frontends.
As consequence, he tried to connect to the wrong server.
In this case this was no problem because this server had no repository
on the same location; but "bad guys" might use this for fetching confidental
data sent by the svn client to the wrong host.
As often, at the end the human being is the most serious security hole.
But if there possibilities to protect against lazy users, this is a good 
idea.

Proposal:

A new boolean config entry "ssl-no-promt" for the "servers" config file.
If the ssl host cannot be authenticated using "ssl-authority-files",
the svn client fails without promting.
In contrast to implementing such a feature to each individual svn client,
this feature automatically would affect all clients.

Thanks!

Tom

_________________________________________________________________
Don't just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Feature request: Disable ssl prompting in "servers" for better security

Posted by Ben Reser <be...@reser.org>.
On Tue, Dec 21, 2004 at 01:11:38AM +0000, Tom Martin wrote:
> Hello!
> 
> Background:
> 
> We've encountered the following security problem in our company.
> Our repository (containing sensitive data) lives on an dynamic IP.
> Now, one developer connected to a wrong (out-of-date) IP,
> and for accident at this time there was a different host having this IP.
> The svn client (TSVN) popped up the "fingerprint has changed" warning;
> but it seems that many developers (as in this case) simply
> click "ok" onto such buttons not taking such a warning seriously.
> This seems to be a wide-spread behaviour especially for windows-users
> using GUI frontends.
> As consequence, he tried to connect to the wrong server.
> In this case this was no problem because this server had no repository
> on the same location; but "bad guys" might use this for fetching confidental
> data sent by the svn client to the wrong host.
> As often, at the end the human being is the most serious security hole.
> But if there possibilities to protect against lazy users, this is a good 
> idea.
> 
> Proposal:
> 
> A new boolean config entry "ssl-no-promt" for the "servers" config file.
> If the ssl host cannot be authenticated using "ssl-authority-files",
> the svn client fails without promting.
> In contrast to implementing such a feature to each individual svn client,
> this feature automatically would affect all clients.

Sounds like a good idea to me.  I realize a lot of people didn't support
this.  But this is similar to the StrictHostKeyChecking yes which I use
in ssh myself.  Please file an enhancement issue for this.

-- 
Ben Reser <be...@reser.org>
http://ben.reser.org

"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Feature request: Disable ssl prompting in "servers" for better security

Posted by Kenneth Porter <sh...@sewingwitch.com>.
--On Tuesday, December 21, 2004 2:56 AM +0000 Tom Martin 
<to...@hotmail.com> wrote:

> It is your own risk to access your bank account in this way.
> But I want to reduce the dependency of *other's* people correct behaviour
> regarding the security of our company.

In other words, this is like letting your purchasing people contact your 
company's bank using a secure browser. Again, are you asking the same of 
browser makers?

OpenSSH used to block access to a host that changed fingerprint, requiring 
that one remove the old entry from the knownhosts file manually. Now it 
just offers up a warning and allows one to override with a keystroke. (This 
might just be a change to the global config file setting.) I prefer the 
latter when I'm using it to connect to my home server and the ISP has 
changed addresses on me.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Feature request: Disable ssl prompting in "servers" for better security

Posted by Tom Martin <to...@hotmail.com>.
Hi Kenneth!

>From: Kenneth Porter <sh...@sewingwitch.com>
>To: dev@subversion.tigris.org
>Subject: Re: Feature request: Disable ssl prompting in "servers" for better 
>security
>Date: Mon, 20 Dec 2004 18:22:20 -0800
>
>--On Tuesday, December 21, 2004 2:13 AM +0000 Tom Martin 
><to...@hotmail.com> wrote:
>
>>it seems that there is a difference of subversion to many other
>>applications: With subversion you typically have much more sessions than
>>with other applications. For example, when using ssh you typically login,
>>and then have a longer session. When using svn, every single svn command
>>is a new session. This makes it much more likely to simply click warning
>>messages away.
>
>How is this different from connecting to your bank over HTTPS?

There is none. But I don't like this, too.
If someone manipulates DNS or IP packet routing of your bank server:
Can you guarantee that no-one is simply clicking away the fingerprint 
warning message?
Would you bet your money on it?
I definitely wouldn't.

It is your own risk to access your bank account in this way.
But I want to reduce the dependency of *other's* people correct behaviour
regarding the security of our company.

Thanks.

Tom

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Feature request: Disable ssl prompting in "servers" for better security

Posted by Kenneth Porter <sh...@sewingwitch.com>.
--On Tuesday, December 21, 2004 2:13 AM +0000 Tom Martin 
<to...@hotmail.com> wrote:

> it seems that there is a difference of subversion to many other
> applications: With subversion you typically have much more sessions than
> with other applications. For example, when using ssh you typically login,
> and then have a longer session. When using svn, every single svn command
> is a new session. This makes it much more likely to simply click warning
> messages away.

How is this different from connecting to your bank over HTTPS? Every page 
is a new connection. Subversion should provide no more protection against 
changing host fingerprints than a web browser would.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Feature request: Disable ssl prompting in "servers" for better security

Posted by John Peacock <jp...@rowman.com>.
John Peacock wrote:
> Yes, but it is the ssh program itself which challenged the user about 
> the changed key, not Subversion.

DOH, never mind.  ssh != ssl

<slinking away>

John

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Feature request: Disable ssl prompting in "servers" for better security

Posted by Tom Martin <to...@hotmail.com>.
> From: John Peacock <jp...@rowman.com>
>To: Tom Martin <to...@hotmail.com>
>CC: dev@subversion.tigris.org
>Subject: Re: Feature request: Disable ssl prompting in "servers" for better 
>security
>Date: Mon, 20 Dec 2004 21:27:29 -0500
>
>Tom Martin wrote:
>>Authentication itself is a very serious security issue.
>>No serious security manager would rely on proper timeouts and on proper
>>IP routing. There are several possibilities for manipulating this.
>>This is exactly the reason why ssl authentication exists.
>>I am sure you don't want to say that this feature has no reason.
>
>Yes, but it is the ssh program itself which challenged the user about the 
>changed key, not Subversion.  I'm not even sure that it is possible at the 
>Subversion level to affect this behavior, since ssh is the secure transport 
>method and only after the connection is established that svn gets control 
>again.

All ssl properties are read from the subversion config file "servers".
So subversion seems to evaluate them.
Also the subversion command line client evaluates the no-promt option.
Basically my proposal says that "servers" should get a default value for 
"no-promt".
Because of this, although not being a professional developer, I am quite 
sure
that it would be easy possible in subversion.

>This feature belongs in ssh, not in Subversion.
>
>In particular, the StrictHostKeyChecking option to .ssh/config seems to be 
>exactly what you want:
>
>...
>
>Set this to ``yes'' in the .ssh/config file (or if all users are on the 
>same system, then the systemwide config file), and you won't have to worry 
>about this again.

This is ssh. Is there a corresponding ssl option? This would be perfect!

Thanks!

Tom

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Feature request: Disable ssl prompting in "servers" for better security

Posted by John Peacock <jp...@rowman.com>.
Tom Martin wrote:
> Authentication itself is a very serious security issue.
> No serious security manager would rely on proper timeouts and on proper
> IP routing. There are several possibilities for manipulating this.
> This is exactly the reason why ssl authentication exists.
> I am sure you don't want to say that this feature has no reason.

Yes, but it is the ssh program itself which challenged the user about the 
changed key, not Subversion.  I'm not even sure that it is possible at the 
Subversion level to affect this behavior, since ssh is the secure transport 
method and only after the connection is established that svn gets control again. 
  This feature belongs in ssh, not in Subversion.

In particular, the StrictHostKeyChecking option to .ssh/config seems to be 
exactly what you want:

      StrictHostKeyChecking
              If this flag is set to ``yes'', ssh will never automatically add
              host keys to the $HOME/.ssh/known_hosts file, and refuses to con-
              nect to hosts whose host key has changed.  This provides maximum
              protection against trojan horse attacks, however, can be annoying
              when the /etc/ssh/ssh_known_hosts file is poorly maintained, or
              connections to new hosts are frequently made.  This option forces
              the user to manually add all new hosts.  If this flag is set to
              ``no'', ssh will automatically add new host keys to the user
              known hosts files.  If this flag is set to ``ask'', new host keys
              will be added to the user known host files only after the user
              has confirmed that is what they really want to do, and ssh will
              refuse to connect to hosts whose host key has changed.  The host
              keys of known hosts will be verified automatically in all cases.
              The argument must be ``yes'', ``no'' or ``ask''.  The default is
              ``ask''.

Set this to ``yes'' in the .ssh/config file (or if all users are on the same 
system, then the systemwide config file), and you won't have to worry about this 
again.

John

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Feature request: Disable ssl prompting in "servers" for better security

Posted by Tom Martin <to...@hotmail.com>.
Hello John!

>From: John Peacock <jp...@rowman.com>
>To: Tom Martin <to...@hotmail.com>
>CC: dev@subversion.tigris.org
>Subject: Re: Feature request: Disable ssl prompting in "servers" for better 
>security
>Date: Mon, 20 Dec 2004 20:43:02 -0500
>
>Tom Martin wrote:
>>A new boolean config entry "ssl-no-promt" for the "servers" config file.
>>If the ssl host cannot be authenticated using "ssl-authority-files",
>>the svn client fails without promting.
>
>It seems like a waste to spend time adding a new config entry to deal with 
>a situation brought on by poor network management practices.  Repositories 
>on a network must be in a 'fixed' location, so that clients can contact 
>them.  If you choose to give the repository a floating IP (a bad idea in 
>the first place), then the clients must be able to resolve the server 
>address by name (via some resolution method).  Said method should 
>(according to good design) contain a cache that is shorter than any time 
>limit on an assigned IP address.
>
>I think that this was a classic case of shooting yourself in the foot; the 
>tool (in this case Subversion) should not be in the business of setting 
>rules for your network that would prevent this from happening.  There is no 
>security failure here other than the unwise decision to have a movable 
>repository containing sensitive information and the developer's inability 
>to read an error message and act on it appropriately.  IMNSHO.

You are right that a dynamic IP is not perfect (but unavoidable in this 
case);
but it is only making the problem more worse, but it is not the cause of the
problem itself. For the following you may assume that the IP is static.

Authentication itself is a very serious security issue.
No serious security manager would rely on proper timeouts and on proper
IP routing. There are several possibilities for manipulating this.
This is exactly the reason why ssl authentication exists.
I am sure you don't want to say that this feature has no reason.

Agreed, everything would be fine if all people would correctly
response to warning messages. But in practise they are humans.
I try to teach them all the time about several security aspects.
And basically it works mostly; but again and again there are situations
where they do the wrong thing.
It is all my experience that human make errors, and that technology
helping to reduce human errors are a good thing.
Being responsible for security, I want to reduce dependency on correct
user behaviour as far as possible. It will be never perfect, but as more as
better.

BTW, you may argue that other applications work in the same way
as subversion. However, it seems that there is a difference of subversion
to many other applications: With subversion you typically have much more
sessions than with other applications. For example, when using ssh you 
typically
login, and then have a longer session. When using svn, every single svn
command is a new session. This makes it much more likely to simply
click warning messages away.

Thanks!

Tom

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Feature request: Disable ssl prompting in "servers" for better security

Posted by John Peacock <jp...@rowman.com>.
Tom Martin wrote:
> A new boolean config entry "ssl-no-promt" for the "servers" config file.
> If the ssl host cannot be authenticated using "ssl-authority-files",
> the svn client fails without promting.

It seems like a waste to spend time adding a new config entry to deal with a 
situation brought on by poor network management practices.  Repositories on a 
network must be in a 'fixed' location, so that clients can contact them.  If you 
choose to give the repository a floating IP (a bad idea in the first place), 
then the clients must be able to resolve the server address by name (via some 
resolution method).  Said method should (according to good design) contain a 
cache that is shorter than any time limit on an assigned IP address.

I think that this was a classic case of shooting yourself in the foot; the tool 
(in this case Subversion) should not be in the business of setting rules for 
your network that would prevent this from happening.  There is no security 
failure here other than the unwise decision to have a movable repository 
containing sensitive information and the developer's inability to read an error 
message and act on it appropriately.  IMNSHO.

John

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org