In the first blogpost of this series, I’ve shown you how easy it is for an attacker to eavesdrop the SSL/TLS connection between you and your client. This is not a theoretical issue and happens to customers every day. Even strong ciphers and encryption settings don’t help. Why? The problem is trust: If your client trusts any server, it doesn’t matter which cyphers your server is using.
This post is the second in the “Your HTTPS Setup is Broken”-series. Previously, I’ve described how easy it is for an attacker to eavesdrop on your “secure” communication. In this post I’ll show you how to enforce encrypted communication, so an attacker cannot downgrade the connection to unencrypted HTTP.
In this post I’m going to describe an issue we experienced with nginx and its handling of Server Side Includes (SSIs). We saw that nginx at first decodes the SSI URI path and afterwards encodes it when loading the resource. And in some cases, the URI path encoded by nginx was different than the original one. The solution is easy (use query parameters if in doubt), but I thought I’d share this so that others maybe don’t run into this issue and/or see how to debug such things.