On Tue, Nov 20, 2012 at 7:32 PM, Ryan Schmidt
<subversion-2012c_at_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".
Received on 2012-11-22 20:29:55 CET