Pub O'clock probe finds thousands of repeated 512-bit RSA keys Four researchers, a zmap scan and a Friday afternoon have shown that while sys admins are cleaning the FREAK bug out of their Web servers, broadband routers remain a perpetual feast. The boffins from Royal Holloway at the University of London – Martin Albrecht, Davide Papini, Kenneth Paterson and Ricardo Villanueva-Polanco – …
My thought as well. A while back, somebody (can't find the article now) did a check for common factors in publicly-available keys (i.e., if somebody generates A=PQ and somebody else generates B=PR, factoring becomes easy: P is the greatest common denominator of AB). They found a shedload of them, presumably due to the "random number generator" not being especially "random". (I should add that they did something a little more sophisticated than this: they had something like N=a million keys, and had some tricks so they didn't have to do N(N-1)/2 comparisons. But you get the general idea.)
I do wonder: had the researchers in this current instance looked, not just for the A=B case, but for the A and B have a common factor cases, would they have found still more "issues"?
Its not just home grade either. Usually if a manufacturer refuses access to the innards of a professional device there is some dirty washing in there, and this is one of the perinials.
I could name names you would know, but that information is owned by my paymasters and up to them to divulge if they want.
This is one reason why I am a FOSS fanboi. Not because it is more secure, but because it *can* be secured in a reasonable time.
If you sell me a binary blob, the company is liable for security.
If I have the source code, I at least have the choice to PAY for security. Of course,
If the liability for bad and accidental security flaws (I believe there is a distinction) were more significant, perhaps more resources would be spent to actual check code?
Does this sound workable?
P.
That's great, but it doesn't help the masses out there who have a device that suffers from this issue. You and I may buy a router based on the ability to run DD-WRT/OpenWRT on it, so we don't care whether it came with a vulnerable firmware - that may never be fixed since it is "too old" (in vendor speak "we're no longer shipping that model")
What are the regular folks supposed to do? There is zero chance they will be able to install a replacement firmware. Open source provides the tools, but you have to REALLY know what you're doing to figure out which version to install. It wouldn't be terribly hard for that process to be improved so people could be asked a series of questions to help determine the model/version of router they have, and download the proper version. Unfortunately only 0.01% of FOSS people seem to give a damn about improving that end of things.
Even if you know what the heck you're doing deciding which DD-WRT version is the least broken takes hours of research, or some dumb luck (seriously, WTF is up with the idiots running that asylum?) At least openwrt.org has a download link on the front page, though without some knowledge you'd never know exactly which build you need.
Set up a brand. Set up an OEM. Contract the OEM to make and sell devices for the brand. If the OEM screws up, feed them to the wolves, and set up new manufacturer using the OEM's talent. What works for taxes, works for liability.
And for those who didn't go that route, there'd be a lot of litigation.
Configuring an SSL/TLS appliance with a different server certificate - self-signed or otherwise - doesn't help with the FREAK attack. FREAK has two components: the relatively low cost of factoring now-useless export-grade RSA keys, and ways for a MITM to trick a client and server into using an export-grade suite.
When an export-grade suite is chosen, the server will provide the client with a second, short RSA public key, and the client will use that short key to encrypt the premaster secret. That short RSA key is separate from the public key in the server's certificate.
So the server could have a certificate with a 16 Kbit RSA key, and still be vulnerable to FREAK.
Of course, the larger problem with self-signed certificates is that they aren't worth the paper they aren't printed on. They mean nothing. They can be used to exchange public keys over secure channels with entities whose identity you've already verified, but that's a rather limited use case, and PGP/GPG is a better choice for that, since it also provides the whole keyserver-and-web-of-trust PKI infrastructure, which is flawed but better than nothing.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
