Rob Church wrote:
On 23/01/07, Brion Vibber brion@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