Thread

Git 3.0's upcoming SHA-256 default will be a costly mistake

570 points · 536 comments · chmaynard

kpcyrd · 1790876562 · focus · HN ↗
This article is full of mistakes and misleading claims:
1) It's claiming SHA1 insecurity is theoretical, while SHAttered from 2017 was specifically a pratical proof of concept. The only reason Git wasn't affected, is because they didn't bother bruteforcing a git-blob prefix.
2) It's claiming collision attacks don't matter, only second-preimage attacks do. This is incorrect, collision attacks are enough for code-smuggling problems, when two repositories are on the same git commit (verified by the full commit hash), yet contain different code in their git checkout.
3) The Linus quote "The real security is in distribution" is arguing that "git's content-addressed system should not be used to address content". It's arguing that, in case of curl|sh, you shouldn't use a sha256sum-gate to pin the content to something you've reviewed, you should instead ensure curl is fetching from an https server.
1. schacon · 1790877053 · focus · HN ↗
  1) I link to the SHAttered paper, as well as Shambles. Git projects were not affected because it is an inefficient attack vector. I say it's impractical to exploit, which I think everyone agrees with.
  2) I specifically argue that even if both attacks were practical and cheap, it's still not the problem we should be focusing on.
  3) Have you read this email (that I linked to)? It is almost the same general message (20 years ago) that this blog post is. It literally goes though a theoretical object replacement attack and how dumb this scenario is and so SHA-1 is fine.
  <a href="https://lore.kernel.org/git/Pine.LNX.4.58.0504291221250.18901@ppc970.osdl.org/" rel="nofollow">https://lore.kernel.org/git/Pine.LNX.4.58.0504291221250.1890...
  1. bityard · 1790909767 · focus · HN ↗
    In agreement that this is good old fashioned cargo-cult security theatre, but tom7 also coined a more catchy phrase for this, he calls it "toxic max-security." <a href="http://tom7.org/httpv/httpv.pdf" rel="nofollow">http://tom7.org/httpv/httpv.pdf
    ozim · 1790922095 · focus · HN ↗
    Oh I call those people „TLS antivaxxers”.
    Conveniently Tom didn’t mention anything about Edward Snowden and what he published. That was basically start of TLS everywhere.
    Then he didn’t mention ISP idiots that were actually injecting ads to cute websites like Tom’s. I hope Tom likes when his website is used by ISP to make money on ads he doesn’t have any control over.
    Then he goes on to criticize certificate transparency, but it works. Companies got kicked out from trusted root program because they were doing stupid stuff like making certs they shouldn’t.
    Let’s not forget glorious state of Kazakhstan where without TLS they would just listen to all traffic - well with TLS they were trying to pull MITM but were uncovered and got their stuff removed by TLS ecosystem.
    voidnap · 1790924174 · focus · HN ↗
    If I recall, tom7 was at odds with chrome throwing up a warning at users trying to visit his website because he didn't support TLS on it. He wasn't against TLS. Calling them a TLS antivaxxer is not accurate.
    ozim · 1790924789 · focus · HN ↗
    I just read the pdf that parent poster included.
    While he does indeed have extensive knowledge of TLS/SSL. He still completely side steps points I wrote about and exaggerated many minor inconveniences. While PDF seems quite up to date it also picks on stuff that is not there anymore like green padlocks.
    kbolino · 1790945068 · focus · HN ↗
    I don't particularly like the terminology but, still, the attitude that TLS is just for "sensitive" websites, actions, or data is quite wrong. Even if you don't care about surveillance or ISP ad injection, you should care about infrastructure compromises and exploit injection. It sounds exotic and high effort but it's not. Unless you're personally auditing the coffee shop, airport, library, hotel, etc. Wi-Fi hardware and network before you connect, it could affect you easily. It's not even a choice that reasonably belongs in the hands of website owners, because they don't control all the paths from users back to them. And even residential and municipal ISP networks can get compromised, too, along with data centers and everything in between.
    ozim · 1790952904 · focus · HN ↗
    Yeah I kind of forgot exploit injection in the spur of the moment as of course I rushed to correct "someone on the internet".
    ISP injecting ads is like annoying but if someone knows as much as Tom about TLS and totally skips rouge "airport wi-fi" can use his website to own someones else device that is the argument I should use for calling him or anyone else names on the internet.
    I guess Kazakhstan example kind of covers it, because I do believe they would definetly deliver malicious payloads to dissidents.
    kbolino · 1790953260 · focus · HN ↗
    There's a lot of lingering "SSL is just for your bank" sentiment out there. There are other ways to achieve integrity protection than using TLS, and there are even ways to use TLS without WebPKI, but nobody is putting any effort into any of them, and so TLS+WebPKI is the solution, and no website is exempt, because it is fundamentally an infrastructure problem.
    ForHackernews · 1790937960 · focus · HN ↗
    > I hope Tom likes when his website is used by ISP to make money on ads he doesn’t have any control over.
    You mean like how Google makes money showing ads against your content that you don't control? You mean how basically every ad network works?
    yrxuthst · 1790944447 · focus · HN ↗
    No, Google shows ads on their own domain. You would have to opt in by adding the script, for their ads to show up on your domain like the ISP ads do.
    ForHackernews · 1790979000 · focus · HN ↗
    Did you opt-in to having your content shown in "previews" and Gemini "instant answers" along with Google ads?
    I could just as easily argue that by paying my ISP and signing up to their T&Cs, I've opted in to seeing their ads, not the ads from some random website.
    ozim · 1790952446 · focus · HN ↗
    What ISPs were doing they were injecting ads and you had no way of knowing it happens unless some visitor was annoyed enough to make you aware by sending you a screenshot.
    With Google you have to make an agreement and put piece of code in your website willingly and then you get minimal cut but still, that is totally your choice.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.