I've been thinking a lot about password security these days, and have been becoming more and more hesitant to use services that have login forms that are not on HTTPS. As I was researching security, I played around with Cain & Abel on my local network to see how easy it really would be to run a man-in-the-middle attack on sites that don't use HTTPS. Unfortunately, it's pretty dang easy.

So I've been trying to think up ways to get around this. It's unrealistic to expect myself - and certainly the rest of the security-ignorant world - to simply stop using services that don't use HTTPS. There's too many of them that don't.

The plan that I'm most interested in right now utilizes a proxy system on an EC2 instance to do logins remotely, and then pass back the secured session/cookies. Essentially, the flow would look like this:

  1. User send username/password and domain cookies over SSL to an EC2 instance.
  2. EC2 instance uses cookies to imitate the user's session, and submits a login request.
  3. EC2 instance returns any new cookies to the user, as well as any redirects that may have been requested by the login server
  4. User sets cookies per the EC2 response, and either refreshes (if no redirects), or redirects to the specified URL.

The security here relies on the fact that EC2 instances are distributed and anonymous, making them fairly secure against man-in-the-middle attacks. Certainly there is still a possibility, but in my mind this vastly decreases the risks of sending passwords to non-SSL sites.

Are there any security holes here that I'm not seeing? Is there a real security benefit from doing logins this way?

1 Answer 1


I find rather dubious the idea that EC2 instances being "distributed and anonymous" makes them "fairly secure against man-in-the-middle attacks". This may make the task harder for your arch-enemy who is after you specifically, but it won't make much of a difference against an attacker who just want to harvest passwords in a quite impersonal way.

The only tangible benefit I see is that it would strengthen your near-field link -- typically, against some bad guy using the same Wireless hotspot than you. However, it would be both simpler and more thorough to use your external system (the EC2 nodes) as a generic proxy for all your Web traffic: this is very simple to do with ssh (setup a SOCKS proxy with ssh -D, and configure your browser to use it; PuTTY can also do it). You could also install an HTTP proxy which you contact through HTTPS. Or, even more thorough, tunnel all your traffic through a VPN (see OpenVPN).

Such proxying will not protect you against wide-scale attacks (e.g. MitM enacted through DNS poisoning) but it will give you some protection against low-powered stalkers who perform their villainous felonies only locally. At least it won't harm.

(And Amazon will quite like your scheme, too.)

  • Agreed - there's nothing I could do to avoid a MITM on amazon's servers. However, the vast majority of Amazon servers aren't used for this sort of proxying, so I think there would be a low risk of targeting. The end-goal would be a widely distributed service, so I don't think 100% proxying of all web traffic is doable - it's just too slow. I know that the only real security in this situation would be for the service to SSL, but I'm looking for a next-best-thing here.
    – jwegner
    Commented Oct 16, 2012 at 15:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .