Version Control with Subversion - Login

Server ConfigurationOne word of warning: HTTP Basic Auth passwords pass in very nearly plain text over thenetwork, and thus are extremely insecure.Another option is to not use Basic authentication, but to use Digest authentication instead.Digest authentication allows the server to verify the client's identity without passing theplain-text password over the network. Assuming that the client and server both know theuser's password, they can verify that the password is the same by using it to apply a hashingfunction to a one-time bit of information. The server sends a small random-ish string tothe client; the client uses the user's password to hash the string; the server then looks tosee whether the hashed value is what it expected.Configuring Apache for Digest authentication is also fairly easy, and only a small variationon our prior example. Be sure to consult Apache's documentation for full details.DAV svnSVNParentPath /var/svnAuthType DigestAuthName "Subversion repository"AuthDigestDomain /svn/AuthUserFile /etc/svn-auth-fileRequire valid-userIf you're looking for maximum security, public key cryptography is the best solution. It maybe best to use some sort of SSL encryption, so that clients authenticate via https:// insteadof http://; at a bare minimum, you can configure Apache to use a self-signedserver certificate. 5 Consult Apache's documentation (and OpenSSL documentation) abouthow to do that.SSL certificate managementBusinesses that need to expose their repositories for access outside the company firewallshould be conscious of the possibility that unauthorized parties could be “sniffing” their networktraffic. SSL makes that kind of unwanted attention less likely to result in sensitive dataleaks.If a Subversion client is compiled to use OpenSSL, it gains the ability to speak to anApache server via https:// URLs. The Neon library used by the Subversion client is notonly able to verify server certificates, but can also supply client certificates when challenged.When the client and server have exchanged SSL certificates and successfully authenticatedone another, all further communication is encrypted via a session key.It's beyond the scope of this book to describe how to generate client and server certificatesand how to configure Apache to use them. Many other books, including Apache's own documentation,describe this task. But what we can cover here is how to manage server andclient certificates from an ordinary Subversion client.When speaking to Apache via https://, a Subversion client can receive two differenttypes of information:• A server certificate• A demand for a client certificateIf the client receives a server certificate, it needs to verify that it trusts the certificate: is the5 While self-signed server certificates are still vulnerable to a “man-in-the-middle” attack, such an attack is muchmore difficult for a casual observer to pull off, compared to sniffing unprotected passwords.174