[Dspace-general] DSpace repositories and self-signed certificates

Larry Stone lcs at MIT.EDU
Fri Mar 9 20:44:21 EST 2007


> > I'm also wondering if presenting so-called untrusted site messages to
> > patrons will make the repositories seem less trustworthy. I'm concerned
> > here with the interaction experience of the users and patrons.
>
> Most users should understand self-signed certs, and if the cert
> name/address match the URL it shouldn't matter.  The sad fact is that
> SSL certs from well known CAs are nothing more than a protection
> "monopoly" that the industry (browser and CA industry) has supported
> through misinformation.  Anyone can pay a CA to get a certificate, yet
> they don't provide any real protection to the end user.  A self-signed
> cert is probably more secure than a cert from the big CAs since you
> control how secure the cert actually is and its valid lifetime.

Actually, since the purpose of a server certificate is to confirm
that the server machine is a bona fide representative of the organization
it names.  It may be more obvious in a commercial application, where you
want to be sure that the site you're giving your credit card number to
is truly Amazon.com and not some imposter -- your browser does this by
checking the signature on amazon.com's server cert against the public key
it already has for the CA that created that cert.  So, it's true you're
implicitly trusting your browser and the organization that runs the CA that
created Amazon's server cert, and most users have no idea what that means.

Some CA's now offer "premium" certificates where they supposedly check up
on the veracity of the requestor more carefully, but you're right,
it's mostly a sleazy protection racket.

So, a self-signed cert is no use at all to identify the server,
but it's just as effective at encrypting the connection.  Don't count on
users to understand this distinction, unfortunately..

Mark Diggory has a clever configuration setup on our DSpace at MIT IR that
allows it to run under unencrypted HTTP and just redirect to HTTPS for
the login page where you enter a password, and then go back to HTTP.
The only risk of this technique is that your authentication cookie
gets sent in cleartext, but as of DSpace 1.4 it is protected against
cookie-sniffing attacks.

    -- Larry





More information about the Dspace-general mailing list