31–40 of 136 posts
Seems like the SSL certificates that CloudFlare automatically generates for sites are SHA-1 signed. Anyone know if they're planning to upgrade to SHA-2?
They can be seen in the Chrome discussion thread, complaining to Google that the timeline is too aggressive. But they're a good company, and I imagine they'll update as soon as they can.
(For anyone else, here's the link: https://groups.google.com/a/chromium.org/d/msg/blink-dev/2-R...)
Two nits, both pedantic: An attack on SHA1 that makes certificate forgery viable within the next few years doesn't seem very likely, although over the long term it might be. The attack on SHA1 isn't like the attacks on RSA-1024; my sense is that the literature already knows how to break RSA-1024 given enough compute, but does not know how to do that with SHA1. Further, factoring RSA-1024 provides an attacker with a t…
@tptacek - I tried to include enough detail to make it clear that a SHA-1 forgery isn't as trivial as a brute force. That you'd have to "coax a Certificate Authority" into issuing you a targeted forgery, and that that's what the MD5 team did. The SHA-3 mention at the very bottom was in the spirit of "all things are broken eventually", not a specific comment on SHA-2 (though my understanding is that there are some con…
I'm also not comparing attacks on SHA1 to brute force (which is also not how MD5 fell).
It would be helpful, when people posit attacks on SHA1, if they'd cite the literature they're referring to.
Earlier quoted context omitted.
From the OP: If you poke around Google's SSL configuration, you'll see that (!) they use certificates signed with SHA-1. But each certificate expires in 3 months, a short-lived window that reduces the chances that a certificate could be forged, while they migrate to SHA-2 in 2015.
If going SHA-2 only requires a request flag, why so long for a transition? Is there some downside (e.g. old clients that don't support it) that holds Google off?
Would be interesting to know how this affects Git version control, which has SHA-1 at its core.
I assume you would need to forge a meaningful (and potentially harmful) commit with the same SHA-1 as an existing one to do arm. That's probably more difficult than forging an SSL certificate (since the actual contents of the blob are more constrained that the certificate file, probably). I'm also not really sure what would happen if commits made after the "compromised" one happened to conflict with it but I'm pretty…
I'm not familiar enough with the inner workings of git to know, but I imagine it would be a pain to juggle updating new commits from people working from a local copy of the repo - potentially your malfeasance would be detected quickly if you tried to calculate a diff between the old file and the new file from the local copy (which would presumably not be updated, given that the checksums match).
That said, if people are in the habit of signing their tags/commits using SHA-1, then that would be just as vulnerable as any other signing problem.
Would be interesting to know how this affects Git version control, which has SHA-1 at its core.
> If it has the same SHA1, it means that when we receive the object from the other end, we will not overwrite the object we already have.
> So what happens is that if we ever see a collision, the "earlier" object in any particular repository will always end up overriding. But note that "earlier" is obviously per-repository, in the sense that the git object network generates a DAG that is not fully ordered, so while different repositories will agree about what is "earlier" in the case of direct ancestry, if the object came through separate and not directly related branches, two different repos may obviously have gotten the two objects in different order.
> However, the "earlier will override" is very much what you want from a security standpoint: remember that the git model is that you should primarily trust only your own repository.
> So if you do a "git pull", the new incoming objects are by definition less trustworthy than the objects you already have, and as such it would be wrong to allow a new object to replace an old one.
...
> in this case, the collision is entirely a non-issue: you'll get a "bad" repository that is different from what the attacker intended, but since you'll never actually use his colliding object, it's literally no different from the attacker just not having found a collision at all, but just using the object you already had (ie it's 100% equivalent to the "trivial" collision of the identical file generating the same SHA1).
Earlier quoted context omitted.
They can be seen in the Chrome discussion thread, complaining to Google that the timeline is too aggressive. But they're a good company, and I imagine they'll update as soon as they can.
Ah interesting, thanks. (For anyone else, here's the link: https://groups.google.com/a/chromium.org/d/msg/blink-dev/2-R... )
Two nits, both pedantic: An attack on SHA1 that makes certificate forgery viable within the next few years doesn't seem very likely, although over the long term it might be. The attack on SHA1 isn't like the attacks on RSA-1024; my sense is that the literature already knows how to break RSA-1024 given enough compute, but does not know how to do that with SHA1. Further, factoring RSA-1024 provides an attacker with a t…
[1] https://marc-stevens.nl/research/papers/EC13-S.pdf [2] http://people.scs.carleton.ca/~paulv/papers/JoC97.pdf
It's surprising how much energy Certificate Authorities invest into arguing about this. Instead, they should invest that energy into improving their SHA-2 support and helping their customers migrate.
Can someone post a summary of the part of the story hinted to by the headline? I couldn't find it.
Basically, by 2015, Google will update Chrome to show websites with HTTPS certificates using SHA-1 as "insecure." The level of insecurity shown will get more severe over time, as well as being based on when your certificate expires. Here is the full link for details:
http://googleonlinesecurity.blogspot.com/2014/09/gradually-s...