[please CC me on replies]
On Thu, May 15, 2008 at 08:08:39PM +0200, Daniel de Kok wrote:
Questions on how this may affect CentOS users should be directed to the CentOS users list. List subscription information is available from:
In addition to the fixed OpenSSL packages, Debian also released an update to OpenSSH that includes a blacklist of the weak keys. With this update, any connections attempting to authenticate with a weak key are rejected. There's also a utility which searches through user ~/.ssh directories for blacklisted keys.
This blacklist would help in securing non-Debian systems as well. Are there any plans to include this ssh update in CentOS?
Chris Butler wrote:
In addition to the fixed OpenSSL packages, Debian also released an update to OpenSSH that includes a blacklist of the weak keys. With this update, any connections attempting to authenticate with a weak key are rejected. There's also a utility which searches through user ~/.ssh directories for blacklisted keys.
This blacklist would help in securing non-Debian systems as well. Are there any plans to include this ssh update in CentOS?
Dag pointed out that Suse is also considering setting up a blacklist of this nature. I dont mind looking at something like this within CentOS if someone wants to make a case for it. Would it be better to just have some tool ( Daniel already brought that up! ) that could audit setups instead of running such a blacklist ?
Imho, the CentOS team would be open at looking at anything that helps improve security for the users. And lets also keep an eye on what comes down from upstream. But till such time as there is an upstream release to address this issue ( if at all ) nothing stops us from providing the resources required.
Karanbir Singh wrote:
Dag pointed out that Suse is also considering setting up a blacklist of this nature. I dont mind looking at something like this within CentOS if someone wants to make a case for it. Would it be better to just have some tool ( Daniel already brought that up! ) that could audit setups instead of running such a blacklist ?
The problem is that the tools I know only look for broken ssh keys (dowkd.pl, ssh-vulnkey) and none of them address other problematic areas like certificates, dnssec-keys (although Lutz Donnerhacke mailed all people running zones with broken keys) and so on.
If you take a look at http://debian.wideopenssl.org/ there are so many applications which might have broken keys even on non-Debian systems that I think offering a tool for just ssh keys might give people a wrong sense of security, if they don't find broken ssh keys on their machines.
Ralph
On Sat, May 17, 2008 at 12:25 PM, Ralph Angenendt ra+centos@br-online.de wrote:
If you take a look at http://debian.wideopenssl.org/ there are so many applications which might have broken keys even on non-Debian systems that I think offering a tool for just ssh keys might give people a wrong sense of security, if they don't find broken ssh keys on their machines.
People often mistake tools for facts. Just like rootkit detection utilities, people should realize that key detection is just a tool to assist with finding obvious compromises. I think it is ok, to provide one of these detection tools through the -extras repository, as long as it is made clear in the documentation what it detects, what it does not detect, and whether there is a chance of having false-positives.
Wrt. fingerprint-based blocking in OpenSSH:
- What does our upstream think about this? - What do the OpenSSH developers think about this?
I think a general scheme for blocking certain public keys might be useful, even outside this specific case. But I am not sure it is a good idea to make/use vendor-specific extensions.
Take care, Daniel
Daniel de Kok wrote:
- What does our upstream think about this?
- What do the OpenSSH developers think about this?
Someone is going to need to ask those questions of the people...
Karanbir Singh wrote:
Daniel de Kok wrote:
- What does our upstream think about this?
- What do the OpenSSH developers think about this?
Someone is going to need to ask those questions of the people...
I don't think the OpenSSH devels really do care about that - there is no discussion whatsoever on the secureshell list or on the devel list.
No idea about our upstream, but I don't think so either.
Ralph
Ralph Angenendt wrote:
- What does our upstream think about this?
- What do the OpenSSH developers think about this?
Someone is going to need to ask those questions of the people...
I don't think the OpenSSH devels really do care about that - there is no discussion whatsoever on the secureshell list or on the devel list.
No idea about our upstream, but I don't think so either.
Does anyone know the point of the patch in the first place? That is, why would a distro-specific modification have been needed at all? I don't suspect an intentional compromise here but I'm curious about why anyone would consider a non-standard change.
Les Mikesell wrote:
Ralph Angenendt wrote:
- What does our upstream think about this?
- What do the OpenSSH developers think about this?
Someone is going to need to ask those questions of the people...
I don't think the OpenSSH devels really do care about that - there is no discussion whatsoever on the secureshell list or on the devel list.
No idea about our upstream, but I don't think so either.
Does anyone know the point of the patch in the first place? That is, why would a distro-specific modification have been needed at all? I don't suspect an intentional compromise here but I'm curious about why anyone would consider a non-standard change.
The change was added due to valgrind testing of openssh and warnings produced while compiling.
The removal was discussed on the openssh-devel list.
If was clearly an accident caused by trying to do the right thing.
On Mon, May 19, 2008 at 3:53 PM, Johnny Hughes johnny@centos.org wrote:
Les Mikesell wrote:
Does anyone know the point of the patch in the first place? That is, why would a distro-specific modification have been needed at all? I don't suspect an intentional compromise here but I'm curious about why anyone would consider a non-standard change.
The change was added due to valgrind testing of openssh and warnings produced while compiling.
The removal was discussed on the openssh-devel list.
If was clearly an accident caused by trying to do the right thing.
And a miscommunication, it seems that the OpenSSL developers the patch was just used for debugging purposes, while the Debian packages understood it as a confirmation that the patch was ok.
Errors do happen, even to the brightest of all developers. Though, most bugs do not have such far-reaching consequences. The best thing is to learn from it, and to move on.
Take care, Daniel
On Sat, May 17, 2008 at 7:57 PM, Karanbir Singh mail-lists@karan.org wrote:
Daniel de Kok wrote:
- What does our upstream think about this?
- What do the OpenSSH developers think about this?
Someone is going to need to ask those questions of the people...
I don't think either Red Hat or OpenSSH are going to do much with this. From what I have been told the search for bad ssh items if used inside of SSH slows down connections quite a bit because it does a search through the 1.5 MB space everything you connect. However, that could have been fixed with a quicker search algorithm by now
-- Karanbir Singh : http://www.karan.org/ : 2522219@icq _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Sun, May 18, 2008 at 7:55 PM, Stephen John Smoogen smooge@gmail.com wrote:
I don't think either Red Hat or OpenSSH are going to do much with this. From what I have been told the search for bad ssh items if used inside of SSH slows down connections quite a bit because it does a search through the 1.5 MB space everything you connect. However, that could have been fixed with a quicker search algorithm by now
It uses binary search, so O(log n). Should be fast enough...
-- Daniel
-
Chris Butler -
Daniel de Kok -
Johnny Hughes -
Karanbir Singh -
Les Mikesell -
Ralph Angenendt -
Stephen John Smoogen