In reply to a post by RobertoS:

It's a distinct possibility I'm afraid. Ten minutes work.

It could take just over that to resolve the issue.

In reply to a post by RobertoS:

I'm quite worried by people on this forum pursuing the (non-)issue.

I wouldn't say its a non issue, it has security issue on the actual server, and its using an insecure certificate which needs to be fixed, maybe its my OCD kicking in again.

The CERT expires in June so the CERT issue will be resolved then, I am guessing the server "might" be done then.

TBH I haven't really used that site for a few months now, so if they didn't fix the ISSUES on that server its no Biggy, the information on there wasn't that correct anyway.

If I really wanted to get the average fibre speed for a line I would just use the Where and when page.

Paul

Edited by PaulKirby (Wed 01-Mar-17 12:04:02)

The other thing to consider is that the server has used that cert and those settings probably for a long time. If it wasn't hit before now what makes it suddenly a target - just because now Google/etc tell people it isn't secure doesn't make it any less secure than it was 6 months ago.

Considering the collision exploit that set this whole thing off has only just been carried out in practise at a cost of $7.4m I'd tend to agree with you...

http://www.networkworld.com/article/3173701/security...

So it is possible but difficult.

Also, the next question I would pose - if it was not HTTPS at all then would it matter? If the pages were published with no encryption what would anyone watching the traffic find out - I'm thinking not a lot. They could remove the certificate and publish as HTTP and still not be giving away any particularly sensitive data.

All major browser are saying this, not just Chrome.

The issue is where the hashing that their CERT uses (i.e. SHA1) and also that TLS 1.0 is old about to be obsolete and has known security issues.

But yeah its possibly been like that for a while now, its just that our browsers have been updated to notify the users that its not secure and why, which is true and possibly future browser updates will no longer use the obsolete SHA1 hashing and TLS 1.0.
And when that happens nobody will be able to access that site.

Well unless they use the HTTP version or ignore the popup notice.

But my guesses is that it will be resolved in Jun when they renew their CERT which will have SHA256 or better for their hashing.

Paul

In reply to a post by ian72:

So it is possible but difficult.

Also, the next question I would pose - if it was not HTTPS at all then would it matter? If the pages were published with no encryption what would anyone watching the traffic find out - I'm thinking not a lot. They could remove the certificate and publish as HTTP and still not be giving away any particularly sensitive data.

This is true, however any personal information is sensitive data in a way, not as sensitive as credit card information or passwords etc.

TBH I consider my Phone Number and Address sensitive information due to we are ex-directory.

So no I wouldn't use a site that doesn't use a secure site if I am submitting private information.

But saying that, these forums if I recall uses HTTP when you login, but in this case I am using non secure information.

But we will see what happens in June to see whether they renew the CERT or not.

Paul

Edited by PaulKirby (Wed 01-Mar-17 14:35:14)

All major browser are saying this, not just Chrome.

Hence my OP says "Google/etc". The etc was covering the others.

In reply to a post by ian72:

All major browser are saying this, not just Chrome.

Hence my OP says "Google/etc". The etc was covering the others.

Ah, ok.
But you are right about it not making it less secure than it was six months ago, its been insecure for many years going by the missing security patches, it was just that we was unaware of it.

Paul

In reply to a post by huwwatkins:

Considering the collision exploit that set this whole thing off has only just been carried out in practise at a cost of $7.4m I'd tend to agree with you...

How we got here:

We have known for more than 10 years that SHA-1 is weaker than intended. The result of this weakness is that eventually, using the same approach as in Google's Proof Of Concept this week, bad guys would be able to make two documents which SHA-1 treated as the same, if the documents were SSL certificates instead of PDF files, this would enable bad guys to present one certificate to be signed, but then actually use the signature on a different certificate. Like if you got some fool to sign a blank cheque.

This really happened for SHA-1's predecessor, MD5, academic researchers got themselves a bogus certificate this way in 2008, and James Bond types seem to have done it again in the "Flame" malware program which has a fake Microsoft certificate. Both were MD5 which we knew should have been phased out but it wasn't for ages.

By 2014 it was apparent that this would happen soon for SHA-1 too. Certificate Authorities agreed to stop issuing all SHA-1 certificates before 2016, and Browser vendors agreed to stop accepting these certificates in 2017.

The idea was that if you can't get a new certificate, you can't use the attack (you can't use this attack on an existing certificate, it's just a way to trick people when issuing a new one), and if browsers stop trusting the certificates, there will be no incentive to break the rules and issue one anyway. During 2016 we had a few dozen incidents where we caught CAs issuing old SHA-1 certificates "by mistake" and some got in lots of hot water for it, but overall things went pretty well.

So, the DSL checker site isn't "more vulnerable" per se as a result of this old SHA-1 certificate, but we had to mark it as untrusted or else the whole web is effectively left vulnerable. It's like the way Australia was really angry about Johnny Depp's dogs. _Those_ dogs were probably fine on their own, but Australia needs strict rules to protect the weird Australian native wildlife, so it can't just let people disobey the rules like it's no big deal.

BT will have been told, repeatedly, by their vendors to fix this, most certificate vendors offered free re-issues to anyone who might be affected. But I guess no-one at BT cared.

In reply to a post by PaulKirby:

Well it depends on where you get your certs from, I can as far as I know still request verified certificate with a signature hash algorithm of sha1, not that I would do that.

I know I made a mistake about a year ago when I typed in sha1 instead of sha256 and they issued them fine, I then started playing with other flags like key sizes to see how high I could get it before they moaned, got bored at 32768 Bit keys, plus I didn't want to annoy the issuer

If your certificates come from a public CA (ie they'd be trusted in somebody's web browser) then lots of people would be very interested in seeing a SSL/TLS certificate issued "a year ago" (or today) using SHA1 because this would be a violation of root programme policy and of the Baseline Requirements.

Of course if "a year ago" actually means "It might have been 2015", or if your issuer is only trusted in some poxy local system, like at a bank or somewhere else that doesn't take security as seriously as the Web does then never mind.