Hacker News Reader

Comment by mrunkel | Hacker News Reader

At $previous_job we once turned on HTTPS for our entire customer website and online store, only to have our customer support team be bombarded by phone calls claiming that our "website was down."

After much teeth gnashing and research, we determined that a large segment of our user base was still using WinXP and the encryption protocols we offered weren't available to them.

We didn't think this would be a problem because the current version of the software wasn't compatible with WinXP any longer.

There was some debate internally whether the better fix was to including the legacy encryption protocols or just leave the HTTP version of the site running and use Strict-Transport-Security to move capable browsers to HTTPS.

In the end we had to include the legacy protocols so those customers could use our online store.

View on HN

At $current_job we're currently in the middle of the same thing, but took the precaution of checking logs to see which customers use older encryption protocols (we're B2B), and have given them X months to upgrade their systems before we make the switch on our side.

The logic that was communicated to them was that as a service provider, security a prime concern for us (as it should be for them as well), so we can't keep lagging on this forever. Currently, we have $single_digit merchants we're still waiting to make the switch.

It's made the whole switch process much easier and made customers actually appreciate our pro-activeness in this! :)

I know it's hindsight and all that, but why didn't you check your website analytics first? Seems a fairly massive assumption that should have taken 10 seconds to check.

Some people don't spy on their customers and don't have these kinds of information available for analyses

They're admittedly few though and their moral high ground is debatable considering that there are self hosted FOSS alternatives around nowadays

Calling aggregate anonymous analytics "spying on your customers" is absurd nonsense.

Declaring "absurd nonsense" isn't an argument.

In this case, the absurdity and nonsensical character of the 'spying' claim is fairly self-evident.

When a client voluntarily makes a request to a server, it presents a bunch of information for the server to see and consume. This information is not meant to be kept secret from the server. Among such pieces of information can be some about the characteristics of the user agent, including OS. It is disingenuous at best to call collecting such voluntarily-presented and clearly-transmitted data as "spying" on a user.

A basic requirement for spying is for a collecting party to be obtaining information that can be reasonably considered confidential or restricted. Details about the system from which you send a request are by definition of the protocol not confidential or restricted to the recipient of your request. It is not reasonable to expect a server to not look at or use information you present to it. Therefore, it isn't "spying" for the recipient to consume the information. The information might be used in ways some people(e.g., OP) don't like, but that does not make obtaining the information "spying".

I only posted this because it was the second time that day I saw "absurd nonsense" used as a comment with no additional content. It annoyed me enough the first time that it stuck out like a sore thumb the second time, then I noticed it was the same user and it was their last 2 comments.

You don't need an argument against absurd nonsense.

Better men than you have been beaten by absurd nonsense that shouldn't have needed to be argued against. ;)

I recall a woman who recently had this experience as well.

Just like those anonymous taxi fare statistics, no one ever extracted meaning from those..

The whole point is to extract meaning from analysis but not spy on personal information. Knowing which clients support what kind of SSL isn't personal, it is part of the request transaction.

It's "spying" when you're gathering data they didn't consent to give, like mining through their contacts, scanning running processes or uploading unrelated content from their computer. The browser User-Agent string is hardly classified information.

Yeah, this is more like the used car dealership noticing that a lot of their clientele drives Toyotas. SPIES!

Analytics on the web are neither aggregate nor anonymous.

Mere server-side logging can pick out something like this via User-Agent. Is it spying to count the number of times a request with "Windows NT 5.1" is sent to your server?

Mere server-side logging can include the negotiated encryption parameters (but doesn't by default, IIRC).

Yes, of the connection the server is party to. It's bad security to record them, but how is it spying?

I completely understand where you're coming from, but the User-Agent string is included in regular HTTP requests and you don't need to resort to overbearing client-side analytics to aggregate it; it's right there in the access logs on the server.

Are you implying that analyzing server logs to gather aggregate user agent statistics is "spying on [your] customers?"

Because that is untrue.

Aside from my personal opinion (which largely agrees with you), there are jurisdictions where a specific IP address is considered enough to make it (and the rest of the data) personal information, requiring a justification, information (or even consent), and other processes to protect privacy.

That's why Google Analytics has an option to remove the last three digits of an IP.

Out of all the grey comments, this one does not deserve to be greyed out.

Well you can use qualsys labs tool to check your ssl and all the main search engines have said they will start flagging sites that use unsafe HTTPS or show the warning page before letting you proceed

The important part is whether the data are anonymous.

You might be interested in the EFF's Best Practices for Online Service Providers:

https://www.eff.org/wp/osp

That would have been really smart. However, this move was driven by the product owner, including the requirement that we must score an "A" on the SSL Test site. I had just assumed he knew what he was asking for.

The scanning of the server logs occurred to us in hindsight as well.

> We didn't think this would be a problem because the current version of the software wasn't compatible with WinXP any longer.

> There was some debate internally whether the better fix was to including the legacy encryption protocols or just leave the HTTP version of the site running and use Strict-Transport-Security to move capable browsers to HTTPS.

Where can I read about this? Is there any way to display a special "Your browser is outdated" page for the users on WinXP?

Sorry if these seem like basic questions. I am just curious and would like to hear some expert advice.

At our place, we put a redirect on the front end networking device that detected if a browser couldn't support more modern encryption protocols, and sent them to an HTTP information page (instead of to the application itself) if so. This allowed us to update the core app to force newer protocols, while still providing some sort of UX for those left behind. We used Piwik to track the hits on the redirect page to get a sense for how many users were left behind.

We did a similar thing, but folded it into unsupported and deprecated - unsupported browsers will get an HTML page extolling the virtues of updating your browser once a decade, whilst deprecated browsers (basically IE10 at the time tbh) were treated to a popup explaining that whilst the site probably works just fine, their browser wasnt fully upto date and the experience might suffer.

Eventually, and I doubt we had anything to do with it, IE10 usage dipped below the magic .5% (when it costs is more money to support than it earns us) and it was finally unsupported.

The only crappy browsers we still officially support are ancient safari and IE11, both of which are still going relatively strong for reasons we've never been able to fully explain!

Corporate environments often rewrite employees to use IE 11 because of outdated internal web apps. Where I work the Windows laptops, even Windows 10, only allow IE 11, not even Edge.

IE11 is the most recent version of IE, it's not like it's old or unsupported. And it has way more compatibility tweaks than Edge, so lots of people haven't switched.

> Is there any way to display a special "Your browser is outdated" page for the users on WinXP?

https://browser-update.org/ is a great service that does this.

For the case where SSL was broken, unfortunately that wouldn't help at all, because they'd never be able to load the webpage.

Out of curiosity - roughly what year was that and what percentage of the customer base would you say was still on Windows XP at the time?

Had a similar one at my last role. It was a HTML5 remote desktop thing with websockets, TLS1.2 etc etc. Got a bug report from a user that it didn't work in Safari. We didn't have a Mac in the office to test with, so asked the user for more details.

"Oh no, this isn't a Mac, it's Windows"

This is a user of a highly secure system, containing user PII, who expected to use it on a 5 year old browser with XP.

~bangs head~

In unrelated to topic note, I am in a team making html5 remote desktop thingie, I have to now start making the linux agent.

If its alright for you to answer,

1. What would be the best/cross platform way to proceed?We now have separate agents for windows, mac which causes maintenance hell

2. Is chrome remote's way of streaming desktop images as video better than images + diff.

3. Is there any open source mirror driver kind of thing in linux?

The software used was a commercial tool made upon Guacamole (Apache) called Inuvika. It's pretty awful, but having Linux and Windows apps on the same virtual desktop is quite cool. I don't know how much of that functionality comes from Guacamole or from the Inuvika addons.

Inuvika/Guacamole also support plain RDP, but we didn't use this, just the html5 client (browser)

If you want to see what open-source can do then look at Guacamole and go from there.

Don't think that helps, but...

The frustrating point about a similar experience was...

You can support HTTP and the occasional knowledgeable person will suggest you should upgrade. Or you can force TLS with SSLv3 enabled, and suddenly you'll hit a flood of people letting you know you're about to be hacked, based on online scanners. Often complete with requests for a bug bounty.

The other problem with Windows XP and https is SNI. You cant serve more than one domain with different ssl certificates from the same IP address, you either use SANs or different IP addresses. This does not only affect IE on XP but every browser.

> https://twitter.com/David_Leavitt/status/866790014717497345

IIRC, Chrome and Firefox for XP support SNI because they bundle their own TLS libraries, rather than using a system library.

im suprised there are any non sni visitors to SO. i expect most of them are bots eg. old versions of wget etc.

Did you use any alerting mechanism that informed you about the how many % were affected by this?

Reply on news.ycombinator.com