XP seems to be a lot of "fun", these days with security especially since the security features XP DOES support are being phased out day by day. for all those who want to drop XP there is always the problem that the people wont be able to access the site, especially since Google Prefers HTTPS now they probably link to HTTPS sites which can easily be not working if they value security more than XP.

they have seemingly no chance of giving the user an Upgrade warning or similar, and here's a question that tries to address this:

is it possible to reverse-proxy users with "bad" security based on their clienthello, so they could be internally redirected to a behind-server with its own certificate (e.g. a SAH1 cert so that even old androids and XP can see it) which could have an upgrade warning, so that people at least know what's going on and provoding them with help to use the site securely and as intended (e.g. with Firefox) and explaining why that's needed without compromising the security of the Main System.

  • Yes, it's possible, but for which web server? – Michael Hampton Jan 19 '16 at 11:15
  • well I would prefer apache because that's what I use now, but I am open for others and also it's better for the community if there are solutions available for multiple servers – My1 Jan 19 '16 at 11:17
  • OK, wait, it's possible to redirect users not using TLS 1.2, for instance, but the part about "redirecting" to another server with an old SHA1 certificate may be rather impossible, since nobody is actually going to issue you such a certificate. – Michael Hampton Jan 19 '16 at 11:21
  • okay well thats true, just found out, too bad. maybe they (CA/B Forum) allow explicit legacy certs someday. – My1 Jan 19 '16 at 11:40
  • Don't count on it. The proper thing to do at this late date is to not support XP and other ancient and unsupported systems. Anyone still running XP two years after Microsoft finally pulled the plug is most likely insane. – Michael Hampton Jan 19 '16 at 11:45

The whole proxy and pre hello inspection is not needed.

  1. You allow on the server also the less secure suites and protocols.
  2. In the next step you check what ciphersuite was negotiated (possible in java and php) and depending on the suite you show an large red Alert flag.

With client hello inspection you can limit the fallback to certain known client ssl fingerprints.

  • but with client hello inspection I can move them right away from the site, meaning they can do a lot less harm (e.g. XP botnet trying to ddos, doesnt really interact much with the "main" server, but gets dished away. also Java is BAD, really BAD, a lot of people might not even have it installed... if you means javascript, well no thanks I dont really like it, since js tends to break a lot on slow internet connections, like phone. also how is it possible to see the cipher in PHP when there isnt even a reliable way to identify an HTTPS connection in PHP (because the servers do what they want) – My1 Jan 19 '16 at 13:09

I see that there are many ssl infos available in PHP: http://www.eschrade.com/page/what-ssl-_server-variables-are-available-in-php/ With java i mean systems like tomcat / jetty etc.

Javascript is client side. And an additional proxy for moving bots to another server is stupid because he could if you could detect bots.

  • well it isnt for bots exclusively but XP users (and everything else with bad SSL) have a way higher chance of turning into bots because it is unmaintained. – My1 Jan 21 '16 at 8:21
  • also are those variables even reliable? IIS for example doesnt do what usually should be done e.g. with the "is HTTPS used" variable instead of it being able to be cast to true or false they are "on" or "off", that's why kicking them away at the server level seems more reliable – My1 Jan 21 '16 at 8:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.