1

I have found many posts regarding checking the SNI browser support part, but not combining with the system time.

The default landing for my site is http. Now I have set up SSL. But compatibility is most important to me. Security is least important. I only want to auto-redirect users to https if I'm damn sure they won't see an error (and then falsely think my site's broken).

Since landing page is HTTP, we can use php or .htacess to detect. I had seen discussion elsewhere on using php redirections which may cause some "Back" button issue. (Force SSL and handle browsers without SNI support)

Besides SNI support, I also know that if user has a wrongly configured system time, he may encounter error on https site.

So what's the best approach to achieve both SNI + system time check? Any other possible scenario where user get redirected to https may encounter errors?

=====================================================================

Update:

Loading the home page doesn't really require "security". I'm thinking whether I can do a quick check to see if user could successfully load an object e.g. https://example.com/test.ico , if yes then show a "Secure Login" option. (Kudos to Steffen). The post action will then be done in https to prevent credentials being submitted unsafely.

If the test for https fails, then no choice the user has to login without https.

  1. Will this work?
  2. The additional test would definitely be a drag on site load speed isnt it
Community
  • 1
  • 1
klklklsg
  • 11
  • 2

2 Answers2

0

This is not the answer you are looking for and was going to leave as a comment for that reason, but got to long, so decided to answer instead:

While it's admirable to try to handle all your users no matter what antiquated tech or bad setup they have, at some point you've got to ask yourself about the effort's you're putting in versus the reward of a few extra hits?

Managing dual http and https is an administrative nightmare that just puts your https-capable users (the vast majority on nearly all sites) at needless risk due to downgrade attacks, inability to make cookies secure, accidentally including insecure content... etc. From an SEO perspective as well you basically have two sites which is difficult to manage.

IMHO, if you feel this strongly about SNI users then pay for a dedicated IP, if not move on to HTTPS only.

compatibility is most important to me. Security is least important

Then stick to HTTP and don't even consider HTTPS.

Finally you've got to remember that browsers will force you move on soon enough. Forcing SHA-2 certs for example (which are not supported by very old browsers - similar to SNI) means that you will eventually have to call it a day on older browsers. So any answer you come up with here will only be short lived. And that's assuming you can come up with a solution that will work across all browsers (no small ask in itself!).

Barry Pollard
  • 40,655
  • 7
  • 76
  • 92
0

There is no way to detect this on the server side with PHP or .htaccess because if a connection fails because of missing SNI or wrong system time then it fails already during the SSL handshake. But the PHP part or .htaccess gets only used for the HTTP part, i.e. only if the SSL handshake completed successfully.

What you might try to do is to include a https resource into your landing page and see if this gets loaded successfully. This might be done with image, css , XHR or similar. For example you could do this

<img src="https://test-ssl.example.com" 
    onload="redirect_to_https();" 
    onerror="notify_user_about_problem();" />

If the SSL connection to your site got established successfully the onload handler gets executed and the user gets redirected to the https site. If the handshake fails instead the user gets notified about the problem.

Note that you cannot distinguish between different kinds of errors this way, i.e. you don't know if the problem is caused by the wrong system time or missing SNI support. If you want to do this you need to have to include a non-SNI resource the same way and see if it gets successfully loaded.

But compatibility is most important to me. Security is least important.

I consider this a bad but unfortunately very common approach. I would recommend you instead use this mechanism not to allow the user to access all functionality of your site with http only, but the sensitive parts should be restricted to https. But you could use this approach to inform user about the problem in detail and showing alternatives instead of just causing some strange connection error because of the failed SSL handshake.

Steffen Ullrich
  • 114,247
  • 10
  • 131
  • 172