[cap-talk] [Off-topic] SSL/TLS problems (was: Why petnames should not be used for password hashes.)

[Jed at Webstart]

At 08:44 AM 8/20/2005, David Hopwood wrote:
>Ian G wrote:
>>Many installations have to suffer the indignity
>>of one IP number, and this effectively
>>limits them to one Apache TLS server.   The long
>>and the short of this is that you have to pick
>>the favourite to get the secure web server, which
>>is a real dampener on the growth of your activity.
>>In practice, the flaw here is the deliberate
>>discrimination of "TLS for commercial purposes"
>>which has resulted in most of the web being
>>insecured and led inevitably to phishing due
>>to poor and infrequent use of TLS for security
>>purposes.
>
>I agree completely.

Even where arbitrary numbers of IP addresses are
available for virtual hosts, the cost of setting up
all the mappings between hosts and IP addresses
is still significant enough to put a damper on
using the number of virtual host that would otherwise
be appropriate for SSL communication.  I set up such
a mechanism for a modest 9-10 virtual hosts about
a year ago and I'm still paying the price of supporting
the baggage (special network init for the alias IPs,
Web server config for same, etc.).

However, with regard to:

>>Under TLS there is an ability to hint which domain
>>you require, but this feature is not implemented
>>in enough places to make it work as yet.
>
>As it happens, I'm a co-author of the relevant RFC
>(<http://www.rfc-editor.org/rfc/rfc3546.txt> section 3.1). I agree
>that it isn't implemented in enough places yet.

I've got a bit of a bone to pick.  This may be even more off
topic, so perhaps David can point me elsewhere to follow up.

The bone is that it also seems to me desirable to eliminate
the costly mechanisms for supporting multiple certificates
for the multiple SSL virtual hosts on a single physical
host (and IP).  In the case of such multiple named virtual
hosts using SSL over a single IP address, what is to be
gained by requiring them all to have distinct certificates?
Its the same software acting within the same authentication
space that is picking up the communication, regardless of
which virtual host configuration it happens to get directed to.

If the certificate could be tied to the IP address or even
the A record for a DNS name with multiple Cnames allowed
(for all the virtual hosts), that would eliminate yet another level
of overhead that adds cost but no value as far as I can see.
I don't see this last aspect of eliminating the special SSL
costs for virtual hosts addressed in the above RFC.  Please
let me know if I missed it and it is there.

I feel I'm acting in a relatively benign environment in that
we at least have no $ cost for certificates and relatively low
overhead for generation and renewal, but the administration cost
(e.g. generation of the certificate requests, approval,
installation of the new certificates and private keys, etc.)
are still significant enough to make some otherwise
appropriate sorts of configurations more costly than
can be justified.

Any chance of going that last step to make such SSL virtual
hosts (e.g. required in most environments for authenticated
communication) as easy to configure as non-SSL hosts,
namely just a server configuration parameter?

--Jed http://www.webstart.com/jed/