With SSH, things are done like this:
- on the laptop, run
ssh -N -D 5000 proxy-machine (where
proxy-machine is the DNS name of the "Web Proxy" machine);
- configure the browser to use the SOCKS protocol on
localhost and port 5000.
This is convenient, and activated in much less than 20 minutes. It has, however, the following consequences:
- The laptop user must run the
ssh command and keep it running as long as he wishes to browse the Internet through the proxy.
ssh command must be installed on the laptop (it is standard issue with MacOS X, Linux and all the Unix-like systems, but not with Windows).
- The Web Proxy machine must run an SSH server.
- The laptop user must have an account on the Web Proxy machine (it is possible to restrict that account to the setting up of tunnels like the one above, but it is not easy to configure).
With SSL, you would have to install some proxy software on the Web Proxy (e.g. squid) and configure it with an X.509 certificate, so that clients (the laptop) use
https://proxy-machine:9000/ as proxy URL (the port number can be changed at will, I used 9000 as an example). There is no software to install on the laptop; the browser just has to be configured to use the right URL as an HTTP-level proxy. Be wary of proxy autoconfiguration scripts, they could be ways for the attacker to force another proxy configuration; you'd better configure the proxy manually.
SSL and SSH use distinct protections against Man-in-the-Middle attacks. The SSH client records the public key of the target machine (in the
$HOME/.ssh/known_hosts file on Unix-like systems) so that it may check that the server public key is the right one; only the first connection ever is vulnerable. SSH public keys have fingerprints (i.e. hash values) which can be used to check that a key is correct (the idea being that you can phone the sysadmin, and he will spell out the fingerprint; this is tedious but needs to be done only once per SSH server). Until the laptop or the proxy is compromised, or the cryptographic algorithms get thoroughly demolished by irate cryptanalysts, the SSH way is secure.
SSL relies on X.509 certificates. The security comes from the set of trust anchors (aka "root certificates") already embedded in the browser (or the operating system). The certification authorities are supposed to issue certificates only to duly authenticated entities, and the digital signatures are the cryptographic tools by which the browser may verify that certificate contents have not been tampered with, and only accepted certification authorities have been involved. To mount a MitM, an attacker would have to bribe a CA into issuing a fake certificate, with the name
proxy-machine, but with a public key owned by the attacker.
The X.509 security relies on a lot more assumptions than the SSH security, which is handled locally and where what happens is pretty simple. But the SSH scenario requires the laptop user to be a bit more aware of what is happening. For me, I would use SSH (indeed, that's what I do); for an organization with many users, I would follow the SSL path (but the "20 minutes" requirement would be a joke).