Insecure connection to this site

[Martin Bush]

This site has started generating a "!" In the address bar of Chrome on my android phone. When I click it there's an explanation saying that my connection to this site is insecure.

Any idea why that would be? I don't get it on any other sites.

Martin

[Nuvistor]

It due to the site requiring user name and password but not using SSL.

No doubt Paul will have a much better explanation.

Frank

[Martin Bush]

So, as things stand, all is OK?

Thankfully my name is not, as you may have guessed, my real one. So at least that 'personal data' is of no use to anyone.

Although possible I don't think hackers 'mine' sites like this too much, lots (and lots and lots) more information to be got from the likes of facebook and other mass social media sites. I had very odd parents (one of each sex), my name here is my real one.

[Boater Sam]

Its a circle around a ! on Chrome, I get it on lots of sites, Golbourne, ebay, sudoku, not worried, the trackers have much better hunting grounds than us, social media sites are their gift. Besides, do you ever use a credit card # on an unsecured site?
Paypal locks as soon as you get to your login page. Bank sites are always locked.

[dsergeant]

Widely reported on the web, since Chrome 56 any site which is http:// but also has a login option, even though the login page is behind https://, will be flagged as 'insecure'. It is part of the 'https:// anywhere' trend. Totally OTT and nothing whatsoever to worry about.

[Martin Bush]

Fair enough. I just wondered why it was. This is the only one I have experienced it on, and only noticed it this week. Seems all is OK anyway.

[Paul Stenning]

You should find that https://www.vintage-radio.net/forum/ works OK now too. The hosting platform is now automatically deploying basic free Let's Encrypt SSL certificates to all domains that don't have them.

I wouldn't rely on a free one like that for an eCommerce site, but for a forum login it's fine.

I have changed the configuration to use https:// by default. It would be interesting to hear if anyone has any problems with it.

[dsergeant]

You don't automatically switch to https:// though Paul, I am still accessing the http:// - maybe I should change my bookmark....
Dave

[vidjoman]

That's the way to do it. Clicked on Pauls link and in via https.
Edit- just noticed it still has the exclamation mark in Chrome and says that although it is encrypted there is a possibility of letting some thug in.

[paulsherwin]

I agree with #6. Insisting on HTTPS everywhere is pointless and gives a false sense of security, as man-in-the-middle weaknesses like the recent Cloudflare security bug can expose the encrypted connection anyway. Wikipedia went to an encrypted connection about a year ago, a complete waste of time and computer resources.

[Paul Stenning]

At some point I will try to make all pages with a login form SSL (as well as PMs and the admin system the mods use) while leaving the rest non-SSL. I will probably need to modify the vBulletin code a bit to do that.

There is no reason for the main forum to be SSL, as Paul says it would be a waste of resources for no benefit.

[MrBungle]

SSL is pretty low overhead in 2017. We handle about 7,000 TLS v1.2 connects per second (!) peak and the overhead is around 5-6%. It is beneficial to have SSL across the whole site as it prevents theft of the session cookies. The CloudFlare security hole was a trivial buffer overrun, not an error in process or principles. If you set the cert up properly, the ciphers and enable PFS, MITM attacks are impossible.

You can find any problems with the TLS config with this tool: https://github.com/drwetter/testssl.sh

Anyway I'm taking that hat off for the day now

[dsergeant]

A sort of related point, have you considered providing ipv6 support for the forum? With at least two ISPs in the UK now largely fully ipv6 (BT and Sky) and many major sites like Wikipedia and Google now fully ipv6, it may be worth doing. No biggie but it does mean a small speed improvement for those of us who do have an ipv6 connection. I updated my personal sites the other week and it was nothing more than ticking a box in the hosting settings.
(and I just checked at one of the ipv6 test sites, vintage-radio.net doesn't currently support it).

Dave

[Paul Stenning]

I'm sure that's something the hosting company will address at server level when it becomes important. I will ask if there is any plans, as it will affect their routers and other network systems as well as servers.

[GMB]

Do be careful on changing to SSL. I am noticing an increasing number of web sites that suffer from strange problems due to doing this.

It may be that modern systems are getting tougher about any minor anomalies that could be construed as a hack attempt. These are not always the fault of the site itself, e.g. I have hit some sites that due to where they got their SSL certificate often get the problem where the server that lists the revocations lists is down and now modern systems get very upset about that.

[MrBungle]

The main problem is the insistence of Google Chrome that it must enforce the best standards on everyone. This isn't a policy decision I agree with. The Internet is built on interoperability and managed change, not a loud mouthed monopoly forcing everyone along.

This breaks things for people. For the average user, this approach isn't delivering them any benefit.

A slightly iffy TLS config is better than serving something over plain HTTP.

[Paul Stenning]

http:// and https:// both work, with https:// the default, so you can use whatever you prefer or whatever works best for you. If your browser bookmark/favourite is the http:// URL then that's probably what you will be using.

Personally I think it is right for a browser to highlight a possible security issue if there is a password field on a non-SSL page. With the increased use of free wi-fi connections (some of which have no wireless security) and mobile devices, along with fake wi-fi connections with the same names intended for stealing credentials, there is a higher risk now.

However I do not see any point in sending all data over SSL regardless, but it's not something I can do anything about.

I think for a site like this having both options available and not enforcing one of the other is the best compromise at the moment. This may change over time of course.