How HTTPS Stops Attackers: What Every Web Dev Should Know

Good read about HTTPS, but very bad title. HTTPS does NOT stop attackers. It does stop data sniffing on wirelress network, but does not prevent any server-side attack (XSS, SQL Injection, an flaw in the web application).

Ah good point, I sorta dashed off the title at the last minute. But the main focus of the article (and the whole point of HTTPS) is to make a secure end-to-end connection between a client and a server, not stop all attack vectors on a web server.

What about proxied MITM attacks using a valid CA certificate for the proxy? And also, browsers are not the only HTTP clients out there. HTTPS I believe is a quite a mess as is cert validation and the CA Cert system in general. I view HTTPS as security-lite. I think we need something better.

This is pretty much what I was trying to see if we could do: proxy HTTPS requests to another site through our server. When proxies are involved with HTTPS, there are really two options:

1. The client sends a CONNECT request (instead of GET) which instructs the proxy to open up a secure tunnel with the remote server. In this situation, the proxy steps out of the way and simply shuffles bits back and forth, as if it were just another router between networks.

2. Setup a "Man in the Middle Proxy" which creates/signs certificates for each site on the fly. Basically, the client thinks the proxy is the server, and the server thinks the proxy is the client. The only way this works though, is if the browser is instructed to trust certificates signed by the MitM proxy. So this works fine if you're setting up a proxy on your local dev machine, for example. But not for proxying HTTPS requests to actual users.

Why don't they mention HSTS? Seriously a very important safeguard against HTTPS stripping.

Apart from that, my idea of what every web dev should know about HTTPS is use HTTPS for everything. The performance reduction is minimal and far less important than the security gain...