Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

When did POP and IMAP become a “legacy protocol?”

boston.conman.org

Post reply on HN
Print view View original

201–210 of 222 posts

Re: When did POP and IMAP become a “legacy protocol?”

#201

Post by Avamander »

shakna wrote: post #200
shadowgovt wrote: post #193

Earlier quoted context omitted.

This is a self-signed cert with no chain of trust to a cert issuer, which means we're back to square one... No way to know that whoever is providing the data to Gemini isn't lying about being Conman Laboratories.

Again, that's part of the Gemini spec. > 4.2 Server certificate validation > Clients can validate TLS connections however they like (including not at all) but the strongly RECOMMENDED approach is to implement a lightweight "TOFU" certificate-pinning system which treats self-signed certificates as first- class citizens. This greatly reduces TLS overhead on the network (only one cert needs to be sent, not a whole chain…

That is a terrible security assessment and it is an awful model for the web.

OpenSSH's TOFU works in its specific context primarily because SSH targets have been connected to beforehand and you can't place an evil proxy between. In order to prevent issues with TOFU, we've got SSHFP DNS records (so, trusting DNSSEC).

Now with the web, it's already rather ridiculous to suggest that it's not a terrible security model to not visit any new websites on untrusted connections. Plus the seeming lack of alternative methods (like SSHFP/TLSA + DNSSEC) to establish trust with untrustworthy networks (which well, most networks should be considered as).

Re: When did POP and IMAP become a “legacy protocol?”

#202

Post by Avamander »

1vuio0pswjnm7 wrote: post #199
1vuio0pswjnm7 wrote: post #31

Earlier quoted context omitted.

"Lack of HTTPS on the author's site also adds a nice subtle flavour to the blogpost." This blog can be read over TLS using gemini://. printf 'gemini://gemini.conman.org/boston/2022/09/22.1\r\n' \ |openssl s_client -connect 71.19.142.20:1965 -ign_eof Also https://portal.mozz.us/gemini/gemini.conman.org/boston/2022/...

The Gemini protocol is not a commercially-controlled HTTPS. Some folks like it better than HTTPS. 4.2 Server certificate validation Clients can validate TLS connections however they like (including not at all) but the strongly RECOMMENDED approach is to implement a lightweight "TOFU" certificate-pinning system which treats self-signed certificates as first- class citizens. This greatly reduces TLS overhead on the net…

Some people might like it more, but it's a terrible model.

Most ISP's can't be trusted, TOFU becomes basically useless. Ignoring that major issue with the model, it's also unusable in especially untrustworthy networks like Airport WiFi. I'm also going to preemptively say that suggesting not to visit new websites on those networks (because you can't TOFU) is just ridiculous.

"It is not awful" in this context is a very strong claim with little backing it up.

Re: When did POP and IMAP become a “legacy protocol?”

#203

Post by megous »

magicalhippo wrote: post #165
megous wrote: post #159

Earlier quoted context omitted.

What does oauth have to tho with authentication (let alone 2FA)?

Besides being used for authentication? https://learn.microsoft.com/en-us/exchange/client-developer/...

More like authorization. Authentication is completely opaque for most people using gmail. (except for those very few using service accounts and signing their own authorization tokens)

Or maybe you can enlighten me how you can get the token for XOAUTH2 from just your gmail email address and password without involving any opaque google service.

Authentication is happening completely outside of OAuth inside some google black box. 2FA has nothing to do with OAuth at all. It's just another feature of the google's black box which decides whether to give you the access/refresh tokens or not.

Re: When did POP and IMAP become a “legacy protocol?”

#204

Post by megous »

billpg wrote: post #161
megous wrote: post #152

Earlier quoted context omitted.

What downsides POP3 has? Looks like a terribly simple protocol and does the job of moving messages from one place to another quite well for me. Having to use anything more complex would be a downgrade. More complex to setup on server and client side, with more options and more problems to take care of. I like to use the simplest tool for the job.

The UIDL command is specified as an optional command, but it's really required. https://billpg.com/pop3-uidl/ The workload required to poll is heavy. You need to reconnect TCP, TLS and login. Once you find you have no messages, you have start over to check again. https://billpg.com/pop3-commit-refresh/ Clients and servers need to keep a short-term "message id" to long-term "unique-id" map. https://billpg.com/pop3-mes…

Looks like most of these are issues for large providers only or if you have multiple clients/protocols enabled, which is I guess fair. Thanks for the overview, it's always interesting to see limitations of protocols I use daily.

I use POP3 only to move messages from my mail server's mailbox on a VPS to my LAN using a pull method. Polled mailbox is thus mostly empty or has very few messages at each poll. So it's a nice fit.

Re: When did POP and IMAP become a “legacy protocol?”

#206

Post by shadowgovt »

1vuio0pswjnm7 wrote: post #194
shadowgovt wrote: post #38

Earlier quoted context omitted.

Do either of these address the underlying problem that without https there's no guarantee that the blog content hasn't been modified in transit? Neither Gemini nor the Internet Archive have access to the content through a channel other than the insecure HTTP endpoint, right?

The Gemini to WWW portal does have access to the content via TLS1.2 or greater, as that is the only way content is served under the Gemini protocol. AFAIK, Internet Archive (IA) does not crawl gemini://. I thought perhaps IA might have crawled https://portal.mozz.us , but I was mistaken. Regarding the issue of "integrity", i.e., not being modified in transit, ideally all www pages could have a hash (signature), or "d…

> As such, there is some (misplaced) trust involved when people use IA, Google or other intermediaries

That's the unfortunate reality of trust as a currency... On average, people are way more likely to trust Google, a household name, than Gemini, a three-year-old brand-new protocol with its own mystery set of new and exciting not-yet-discovered security issues.

Google does mis-crawl all the time (in fact, they have a whole division dedicated to confirming whether sites aren't detecting their crawler and actively lying to them; sites that do get penalized in search results). But it's Google, so people believe they have a vested interest in getting it right. There's no such guarantees in people's minds for data coming over Gemini protocol; it hasn't been earned yet.

Re: When did POP and IMAP become a “legacy protocol?”

#207

Post by ReallyOldLurker »

Avamander wrote: post #154
megous wrote: post #152

Earlier quoted context omitted.

What downsides POP3 has? Looks like a terribly simple protocol and does the job of moving messages from one place to another quite well for me. Having to use anything more complex would be a downgrade. More complex to setup on server and client side, with more options and more problems to take care of. I like to use the simplest tool for the job.

> What downsides POP3 has? Looks like a terribly simple protocol Exactly that, it's terribly simple. People have multiple devices, that alone makes POP3 an annoying protocol to use.

>> ... multiple devices, that alone...

A big assumption. POP3 works perfectly fine and is preferable in my situation.

Re: When did POP and IMAP become a “legacy protocol?”

#208

Post by tptacek »

Avamander wrote: post #201
shakna wrote: post #200

Earlier quoted context omitted.

Again, that's part of the Gemini spec. > 4.2 Server certificate validation > Clients can validate TLS connections however they like (including not at all) but the strongly RECOMMENDED approach is to implement a lightweight "TOFU" certificate-pinning system which treats self-signed certificates as first- class citizens. This greatly reduces TLS overhead on the network (only one cert needs to be sent, not a whole chain…

That is a terrible security assessment and it is an awful model for the web. OpenSSH's TOFU works in its specific context primarily because SSH targets have been connected to beforehand and you can't place an evil proxy between. In order to prevent issues with TOFU, we've got SSHFP DNS records (so, trusting DNSSEC). Now with the web, it's already rather ridiculous to suggest that it's not a terrible security model to…

Giving the DNS PKI any influence over your SSH connections seems insane, since there is literally no reason whatsoever the DNS root and TLD operators should have any say whatsoever in how you connect to your own servers.

If you're worried about key continuity issues, do what large SSH fleet deployers do, and use certificates. Key continuity was the motivating use case for SSH certificates, before they were used to do MFA/SSO logins for users.

I don't disagree with the analysis of Gemini's trust model; I think you're right that key continuity doesn't work on the scale of the public web. Of course, I don't think DNSSEC has any answers here, either; the Web PKI is probably the best thing we've got right now.

Re: When did POP and IMAP become a “legacy protocol?”

#209

Post by 1vuio0pswjnm7 »

1vuio0pswjnm7 wrote: post #31
Avamander wrote: post #3

I get the impression that the article's author didn't really read the linked help page. It's basic auth that's getting deprecated, due to being considered a legacy authentication protocol. For good reasons, as described. That aside, POP should really be considered legacy, it comes with many downsides that hinder people's e-mail usage. IMAP is definitely more functional, but has a successor - JMAP. So in some sense, i…

"Lack of HTTPS on the author's site also adds a nice subtle flavour to the blogpost." This blog can be read over TLS using gemini://. printf 'gemini://gemini.conman.org/boston/2022/09/22.1\r\n' \ |openssl s_client -connect 71.19.142.20:1965 -ign_eof Also https://portal.mozz.us/gemini/gemini.conman.org/boston/2022/...

It's consistently baffling to me to why people try to "attack" Gemini, as if it is some sort of "threat". A threat to what I am not sure. One of the common foibles is they try to compare it to "the web". This is absurd since Gemini is not "the web", nor is it anything close to a Hypertext Transfer Protocol (HTTP).

IMHO, at best Gemini is a Gopher redux. No one is planning to run commerce over Gopher. It is no different for Gemini. It's a "people's protocol", not a corporate one. It does not even have an RFC. It's relatively easy to write clients and servers. No corporate vendor or advertising sponsorship is needed. No one needs to have a "business model" to publish data/information via Gemini.

The Gemini FAQ explicitly addresses critics who see the internet through web-tinted glasses:

1.6 Do you really think you can replace the web?

Not for a minute! Nor does anybody involved with Gemini want to destroy Gopherspace. Gemini is not intended to replace either Gopher or the web, but to co-exist peacefully alongside them as one more option which people can freely choose to use if it suits them. In the same way that some people currently serve the same content via gopher and the web, people will be able to "bihost" or "trihost" content on whichever combination of protocols they think offer the best match to their technical, philosophical and aesthetic requirements and those of their intended audience.

Re: When did POP and IMAP become a “legacy protocol?”

#210

Post by Avamander »

tptacek wrote: post #208
Avamander wrote: post #201

Earlier quoted context omitted.

That is a terrible security assessment and it is an awful model for the web. OpenSSH's TOFU works in its specific context primarily because SSH targets have been connected to beforehand and you can't place an evil proxy between. In order to prevent issues with TOFU, we've got SSHFP DNS records (so, trusting DNSSEC). Now with the web, it's already rather ridiculous to suggest that it's not a terrible security model to…

Giving the DNS PKI any influence over your SSH connections seems insane, since there is literally no reason whatsoever the DNS root and TLD operators should have any say whatsoever in how you connect to your own servers. If you're worried about key continuity issues, do what large SSH fleet deployers do, and use certificates. Key continuity was the motivating use case for SSH certificates, before they were used to do…

I just highlighted the fact that OpenSSH (which was an inspiration to the Gemini people) finds this an issue and have devised solutions. You and everyone else are absolutely free to not to trust DNSSEC and deal with the pitfalls of TOFU-over-internet in some other way.

Though in theory, just using SSHFP+DNSSEC and those operators being malicious shouldn't degrade SSH's security, it should only hinder the same TOFU. In which case I suspect people would fall back to the Web PKI to look up the reason for the mismatch.

Post reply on HN