Rob Church wrote:
On 23/01/07, Brion Vibber <brion(a)pobox.com>
wrote:
There was some muttering at the time that just
using HTTPS is safer and
it's not worth the bother. Agreement? Disagreement?
What infrastructure changes would it require for us to start migrating
to HTTPS, at least during the login process?
Rob Church
You will need one IP address per HTTPS server name, since you cannot
virtual-host HTTPS: however, there's nothing to stop a single machine
from having as many IP addresses as desired, and thus as many HTTPS
servers as desired. This also means that load-balance cannot "look into"
the encrypted HTTPS connection to see where to send the traffic to: it
will have to go by the destination IP address. However, HTTPS can still
be load-balanced, you just need a different external IP address for each
visible service, and one internal IP address for each HTTPS service on
each server within the load-balancing cloud.
A lot of this could, of course, be made much simpler if you only had a
single HTTPS server URL for login in each project, such as
https://login.wikipedia.org/ -- this would fit rather well with the
unified login idea.
The servers would need to have their certificates signed by a well-known
CA, or browsers will complain (as, for example, occurs with
https://wikitech.leuksman.com). Ideally, images, style sheets and other
media within the login pages should also be served over HTTPS, ideally
from the same server, or some browsers will complain.
HTTPs has a small but significant per-session overhead to perform the
initial authentication and key exchange (but not per-hit, since the
authentication information can be cached between multiple connections
within the same session.) There is also a small extra overhead for all
data passed over the encrypted connection, which has to be
compressed/decompressed and encrypted/decrypted on the fly as necessary;
however, this last is going to be pretty unimportant if all you use it
for is to serve login pages.
-- Neil