Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
Compare cell phone plans using Wirefly's innovative plan comparison tool ×
The Military Encryption Security United States

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.
This discussion has been archived. No new comments can be posted.

US Military Websites Still Relying On SHA-1

Comments Filter:
  • by TWX ( 665546 ) on Tuesday October 27, 2015 @02:21AM (#50807683)
    ...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?
    • by AHuxley ( 892839 ) on Tuesday October 27, 2015 @02:39AM (#50807723) Homepage Journal
      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 :)
      • 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

        • by ILongForDarkness ( 1134931 ) on Tuesday October 27, 2015 @07:23AM (#50808477)

          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?

        • These days GPUs are more than fast enough to do some pretty impressive crypto-cracko. No need to get custom FPGA boards/software.

      • by swillden ( 191260 ) <shawn-ds@willden.org> on Tuesday October 27, 2015 @10:13AM (#50809553) Homepage Journal

        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.

    • by Anonymous Coward
      The 75K figure comes from mis-reporting by the Register of work which Stevens, et.al. did on using disturbance vectors to locate optimal starting points for locating collisions in the compression function which SHA-1 is based on.

      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)

    by AHuxley ( 892839 ) on Tuesday October 27, 2015 @02:22AM (#50807685) Homepage Journal
    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.
  • by Anonymous Coward

    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.
  • by Miamicanes ( 730264 ) on Tuesday October 27, 2015 @03:06AM (#50807779)

    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.

  • by cerberusss ( 660701 ) on Tuesday October 27, 2015 @05:34AM (#50808097) Homepage Journal

    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.

  • by trawg ( 308495 ) on Tuesday October 27, 2015 @06:50AM (#50808349) Homepage

    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?!

    • by AHuxley ( 892839 )
      A lot of nations try ideas like the UK's Government Secure Intranet https://en.wikipedia.org/wiki/... [wikipedia.org] and some network operations centre.
      "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
    • 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.

  • by ramriot ( 1354111 ) on Tuesday October 27, 2015 @07:57AM (#50808611)

    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.

  • 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

Real Programs don't use shared text. Otherwise, how can they use functions for scratch space after they are finished calling them?

Working...