...lucky we post and login via secure forums around here, who knows what information go be gotten otherwise.
Virgin Media has failed to upgrade weak encryption software that it uses for sensitive parts of the telco's website, despite complaints from customers who claim to have repeatedly flagged up security concerns to the firm. In parallel with the gripes, Mozilla – which recently told netizens that it planned to end support for the …
Come on guys.
SSL takes MINUTES to purchase, a pittance per year, and then you can slap it into the website in a week if you need it. No-one's asking for a full security review, just a HTTPS on the form that submits.
You were able to piss about with Pratchett HTTP headers in your Apache easily enough, adding a duplicate site under SSL takes about ten minutes.
Even applying the "do-it-semi-properly" corporate multipliers, it's shameful that this still isn't done.
You can't report on other's security misgivings when you can't even manage to get close yourself.
It's been a few months since I wrestled with trying to reset a mail password on Virgin, but it used to be hilariously bad. The system disallowed my choices for being too long, then for having a space in, then for having the wrong kind of punctuation in the wrong places. Amateurs.
Agreed, it's comical..
Must be 6 to 8 letters long, Numeric, Upper and Lower-case only. No symbols, no spaces. Rules out any use of password managers for a decent password. I don't understand the restriction (except laziness on their part) ; I thought they were using a re-skinned g-mail client.
"Yes - El Reg, you should be pursuing them about this too - trivial to lift those restrictions."
When you are dealing with a service that has millions of customers accessing it, no change (however trivial it might seem) is trivial.
That doesn't let Virgin Media off the hook though. If parts of their web infrastructure have potential security problems, they should be working to resolve them as quickly as they can.
"When you are dealing with a service that has millions of customers accessing it, no change (however trivial it might seem) is trivial."
It's trivial. They've had months if not years to fix it, and they're a big bad company with dozens of experts to test it to destruction.
I repeat - it's trivial.
"Agreed, it's comical.. "
No, what is really comical is people who worry about using secure passwords on sites where the only real issue* if someone hacks the account is that they could pay your bill for you!
I recently had a water company insist on mixed case, numbers AND at least one symbol - Why? I really don't care if someone else pays my bill for me, no I really, really don't.
* Assuming you aren't using VM's email that is, and who in their right mind would.
@badvok "the only real issue* if someone hacks the account is that they could pay your bill for you!"
Really? Let's see.
- They can get your landline number and your name (don't think the postal address is available)
- They can see every telephone number you called, with its time, duration and cost.
- They can see every PPV thing you ordered, and when (I presume - I don't have their TV)
- They can muck about with up to 9 other accounts you can set up for people.
- They can change your subscription, such as broadband speed and TV bundles - imagine the hoops you'd have to jump through to rectify that
- They can see your security question and answer (Yep - another Virgin Media fail - it's there in plain sight on the web page)
Hmm - your complacency seems somewhat naive, especially as you are keen to give the impression you know all about security.
@handle: if you really are such a paranoid privacy freak that you really worry that there are people out there who would want to see all that information about you then I guess you have a problem - though trusting VM to keep secret your activities is not your biggest issue. Maybe you don't realise that pretty much anyone at VM can also see all that stuff and, horror of horrors, without even knowing your password!
And no you can't get your package changed without phoning them, or that's my experience anyway.
I never said that you can't use a high quality password if YOU want but I fail to see there is a need for VM to require their users create a complex password. Most users will not need it, and it just leads to more support calls for forgotten passwords, which in turn leads to easy password bypass.
@Badvok - when in a hole, I suggest you note the thumbs and stop digging. You've been proved comprehensively wrong that the only thing a VM password allows you to do is pay someone else's bill, and now you're trying to cloud the issue by chucking in the irrelevance of VM employees.
... and at best the password is stored with reversible encryption. When you phone the call centre they ask for your password, and I've received it in emails and written letters from Virgin.
As I say, at best, reversible encryption. It might not even be encrypted at all.
"Yes, the RC4 issue isn't particularly practically exploitable based on the information that is known publicly, but – as pointed out to VM – the service is also TLS 1.2 intolerant, which means that the software they use can't have been patched in years and is therefore, by definition, going to be security vulnerable to other issues."
I don't know what operating systems Virgin is using but there are tons of systems which can't use TLS 1.2. For instance Redhat Enterprise 5 doesn't support TLS 1.2. This is still widely used and will remain in production support until March 2017. That doesn't mean that the systems haven't been patched in years just that Redhat backports fixes to an older version of OpenSSL but doesn't add new features.
You have completely misunderstood and confused a server being intolerant to TLS 1.2 from actually supporting/implementing the TLS 1.2 protocol. They are entirely different concerns/things.
A server has to support TLS version negotiation correctly so that insecure TLS version fallback doesn't have to take place in a modern Web browser that supports TLS 1.2 for it to be accessible. The server can still happily only implement the TLS 1.0 protocol, it just has to do so correctly. The bug here is that Virgin's TLS 1.0-only servers do not respond correctly, per TLS 1.0 spec, to a TLS 1.2 Client Hello. Version negotiation fails.
Being version intolerant to TLS 1.2 Client Hellos definitely does therefore mean that a server has not been patched. It has been patched for years.
Firefox will remove insecure fallback in a forthcoming release. See https://bugzilla.mozilla.org/show_bug.cgi?id=1084025 and https://bugzilla.mozilla.org/show_bug.cgi?id=1126620
It is this intolerance that Chrome is calling out when you view details of the connection to Virgin Media's services, not the lack of TLS 1.2 support.
David, sadly you completely misunderstand what TLS version intolerance is.
A TLS client will use the highest TLS version it supports in its initial hello to the server. A server which is intolerant to newer TLS version numbers than its self will error and terminate the connection. Rather than replying correctly (as per spec) and negotiating the TLS version.
A server which is intolerant to newer TLS versions causes the browser to fall back, as such the browser will connect using an older TLS version. Obviously this had a negative impact on performance for clients.
It was common for older libraries to be intolerant to newer TLS versions, this is why Nick, correctly states that this is a vulnerability canary.
I would also point out, that Virgin Media has zero excuses for running such out dated TLS configurations. There is no reason not to be offering TLS 1.2.
I'd also point out an upto date RHEL 5 server, is not TLS 1.2 intolerant.
No cryptographic library in any RHEL5 release under support (including extended support channels) is TLS1.2 version intolerant.
Yes, OpenSSL in it doesn't support TLSv1.2, but clients don't have to fall back to TLSv1.0 to be able to connect.
Issues like this are there a lot with VM..
Use their webmail and look at the nifty security feature that list the IP addys that has had access to your email... Nope, Not your IP.. It shows a transparent proxy (Useful as that means EVERY user logs in via the same IP!)...
If your Deaf or Mute then their option for contacting them is for you to give someone you know your password and security details so they can manage it all for you over the phone, reason, DPA doesn't allow them to manage things over the "Internet"... Bit sad when you see the forum team tell someone who is deaf that they must use the phone to speak to someone...
Now you can get thousands of spam emails a day, but if you BCC something to 300 people then your email account is frozen for 24 hours too, because, well, who knows!...
Some of the mailshots they used to send also had a code printed in the corner that contained full account numbers, but they did eventually "Discover" that after years of users complaining and wala, it was fixed.
I have seen worse (Hi PayPal!), but overall what they are doing is not typically deal breaking and they probably know this - hence no need to rush out a fix.
Granted, All of those fixes will come when they deploy IPv6.. They said that would happen once they have more users than IPv4 IP's that they can give out. (When asked how giving out IPv4 was related to IPv6 Adoption they said that users don't need IPv6 until the ISP has no more IPv4)...
It is surely concerning that it requires a whole program of work for what should just be a software upgrade and configuration change on a few devices. This after it was apparently reported to them months ago?
This is a well understood area so this is, I think, inexcusable. Why the delay?
They should be following the advice given by Mozilla, their intermediary configuration, as it best maps to whatever they're using for TLS purposes: https://wiki.mozilla.org/Security/Server_Side_TLS
There's been a pile of articles on this lately and it boils down to: doesn't matter. There's no downside to not improving security. Even the cost of fixing the hack at Sony was a drop in the bucket and much covered by insurance. Same goes for Target and the other retailers. They don't care because improving their security costs more money then they would lose from a hack.
Mozilla will soon prohibit both insecure TLS version fallback and the RC4 cipher in Firefox. These issues will both, independently, make services that are TLS version intolerant or RC4-dependent inaccessible in that browser.
Google are likely to follow suit in relatively short order in Chrome.
I would say that's a tangible downside of not keeping your eye on the ball.
Assuming competent staff, the costs of fixing this are likely to be marginal.
" big bad company with dozens of experts "
In my dealings with them
Big - correct
Bad - who knows?
Dozens of experts - not so sure about that - it took me three years to convince them they had cable running past our offices. I knew it was there - dodgy trench with wavy non-parallel sides - badly filled and resurfaced to ensure a major trip hazard - just like all the other pavements in the borough where their cowboy contractors had laid cable. Trouble was their systems did not know where their own cables were. After I had finally convinced them that there was actually cable outside the front wall, it was connected up and worked surprisingly well, about a week later a scruffy bloke in a VM fleece came to the office to ask if our broadband was working. Upon being told it was he said he was surprised as the cabinet he thought it was connected to was lying flat on the floor having been run over by a truck years back. Clearly they had no idea what the cable runs were even after it was connected. I came away with the impression that once the network was built, anyone with a clue was let go, and the current call centre bunch just keep it all running by following the installer's notes and hoping for the best.
Biting the hand that feeds IT © 1998–2019