Hacker News Reader

Comment by advisedwang | Hacker News Reader

I understand the desire to use trust-on-first-use to get rid of certificate authorities (some of the most dispicable and untrustworthy organizations around, and the largest security hole in TLS). However trust-on-first-use basically hands any long-term man-in-the-middle a complete victory. Authoritarian regimes are going to require ISPs to mitm every connection from first use, and hand over whatever data is desired to the secret police.

CAA, Key Pinning, certificate transparency all bring the risk of CA abuse way down without opening a huge new vector of ISP abuse.

View on HN

Personally I've come to believe none of it matters and that encryption is a total waste of time, at least for the kind of stuff I would want to publish using Gemini (long-form text) where there's nothing interactive or user-specific in any request. Just the act of making a network connection gives away who you are, where you are, when you are online, and what you're reading: https://kieranhealy.org/blog/archives/2013/06/09/using-metad...

Restricting Gemini to just long-form text (one way consumption) is really reducing the possibilities Gemini can have, IMO. Though the whole minimalist attitude would probably preclude most of them.

> reducing the possibilities Gemini can have

Gemini is all about reducing possibilities. If you want more possibilities, use the web IMO

Fair. I certainly think that type of simplistic Gemini has a place in the world.

But I think ">If you want more possibilities, use the web IMO" goes against the minimalist ethos of Gemini as well; I don't want something as bloated as the web, but perhaps I do want a comment section of my posts? I think that's not too bloated to be thrown in with the rest of the web. But it might very well be too bloated to throw into Gemini, which is reasonable.

Footnote: An email alongside the post + the author editing the post with meaningful and thoughtful contributions could perhaps be a substitute.

With Gemini, the philosophy of intentional austerity means that everyone is going to be a bit unhappy, and want some feature added to it. Its "incompleteness" is a necessary consequence of its design philosophy -- it calls on us to accept it "as-is" rather than try and extend the spec. A mailing list for comments, as you describe, would be more "gemini philosophy". This is what the author does:

=> https://lists.sr.ht/~sircmpwn/public-inbox

Mailing lists are a bit out of vogue, but there's no reason not to bring them back into vogue, at least for people sympathetic to Gemini's ideals.

I find it laudable you're openly admitting making users unhappy.

Of course, what's "added" and what's "simple" is a political value choice in an of itself.

Using a mailing list for comments sounds like "returning to the golden days when we didn't need to take non-techies people seriously but could tell them what to use their cognitive capacity for" i.e. to learn arcane UI that never even tried to really take into account all the learnings of Human-computer interaction about how learning and cognition works.

It really doesn't sound like there's been an actual critical discussion taking into account the needs of a substantial array of potential users. Instead the design seems like a reactive wish to return to olden days.

Which is okay of course, just how it's presentes seems skewed in a very particular way.

I really don't think it's okay. I've noticed this type of "tech reactionarism" a lot recently in open source as a form of wishful thinking. This author in particular seems to write about it quite a lot. But it's misleading and not being fair to the users, who deserve to know that what they're doing is a waste of time. Unless someone wants to pull out the old teletype and modem connected to a phone line then we can't go back to the olden days. And honestly, nobody wants to do that in 2021.

> what they're doing is a waste of time.

I fundamentally disagree here. There are ways that people waste their time on the web that are far more pernicious than "learning how to write gemtext markup"

The web is in a seriously messed up state, and in many ways, things are getting worse. I think it's far more dangerous to shrug our shoulders and just let things continue as they are than to work on projects that attempt to present an alternative.

I don't see how you're disagreeing, you seem to acknowledge that it is a waste of time. And I don't see how any one of these is more pernicious than another, there can be bad actors, cyberstalkers, scammers, criminals everywhere on the net including on gemini.

Edit: A point I'd like to make here is that Gemini is not an alternative web and never will be, according to the designer's own statements. I share your frustration with some of the modern aspects of the web but the web also does a lot of things right that we may take for granted, let's not be so cynical as to forget that. I'm guilty of it myself in the past but no longer, and part of it was because people misled me.

Yeah, depends on the direction from which you look at "okay" from.

Arguably there are worse things in society than techies making tech for themselves.

Ironically though ... , to me it seems that Gemini and Facebook, though culturally presented as opposites here, are really fruits of the same tree, just different gardens and different stages of growth.

No, we are talking about reducing security here.

Alternate streams for rich content.

I think that this restriction is good, though. For other uses, there are other file formats (Gemini protocol supports the use of other file formats too, e.g. you can use audio/ogg or audio/opus for audio, image/png or image/xpixmap for pictures, etc; a client might not support them and a user might not want them, so really you should use text if that is suitable (I am one who would rather have an explanation in text rather than a video), although you can still have links to other files too if needed) and other protocol (e.g. NNTP for slow communication (including if you want to allow comments for your articles), IRC for fast communication, Telnet/SSH for interactive applications, and other protocol should be made up for database access then you can use a SQLite extension to access them) (the text/gemini format can include links to other protocols too).

What I think is that a "insecure-gemini:" scheme should be added, which is the same except without TLS and 6x response is not allowed (if a client certificate is required, it must redirect to the protocol with TLS).

"pollux://"

People, or businesses, that you know in real life could exchange certificate hashes in person.

This is one of those things that usually garners the response "normal people would never do that", but honestly I'm surprised that no-one has even tried.

Let's say that web browsers put a short hash of the certificate right in the URL bar. Amazon, for example, could print its hash on every shipping box. Banks could print their hashes on plaques in every branch. Newspapers on their, well, newspapers. Media organizations could occasionally add them to their TV logos and radio jingles. And so on. There's any number of out-of-band channels available.

For most sites, you actually wouldn't need to verify the hash anyway. You usually wouldn't care. But when you did care, I honestly think this isn't such a crazy idea.

It’s a good form of secondary support for authentication, and is a reasonable foothold to start expanding circles of trust (I.e. second hand trust.. or “trust what my trusted source trusts”).

> People, or businesses, that you know in real life could exchange certificate hashes in person.

This happens about as often as using PGP email. Approximately never.

This is the exact response that I tried to cover with the rest of my comment.

I actually think it’s an interesting idea that merits some investigation.

My first idea is that it would be a nightmare from a supply chain security perspective. Eventually someone from the Amazon box printing company will be bribed to print a different certificate hash on 0.5% of the printed boxes, for example.

.onion addresses are hashes, but a hash long enough to prevent a brute forcing is also too long for people to consistently recognize. Is facebookwkhpilnemxj7asaniu7vnjjbiltxjghye3mhbshg7kx5tfyd.onion the right URL for Facebook or a clever near-collision?

This is only true if you limit yourself to standard character based hash representations.

I feel like whatever scheme you use, if it is too simple there won't be enough unique keys to go around, but if it is complex enough it can be subtly changed in ways a human would find hard to notice.

Isn't the whole point of a hash that you can't "subtly" change it?

Would you notice if someone changed the "f" in the middle of that onion link to an "l"?

Again, it's impossible, or should be impossible, to easily change a single character in a hash. The avalanche effect means that small changes in the input data will result in huge changes to the hash.

On the other hand, it's probably easy to brute force search a hash which is visually close enough for most people to not notice the difference.

The input data in this case is the private key so if you had that available to change, you would not need to do anything more as you could already control the real .onion domain.

The attack on things like onion domains would be finding another domain that to a human looks similar enough to be mistaken for the real deal. You'd do that by brute forcing (same as what Facebook did to get the "facebook" prefix in their onion domain) and for a sucessfull attack the space you need to brute force is limited by what humans can distinguish, which is smaller than the whole hash space.

that's the point of a machine-checked hash, because computers are really good at exact equality operations. humans have a much harder time with it.

The limit is much more about how many bits a human is capable of distinguishing reliably at a glance, which I think is very likely below the brute-forcible level

(The correct address is facebookwkhpilnemxj7asaniu7vnjjbiltxjqhye3mhbshg7kx5tfyd.onion)

("q" instead of "g").

Many years ago, I was put into a situation where I had to start using online banking. Being skeptical about security, I asked for something along the lines of a certificate hash that could be verified in person. They couldn't answer that. So I tried asking how I could verify that the certificate displayed by the web browser was correct. They couldn't answer that. In the end, I ended up trusting the padlock icon and being left with the impression that commercial security was mostly about the illusion of security. To this day I'm left with the impression that some sort of MITM attack would be possible through the creative abuse of certificate issuers and proxies since there is no direct means of verifying the certificate is authentic. And they won't take that final step since it shatters the illusion of security being simple.

Nowadays, all certificates have to be submitted to Certificate Transparency Logs and must have attached proof to be considered valid. Also, there are CAA records to ensure that only specific CAs are able to issue certificates.

I think it was more that a random bank teller could not be expected to explain the intricacies of certificate authorities and online encryption. The bank likely has a security whitepaper on their website which explains all this.

> mostly about the illusion of security. To this day I'm left with the impression that some sort of MITM attack would be possible through the creative abuse of certificate issuers and proxies since there is no direct means of verifying the certificate is authentic

Why would a bank's customer support agent know about encryption? Usually IT is a siloed function in most banks.

In a sane world, the bank would have a flier for the teller to give to the GP with several ways to verify the bank's key.

We only live without this because the bank can just reverse transactions when there is a problem and the police will fall pretty heavily on anybody that exploits the weakness. And also, because there are plenty of easier to exploit ones.

Trust on first use combined with preloaded public key lists is the best of both worlds in my opinion. You may say that browsers made in authoritarian countries would sabotage the preload lists, but they could also bundle illegitimate CAs or break HTTPS in other ways anyway.

This. Some standards bodies (arguably) made a big deal about client certificates some time ago to reliably pin client identities for client->server connections (whether it worked is a different story), and I certainly think having functionality for the reverse (pinning server identities) should exist too.

Doesn't have to be Gemini even, but I think getting buy in from browser vendors after the removal of HPKP is going to be a problem...

'HTTPS in other ways': https://en.wikipedia.org/wiki/Kazakhstan_man-in-the-middle_a...

Another option would be something similar to Go's sum database, but with something like a DHT instead of a hosted centralized service.

Or perhaps instead of a DHT, users could export all their certs to a file and combine/compare entries in a grassroots manner with each other and with devices on different networks.

SSH is TOFU.

SSH works.

There is no government effort to MitM SSH. And if there was, it would immediately crumble because not a single person manually verifies their ssh connection.

SSH has a different service model; there aren’t masses of anonymous clients connecting to a typical SSH server, but rather deliberate 1:1 relationships, which is why the model works there. And still, high-security environments deploy certificate SSH, specifically to avoid this problem.

Reply on news.ycombinator.com