2

I have a scenario where a secure website with an A ssllabs overall rating is getting some warnings due to a lack of support for non-SNI browsers.

  • Android 2.3.7 Incorrect certificate because this client doesn't support SNI
  • IE 6 / XP Server closed connection
  • IE 8 / XP Incorrect certificate because this client doesn't support SNI
  • Java 6u45 Client does not support DH parameters > 1024 bits

I got the idea (maybe not the best one) of allowing those browsers to reach the website by sending the requests to a secondary insecure (non-https) backend using the http user agent information.

I understand that allowing those clients to reach the website would be a security breach, but at least They'll be able to see the website.

So, my question is about a security conception, what is worse/better? Allowing those clients to reach the website even if it means a security issue, or to deprecate support for those browsers?

5
  • Does the website just have GET requests or can users introduce changes in the database as well? – Limit Sep 24 '16 at 22:30
  • Also, many of these browsers are fairly old, are you sure you still want to support them? – Limit Sep 24 '16 at 22:31
  • The website is mostly based on GET requests yes, the frontend is just a search engine made with jinja and json for the data, so no database at all. But in a separate location block there is a contact form that uses php. – J. Canseco Sep 24 '16 at 22:48
  • About the support, I have been monitoring stats (last month) and the only browser I see is the one in "Android 2.3.7", and is just < 0.01% of the total. – J. Canseco Sep 24 '16 at 22:54
  • You can't route or (probably better) redirect by user-agent until after SSL/TLS is successful, in which case you don't need to. You could fix the non-SNIs (if they have no other problem) by using a single cert with wildcard and/or SAN aka multidomain; this does make it clear if e.g. fluffykittenvideos.cute and bondagesextoys.xxx are related, but DNS already exposes that to someone who looks. For Java6 if you install an ECC provider like BouncyCastle it will do ECDHE which avoids the DHE limitation, but if you can do that why not just upgrade Java? – dave_thompson_085 Sep 25 '16 at 11:24
0

In your particular case, dropping the support seems like a good idea.
Every new service you provide, adds a potential attack vector. Apart from that you increase the maintenance cost of your product. Adding a completely new support mechanism for less than 0.01% users doesn't seem like a good idea to me unless they are significantly important users (say have a 10% share in your income or something).

However, you can have a safe website which uses HTTP (Stack exchange doesn't use HTTPS). In a general scenario, I would say the decision is more related to economics and maintenance issues rather than technical issues.

  • How badly do you want a A rating?
  • Do those customers generate enough revenue to balance the maintenance cost of non-HTTPS servers?
1
  • I think this is the right answer, and the best solution for this scenario is to remove HTTPS from the website and move the contact form to a 3rd party solution (google form for example). Due to the application being maintained by a NPO, there is no way to measure any revenue impact. So as mentioned, the best solution is to cut down the maintenance to a minimum needed. – J. Canseco Sep 24 '16 at 23:44

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.