11 ms·

Basically, now Chrome sends the header HTTPS: 1 when issuing a request over HTTP to notify it "prefers" HTTPS. However, this header is (or was) used by several

by martius 11y ago

Basically, now Chrome sends the header HTTPS: 1 when issuing a request over HTTP to notify it "prefers" HTTPS. However, this header is (or was) used by several HTTP servers/proxies (including Apache, I believe) to notify the application that the client connection is established in HTTPS. Wordpress reacts to this header by generating https:// https:// URLs, which may not work if the server doesn't serve HTTPS with a properly configured certificate.

deleted 11y ago
[deleted]
michaelt 11y ago
Forgive my ignorance, but why would a browser need to say that it prefers https? Doesn't that go without saying nowerdays? Surely only the most obscure, ancient legacy systems would have problems with being redirected to https?
- ricogallo 11y ago
  Indeed, but you can see that a bunch of Wordpress sites are obscure, ancient and insecure by default.
  - martius 11y ago
    He's talking about a client not supporting HTTPS. A client may have reasons to prefer HTTP over HTTPS: perfs, plaintext for debug, etc. It's hard to assume that "HTTPS should be the default" in any circumstance. I'm not sure the wordpress sites are to blame here (for once): SSL isn't free to deploy (yet).
    - uxp 11y ago
      SSL is free to deploy: https://www.startssl.com?app=12 https://www.startssl.com?app=12 If you have a site that gets enough traffic that you need a better supported or more validated certificate, then I'm sure the $40/yr for a cheapass godaddy cert is worth the money.
      - martius 11y ago
        Assuming you have time and knowledge to do it. Assuming you own the domain or at least are able to access to its DNS records. Assuming you can use SNI (and all your visitors too) or have your own IPv4 address. Assuming $40 is free... No, even a free certificate doesn't mean that deploying ssl is free.
jrockway 11y ago
Shouldn't the frontend remove the header if it's something that it would normally add? It's a major problem if your application is expecting a header to be set by the frontend web server, but is actually getting the value from the user agent.
- martius 11y ago
  The issue here is that the frontend may be behind a reverse proxy, talking to the client in HTTPS but to the frontend in HTTP. In that case, the frontend should probably let the HTTPS header. In practice, with X-Forwarded-Proto, they don't, unless they can authenticate the downstream hop.
  - jrockway 11y ago
    I haven't done web development for a while, but here's how I imagine the frontend server should behave. Let's say you configure your frontend server to set X-Foo and X-Bar fields. First, it should always send a header to the application indicating that it's messing with X-Foo and X-Bar, say "X-Added-By-My-Webserver: X-Foo, X-Bar". That way, the application can be sure that the frontend server is properly configured. Next, it should strip any X-Foo, X-Bar, and X-Added-By-My-Webserver, to prevent the client from being able to confuse the application with information the application expects to receive from the server. This is still flaky because the frontend server could fail, and the user could send X-Added-By-My-Webserver, and so on, but if you must use in-band signalling, this seems like the safe route. Just blissfully adding a header is not enough to protect against evil or changing user agents. Furthermore, it seems like a bad idea to make up your own header and not use an X- prefix.
    - martius 11y ago
      Yes, it's a bad idea, but an awful lot of bad ideas were the common practice a long time ago, when vendors had to deal with limitations of the HTTP/1.0 and 1.1 RFCs. In fact, we aren't talking about application headers. The HTTP RFC makes a distinction between application headers and hop-by-hop headers. There are mechanisms that proxies are required to implement, but they still don't. For instance, a proxy must declare itself by appending its signature to a "Via" header - however most of them don't. The RFC about forwarded HTTP extension is unclear about how a hop should deal with those headers, there is no one-size-fit-all situations: http://tools.ietf.org/html/rfc7239#section-8.1 http://tools.ietf.org/html/rfc7239#section-8.1
jrochkind1 11y ago
Hm, shouldn't apache be ensuring that clients _can't_ set the flag that indicates "this is an HTTPS request"? Otherwise app code that's _checking_ the flag, to ensure that a sensitive URL is only being accessed via HTTPS can be spoofed by the client simply saying it's HTTPS when it's not. That doesn't seem right. If that's what's going on, it seems like a bug in apache, with security consequences. ?

by martius 11y ago

deleted 11y ago

[deleted]

michaelt 11y ago

Forgive my ignorance, but why would a browser need to say that it prefers https? Doesn't that go without saying nowerdays? Surely only the most obscure, ancient legacy systems would have problems with being redirected to https?

ricogallo 11y ago
Indeed, but you can see that a bunch of Wordpress sites are obscure, ancient and insecure by default.
- martius 11y ago
  He's talking about a client not supporting HTTPS. A client may have reasons to prefer HTTP over HTTPS: perfs, plaintext for debug, etc. It's hard to assume that "HTTPS should be the default" in any circumstance. I'm not sure the wordpress sites are to blame here (for once): SSL isn't free to deploy (yet).
  - uxp 11y ago
    SSL is free to deploy: https://www.startssl.com?app=12 https://www.startssl.com?app=12 If you have a site that gets enough traffic that you need a better supported or more validated certificate, then I'm sure the $40/yr for a cheapass godaddy cert is worth the money.
    - martius 11y ago
      Assuming you have time and knowledge to do it. Assuming you own the domain or at least are able to access to its DNS records. Assuming you can use SNI (and all your visitors too) or have your own IPv4 address. Assuming $40 is free... No, even a free certificate doesn't mean that deploying ssl is free.

jrockway 11y ago

Shouldn't the frontend remove the header if it's something that it would normally add? It's a major problem if your application is expecting a header to be set by the frontend web server, but is actually getting the value from the user agent.

martius 11y ago
The issue here is that the frontend may be behind a reverse proxy, talking to the client in HTTPS but to the frontend in HTTP. In that case, the frontend should probably let the HTTPS header. In practice, with X-Forwarded-Proto, they don't, unless they can authenticate the downstream hop.
- jrockway 11y ago
  I haven't done web development for a while, but here's how I imagine the frontend server should behave. Let's say you configure your frontend server to set X-Foo and X-Bar fields. First, it should always send a header to the application indicating that it's messing with X-Foo and X-Bar, say "X-Added-By-My-Webserver: X-Foo, X-Bar". That way, the application can be sure that the frontend server is properly configured. Next, it should strip any X-Foo, X-Bar, and X-Added-By-My-Webserver, to prevent the client from being able to confuse the application with information the application expects to receive from the server. This is still flaky because the frontend server could fail, and the user could send X-Added-By-My-Webserver, and so on, but if you must use in-band signalling, this seems like the safe route. Just blissfully adding a header is not enough to protect against evil or changing user agents. Furthermore, it seems like a bad idea to make up your own header and not use an X- prefix.
  - martius 11y ago
    Yes, it's a bad idea, but an awful lot of bad ideas were the common practice a long time ago, when vendors had to deal with limitations of the HTTP/1.0 and 1.1 RFCs. In fact, we aren't talking about application headers. The HTTP RFC makes a distinction between application headers and hop-by-hop headers. There are mechanisms that proxies are required to implement, but they still don't. For instance, a proxy must declare itself by appending its signature to a "Via" header - however most of them don't. The RFC about forwarded HTTP extension is unclear about how a hop should deal with those headers, there is no one-size-fit-all situations: http://tools.ietf.org/html/rfc7239#section-8.1 http://tools.ietf.org/html/rfc7239#section-8.1

jrochkind1 11y ago

Hm, shouldn't apache be ensuring that clients _can't_ set the flag that indicates "this is an HTTPS request"? Otherwise app code that's _checking_ the flag, to ensure that a sensitive URL is only being accessed via HTTPS can be spoofed by the client simply saying it's HTTPS when it's not. That doesn't seem right. If that's what's going on, it seems like a bug in apache, with security consequences. ?