4 ms·

What's the threat model for serving a read-only, public, marketing site over http? Or is it just a general principle?

by ctdean 9y ago

adrianN 9y ago
Users are for example protected from ISP injecting ads or tracking in the website.
harshreality 9y ago
That website is not a read-only, public marketing site. It contains their order page, which asks for personal information: https://www.rsync.net/signup/order.html https://www.rsync.net/signup/order.html Their unencrypted pricing page links to that encrypted order form page. We all agree there should be no http to http transitions like that, right? If you'll note, that encrypted order page is on the same host as their unencrypted pages. Both rsync.net and www.rsync.net covered by the cert. They have SSL set up already, and they just purposely redirect away to http for their static pages. That is a well-known ssl antipattern.
- brazzledazzle 9y ago
  When you say "on the same host" do you mean "have the same DNS name" or do you mean literally on the same server? It's possible it's just behind the same load balancer so I'm curious what the threat model that you're concerned about is specifically. To be clear: I don't like transitions like that either but that concern is something I've only previously had with sites that do e-commerce or login portal that's not on a different (sub)domain. Apple and some banking sites are notable examples that used to concern me (though I doubt they are still like that).
  - deleted 9y ago
    [deleted]
  - mvkg 9y ago
    The threat for http to https transactions is that man in the middle can rewrite, drop, or add data before the user reaches the https site. See sslstrip[0] for an example of this attack. [0] https://moxie.org/software/sslstrip/ https://moxie.org/software/sslstrip/
  - brians 9y ago
    That load balancer is a server. It has the TLS key, and so is authoritative for be content of the site. The model of “surrogate origin server” is sometimes more helpful than “middlebox” and similar.
dawnerd 9y ago
It’s a sign that security isn’t their first priority. It’s almost 0 effort to put ssl on an entire site. Pretty much no reason not to.
- rsync 9y ago
  The actual answer is probably going to surprise you ... The reason that the vast majority of rsync.net is not covered by https is because I personally have not yet decided how I feel, philosophically, about the notion of https-only websites. As silly as it may sound to you, I very much like the fact that you can read rsync.net HOWTO pages with netcat. Or telnet'ing to port 80. Or grab them with old versions of 'fetch'. I used to do all kinds of interesting and time-saving tasks on the pre-https internet with simple, static UNIX tools. As you can imagine, almost all of those workflows are now either broken or require a big huge pile of python libraries. So in summary, I am sorry to deprive you of your righteous indignation. You can see from our properly implemented order form that we understand https just fine, thank you. The real answer is that https-everywhere sounds like it's probably a good idea ... but also sounds like you should maybe get off of my lawn ... but I'm not sure yet.
  - Pyxl101 9y ago
    If you want to support HTTP too, that's fine. But why redirect people who use HTTPS URLs back to the HTTP page? In any case, modern software toolchains have no trouble with HTTPS. I can interact with it from the command line pretty easily with `wget` or `curl` and similar.
  - Walkman 9y ago
    Man, you don't even understand basic security practices. When going from a HTTP page to a HTTPS page, what guarantees can you give that I see the original content and clicked the proper link and that I was not MITM-ed? A potential attacker can MITM and easily redirect me to any order page they want... This is security 101.
    - rsync 9y ago
      I understand the attack you've outlined just fine. What you don't understand is that people that don't notice being redirected to a different domain are not smart enough to be using rsync.net in the first place. So it's not an issue. Or, I should say, in the fifteen years that we have been providing "cloud storage"[1] it hasn't been an issue. [1] It wasn't called "cloud storage" back then - our service predates the term.

What's the threat model for serving a read-only, public, marketing site over http? Or is it just a general principle?

by ctdean 9y ago

What's the threat model for serving a read-only, public, marketing site over http? Or is it just a general principle?

adrianN 9y ago

Users are for example protected from ISP injecting ads or tracking in the website.

harshreality 9y ago

That website is not a read-only, public marketing site. It contains their order page, which asks for personal information: https://www.rsync.net/signup/order.html https://www.rsync.net/signup/order.html Their unencrypted pricing page links to that encrypted order form page. We all agree there should be no http to http transitions like that, right? If you'll note, that encrypted order page is on the same host as their unencrypted pages. Both rsync.net and www.rsync.net covered by the cert. They have SSL set up already, and they just purposely redirect away to http for their static pages. That is a well-known ssl antipattern.

brazzledazzle 9y ago
When you say "on the same host" do you mean "have the same DNS name" or do you mean literally on the same server? It's possible it's just behind the same load balancer so I'm curious what the threat model that you're concerned about is specifically. To be clear: I don't like transitions like that either but that concern is something I've only previously had with sites that do e-commerce or login portal that's not on a different (sub)domain. Apple and some banking sites are notable examples that used to concern me (though I doubt they are still like that).
- deleted 9y ago
  [deleted]
- mvkg 9y ago
  The threat for http to https transactions is that man in the middle can rewrite, drop, or add data before the user reaches the https site. See sslstrip[0] for an example of this attack. [0] https://moxie.org/software/sslstrip/ https://moxie.org/software/sslstrip/
- brians 9y ago
  That load balancer is a server. It has the TLS key, and so is authoritative for be content of the site. The model of “surrogate origin server” is sometimes more helpful than “middlebox” and similar.

dawnerd 9y ago

It’s a sign that security isn’t their first priority. It’s almost 0 effort to put ssl on an entire site. Pretty much no reason not to.

rsync 9y ago
The actual answer is probably going to surprise you ... The reason that the vast majority of rsync.net is not covered by https is because I personally have not yet decided how I feel, philosophically, about the notion of https-only websites. As silly as it may sound to you, I very much like the fact that you can read rsync.net HOWTO pages with netcat. Or telnet'ing to port 80. Or grab them with old versions of 'fetch'. I used to do all kinds of interesting and time-saving tasks on the pre-https internet with simple, static UNIX tools. As you can imagine, almost all of those workflows are now either broken or require a big huge pile of python libraries. So in summary, I am sorry to deprive you of your righteous indignation. You can see from our properly implemented order form that we understand https just fine, thank you. The real answer is that https-everywhere sounds like it's probably a good idea ... but also sounds like you should maybe get off of my lawn ... but I'm not sure yet.
- Pyxl101 9y ago
  If you want to support HTTP too, that's fine. But why redirect people who use HTTPS URLs back to the HTTP page? In any case, modern software toolchains have no trouble with HTTPS. I can interact with it from the command line pretty easily with `wget` or `curl` and similar.
- Walkman 9y ago
  Man, you don't even understand basic security practices. When going from a HTTP page to a HTTPS page, what guarantees can you give that I see the original content and clicked the proper link and that I was not MITM-ed? A potential attacker can MITM and easily redirect me to any order page they want... This is security 101.
  - rsync 9y ago
    I understand the attack you've outlined just fine. What you don't understand is that people that don't notice being redirected to a different domain are not smart enough to be using rsync.net in the first place. So it's not an issue. Or, I should say, in the fifteen years that we have been providing "cloud storage"[1] it hasn't been an issue. [1] It wasn't called "cloud storage" back then - our service predates the term.