Bug #185
closed
replication security hole
Added by Matt Jones about 23 years ago.
Updated about 22 years ago.
Description
Need to fix security hole in Metacat replication feature where host name can be
spoofed, allowing complete access to the server's data.
This bug arises because the client metacat provides the hostname in the
parameter data during replication, and the server metacat "trusts" (unwisely)
that the client is telling the truth. Chad has a potential solution outlined
which basically involves setting this up over an SSL connection, so that each
metacat server is identified by a cryptographic host key. This of course
requires SSL operation, which Jivka has at least partially implemented. See bug
235 for details of the ssl implementation.
Owen -- don't know if you noticed -- I reassigned this important security bug to
you. Think you'll be able to take a look at it? If so, please accept it,
otherwise I'll have to reassign it again.
Added support for running replication over HTTPS.
Removed the check of IP address using the DNS because it doesn't provide enough
security because of possible IP spoofing.
In order to configure 2 Metacat servers to replicate over HTTPS (no matter of
one-way or two-way replication):
1. Included interface in replControl.html to exchange certificate files by
adding additional input box that should specify the source location of cert
file. This should be done on "Add This Server" action.
2. Preliminary both Metacat servers should export their certificates in a file
on their own file systems and both should download each other's certificate
files using relpControl.html page. Then both should import the downloaded files
on their side as trusted certificates.
DONE
The problem is described in Metacat Installation Instructions in
knb.ecoinformatics.org web site
Original Bugzilla ID was 185
Also available in: Atom
PDF