It's lovely. Not perfect, but lovely all the same.
All over the world, systems administrators are scrambling to fix the OpenSSL “Heartbleed” bug. At the same time, certificate sellers are preparing rub currency all over their bodies as Web admins virtually swipe the corporate Amex to revoke and renew their certs. OpenSSL's history reaches back to Eric Young's SSLeay. While it …
Nice to see they've added Heartbleed testing - it didn't check for it yesterday as that site was my first port of call and flagged up all the servers I needed to test as green, but at least has flagged up the one I know has an issue with a big fat red F.
However, it does state that the Heartbleed check is experimental, so it may report a pass even if the server actually is vulnerable. Might be worth using a few different tests, including use openssl itself on a box local to the servers being tested to cut out any intermediate termination points that might be disguising the issue.
Although they do only list like the last 10 worst, and so many people use it, this list changes every second, so it isn't likely to become a lightening rod for attacks in about a second.
Not to mention the check box, which you can tick to not have your info displayed on the boards, right under the input box.
Telcobox = unsecure
mybox = secure
Use the telcobox for transport only and triple-play, then get LAN/WLAN and security from mybox only.
Of course, mybox must not be remotely managed, must not trust anything coming from telcobox and it should run one of the popular freewares (dd-wrt, openwrt, tomato).
•Can I easily find out if my router is running OpenSSL, and if so what version? (Answer: probably no)
- With OpenWRT this is pretty easy
•Can I easily upgrade to a secure version? (Answer: only if my vendor or the ISP that provided the hardware ships a firmware upgrade)
- With OpenWRT this is pretty easy
•Will old devices get upgraded? (Answer: probably not in a hurry and almost certainly not automatically)
- With OpenWRT this is pretty easy
•What can I do? (Answer: turn off remote management, if you can).
- Keep using open source router firmware? :)
it was open source that caused this problem in the first place.[Citation Needed]
You sure it wasn't someone making buggy code that caused this problem in the first place?
And the open source development model that made the bug more likely to be discovered and fixed?
...and the closed off, black box nature of shitty SoHo routers that prevents a lot of people from easily applying the fix?
Yes, yes and yes.
"But have they issued a patch yet?"
Uh, yes... Patched on the 8th of April, but compiling from source is not difficult either.
Confirming whether you're safe or not is as simple as:
# opkg list | grep openssl
Updating to the latest version is as easy as
# wget http://downloads.openwrt.org/snapshots/trunk/ar71xx/packages/libopenssl_1.0.1g-1_ar71xx.ipk
# wget http://downloads.openwrt.org/snapshots/trunk/ar71xx/packages/openssl-util_1.0.1g-1_ar71xx.ipk
# opkg install libopenssl_1.0.1g-1_ar71xx.ipk
# opkg install openssl-util_1.0.1g-1_ar71xx.ipk
As far as "It was open source that caused the problem in the first case" - I don't even know whether to bother explaining the errors in logic. How does publishing the source code of a program cause it to be insecure? Either it's secure or it's not.
Well, someone had to say it :-)
I've just bought an old Cisco router to try and get away from the bulk Soho consumer routers because Virgin Media won't fix bugs in their supplied product.
Now I have to go back to school to learn how to configure the blasted thing.
Oh, and given that it runs IOS how come Apple haven't sued Cisco yet?
Mine's the one with the infinite pockets to hold all the CLI manuals.
A Cisco 837 ADLS router, which copes with "Up to 8Mbps" just fine, may only cost £30 off the web. Cisco's web site has plenty of examples of how to configure various routers. You may have to get your head round Access Control Lists when locking the thing down or, worse, allowing some external access. You may not legitimately be able to maintain IOS – if that is of concern. But probably are much more secure option than whatever the ISP supplies.
I have that router.
Its not really Cisco and it doesn't run IOS - it was badge engineered linksys I think. Whatever. Cisco bought a company to get into low end, and then sold it again.
It is however a decent router with nearly all the features a geek needs and most importantly, they actually do work.
And it runs hotter than hell.
If it's old you might be fine. From what I can see the issue only affects the newer versions of openssl, older versions like 0.9.8 and below don't have the vulnerability, so some older kit will likely be fine. For instance Watchguard report some of their older firewalls are unaffected, and I believe CentOS 5.x is also fine as it doesn't support OpenSSL newer than 0.9.8, unlike any of the CentOS 6.x versions which have the newer one and therefore need looking at.
so: "it's nearly impossible for the average end user to work out what version of software a consumer broadband router is running."
Hmm. If the router is running linux, surely all I have to do is check the source code handily supplied to me by the manufacturer ... (ROFL)
wait, wait ... wasn't my ROFL big enough for you? Am I not allowed to chuckle at both (a) the idea of average users checking src code, and (b) manufacturers (not) supplying source code?
So you are admitting to performing a security probe without authorisation from the server owner? Congratulations on becoming a criminal.
Under what law? The special Internet law that doesn't exist?
Unless of course you know in which jurisdiction the OP resides, and can quote the relevant passages from the relevant acts verbatim.
I've always wondered *why* anyone would need to remotely manage their home router?
The only scenario I can think of is that the router is locked down super tight (static addresses for every device on the LAN) and the person adminning it is out of town for a couple of weeks when a family member buys a new device and wants to connect it to the LAN.
I suspect that remote management may include your ISP updating firmware on your router.
May also include remote management to fix finger trouble by unskilled users.
When routers are provided as part of a turnkey solution then remote support capability is more or less a given.
Store and access files on router connected storage.
Music and movie streaming
Bandwidth and data management (caps)
DYN DNS type service
Whitelist or blacklist sites
Change traffic priority rules
Restart a consumer grade router that ran out of memory
See if your house is there after a disaster
There's probably a better way to do many of these things, but remote management through a simpler than setting a box up yourself webpage makes them so simple. I can remotely access my router, just in case. (Turned off atm until I can call support tomorrow)
I wonder how often the remote management is on by default in these devices? The ADSL+WLAN router I bough several years ago had it disabled, and after some thinking I left it that way, not seeing any good reasons to enable it, just lots of risks. But I could imagine some manufacturers having a different policy, in which case those devices are probably pwned by now.
While this vulnerability is rather catastrophic, you're looking for demons in additional places where they do not lie. To the extent that any of these home routers and access points bother with SSL _at all_, they are using self-signed certificates which are already insecure and worthless. Being able to steal the private key from a device using a self-signed certificate to begin with isn't much further of a vulnerability.
No I think you misunderstand. The vulnerability allows _all_ the memory on the device to be leaked (albeit in 64kb chunks). There could be _anything_ in there - I guess any web traffic sent in plain text will be visible (presumably anything encrypted in the browser would be fine)
Isn't the scope of the compromise limited to the type of hardware? For firmware devices with a simple process and memory model, I can see the compromise extending to _all_ the memory.
But for other devices, including the webservers at companies, it seems the access would be more limited. How can _all_ the memory be compromised when the OpenSSL library would be loaded inside a process context with memory protection that prevents you seeing the memory of other processes? It seems you should only get it for the particular process(es) using OpenSSL in support of each IP ports communications.
Why do you consider a self signed certificate worthless? I don't see how paying a 3rd party to sign your cert with their trusted root certificate makes things anymore secure, it just means browsers trust them by default.
If you add the self signed cert to your trusted certificates you'll know if someones trying to spoof your host or something funny is going on.
That's because the definition of self-signed certificates includes two types of certificates:
1) certificates created by a device/software during its installation process
2) certificates signed by a non-global CA
#1 above can, depending on the author of the installation script, create identical certificates on every device.
#2 is what you get when you build your own, internal, CA. Either using openssl and a handful of scripts or a package like ejbca. You can create certificates equal to, or better than, certificates issued by any global root CA. At nearly zero cost.
Have been using Mikrotik for my home routers for a couple of years now. Not only are they cheaper than your 'generic' consumer routers, but they are much better specified, and more configurable. I have no problems recommending them.
Add the fact that they're not susceptible to the current SSL issue, and it's all good.
I thought this vulnerability only related to 1.0.1 and later? Older OSes and routers etc may well be running 0.9.x or possibly earlier. RHEL5/Centos5 was on 0.9.8 the last time I looked, for example. Yes, I know RH backports some stuff so version numbers aren't always indicative, and maybe you rolled your own rather than using an rpm or .deb or whatever.
Biting the hand that feeds IT © 1998–2019