US Military Websites Still Relying On SHA-1 (netcraft.com) 52
An anonymous reader writes: Netcraft confirms many U.S. Department of Defense websites, including a remote access service used by the Missile Defense Agency, are more vulnerable to man-in-the-middle attacks than most consumer websites. The weaker than previously-thought SHA-1 algorithm is the main culprit, with the DoD today being the most prolific user of SHA-1 signed SSL certificates, even though NIST banned new use of this signature algorithm two years ago. Most of the vulnerable certificates to be issued recently are used by .mil websites, which are operated by agencies, services and divisions of the DoD. All of these sites are consequently vulnerable to attack by enemy governments and criminals who can stump up enough cash ($75,000) to crack the certificates.
Gonna need a reference here... (Score:4, Interesting)
Re:Gonna need a reference here... (Score:5, Informative)
http://www.pcadvisor.co.uk/new... [pcadvisor.co.uk]
"... US$75,000 and $120,000 to mount a viable attack using freely available cloud-computing services"
"... someone can create two different files that have the same hash, it's possible to digitally sign one" Try searching for 75K or $75,000 by date and see what other public news can be found
Re: (Score:3, Insightful)
"... US$75,000 and $120,000 to mount a viable attack using freely available cloud-computing services"
That would be the quick & dirty method then, I suppose? (which admittedly is often the method of choice for black hats)
But speaking as devil's advocate here: if I were serious / determined enough to throw 75~100K$ at 'cracking some code', wouldn't it make more sense to buy some serious FPGA boards and do it in hardware? This looks like the kind of job where an FPGA-based setup could do it a lot faster, cheaper, or more efficient than some software running on cloud services.
Sure setting that up is s
Re:Gonna need a reference here... (Score:4, Interesting)
Yeah probably a lot lower. I've often found a 10X speed boost when optimizing SQL code for example. People just thought it must take about that long so didn't bother looking for a better way. Slap an index, reorder a query and presto. I get there are mathematical limits to cracking crypto but in this case you are trying to duplicate a file it sounds like right? I'm sure someone will come up with an in memory solution etc that somebody didn't think of. In short that $75k problem is probably more like 7.5k or even $750.
Not to mention: if I'm trying to hack a government site do you think I'm morally opposed to creating a botnet for ~free?
Re: (Score:2)
These days GPUs are more than fast enough to do some pretty impressive crypto-cracko. No need to get custom FPGA boards/software.
Re:Gonna need a reference here... (Score:5, Insightful)
A quick search found "SHA-1 hashing algorithm could succumb to $75K attack, researchers say" (08 Oct 15) http://www.pcadvisor.co.uk/new... [pcadvisor.co.uk] "... US$75,000 and $120,000 to mount a viable attack using freely available cloud-computing services" "... someone can create two different files that have the same hash, it's possible to digitally sign one" Try searching for 75K or $75,000 by date and see what other public news can be found :)
Which doesn't allow a web site's certificate to be "cracked". The article is bogus.
The $75K-$120K figure is the estimated cost to find a SHA-1 hash collision. That is, to find two inputs that hash to the same value. The inputs will be random byte strings. Researchers have demonstrated that with such a collision it is possible to create two certificates that have the same signature, but in order to do that they also have to construct the RSA signing keys in a particular way.
But collisions do not enable the construction of fake certificates that appear to be signed by an arbitrary, unknown, private key. For that, you'd need to be able to find an input that hashes to a specific value. This is a completely different -- and dramatically harder -- problem than finding two inputs that hash to the same value. In addition, you'd probably need to find an input with a particular structure that hashes to a particular value, which is harder yet.
Good cryptographic hash functions have both "collision resistance" and "second pre-image resistance". SHA-1's collision resistance has been broken, which does make it insecure for certain uses, in algorithms that depend on collision resistance, but doesn't directly affect other uses -- like digital certificates -- that depend only on second pre-image resistance. It does hint that perhaps there is a weakness that may someday allow a second pre-image attack, which makes moving away from SHA-1 a good idea. But it has no direct impact on the security of CA certificates.
Re: (Score:2)
Correct, but note the chosen-prefix collision algorithm (sufficient for forging certs) proved to be easier in md5 than full second pre-image computation.
Yes, that's the attack I mentioned, which required not only chosen-prefix collisions, but also the freedom to choose the public keys for both certs.
Re: (Score:1)
The story is here:
http://www.theregister.co.uk/2015/10/09/sha1_75k_attack [theregister.co.uk]
The research paper is here:
http://eprint.iacr.org/2015/967.pdf [iacr.org] If one takes time to read the paper, which obviously the writer(s) for the Register did not, you will find the only computational work repo
Honeypot (Score:4, Informative)
The only thing thats going to be "discovered" is a log or trace of anyone looking at the site.
Its all just bait. If the person looking is found domestically, they might get the recruited by indictment offer.
Re: (Score:3)
OMG. The USAF has aircraft? Who knew?
Netcraft (Score:1)
The last time Netcraft confirmed something on /. it largely turned to be false. ...posted from NetBSD
Re: (Score:1)
Re:Well Of Course They Are (Score:5, Insightful)
A real, bona fide, practicing, reliability engineer explained to me once that military procurement procedures are intentionally biased toward older technologies and minimal upgrading. He said (and I believe him) that the military's nightmare scenario is that they will do something like installing 50000 computer boards in equipment scattered worldwide in poorly accessible equipment only to find that the ROMs they have used lose their memory after three or four years.
Obviously, that's primarily a hardware concern. but it's far from clear that it doesn't have considerable validity for software as well. And it's the way their process is set up.
Personally, I'm far from convinced that the current civilian -- ship now, we'll fix the problems in production -- approach to systems work is going work out well in the long run.
Re: (Score:2)
There is a cost to try to prevent abuse to the system.
A small private company may not pay the lowest cost for the service, but they don't need to pay for all the bs to make sure they are paying the lowest cost.
I can't think of a better argument for McAfee in 2 (Score:2)
Re: I can't think of a better argument for McAfee (Score:1)
Pure hype & FUD (Score:3)
SHA-1 hasn't been "defeated" -- at most, an attacker able to muster substantial computer resources *might* be able to discover a random binary file of random length that shares the same SHA-1 hash as something else.
In other words, there might be some denial-of-service potential if an attacker were able to forge the signature for an update file & trick a remote computer into replacing good files with nonworking ones, but that's pretty much *it* for the immediate future.
Should a new app use SHA-2? Of course. It's no harder to use, and bulletproof at this point. But there's no great urgency to replace SHA-1 in existing code at this point.
Re: (Score:1)
This pertains to certificates as used by websites, for browsers to authenticate the server.
https://blog.mozilla.org/secur... [mozilla.org]
https://en.wikipedia.org/wiki/... [wikipedia.org]
As often is the case on things secure, wikiP leaves a lot to be desired, but Teh Google may work for you, too.
Big organizations are slow as molasses, news at 11 (Score:4, Interesting)
Right now, I'm freelancing as a software developer, working for a company with a 10 billion yearly revenue. As you can imagine, the IT here is very complex and you have dozens of "software architects" trying to keep an eye on all the connections between systems.
At some point, an internal iOS app wouldn't work because since iOS 9, Apple by default requires decent algorithms for secure network connections. Upgrading these requires consulting half a dozen software architects, just to coordinate a simultaneous upgrade of all the systems.
And before that, I find myself explaining to software architects what the difference is between SSL and TLS.
So does Australian intelligence agency ASIO (Score:4, Interesting)
I noticed the other day that ASIO (Australian Security Intelligence Organisation) throws a SHA-1 warning in Chrome ("This site uses a weak security configuration (SHA-1 signatures), so your connection may not be private").
https://www.asio.gov.au/About-... [asio.gov.au]
Still almost two years left on the cert.
So I wonder:
1) Is this a terribly big deal and, as Chrome (i.e., Google) warns, should I be massively concerned that our chief intelligence agency is running with algorithms that are considered obsolete by the infosec community?!
or
2) Have they carefully looked at all the known SHA-1 weaknesses (and presumably several that are not known to the wider public) and determined the risk is acceptable and that (for example) people applying for jobs on their website are not in danger of having their details compromised?!
Re: (Score:2)
"Email traffic in and out of the network is filtered by an external provider."
Testing and first contact is often done via an external agency to see if the person even has the skills listed to any level expected.
Standard tests any private sector provider might offer via another private sector contractor.
If passed then an interview with a private sector contractor is of
Re:So does Australian intelligence agency ASIO (Score:4, Informative)
As I understand it constructing a rouge certificate by attacking secure hash functions requires either
1: a preimage attack on sha1 with chosen prefix and chosen suffix. This seems unlikely in the forseable future even for MD5.
2: a collision attack with distinct chosen prefix and common chosen suffiix combined with a CA that has poor procedures that allow the purchaser to predict what their certificate metadata will be. This has been demonstrated in the past for MD5 (google "md5 collisions inc"). Noone has yet demonstrated a full collision for SHA1, let alone a distinct chosen prefix collision.
As of right now I would class this as a lower risk than the risk of some CA simply issuing an end entity certificate to someone other than the legitimate owner of the domain and/or issuing and intermediate certificate to the attacker. Of course attack techniques are improving all the time so it's prudent to move sooner rather than later. Chrome is being a bit alarmist because they know if they don't then people won't move until it's too late.
B*****cks! (Score:3)
If this post is a true reflection of the source material then its a Load of Fetted Dingoes Kidneys.
"Netcraft confirms many U.S. Department of Defense websites, including a remote access service used by the Missile Defense Agency, are more vulnerable to man-in-the-middle attacks than most consumer websites." - True but not by enough to matter unless you can utilize the worlds GRP in processors.
"even though NIST banned new use of this signature algorithm two years ago." - Not banned, deprecated & there is an application in the works to continue issuance until the end of 2016.
"vulnerable to attack by enemy governments and criminals who can stump up enough cash ($75,000) to crack the certificates." - That is a gross underestimate by many many orders of magnitude. The figure I guess comes from the recent paper where the researches spent about this much to generate a collision for the most inner part of the algorithm, that was NOT against the entire signature function which would be orders of magnitude more costly in processing time.
Common misunderstandings WRT TLS1 and SHA1 (Score:2)
TLSv1 is not insecure regardless of what PCI asserts. There have been a number of implementation flaws having been fixed in various implementations and design flaws that have been effectively worked around. There are no credible attacks for a fully patched and properly configured TLSv1 implementation.
SHA-1 vulnerabilities DO NOT affect sites still using SHA-1 any more than they affect everyone else still willing to accept certs with SHA1.
The reason for this is simple: If I'm an attacker crafting public k