Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to build an absurdly backwards-compatible website

flower.codes

Post reply on HN
Print view View original

11–20 of 67 posts

Re: How to build an absurdly backwards-compatible website

#11

Post by david422 »

forgotmypw17 wrote: post #9
jefftk wrote: post #8

I don't think that the advice to offer non-HTTPS is good: it exposes your users to downgrade (SSL stripping) attacks. Even extremely old browsers supported HTTPS: it was added to Netscape in 1994, and Internet Explorer in 1995 (IE2). You shouldn't have to give up security for users of modern browsers in pursuit of backwards compatibility. (It might be a bit tricky to find an HTTPS configuration that supports for both…

I disagree completely. Sometimes backwards compatibility is more important. There are applications where you want maximum security (e.g. banking) and there are others where it is not only not necessary, but also a hindrance (ART, for example)

> not only not necessary, but also a hindrance

It's always necessary. We've learned that with http connections, middlemen can inject adware or other crap into the page. https://www.infoworld.com/article/2925839/code-injection-new...

Re: How to build an absurdly backwards-compatible website

#12

Post by Wowfunhappy »

david422 wrote: post #11
forgotmypw17 wrote: post #9

Earlier quoted context omitted.

I disagree completely. Sometimes backwards compatibility is more important. There are applications where you want maximum security (e.g. banking) and there are others where it is not only not necessary, but also a hindrance (ART, for example)

> not only not necessary, but also a hindrance It's always necessary. We've learned that with http connections, middlemen can inject adware or other crap into the page. https://www.infoworld.com/article/2925839/code-injection-new...

Google, Apple, Microsoft, Raymond Hill, and others also have this ability, even with https, depending on your OS and browser. It all comes down to who you decide to trust.

You've made a judgement call that ISPs are inherently less trustworthy than every other party in the chain, but I don't think you should make that decision for everyone else, particularly given that you don't know what ISP they have.

Re: How to build an absurdly backwards-compatible website

#13

Post by 0xbadcafebee »

jefftk wrote: post #8

I don't think that the advice to offer non-HTTPS is good: it exposes your users to downgrade (SSL stripping) attacks. Even extremely old browsers supported HTTPS: it was added to Netscape in 1994, and Internet Explorer in 1995 (IE2). You shouldn't have to give up security for users of modern browsers in pursuit of backwards compatibility. (It might be a bit tricky to find an HTTPS configuration that supports for both…

I don't think it's possible to use modern HTTPS with old browsers. All the old ciphers are now insecure and obsolete. Even if you supported the old ciphers, what would be the point, since they're insecure? So just provide plain HTTP.

For the majority of users, man-in-the-middle attacks (by someone other than your ISP) will never be an issue. It's mostly a theoretical problem. Your connection at home (and your laptop) is as safe as your Wifi connection. Your mobile connection is probably more secure. And there is no hacker sitting in your coffee shop waiting to p0wn your connection to Facebook or send you a 0day. HTTPS is necessary for the whole world to trust e-commerce, but saying everything has to be encrypted is ridiculous.

The most likely MitM anyone will ever experience is DNS cache poisoning, and that's pretty rare.

Re: How to build an absurdly backwards-compatible website

#14

Post by forgotmypw17 »

david422 wrote: post #11
forgotmypw17 wrote: post #9

Earlier quoted context omitted.

I disagree completely. Sometimes backwards compatibility is more important. There are applications where you want maximum security (e.g. banking) and there are others where it is not only not necessary, but also a hindrance (ART, for example)

> not only not necessary, but also a hindrance It's always necessary. We've learned that with http connections, middlemen can inject adware or other crap into the page. https://www.infoworld.com/article/2925839/code-injection-new...

With HTTPS connections, compatibility problems or even a clock which is set wrong can keep someone from accessing important information.

Not to mention that you are at the mercy of the SSL authorities.

Re: How to build an absurdly backwards-compatible website

#15

Post by amiga-workbench »

Regarding https, one thing I like to do on my personal websites is listen if the client actually wants to upgrade protocols instead of forcing https on everyone.

  set $need_http_upgrade "$https$http_upgrade_insecure_requests";

  location / {
    if ($need_http_upgrade = "1") {
      add_header Vary Upgrade-Insecure-Requests;
      return 301 https://$host$request_uri;
    }

    index index.php index.html;
    try_files $uri $uri/ /index.php?$query_string;
  }
Its pretty straightforward to do in nginx, and my websites remain usable in IE5, Contiki, various feature phones.

Re: How to build an absurdly backwards-compatible website

#17

Post by zachflower »

amiga-workbench wrote: post #15

Regarding https, one thing I like to do on my personal websites is listen if the client actually wants to upgrade protocols instead of forcing https on everyone. set $need_http_upgrade "$https$http_upgrade_insecure_requests"; location / { if ($need_http_upgrade = "1") { add_header Vary Upgrade-Insecure-Requests; return 301 https://$host$request_uri; } index index.php index.html; try_files $uri $uri/ /index.php?$query…

Oooo I like this! I’ll have to steal it.

Thanks for the tip!

Re: How to build an absurdly backwards-compatible website

#18

Post by layer8 »

amiga-workbench wrote: post #15

Regarding https, one thing I like to do on my personal websites is listen if the client actually wants to upgrade protocols instead of forcing https on everyone. set $need_http_upgrade "$https$http_upgrade_insecure_requests"; location / { if ($need_http_upgrade = "1") { add_header Vary Upgrade-Insecure-Requests; return 301 https://$host$request_uri; } index index.php index.html; try_files $uri $uri/ /index.php?$query…

Reading the article, I was just thinking there should have been an Accept-Protocol header, but now I see that a limited version of that exists as Upgrade-Insecure-Requests.

Re: How to build an absurdly backwards-compatible website

#19

Post by layer8 »

eyelidlessness wrote: post #2

This is a cute and cool dive into taking backwards compatibility to absurd extremes. There’s one bit I might take overly-serious issue with (I hope the author will take this as non-serious criticism and an amused engagement with the thought process): > That said, browsers that predate CSS do not know what to do with tags, and as a result simply print the styles out at the top of the page. It's pretty ugly and, depend…

> color palette

The TFA failed to mention websafe colors. I still have that poster hanging on the wall: http://www.visibone.com/color/poster4x.html

Re: How to build an absurdly backwards-compatible website

#20

Post by RcouF1uZ4gsC »

amiga-workbench wrote: post #15

Regarding https, one thing I like to do on my personal websites is listen if the client actually wants to upgrade protocols instead of forcing https on everyone. set $need_http_upgrade "$https$http_upgrade_insecure_requests"; location / { if ($need_http_upgrade = "1") { add_header Vary Upgrade-Insecure-Requests; return 301 https://$host$request_uri; } index index.php index.html; try_files $uri $uri/ /index.php?$query…

This has enabled man in the middle attacks even for clients that want to upgrade protocols. An ISP or owner of the Wi-Fi network can just quietly drop all upgrade security headers.
Post reply on HN