US Military Websites Still Relying On SHA-1 (netcraft.com)
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.
...how did the $75,000 figure come to be? Is that what it costs for computer time to brute-force something? Is that what someone that holds a huge list of brute-calculated keys charges to do a lookup and provide the reverse-engineered private key?
Do not look into laser with remaining eye.
Given the pages are mostly a picture, logos, public mission statements, employment/recruiting details, domestic and global propaganda images.
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.
Domestic spying is now "Benign Information Gathering"
Microsoft gives NSA direct access to their mail servers because they still use the same shitty encryption also.
The last time Netcraft confirmed something on /. it largely turned to be false. ...posted from NetBSD
If the CinC is a security expert, we won't have to read about clownshoes bullshit like this anymore.
Thank you, Slashdot Mobile, for not alerting me to the fact I had exceeded my character limit. Obviously, John McAfee would've been just as good a candidate for Emperor of Rome.
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.
Libs fly, when they get thrown off rooftops.
https://www.schneier.com/blog/archives/2005/02/sha1_broken.html
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.
8 of 13 people found this answer helpful. Did you?
And here I thought there was a web interface for launching missiles, and they could be hacked...!
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-...
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?!
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.
You can't see ANYTHING from a car, You've got to get out of the goddamned contraption and walk...Edward Abbey
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.
If you use Google's business service offerings for email etc, the only way to sync credentials is to ship them an SHA1 hash. Not even a salted hash, just a hash.
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.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
A stupid name change for an upgraded version of the same software because Nutscrape owned the trademark on SSL?
Nailed it.
It would be quicker and cheaper to send phishing emails to military members and gain legit logon credentials.
Another problem I've seen are the number of .gov servers which communicate using SSLv3 and weak TLSv1 ciphers.
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 keys with useful signature collisions I sure as heck will not be wasting my time with one individual site. Instead I will be going after intermediate certificates which offer me the ability to link my own intermediate and impersonate every site on the planet to any browser on the planet still willing to accept SHA1 signatures.
If your browser still accepts SHA-1 your not really any more secure than users of these mil sites.
All the rules trying to "force" "fairness" have made the government stupid, inept, powerless, unable to attract talent, unable to handle basic problems, unable to serve its people as it was meant. Please, don't vote for more services/spending/etc until we fix these issues. Allow the government, for purposes of employment, to be treated as any other commercial entity, so that cases for wrongful termination, discrimination, etc can be heard without the "government allowing it". Then get rid of all this nonsense like gs scale, lowest bidder (you get what you pay for!), iso 9000 certified minority, veteran owned swindler contractors getting preference, contracts written with all sorts of fairness caveats that prevent the likes of Google, Apple, Microsoft, Oracle, etc from competing in government contracting. All these idiotic rules have done is force unfairness to the taxpayers in guaranteeing the worst of the worst contractors and the wrong people work in government positions making it utterly useless. Heathcare.gov should have been a wakeup call. Here's another example. This extends out beyond tech as well. The stupid rules apply equally in all sectors of government (wonder why we have a story on the FDA and decongestants on Slashdot the same day as this?). Stop voting for party's, start demanding accountability, and get rid of all this (un)fairness doctrine in the government. Maybe then we can be a strong country again rather than the laughing stock of the world and the butt of every joke.
ohh gee.. don' t they know north korean script kiddies with 3d video cards can crack sha-1 ?
Or, stay with me on this, TLS is a standardized release of SSL which does (at least) two things: first, it more aptly describes what the protocol does, and second it corrects most of the deficiencies in the predecessor.
Just sayin'.