4 ms·

The author lists 5 problems, but all of them have to do with the fact that the website in question is not 100% HTTPS. So it's really just one problem that has m

by kijin 14y ago

The author lists 5 problems, but all of them have to do with the fact that the website in question is not 100% HTTPS. So it's really just one problem that has many different implications. When you maintain both an HTTP site and an HTTPS site, it's nearly impossible to toss state back and forth between them without exposing yourself to at least one of these problems. Even if you do everything perfectly, people will complain that they get logged out when they visit HTTP URLs. The only solution is to treat HTTP, from now on, as if the only response it could produce were: HTTP/1.1 301 Moved Permanently Location: https://www.example.com/remainder/of/url That's it. If you handle personal information, never send "200 OK" responses over plain HTTP, ever. Need more server resources? Maybe. And this is probably why 99% of websites that have the problem the author mentions resist making changes. But the "HTTPS uses more server resources!" complaint is so 20th-century it's not even funny anymore. If you're not going to invest in 10% more server resources (or 5%, or 25%, or whatever) to protect your users' personal information, I seriously doubt that you deserve anyone's business in the first place.

lucb1e 14y ago
> all of them have to do with the fact that the website in question is not 100% HTTPS Problem number 4 is actually also relevant for HTTPS-only websites. That is, if the website doesn't use HSTS, and most don't. Also a 301 only works for one page. Consider this: You go to example.com (typed in address bar), it redirects you to https://example.com https://example.com via a 301, then you load your favorite news website, I inject an iframe in the news website that loads http://example.com/pwnd http://example.com/pwnd, and the browser happily sends the cookie (if it wasn't set to secure-only). The HSTS header is what you need to do, not only a 301.
- kijin 14y ago
  > Problem number 4 is actually also relevant for HTTPS-only websites. You're right, but I was thinking along the lines of: The reason why they don't set secure cookies is probably because they want to share state between their HTTP site and their HTTPS site. > Also a 301 only works for one page. You can make it work on every page. Even the query string will remain intact. POST requests are more complicated, but they are usually triggered by forms and JS on your own pages, so you have more control over that. RewriteEngine on RewriteCond %{HTTPS} !on Rewrite (.*) https://www.example.com/$1 [L] Of course, this doesn't solve the insecure cookie problem. But again, I'm assuming that not being HTTPS-only is the root of all evils.
  - lucb1e 14y ago
    Of course you can activate the 301 on all pages, I actually assumed that, but it was about the cookie that can be stolen via problem #4.
  - ivanr 14y ago
    By the way, you will probably want to apply [B] to that rewrite rule. In order for mod_rewrite to do its thing, it has to URL-decode the path, which means that you will get decoded data in the $1 capture. In some cases, the resulting URL (after mod_rewrite) may end up being corrupted -- for example if there's a URL-encoded slash or question mark. The [B] flag tells mod_rewrite to URL-encode backreferences. The process is not guaranteed to end up with the same URL, but with [B] it is at least a bit safer.
brey 14y ago
> Need more server resources? Maybe. AWS does this for (almost) free - load balancing includes optional SSL termination. really simple to set up, all HTTPS traffic just forwards to port 80 on your instance.
nodata 14y ago
No, please don't do this: If a visitor goes to http://domain/some/url http://domain/some/url they should not redirect to https://domain/some/url https://domain/some/url - it makes it harder to catch pages that use the wrong protocol. Better to redirect http://domain/some/url http://domain/some/url to https://domain https://domain Edit: if you're logging referrers from your own domain with non https:// https:// urls AND using secure cookies, ignore my comment!
- trust-me 14y ago
  Nooo, don't erase the address that took me 5 minutes to type. What you say doesn't make any sense. You should obviously configure the https redirect as a site wide setting and not per page.
  - ivanr 14y ago
    That's clearly true from the usability perspective. However, the problem is that bulk redirections like that make it very difficult to catch insecure resources. For example, let's suppose you have a secure page that's referencing some JavaScript resource via a plain-text connection. Because of the redirection, the browser will ultimately fetch the required file, but only trying plain-text HTTP first. That one plain-text request can be hijacked by a man-in-the-middle attacker and abused to take over the victim's browser (and account). Further, if your users have bookmarks to plain-text pages, their first access to your web site is always going to be insecure, which means that they can be attacked via sslstrip. These problems are solved with Strict Transport Security, but it will probably take some time until we can fully rely on it. In the meantime, the plain-text URL can be preserved, and the redirection carried out via an intermediary page that explains why links to plain-text pages are dangerous. It's ugly, but I don't think there's a better (safer) way.
    - trust-me 14y ago
      Yes, these are real problems, but how is redirecting to the home page helping in any way? When the user navigates back to the page she wanted the in-secure script will still be fetched. A MITM is still able to serve a copy of your page.

by kijin 14y ago

lucb1e 14y ago

> all of them have to do with the fact that the website in question is not 100% HTTPS Problem number 4 is actually also relevant for HTTPS-only websites. That is, if the website doesn't use HSTS, and most don't. Also a 301 only works for one page. Consider this: You go to example.com (typed in address bar), it redirects you to https://example.com https://example.com via a 301, then you load your favorite news website, I inject an iframe in the news website that loads http://example.com/pwnd http://example.com/pwnd, and the browser happily sends the cookie (if it wasn't set to secure-only). The HSTS header is what you need to do, not only a 301.

kijin 14y ago
> Problem number 4 is actually also relevant for HTTPS-only websites. You're right, but I was thinking along the lines of: The reason why they don't set secure cookies is probably because they want to share state between their HTTP site and their HTTPS site. > Also a 301 only works for one page. You can make it work on every page. Even the query string will remain intact. POST requests are more complicated, but they are usually triggered by forms and JS on your own pages, so you have more control over that. RewriteEngine on RewriteCond %{HTTPS} !on Rewrite (.*) https://www.example.com/$1 [L] Of course, this doesn't solve the insecure cookie problem. But again, I'm assuming that not being HTTPS-only is the root of all evils.
- lucb1e 14y ago
  Of course you can activate the 301 on all pages, I actually assumed that, but it was about the cookie that can be stolen via problem #4.
- ivanr 14y ago
  By the way, you will probably want to apply [B] to that rewrite rule. In order for mod_rewrite to do its thing, it has to URL-decode the path, which means that you will get decoded data in the $1 capture. In some cases, the resulting URL (after mod_rewrite) may end up being corrupted -- for example if there's a URL-encoded slash or question mark. The [B] flag tells mod_rewrite to URL-encode backreferences. The process is not guaranteed to end up with the same URL, but with [B] it is at least a bit safer.

brey 14y ago

> Need more server resources? Maybe. AWS does this for (almost) free - load balancing includes optional SSL termination. really simple to set up, all HTTPS traffic just forwards to port 80 on your instance.

nodata 14y ago

No, please don't do this: If a visitor goes to http://domain/some/url http://domain/some/url they should not redirect to https://domain/some/url https://domain/some/url - it makes it harder to catch pages that use the wrong protocol. Better to redirect http://domain/some/url http://domain/some/url to https://domain https://domain Edit: if you're logging referrers from your own domain with non https:// https:// urls AND using secure cookies, ignore my comment!

trust-me 14y ago
Nooo, don't erase the address that took me 5 minutes to type. What you say doesn't make any sense. You should obviously configure the https redirect as a site wide setting and not per page.
- ivanr 14y ago
  That's clearly true from the usability perspective. However, the problem is that bulk redirections like that make it very difficult to catch insecure resources. For example, let's suppose you have a secure page that's referencing some JavaScript resource via a plain-text connection. Because of the redirection, the browser will ultimately fetch the required file, but only trying plain-text HTTP first. That one plain-text request can be hijacked by a man-in-the-middle attacker and abused to take over the victim's browser (and account). Further, if your users have bookmarks to plain-text pages, their first access to your web site is always going to be insecure, which means that they can be attacked via sslstrip. These problems are solved with Strict Transport Security, but it will probably take some time until we can fully rely on it. In the meantime, the plain-text URL can be preserved, and the redirection carried out via an intermediary page that explains why links to plain-text pages are dangerous. It's ugly, but I don't think there's a better (safer) way.
  - trust-me 14y ago
    Yes, these are real problems, but how is redirecting to the home page helping in any way? When the user navigates back to the page she wanted the in-secure script will still be fetched. A MITM is still able to serve a copy of your page.