Unable to access Plusnet website

[#1]

---

@jgj18 wrote:

The user agent string in Chrome on my phone that doesn't work is exactly the same as kissinuk's second string in post 24 above, for his/her phone that does work. So I guess that's not the problem?

---

The evidence would suggest not

@RevvyRevRev wrote:

type chrome://flags into the address bar.  Then type TLS in the search field.

You should see an option that comes up "Allow SHA-1 server signatures in TLS."  Enable this.  Click on Relaunch and you should find that the Plusnet website is now accessible.

I have been unable to replicate the issue, but I can if I explicitly set this flag to 'Disabled', so we may be getting somewhere.

@ont wrote:
You are absolutely correct, can access correctly now.
Web Devs at plusnet take note
SHA-1 has known collisions and is no longer considered a secure hash function. Removing support ensures these weaknesses cannot be used by an attacker to impersonate a TLS server. Use of SHA-1 signatures in TLS has been deprecated by the IETF in RFC 9155.

From what I can establish, the site isn't using SHA-1?

[#2]

I did notice the main site was reporting TLS 1.2 whereas the forum was 1.3 if that helps.

Very strange that the same version of Chrome on my tablet & mobile work differently, both are set to "default" for that setting.

[#3]

The change to Chrome flags to allow SHA-1 works for me, on both mobile and Windows.

Thanks for discovering that. Hopefully Plusnet will now be able to upgrade their website so that it works with the default Chrome settings.

Kind regards, John

[#4]

@jgj18 wrote:

Thanks for discovering that. Hopefully Plusnet will now be able to upgrade their website so that it works with the default Chrome settings.

I use default Chrome settings and everything works perfectly fine for me.

These are the ciphers I see for www.plus.net: -

| ssl-enum-ciphers:
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
|       TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 2048) - A
|       TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|     compressors:
|       NULL
|     cipher preference: server
|_  least strength: A

The Plusnet site also passes a Qualys SSL check here with a Grade A.

I wonder if it's something to do with the additional certificate below?

[#5]

I would have thought that it is in Plusnet's interest to fix the problem, whoever's fault it is. Chrome users browsing for a new broadband deal and unable to see the Plusnet deals are likely to choose another supplier, rather than tinker with their Chrome flags! I wonder how much business Plusnet have missed out on because of this?

Regards, John

[#6]

I fully recognise that John. It's hard to fix something you don't know the root cause of though 

Was just pointing out that it doesn't affect everybody using a default Chrome install.

If there's something within our domain that we can do to remedy the problem then we will.

Edit: After some further digging, I'm fairly certain that SHA1 sig in the certificate chain is the culprit. I can't explain the inconsistency with Chrome, and why some encounter this issue/others don't, but will see if we can make a change at this side (ref: INFOPS-96681).

[#7]

Seems the Chrome default for that setting is being changed and slowly rolled out so at some point it won't work on any version:
https://groups.google.com/a/chromium.org/g/blink-dev/c/ZdpqIOKTHeM?pli=1

Probably explains why it works on one of my devices and not the other, even though they are both set to 'default'.

[#8]

Congrats to the post that Identified the relevant setting and the analysis after. This was a tricky one without useful diagnostics from Chrome and the way its advanced settings are hidden.

It does illustrate that even if something is reported by only a few users it's still worth investigating as it's not always just an issue with their PC. These days configuration changes get rolled out independently of app version updates and change logs.

If this change is being rolled out then maybe all Chrome users will eventually lose access if not fixed promptly.

[#9]

I have the same issue as OP, same message. Thanks to @RealAleMadrid for the pointer to here.

[#10]

Interesting to find that the community works from a link to it in an email. But try going to anywhere else on plus.net and the same initial error occurs. Not sure if that helps anyone trying to fix at Plusnet, or of course apologies if it's been noted and recognised already.

[#11]

This worked for me. Thanks!

[#12]

Interestingly, my other (older) Windows 10 system that is able to open plus.net has SHA-1 server signatures set to Default.

Just to check, I have set it to Enabled and restarted Chrome and it can still open plus.net. Not missing too many tricks, I closed the tab, set it to Disabled, restarted Chrome and opened a new tab to plus.net and it will not open.

So, it seems that the Default SHA-1 setting is different between these two systems despite them being the same Windows Build 22H2.

Go figure!

[#13]

It looks as though Google have a way of rolling out changes to these default values independently of Chrome version updates. They are presumably doing it slowly so that websites affected are not brought down overnight. There was a gap of a couple of weeks between my W10 system and my mobile being affected. It's a shame that the error message from the browser is not more explicit about the reason for the mismatch - if it had mentioned an unacceptable SHA-1 cipher, the problem would have been clear to Plusnet immediately.

Regards, John

[#14]

I should have read more before I posted the same problem. Thanks, the change in flags suggested by a previous poster fixed it for me.

[#15]

Worked for me too thanks.