|
On Wed, Jul 30, 2003 at 10:11:20AM +1000, James Bourne wrote:
> It is possible. I made sure that the SSL certificate was available to each
> real server/virtual host via an NFS mount. I use a single centralised
> httpd.conf file across all real servers. For example:
>
> <VirtualHost <VIP>:443>
> SSLEngine On
> ServerName servername:443
>
> DocumentRoot "/net/content/httpd/vhostname"
> ServerAdmin email@xxxxxxxxxx
> ErrorLog /net/logs/httpd/vhostname/ssl_error_log
> TransferLog /net/logs/httpd/vhostname/ssl_access_log
> CustomLog /net/logs/httpd/vhostname/ssl_request_log "%t
> %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
> SSLCertificateFile /net/conf/httpd/certs/vhostname.crt
> SSLCertificateKeyFile /net/conf/httpd/certs/vhostname.key
> SSLCipherSuite
> ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
>
> <Directory />
> Options None
> AllowOverride None
> Order Allow,Deny
> Allow from a.b.c.d/255.255.255.0 a.b.c.d/255.255.255.0
> </Directory>
>
> </VirtualHost>
>
> /net/logs, /net/conf and /net/content are all NFS mount points.
>
> The downside is that unless you have real signed certificates from Thawte etc.
> your browser may want to confirm the legitimacy of the certificate presented
> each time it hits a new real server. This depends on the load balancing method
> used.
>
> Hence why the use of persistence is good with https.
The other reason that persistance is a good idea relates to session
resumption. This allows subsequent connections to be set up much
faster if an end-user connects to the same real server. Some Layer 4
Switching implementations allow persistance bassed on session Id for
this reason. LVS doesn't do this. And it is a bit hard to put into
the current code (when I say a bit, I mean more or less impossible).
For those who are interested, this is how Session IDs are used.
An basic SSL/TLS connection has two main phases, the handshake phase
and the data transfer phase. Typically the handshake occurs at the
begining of the connection and once it has finished data transfer
takes place. The handshake uses asymetric (public key) cryptography,
typically RSA, while the data transfer uses symetric cryptography,
typially something like DES3. When the sesssion begins the
public keys are generated. They are then used to securly transfer
the keys that are generated for use with the symetric cryptography
that is used for the data transfer.
In a Nutshell the idea is
to use slow asymetric cryptography to share the keys required
for fast symetric cryptography which is used to transfer the data.
Unfortunately the handshake itself is quite slow. Especially for
many short connections - as the handshake usually only occurs once
its persentage of time for a connection diminishes the longer
the connection lasts.
To avoid this problem SessionIDs may be used. This alows an end-user
and real-server to identify each other using the SessionID that was
issued by the real-server in a previous session. When this occurs
an abreviated handhake is used which avoids the more expensive
parts of the handshake. Thus making things faster.
Note that using different real-servers will not cause connections
that try to use Session IDs to fail. They will just use the slower
version of the handshake.
--
Horms
|
