On Tue, Nov 20, 2012 at 7:32 PM, Ryan Schmidt <subversion-20...@ryandesign.com> wrote: > On Nov 19, 2012, at 06:33, Nico Kadel-Garcia wrote: > >> Note that hostname based virtual hosts are one of the irksome >> poltergeists of secure computing. The big part of the problem is that >> SSL keys are tied to IP addresses, and you can't use different keys >> for different virtual hosts on the same IP address. > > Yes you can. > > http://en.wikipedia.org/wiki/Server_Name_Indication
Good point, but it requires working SNI. To quote the Wikipedia article you cite: > As of November 2012, the only major user base whose browsers do not support > SNI appear to be users of Windows XP. Unfortunately, there are one heck of a lot of "minor user bases". I have to support some of them, such as RHEL 4 users. (Don't get me started on the difficulties of supporting them: there's a reason I'be been publishing backports of Subverison 1.6.x and Subverison 1.7.x for them.) >> The other problem >> is that for most configurations, you wind up having to use the fully >> qualified hostname for all URL's, > > As opposed to what? As opposed to valid CNAME's or local hostnames with domains automatically added. For example, for my Subversion "svn.example.com", I might be able to use "svn" inside my local domain, or add a CNAME and have "www.svn.example.com", and with the local domain set in the DNS search order, I can also use ""www.svn", "svn", or valid values for any other valid CNAME's or /etc/hosts activated hostnames. But there is *no way* for the web server to know all the DNS valid but unpredictable hostnames that a client might use, and this can present fascinating problems for an SVN repository that hosts multiple projects with multiple hostnames. You wind up having to set up multiple virtual hosts, or set up "ServerAlias" entries in the apache or httpd configurations. This way lies maintenance madness. Instead, using a separate, virtual IP address allows the *reliable* use of distinct SSL keys, and you can avoid the "ServerName" and "ServerAlias" issues. It's also easier to configure when hosts have multiple ServerAlias entries that may inadvertently overlap each other. >> and can't use the IP address or >> aliases for the same site unless you *manually* set them all up as >> ServerAlias options. > > Sure; don't try to use bare IP addresses in URLs. That's why DNS was invented. In general, use. But I went through an issue 2 weeks ago where I had to access an internal source control repository while I had a Cisco VPN active to an external site that forced use of their DNS servers, which had no access to my internal DNS. And the external DNS IP addresses cause...... confusion about the service access unless your setup is very robust. (I've had real firewall configurations with this sort of issue.) >> If feasible: get a separate IP address for the separate service, set >> it up as a virtual IP address, and set up a different IP based virtual >> host to separate out the functions of bugzilla and Subversion. > > IPv4 addresses are scarce; we shouldn't encourage wasting them. > > http://en.wikipedia.org/wiki/IPv4_address_exhaustion Neglecting IPv6 (which is still far from reliable tdue to poor deployment) his is why NAT has become so popular. Internal, unroutable addresses such as 10.* addresses are easily available, and help provide additional security for your externally exposed services. Getting more externally exposed IP addresses is a real cost, and can involve uncomfortable negotiations with an IT department that doesn't see the need for you to expose services directly. That's why I said "if feasible".
