When did POP and IMAP become a “legacy protocol?”(boston.conman.org)
boston.conman.org
When did POP and IMAP become a “legacy protocol?”
http://boston.conman.org//2022/09/22.1
221 comments
The linked help page doesn't make up for what the letter says. The letter is just plainly misleading.
Read it again - they're unambiguously saying that non-Microsoft email programs that rely on SMTP, POP and/or IMAP will "stop functioning when Microsoft chooses to disable these protocols".
That the linked help clarifies a little doesn't mean this is a flatly misleading letter.
Read it again - they're unambiguously saying that non-Microsoft email programs that rely on SMTP, POP and/or IMAP will "stop functioning when Microsoft chooses to disable these protocols".
That the linked help clarifies a little doesn't mean this is a flatly misleading letter.
This has already happened! My school promised email for life, and uses Microsoft's Office365. A couple months ago they sent out emails saying if you don't update your client to use "modern auth" (which was a new term for me) I'd lose the ability to check my email.
Well Microsoft blocks the Thunderbird embedded browser, so you can't complete the Oauth2 login. I've been effectively locked out of my account since (I'm not going to use the webmail just for this account - set up a forwarding email and told everyone to use my new address).
Well Microsoft blocks the Thunderbird embedded browser, so you can't complete the Oauth2 login. I've been effectively locked out of my account since (I'm not going to use the webmail just for this account - set up a forwarding email and told everyone to use my new address).
Microsoft doesn't by default block the embedded Thunderbird browser. An admin can however enable that setting.
Guess it would be nice with a fall-back option in Thunderbird to use the system browser.
So spoof the user agent.
That letter isn't from microsoft though, I manage several tenants, and none of our end users or admin got that letter.
specifically what is missing, is that email using basic auth won't disconnected OCT 1st because of the tons and tons of machine that do things like email faxes, and scans that do not support modern authentication.
This looks like whoever "enterprise services" is, they wrote a brief message that wasn't very accurate.
specifically what is missing, is that email using basic auth won't disconnected OCT 1st because of the tons and tons of machine that do things like email faxes, and scans that do not support modern authentication.
This looks like whoever "enterprise services" is, they wrote a brief message that wasn't very accurate.
We split off any of our "legacy" devices to SMTP2GO accounts.
It gets worse.
"We won't support clients that dont support microsoft supported practices" is a very short stone's throw away from "we won't support non-microsoft clients", as I've come to discover at my university, where I had to ask for permission to use an email client just for oauth to work.
Which is yet to be granted after 2 months (and if granted, will be granted site-wide ... i.e. unlikely unless there is a large demand for non-microsoft clients)
"We won't support clients that dont support microsoft supported practices" is a very short stone's throw away from "we won't support non-microsoft clients", as I've come to discover at my university, where I had to ask for permission to use an email client just for oauth to work.
Which is yet to be granted after 2 months (and if granted, will be granted site-wide ... i.e. unlikely unless there is a large demand for non-microsoft clients)
> Lack of HTTPS on the author's site also adds a nice subtle flavour to the blogpost.
If you're not doing anything requiring security, you don't need HTTPS, IMHO.
> POP should really be considered legacy
I know people who knowingly use POP to keep their remote boxes empty, and keep everything local, so I don't think we should decide for people that swiftly.
Similarly, I'll let the wisdom of "Teh Internetz" to decide whether JMAP is worthy of the effort to replace IMAP. Having a IETF RFC is a good start, but let's see...
If you're not doing anything requiring security, you don't need HTTPS, IMHO.
> POP should really be considered legacy
I know people who knowingly use POP to keep their remote boxes empty, and keep everything local, so I don't think we should decide for people that swiftly.
Similarly, I'll let the wisdom of "Teh Internetz" to decide whether JMAP is worthy of the effort to replace IMAP. Having a IETF RFC is a good start, but let's see...
> If you're not doing anything requiring security, you don't need HTTPS, IMHO.
I disagree, for a lot of reasons. For one thing, I don't want some random WI-FI to know every page I visit, even insecure pages.
I also don't want to leak any information about my browsing habits. Using https everywhere limits the information you leak about how much of your traffic is sensitive.
I disagree, for a lot of reasons. For one thing, I don't want some random WI-FI to know every page I visit, even insecure pages.
I also don't want to leak any information about my browsing habits. Using https everywhere limits the information you leak about how much of your traffic is sensitive.
Unless you use DNS over HTTPS, all the effort there is moot. Even then, a flow server can trace all the point to point IP traffic passing over it. Yes, it limits the obtained data a lot (no hostnames to begin with), but a proper traffic analyzer is rarely blinded completely by HTTPS.
Knowing that I'm watching YouTube is one thing, knowing what YouTube video I'm watching is a completely different problem.
Edit also: even with DNS over HTTPS, a lot of the Internet uses SNI for TLS, so anyone snooping can anyway see what hostname you're visiting (not to mention, IPs are not significantly more private than host names, and those will always be public unless you're using ToR or something similar).
Edit also: even with DNS over HTTPS, a lot of the Internet uses SNI for TLS, so anyone snooping can anyway see what hostname you're visiting (not to mention, IPs are not significantly more private than host names, and those will always be public unless you're using ToR or something similar).
Comcast injects data into plain http pages, altering them when they see fit (they put in a datacap warning into the text of the page).
If Comcast is doing something wrong, why does everyone else need to do something about it? If Comcast stops routing packets on port 433, should everyone else stop using it as well?
ISPs are evil and untrusted. That’s just a fact. The solution is to not allow them to see or modify anything.
Other IT corporations are also evil and untrusted.
But no one cares if they can look into all your mails and documents (Microsoft, Google), track you all over the web, see where you are going, which flight you are taking,...
The important is that ISPs are evil and untrusted. facepalm
But no one cares if they can look into all your mails and documents (Microsoft, Google), track you all over the web, see where you are going, which flight you are taking,...
The important is that ISPs are evil and untrusted. facepalm
> But no one cares if they can look into all your mails and documents (Microsoft, Google), track you all over the web, see where you are going, which flight you are taking,...
I don't think I go a single day without reading posts complaining about exactly that, so obviously people do care.
I don't think I go a single day without reading posts complaining about exactly that, so obviously people do care.
ISPs are the most blatantly scummy of the lot. They log everything, usually by government requirements, sell it to anyone, give it to the government without a warrant, inject adverts and js in to unprotected requests, and all kinds of malicious things.
They are easily eliminated from the picture. One less party with access to your data the better. There is really _no_ good argument for not having HTTPS on any site unless its some very rare case like an intranet site.
They are easily eliminated from the picture. One less party with access to your data the better. There is really _no_ good argument for not having HTTPS on any site unless its some very rare case like an intranet site.
Some places the ISP's are monopolies, or duopolies. Even with current tech giants you have many options.
This is like saying we shouldn't use encryption just because there are bad guys stealing our data... just because hackers do something wrong, why does everyone else need to do something about it?
We have to do a lot of things because bad guys do bad things. What is the alternative? Pretend they don't exist?
We have to do a lot of things because bad guys do bad things. What is the alternative? Pretend they don't exist?
They would know the IP address and host name from SNI, but they wouldn't know which articles on the blog I read.
And if you're using TLS ECH, then they wouldn't even know the host name.
The website operator has to use it, too. Many HTTP servers still do not support TLS1.3 let alone ECH (Draft 13). ECH is still experimental. Cloudflare disabled their ESNI trial a while back (ESNI worked great for me outside the browser), so unless they have now got ECH working (I still have not seen any announcement), currently there are even fewer sites offering encrypted SNI. You could probably count them on one hand. And Firefox (nightly), Chromium (105+) and Brave (nightly) are probably the only browsers that would support ECH and it is not enabled by default. I would be pleased to learn I am wrong here, because I would love to again start using sites that do not return requested pages unless a servername is sent.
[deleted]
HTTPs not completely blinding traffic analyzer doesn’t make the partial blinding useless.
DNS over HTTPS is default on some browsers now. Firefox does it iirc.
> Unless you use DNS over HTTPS
It really isn't hard to set up an unbound resolver.
It really isn't hard to set up an unbound resolver.
DoH is bad use DoT instead.
This couldn't be further from the truth. DoT is easy to block, so anyone who wants to censor or surveil you will just do so. You should always use DoH instead, since it's way more resistant to blocking.
Can't wait til google owns your DNS and you can't do shit about it
How does DoH make DNS any more centralized than DoT does?
When Google embed their DNS and their certificate into every Google product you have to use, you can't effectively block it.
If your goal isn't to censor or surveil other people, then why do you need to block Google's DNS rather than just not using it yourself?
Unfortunately, people are now often fighting with their own devices for control over which 3rd party services they access. This sometimes means that you have reasons to MITM or block traffic your own devices generate if you want to control aspects of who you actually send data to, or what data you actually send.
Not just block. I run split-horizon DNS at home for a few of my services. Without being able to control the DNS for devices on my LAN, they can't use those services.
Now you might argue that's a bit silly, but it is a use-case.
Now you might argue that's a bit silly, but it is a use-case.
Chromecast will use Google DNS and there is nothing you can do about it on the device. Guarantee this will happen to Chrome eventually.
Don't use random Wi-Fi then? Or if you do, have an always on routed VPN?
You're leaking data all over the place, placing the burden on the website owner is silly.
You're leaking data all over the place, placing the burden on the website owner is silly.
[deleted]
That's called a personal problem. It's not the responsibilty of a website owner to make his website constantly rot for the sake of strangers.
> If you're not doing anything requiring security, you don't need HTTPS, IMHO.
There have been documented attacks of people getting hacked because they were browsing the web with plain-HTTP and someone injected malicious pages mid-stream; see "Quantum Insert":
* https://www.infoworld.com/article/2609621/uk-spy-agency-uses...
* https://www.wired.com/2015/04/researchers-uncover-method-det...
There have been documented attacks of people getting hacked because they were browsing the web with plain-HTTP and someone injected malicious pages mid-stream; see "Quantum Insert":
* https://www.infoworld.com/article/2609621/uk-spy-agency-uses...
* https://www.wired.com/2015/04/researchers-uncover-method-det...
My ISP injects ads into http sites often.
Now just imagine what this corrupt third world government here can do.
Of course its "not a problem" if you aren't a vulnerable person who dares go against the grain, but on the whole it is.
If your site is not using tls then it's automatically blocked sorry, maybe I'm not your target audience regarding security blogs though :)
Now just imagine what this corrupt third world government here can do.
Of course its "not a problem" if you aren't a vulnerable person who dares go against the grain, but on the whole it is.
If your site is not using tls then it's automatically blocked sorry, maybe I'm not your target audience regarding security blogs though :)
I think the more important question is why are you still supporting this ISP by being their customer?
In corporate hellscapes like the USA, there is often no choice in ISPs, either because other ISPs can't justify the infrastructure investment to set up in opposition to the incumbent, or because the incumbent has lobbied local government to make use of power poles/conduits exclusive to them.
could be on airport wifi, store wifi, cafe wifi, hotel wifi, etc...
https prevents them injecting shit
https prevents them injecting shit
None of those are networks I could consider secure.
Even with https, there's no scenario where I'm not encapsulating all traffic in a tunnel there.
Even with https, there's no scenario where I'm not encapsulating all traffic in a tunnel there.
Sure, but this was in specific reference to “My ISP”. I can understand no choice in a hotel/cafe/etc. But there’s now lots of choice for home internet. Wired, cellular, even Starlink.
As if most people even have a choice.
If you're security focused, why not GRE tunnel to a vultr or similar VM and exit there? Then your ISP gets no information.
> If you're not doing anything requiring security, you don't need HTTPS, IMHO.
No, no, no, no, no, no, no.
ALL Web traffic should be https (or http/2 or /3). If you connect to a site that uses insecure http, ANY link between you and that site can easily snoop on traffic and even inject different content. You CANNOT be sure that the content you see is what was originally served by the server, and you can certainly expect that state actors will be noting that you viewed this content, and building a profile on you based on that information.
No, no, no, no, no, no, no.
ALL Web traffic should be https (or http/2 or /3). If you connect to a site that uses insecure http, ANY link between you and that site can easily snoop on traffic and even inject different content. You CANNOT be sure that the content you see is what was originally served by the server, and you can certainly expect that state actors will be noting that you viewed this content, and building a profile on you based on that information.
Hey, fellow genius on Hacker News, do note that TLS doesn't protect against state actors, because they can very easily manipulate certificate authorities, and a malicious certificate authority completely removes most protections TLS supposedly provides.
It could, if the CAs were globally distributed. Unfortunately currently they are all under the US influence.
It's enough to compromise one CA for TLS to be entirely defeated - any CA can sign a certificate for any site, and TLS implementations will accept it. The only defense is pinned certificates, but that comes with its own problems.
Certificate Transparency is enforced, so it'd be quite easy to detect that compromise by now.
Sure, but still somewhat after the fact.
Firmly disagree.
Anyone can use any protocol they wish to, that's the beauty of the internet.
Anyone can use any protocol they wish to, that's the beauty of the internet.
Have you considered disabling non-https in your browser, and blocked outbound port 80 on your home router?
Expressing a public opinion on how communication systems should implement their authentication needs at least some security, IMHO.
> I know people who knowingly use POP to keep their remote boxes empty, and keep everything local, so I don't think we should decide for people that swiftly.
That could be done using IMAP as well. The overhead for that use case seems quite small. However it is just one protocol to support. And I haverun into a bunch of non-techy users with problems like "if i read my mails on my desktop I can't access them on my phone anymore, so I always use the phone"-like problems, which tells me their mail client on desktop likely uses POP3. By not offering POP3 you are removing that class of support problems with very little downside.
That could be done using IMAP as well. The overhead for that use case seems quite small. However it is just one protocol to support. And I haverun into a bunch of non-techy users with problems like "if i read my mails on my desktop I can't access them on my phone anymore, so I always use the phone"-like problems, which tells me their mail client on desktop likely uses POP3. By not offering POP3 you are removing that class of support problems with very little downside.
In what way can you configure IMAP to not leave messages on the server and yet still give multiple clients access to that email?
If you use POP (and allow it to delete downloaded messages from the server), you still can't access your mail from multiple clients.
> It's basic auth that's getting deprecated
I missed that, because I don't jump down every linked rabbithole. Thanks.
Basic auth shouldn't be used for anything; I'm surprised it isn't already deprecated to hell and back. The letter says that Microsoft intends to deprecate IMAP and POP because some people use them with Basic auth. That doesn't make sense.
I missed that, because I don't jump down every linked rabbithole. Thanks.
Basic auth shouldn't be used for anything; I'm surprised it isn't already deprecated to hell and back. The letter says that Microsoft intends to deprecate IMAP and POP because some people use them with Basic auth. That doesn't make sense.
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.
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.
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.
A big assumption. POP3 works perfectly fine and is preferable in my situation.
No, not an assumption. Also, good for you.
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-message-ids/
Deletes are batched and only committed at the end of a connection. Unless you're willing to close and reopen a connection right away, any messages you delete are in a not-quite-deleted limbo until you close the connection. https://billpg.com/pop3-deli/
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-message-ids/
Deletes are batched and only committed at the end of a connection. Unless you're willing to close and reopen a connection right away, any messages you delete are in a not-quite-deleted limbo until you close the connection. https://billpg.com/pop3-deli/
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.
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.
Didn't know about JMAP - had been looking recently for open JSON-API-over-HTTP protocols, good to know.
Are there any non-Microsoft email clients that support different authentication protocols with IMAP connections to Exchange Online? The message from Microsoft certainly makes it seem like IMAP itself is being deprecated.
"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://.
https://portal.mozz.us/gemini/gemini.conman.org/boston/2022/...
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
https://portal.mozz.us/gemini/gemini.conman.org/boston/2022/...
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?
Neither Gemini nor the Internet Archive have access to the content through a channel other than the insecure HTTP endpoint, right?
> Neither Gemini nor the Internet Archive have access to the content through a channel other than the insecure HTTP endpoint, right?
All Gemini is signed. [0] It's mandatory. That's why the parent piped through openssl to connect.
For example, the page that we're looking at is signed. [1] (Using a bridge to show the certificate, but you can verify it yourself, as well.)
[0] https://gemini.circumlunar.space/docs/specification.html
[1] https://portal.mozz.us/gemini/gemini.conman.org/boston/2022/...
All Gemini is signed. [0] It's mandatory. That's why the parent piped through openssl to connect.
For example, the page that we're looking at is signed. [1] (Using a bridge to show the certificate, but you can verify it yourself, as well.)
[0] https://gemini.circumlunar.space/docs/specification.html
[1] https://portal.mozz.us/gemini/gemini.conman.org/boston/2022/...
Is that signature from the original author, or from an intermediary/Gemini proxy?
The authour. You can see their domain in the email that makes the signature.
> CA/[email protected]
> CN=gemini.conman.org/[email protected]
> CA/[email protected]
> CN=gemini.conman.org/[email protected]
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) and lowers the barrier to entry for setting up a Gemini site (no need to pay a CA or setup a Let's Encrypt cron job, just make a cert and go).
> TOFU stands for "Trust On First Use" and is public-key security model similar to that used by OpenSSH. The first time a Gemini client connects to a server, it accepts whatever certificate it is presented. That certificate's fingerprint and expiry date are saved in a persistent database (like the .known_hosts file for SSH), associated with the server's hostname. On all subsequent connections to that hostname, the received certificate's fingerprint is computed and compared to the one in the database. If the certificate is not the one previously received, but the previous certificate's expiry date has not passed, the user is shown a warning, analogous to the one web browser users are shown when receiving a certificate without a signature chain leading to a trusted CA.
> This model is by no means perfect, but it is not awful and is vastly superior to just accepting self-signed certificates unconditionally.
> 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) and lowers the barrier to entry for setting up a Gemini site (no need to pay a CA or setup a Let's Encrypt cron job, just make a cert and go).
> TOFU stands for "Trust On First Use" and is public-key security model similar to that used by OpenSSH. The first time a Gemini client connects to a server, it accepts whatever certificate it is presented. That certificate's fingerprint and expiry date are saved in a persistent database (like the .known_hosts file for SSH), associated with the server's hostname. On all subsequent connections to that hostname, the received certificate's fingerprint is computed and compared to the one in the database. If the certificate is not the one previously received, but the previous certificate's expiry date has not passed, the user is shown a warning, analogous to the one web browser users are shown when receiving a certificate without a signature chain leading to a trusted CA.
> This model is by no means perfect, but it is not awful and is vastly superior to just accepting self-signed certificates unconditionally.
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).
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).
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.
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.
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.
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.
[deleted]
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 "digest", of the page content. As long as the www user can obtain the signature over a secure channel then, in theory, integrity can be verified. The content could be sent over an insecure channel and integrity could still be verified. This sort of verification has long been common (well before HTTPS became widespread) when downloading files, namely, software, e.g., as tarballs.
The problem with using an intermediary that has crawled the www, whether it is IA or Google or whomever, is that the www user has no way to know how the content was retrieved. How does every www user know that the pages in Google's index that they are purportedly searching were accessed via HTTP or HTTPS. The only people who would have firsthand knowledge of the retrieval are those who observed it. As such, there is some (misplaced) trust involved when people use IA, Google or other intermediaries.
Personally, if I am forced to use an intermediary, e.g., a web archive, a search engine, a third party DNS provider, etc., then I try to use multiple intermediaries to obtain the same data, then compare. This does not solve the problem, but it is arguably better than trusting any particular intermediary.
Ideally, web page authors and intermediaries could provide signatures for the web pages they serve. (The same way that software authors provide signatures for the archives of the software they publish.) For example, if one uses Common Crawl then one gets a "WARC-Payload-Digest" header. For example, the payload digest for example.com's index.html is currently
If its signature was published by the original source, then there could be multiple sources for example.com's index.html across the web. Each copy would match the same signature published by the author of example.com's index.html. This practice has long been used in software distribution where multiple "mirrors" contain copies of the same files.
I still find there are numerous "insecure HTTP endpoints" in operation on the www. It seems to me that as long as these are concealed, no one complains about them. I recently commented about this with respect to podcasts. A surprising number of podcasts are being served over HTTP. But as long as the podcast listener is unaware of how their software is accessing them, no one complains about potential modification in transit or other issues with using an insecure channel.
Regarding the issue of "integrity", i.e., not being modified in transit, ideally all www pages could have a hash (signature), or "digest", of the page content. As long as the www user can obtain the signature over a secure channel then, in theory, integrity can be verified. The content could be sent over an insecure channel and integrity could still be verified. This sort of verification has long been common (well before HTTPS became widespread) when downloading files, namely, software, e.g., as tarballs.
The problem with using an intermediary that has crawled the www, whether it is IA or Google or whomever, is that the www user has no way to know how the content was retrieved. How does every www user know that the pages in Google's index that they are purportedly searching were accessed via HTTP or HTTPS. The only people who would have firsthand knowledge of the retrieval are those who observed it. As such, there is some (misplaced) trust involved when people use IA, Google or other intermediaries.
Personally, if I am forced to use an intermediary, e.g., a web archive, a search engine, a third party DNS provider, etc., then I try to use multiple intermediaries to obtain the same data, then compare. This does not solve the problem, but it is arguably better than trusting any particular intermediary.
Ideally, web page authors and intermediaries could provide signatures for the web pages they serve. (The same way that software authors provide signatures for the archives of the software they publish.) For example, if one uses Common Crawl then one gets a "WARC-Payload-Digest" header. For example, the payload digest for example.com's index.html is currently
WARC-Payload-Digest: sha1:JI6OR3QR4CI526JD6TMMNZNV4QPMPQCH
If its signature was published by the original source, then there could be multiple sources for example.com's index.html across the web. Each copy would match the same signature published by the author of example.com's index.html. This practice has long been used in software distribution where multiple "mirrors" contain copies of the same files.
I still find there are numerous "insecure HTTP endpoints" in operation on the www. It seems to me that as long as these are concealed, no one complains about them. I recently commented about this with respect to podcasts. A surprising number of podcasts are being served over HTTP. But as long as the podcast listener is unaware of how their software is accessing them, no one complains about potential modification in transit or other issues with using an insecure channel.
> 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.
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.
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.
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.
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 network (only one cert needs to be sent, not a whole chain) and lowers the barrier to entry for setting up a Gemini site (no need to pay a CA or setup a Let's Encrypt cron job, just make a cert and go).
TOFU stands for "Trust On First Use" and is public-key security model similar to that used by OpenSSH. The first time a Gemini client connects to a server, it accepts whatever certificate it is presented. That certificate's fingerprint and expiry date are saved in a persistent database (like the .known_hosts file for SSH), associated with the server's hostname. On all subsequent connections to that hostname, the received certificate's fingerprint is computed and compared to the one in the database. If the certificate is not the one previously received, but the previous certificate's expiry date has not passed, the user is shown a warning, analogous to the one web browser users are shown when receiving a certificate without a signature chain leading to a trusted CA.
This model is by no means perfect, but it is not awful and is vastly superior to just accepting self-signed certificates unconditionally.
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) and lowers the barrier to entry for setting up a Gemini site (no need to pay a CA or setup a Let's Encrypt cron job, just make a cert and go).
TOFU stands for "Trust On First Use" and is public-key security model similar to that used by OpenSSH. The first time a Gemini client connects to a server, it accepts whatever certificate it is presented. That certificate's fingerprint and expiry date are saved in a persistent database (like the .known_hosts file for SSH), associated with the server's hostname. On all subsequent connections to that hostname, the received certificate's fingerprint is computed and compared to the one in the database. If the certificate is not the one previously received, but the previous certificate's expiry date has not passed, the user is shown a warning, analogous to the one web browser users are shown when receiving a certificate without a signature chain leading to a trusted CA.
This model is by no means perfect, but it is not awful and is vastly superior to just accepting self-signed certificates unconditionally.
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.
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.
"Most ISP's can't be trusted, TOFU becomes essentially useless."
Why not just use HTTPS on the "untrustworthy" ISP's.
The use of the word "most" implies that there are some that can be trusted.
Assuming you are a trustorthy source for such information (and how do I know it's really you and not an "imposter"), then what are they. Please list the ISPs everyone can "trust".
The point that is being missed in this comment thread, and most others about TLS, HTTPS and CAs, is that there is a question of who decides whether something is "trustworthy" or not.
Personally I like to make these decisions for myself. Unlike an incredible number of internet commentators, I do not purport to tell anyone else who they should or should not trust. That decision is ultimately for each person to make on their own. We can provide information that may help a person with their decision, but it's still their decision, not mine.
But that's not how "chain of trust" works.
The concept of "chain of trust" itself does not even exist in the real world. It only exists in the imagination of socially inept persons hiding behind keyboards. In practice, for HTTPS, the cast of characters is a laundry list of third party intermediaries, all trying "cash in" on the use of the internet, a public resource we already pay ISP's to access. The idea that any of them would be sources of "trust" is comical.
Why trust "domain name registrars" as a source of useful information about people who run websites.
Why trust CAs issuing non-EV certificates. They only verify that someone rents a domain name from an "ICANN-approved" registry.
Why trust CAs issuing EV certificates. The people approving these CAs all have a vested interest in the web (browser) as a means of online advertising.
Why trust the people who "approve" CAs for inclusion in popular web browsers.
There are something like 75 CAs hardcoded into popular web browsers. If I want to remove one, what do I have to edit the source code and recompile. Inconvenient to say the least.
In all of this third party nonsense, there is no opportunity for an ordinary person, not invested in or benefitting from the "tech" company racket, to have any input on whether or not she wants to "trust" a website is being operated by a particular person. She is effectively locked out of the process. These third parties are often comprised of people I would never trust IRL. But they hide behind keyboards so we never get to see them for what they are.
At least with Gemini, clients and servers are smaller and simpler, and easy to edit and recompile. Gemini clients, written by anyone, not necesarily "tech" companies, are not designed with online advertising in mind. The protocol itself is not "advertising-friendly". It is little more than plain text.
The "threat model" for me in the majority of web use is the "business model" of so-called "tech" companies, i.e., surveillance, data collection and advertising, not "imposters". Nevermind that "tech" companies have pushed for a web that is 100% commercial/political, where even recreational use is monitored for insights useful to advertising. That only creates a greater incentive for "imposters". When I started using the internet it was still predominantly used for academic and military purposes.
If a "tech" company employee wants to choose to use HTTPS, DNSSEC, TOFU, etc., then that is their decision. But if they want to remove the ability of anyone else to make that decision for themselves, then I see a problem with that.
Why not just use HTTPS on the "untrustworthy" ISP's.
The use of the word "most" implies that there are some that can be trusted.
Assuming you are a trustorthy source for such information (and how do I know it's really you and not an "imposter"), then what are they. Please list the ISPs everyone can "trust".
The point that is being missed in this comment thread, and most others about TLS, HTTPS and CAs, is that there is a question of who decides whether something is "trustworthy" or not.
Personally I like to make these decisions for myself. Unlike an incredible number of internet commentators, I do not purport to tell anyone else who they should or should not trust. That decision is ultimately for each person to make on their own. We can provide information that may help a person with their decision, but it's still their decision, not mine.
But that's not how "chain of trust" works.
The concept of "chain of trust" itself does not even exist in the real world. It only exists in the imagination of socially inept persons hiding behind keyboards. In practice, for HTTPS, the cast of characters is a laundry list of third party intermediaries, all trying "cash in" on the use of the internet, a public resource we already pay ISP's to access. The idea that any of them would be sources of "trust" is comical.
Why trust "domain name registrars" as a source of useful information about people who run websites.
Why trust CAs issuing non-EV certificates. They only verify that someone rents a domain name from an "ICANN-approved" registry.
Why trust CAs issuing EV certificates. The people approving these CAs all have a vested interest in the web (browser) as a means of online advertising.
Why trust the people who "approve" CAs for inclusion in popular web browsers.
There are something like 75 CAs hardcoded into popular web browsers. If I want to remove one, what do I have to edit the source code and recompile. Inconvenient to say the least.
In all of this third party nonsense, there is no opportunity for an ordinary person, not invested in or benefitting from the "tech" company racket, to have any input on whether or not she wants to "trust" a website is being operated by a particular person. She is effectively locked out of the process. These third parties are often comprised of people I would never trust IRL. But they hide behind keyboards so we never get to see them for what they are.
At least with Gemini, clients and servers are smaller and simpler, and easy to edit and recompile. Gemini clients, written by anyone, not necesarily "tech" companies, are not designed with online advertising in mind. The protocol itself is not "advertising-friendly". It is little more than plain text.
The "threat model" for me in the majority of web use is the "business model" of so-called "tech" companies, i.e., surveillance, data collection and advertising, not "imposters". Nevermind that "tech" companies have pushed for a web that is 100% commercial/political, where even recreational use is monitored for insights useful to advertising. That only creates a greater incentive for "imposters". When I started using the internet it was still predominantly used for academic and military purposes.
If a "tech" company employee wants to choose to use HTTPS, DNSSEC, TOFU, etc., then that is their decision. But if they want to remove the ability of anyone else to make that decision for themselves, then I see a problem with that.
> Why not just use HTTPS on the "untrustworthy" ISP's.
I don't know, ask the Gemini people.
> The use of the word "most" implies that there are some that can be trusted.
Only a Sith deals in absolutes. I'm sure someone out there is their own ISP and can trust themselves.
> Personally I like to make these decisions for myself.
Sure, you do you. That doesn't make it a widely viable neither mostly secure approach.
I don't know, ask the Gemini people.
> The use of the word "most" implies that there are some that can be trusted.
Only a Sith deals in absolutes. I'm sure someone out there is their own ISP and can trust themselves.
> Personally I like to make these decisions for myself.
Sure, you do you. That doesn't make it a widely viable neither mostly secure approach.
Gibberish.
>It's basic auth that's getting deprecated, due to being considered a legacy authentication protocol.
Problem is, it is being replaced by solution that decreases security.
Problem is, it is being replaced by solution that decreases security.
Shaming people for not having HTTPS on their blog is not a great look. :/
I don't see the problem. HTTPS is basic internet hygiene. It's no worse than telling people they should mind their body odor when they're in a space with a lot of other people. Possibly indelicate, but undoubtedly true.
Exactly what risk does it have being on a low profile blog?
Will it always be a "low profile blog"? It just got on the front page of HN, which is not exactly "low profile".
As for what risk, two words: Great Cannon. For those who don't know, it's a well-known MITM attacker which injects JavaScript code on non-HTTPS pages, the injected JavaScript being used to do distributed denial of service attacks on other sites. Using HTTPS protects against these kinds of attacks.
As for what risk, two words: Great Cannon. For those who don't know, it's a well-known MITM attacker which injects JavaScript code on non-HTTPS pages, the injected JavaScript being used to do distributed denial of service attacks on other sites. Using HTTPS protects against these kinds of attacks.
I for example just wouldn't like anyone to be able to see what data I exchange with any server, be it small profile blog or a login page.
I for example just wouldn't like anyone to be able to see what data I exchange with any server, be it small profile blog or a login page.
It results in your browsing history being tracked and sometimes sold by your access point and ISP at a page level instead of just domain level, results in injected ads and banners on some access points, results in injected trackers on Verizon, and more broadly it permits unknown third parties to alter the content of your website.
If someone wants to track you, they can just mark the frame. Marking packets isn’t anything new,
Your analogy is flawed because this is Hackernews and, superior beings that we are, we understand body odor to be a symptom of a microbiome that's out of whack due to "modern life". Accordingly, we don't bathe in order to cultivate healthy skin bacteria; some of us wallow in mud instead.
I'm not sure you read what I wrote. At no point did I say to bathe, or in fact proffer any treatment at all for body odor. I merely pointed out that refusing to deal with it when you're in close quarters with a large number of people is antisocial. If somehow wallowing in mud treats it for someone, then that's what they should be doing. The problem is knowing how to solve it and refusing to do so.
Noting an amusing interaction with the context isn't shaming.
Though if someone can set it up in less than 15 minutes, and doesn't, I reserve the right to snark. It's not a bad look in cases like that.
Though if someone can set it up in less than 15 minutes, and doesn't, I reserve the right to snark. It's not a bad look in cases like that.
You can do it in 15 minutes if you've already done it before. If you didn't, you'd be very lucky doing it in such a short time frame.
I set it up for my home server maybe a year ago. I'm not a web developer or system admin, but I am a highly experienced software engineer with a deep understanding of network protocols. The documentation didn't seem the greatest, basically being, "copy/paste this if you use Apache." My particular configuration was quirkier than the example assumed, and I had to go through a few rounds of troubleshooting. It definitely wasn't trivial.
> but I am a highly experienced software engineer with a deep understanding of network protocols
Thank you for your service
Thank you for your service
Lol, thanks. I rarely work on stuff exposed to the Internet. I've implemented multiple bare metal IP stacks from scratch, including Ethernet, DHCP, ARP, ICMP, and UDP. I've run real-time safety critical packets over TCP links. I've tunneled IP traffic through the international space station. I've done unforgivable things with iptables and awk.
The funny thing is that IPv6 short-circuits my brain. Why do I have four addresses, and where did they come from? Why isn't there a link-local address for loopback and wireguard?
The funny thing is that IPv6 short-circuits my brain. Why do I have four addresses, and where did they come from? Why isn't there a link-local address for loopback and wireguard?
For most modern blog hosts, it's a pushbutton solution or automatic.
For self-hosted, it's table-stakes knowledge. Failure to do it implies the site admin knows so little about modern security that their access logs are probably only thinly secured. It's an "admin smell," if you will.
For self-hosted, it's table-stakes knowledge. Failure to do it implies the site admin knows so little about modern security that their access logs are probably only thinly secured. It's an "admin smell," if you will.
The same people who'd claim http is a bad look would also tell you to pipe curl to bash with sudo.
That's a weird claim to make; what makes you think that?
Though I suppose https is a prerequisite for that pipe to maybe be safe. Piping curl to bash varies from stupid to just fine depending on context.
Though I suppose https is a prerequisite for that pipe to maybe be safe. Piping curl to bash varies from stupid to just fine depending on context.
Just look around at lots of how-tos, particularly ones that tell you how to generate and set up certificates.
Fun fact: HTTPS is implicitly required by the GDPR because the user agent metadata is considered PII and websites are required to implement best current practices, which includes HTTPS. There is no exemption for (public) personal websites as they're still providing a publicly accessible service and processing PII to do so.
The same goes for a privacy policy for that matter.
The same goes for a privacy policy for that matter.
What traffic between a blog without user auth for comments needs to be encrypted? Why? I understand that Let’s Encrypt exists and it’s “easy” to set up (for people with root access to the system hosting their site + a decent level of technical sysadmin proficiency)
So that middlemen can’t spy on which part of the blog you’re visiting / alter the content of the blog / inject ads. There’s also all sorts of vulnerabilities that crop up if you use HTTP and HTTPS on the same site.
All of this was present in the 90s and early 2000s so not really theoretical attacks.
All of this was present in the 90s and early 2000s so not really theoretical attacks.
> inject ads.
If you believe that your ISP or a middleman can't inject ads without breaking the S in HTTPS, I have a bridge to sell you.
They can just push the content into a frame and inject the content outside that frame. I encountered this more than once.
If you believe that your ISP or a middleman can't inject ads without breaking the S in HTTPS, I have a bridge to sell you.
They can just push the content into a frame and inject the content outside that frame. I encountered this more than once.
Unless the ISP forces the use of its own Certificate Authority on its users, this isn't possible. TLS and the infrastructure surrounding it were designed with integrity of the connection in mind. Knowing this, I would be very curious to know what specifically you encountered and where. I see you added some details elsewhere, but it still doesn't jive with how TLS works.
Our ISP doesn't force MITM certificates, but used to try to mess with the retrieved pages sporadically with stream-hijacks (you navigate to HN, and got greeted with a full page ad) or banner insertions, forcing connection to mixed status while keeping the inner frame HTTPS.
They're not doing this anymore, because I guess they now know how to use their DPI infra in useful ways to them.
My mobile carrier still injects stuff to HTTP pages, but doesn't mess with HTTPS ones, at least yet.
They're not doing this anymore, because I guess they now know how to use their DPI infra in useful ways to them.
My mobile carrier still injects stuff to HTTP pages, but doesn't mess with HTTPS ones, at least yet.
That is not possible. You would get a cert mismatch error.
The overall connection will drop to "mixed status", but the inner frame will still be HTTPS.
My ISP used to do that when they started deploying DPI hardware as a technology demo. They'll hijack your traffic and inject full ads w/o redirection or added (bill) warning banners or ads sporadically to retrieved pages.
My mobile carrier sometimes injects SMS & Notifications arriving to my modem if they find the chance w/o disturbing the connection too much.
So, having a HTTPS connection doesn't make it tamper resistant, but tamper evident, at most.
My ISP used to do that when they started deploying DPI hardware as a technology demo. They'll hijack your traffic and inject full ads w/o redirection or added (bill) warning banners or ads sporadically to retrieved pages.
My mobile carrier sometimes injects SMS & Notifications arriving to my modem if they find the chance w/o disturbing the connection too much.
So, having a HTTPS connection doesn't make it tamper resistant, but tamper evident, at most.
> The overall connection will drop to "mixed status", but the inner frame will still be HTTPS.
That is not possible. You would get a cert mismatch error.
Consider what your browser does when you navigate to the page: it directly opens a TLS connection to port 443. There's nothing your ISP can do to force the browser to request the page using a non-TLS connection.
What might have happened, is that you might have carelessly typed the address in your URL bar without the "https://" prefix, as in "www.example.com"; for legacy historical reasons, most browsers (except IIRC some very old browsers from the dialup era, which always required an explicit URL scheme) treated that as if you had prefixed it with http:// (so it actually was the non-HTTPS "http://www.example.com" that you were using). Many sites would then redirect you to the HTTPS site, but your ISP could hijack the page before that redirect (since the redirect was not protected by HTTPS). Had you been careful to always prefix any address you type with "https://", there would be no initial non-HTTPS connection to hijack.
That is not possible. You would get a cert mismatch error.
Consider what your browser does when you navigate to the page: it directly opens a TLS connection to port 443. There's nothing your ISP can do to force the browser to request the page using a non-TLS connection.
What might have happened, is that you might have carelessly typed the address in your URL bar without the "https://" prefix, as in "www.example.com"; for legacy historical reasons, most browsers (except IIRC some very old browsers from the dialup era, which always required an explicit URL scheme) treated that as if you had prefixed it with http:// (so it actually was the non-HTTPS "http://www.example.com" that you were using). Many sites would then redirect you to the HTTPS site, but your ISP could hijack the page before that redirect (since the redirect was not protected by HTTPS). Had you been careful to always prefix any address you type with "https://", there would be no initial non-HTTPS connection to hijack.
Afaik not actually possible in practice. Browsers these days will a) remember valid certs for a domain b) remember that a domain is HTTPS (no downgrades) c) sniff certificates based on crowdsourcing.
Maybe this is why it reduced and stopped over the years. I'm not as knowledgeable in contemporary HTTPS and its capabilities, probably.
Because I'm pretty sure that happened.
Because I'm pretty sure that happened.
Yeah. I hope you realize though why there’s a stern castigation, on a particularly techy and security conscious forum, of using HTTP instead of HTTPS. People here both remember the problems and what’s been done to combat them. It’s discomforting to see backwards progress when so much has been done. Security isn’t purely a technical problem. It’s an educational one too.
can you explain further?
Two things have happened in the past.
Scenario a:
1. Navigate to https://www.example.com
2. Arrive at https://www.completelyunrelated-adsite.com while your address bar reads https://www.example.com
They used to do this regardless of your DNS. They directly hijacked that stream/connection.
Scenario b:
1. Navigate to https://www.example.com
2. Get https://www.example.com with an ad-banner on top.
They happened rarely, and never survived a reload or further navigation. They completely stopped after a while.
I have a 4G modem from my mobile carrier. They inject a info popup when I receive an SMS or any other notification' if they can manage it. It's very rare now, too.
Scenario a:
1. Navigate to https://www.example.com
2. Arrive at https://www.completelyunrelated-adsite.com while your address bar reads https://www.example.com
They used to do this regardless of your DNS. They directly hijacked that stream/connection.
Scenario b:
1. Navigate to https://www.example.com
2. Get https://www.example.com with an ad-banner on top.
They happened rarely, and never survived a reload or further navigation. They completely stopped after a while.
I have a 4G modem from my mobile carrier. They inject a info popup when I receive an SMS or any other notification' if they can manage it. It's very rare now, too.
Scenario A is impossible and has been impossible for as long as https has been a thing.
The only way it would be possible is if you installed a root cert from your ISP onto your computer so that it would trust a cert issued by them. Otherwise, they would not have a valid cert for example.com and you would be presented with a cert error.
This is literally the exact thing https was designed to prevent. It is and always has been impossible (again, unless the client machine is administered by the ISP or whoever the middleman is, and they can install a cert on the machine)
The only way it would be possible is if you installed a root cert from your ISP onto your computer so that it would trust a cert issued by them. Otherwise, they would not have a valid cert for example.com and you would be presented with a cert error.
This is literally the exact thing https was designed to prevent. It is and always has been impossible (again, unless the client machine is administered by the ISP or whoever the middleman is, and they can install a cert on the machine)
It's possible if the connection goes through an http proxy.
> That aside, POP should really be considered legacy, it comes with many downsides that hinder people's e-mail usage.
And one big advantage - it actually allows you retrieve and store e-mail locally - irrespective of any server allocation.
And one big advantage - it actually allows you retrieve and store e-mail locally - irrespective of any server allocation.
Um what? Nothing in IMAP prevents you from doing the same. Just because most client implementations assume you want to keep your mail on the server by default, does not mean the protocol doesn’t account for the other possibility.
And to be fair, configuring most clients to retrieve and then delete, or keep a local copy in addition to the server one, is not difficult at all - these options are not hidden or anything.
And to be fair, configuring most clients to retrieve and then delete, or keep a local copy in addition to the server one, is not difficult at all - these options are not hidden or anything.
POP3 is exceedingly simple protocol compared to IMAP. I'd rather use the simplest tool for the job.
In case the password leaks, attacker can only fetch new messages over POP3, and not plant them or fetch the entire archive from the server. (yeah, I can fetch and delete over IMAP too, but then what's the point of all the extra unused complexity of IMAP, it's just an extra risk)
In case the password leaks, attacker can only fetch new messages over POP3, and not plant them or fetch the entire archive from the server. (yeah, I can fetch and delete over IMAP too, but then what's the point of all the extra unused complexity of IMAP, it's just an extra risk)
JMAP works great for this too. It’s a shame JMAP isn’t widely implemented - it’s a lovely standard.
So does IMAP? Most clients only cache headers because it’s faster and most devices are always-connected; but you can certainly locally download the entirety of your IMAP contents.
Considering you have to download the entirety of the mail contents to read it anyways, I have no idea what makes you think this is an impossibility.
Considering you have to download the entirety of the mail contents to read it anyways, I have no idea what makes you think this is an impossibility.
Yeah, but typically the difference is that you can't see IMAP as a backup. Whereas with POP3 (and not having your client set up to automatically delete emails on the server) you can.
With IMAP, when an email gets deleted by some client, other clients will also delete their local copies of that email. That won't happen with POP3.
But I haven't read either of the two protocols, so I'm not sure whether that's something required by the protocol or just a common behavior of clients.
With IMAP, when an email gets deleted by some client, other clients will also delete their local copies of that email. That won't happen with POP3.
But I haven't read either of the two protocols, so I'm not sure whether that's something required by the protocol or just a common behavior of clients.
> With IMAP, when an email gets deleted by some client, other clients will also delete their local copies of that email. That won't happen with POP3.
This is not an IMAP feature, this is a client feature. There are plenty of clients that don’t sync deletes, if you don’t want to.
Or, just don’t delete your emails? If you delete a POP email from your client, it’s also gone for good.
This is not an IMAP feature, this is a client feature. There are plenty of clients that don’t sync deletes, if you don’t want to.
Or, just don’t delete your emails? If you delete a POP email from your client, it’s also gone for good.
Yeah, it's much better with POP3, when one client downloads everything it deletes it from the server /s
This isn't IMAP limitation, this is how clients implemented it. Nothing stops one to download every message over IMAP and never delete them.
This isn't IMAP limitation, this is how clients implemented it. Nothing stops one to download every message over IMAP and never delete them.
Common POP I implementations let me leave things on the server indefinitely, for a chosen period, or to delete immediately on retrieval, leaving the local copy intact. Can you think of any IMAP implementations that allow that?
[deleted]
For those of us with Unix-y mail setups the move to OAuth2 can be a bit tricky, but there are now several different programs to help (spurred, I suspect in no small part, by Microsoft/Exchange's stance). The ones I know about are:
Email OAuth 2.0 Proxy <https://github.com/simonrob/email-oauth2-proxy>; mailctl <https://github.com/pdobsan/mailctl>; mutt_oauth2.py <https://gitlab.com/muttmua/mutt/-/blob/master/contrib/mutt_o...> (some suggestion that it might not always work these days?); pizauth <https://github.com/ltratt/pizauth>; oauth-helper-office-365 <https://github.com/ahrex/oauth-helper-office-365>. Disclaimer: I wrote pizauth and it's just about to move into the alpha stage.
Email OAuth 2.0 Proxy <https://github.com/simonrob/email-oauth2-proxy>; mailctl <https://github.com/pdobsan/mailctl>; mutt_oauth2.py <https://gitlab.com/muttmua/mutt/-/blob/master/contrib/mutt_o...> (some suggestion that it might not always work these days?); pizauth <https://github.com/ltratt/pizauth>; oauth-helper-office-365 <https://github.com/ahrex/oauth-helper-office-365>. Disclaimer: I wrote pizauth and it's just about to move into the alpha stage.
Not only it’s tricky and user-hostile, but it also severely decreases security by forcing people to use fundamentally insecure mechanism to obtain the authentication token.
Could you expand on that? How is OAuth 2.0 fundamentally insecure in this setting?
It makes it necessary to use a browser to obtain the token. That browser is a huge attack surface. With web, it doesn’t matter, since you need to be using it anyway, but for mail it’s just additional cruft.
That's just for certain flows, like the common authorization code flow. The client credentials flow does not require a browser, for example.
Not sure about Google, but Microsoft supports client credentials for IMAP/POP3[1], but not for SMTP yet. IIRC it was supposed to be rolled out this January but is still missing. Hopefully they can get that deployed ASAP.
[1]: https://learn.microsoft.com/en-us/exchange/client-developer/...
Not sure about Google, but Microsoft supports client credentials for IMAP/POP3[1], but not for SMTP yet. IIRC it was supposed to be rolled out this January but is still missing. Hopefully they can get that deployed ASAP.
[1]: https://learn.microsoft.com/en-us/exchange/client-developer/...
God forbid you actually have functioning token rotation and revocation alongside 2FA. So insecure. /s
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/...
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.
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.
You can use 2FA with static password authentication. Remember the “password” here only means “character string”, it can easily carry an OTP.
Right, just as with XOAUTH2, the "password" sent to the server is actually the (encoded) OAuth token.
So what does it improve then, that would justify the incompatibility and added technological debt (dependencies)?
Well the question I responded to was "What does oauth have to tho with authentication".
I fully agree with the move away from plain passwords in this case, given that it's no longer "just" the password to a mail account, but to much, much more.
Now while I think OAuth adds some features that can be useful in certain settings, I'll be inclined to agree that requiring OAuth isn't the best move.
However the alternatives would probably require a lot of extra work on Microsoft's behalf, like being able to set up device-specific passwords or similar.
So, given the need to move away from plain account passwords, I can understand why they wouldn't want to do that and just use what they already had.
I fully agree with the move away from plain passwords in this case, given that it's no longer "just" the password to a mail account, but to much, much more.
Now while I think OAuth adds some features that can be useful in certain settings, I'll be inclined to agree that requiring OAuth isn't the best move.
However the alternatives would probably require a lot of extra work on Microsoft's behalf, like being able to set up device-specific passwords or similar.
So, given the need to move away from plain account passwords, I can understand why they wouldn't want to do that and just use what they already had.
Standards are the enemy because they allow you to use alternate client implementations.
And enterprises hate this.
It does increase the cost of tech support.
Perhaps, but I feel the real reason is their security team tells them they can't control it so they should get rid of it.
Yes, that’s exactly the reason. Enforcing security is an endless black hole of effort that will increases exponentially with every new thing you need to support. So yes, reducing the number of things that need to be evaluated isn’t just some security guy trying to control everyone, it’s a hard requirement just to be able to have security at all.
Honestly, that's also a good reason.
> I do have to wonder how long until Google decides that only certain clients can connect with Gmail?
Already the case on mobile:
> If you use the Play store or GitHub version of FairEmail, you can use the quick setup wizard to easily setup a Gmail account and identity. The Gmail quick setup wizard is not available for third party builds, like the F-Droid build because Google approved the use of OAuth for official builds only. OAuth is also not available on devices without Google services, such as recent Huawei devices, in which case selecting an account will fail.
https://github.com/M66B/FairEmail/blob/master/FAQ.md#user-co...
Already the case on mobile:
> If you use the Play store or GitHub version of FairEmail, you can use the quick setup wizard to easily setup a Gmail account and identity. The Gmail quick setup wizard is not available for third party builds, like the F-Droid build because Google approved the use of OAuth for official builds only. OAuth is also not available on devices without Google services, such as recent Huawei devices, in which case selecting an account will fail.
https://github.com/M66B/FairEmail/blob/master/FAQ.md#user-co...
Can you get around this by setting an App Specific password on your Google account?
That functionality was removed in favor of OAuth.
I'm not sure M66B needs to get approval for the other builds, though, because the access is gated at the cloud API, not though client libraries. You can use Play Services to grant OAuth tokens, or you can use the boring old Google API client libraries, or roll your own; you just need to add the other signing key fingerprints and application IDs to the credential in the project's cloud console.
I could easily be mistaken, but there are numerous open-source projects acting as mail clients through the GMail API, Google has granted them access, and they don't have to use a closed-source client to do it. Most of them don't even target Android.
I'm not sure M66B needs to get approval for the other builds, though, because the access is gated at the cloud API, not though client libraries. You can use Play Services to grant OAuth tokens, or you can use the boring old Google API client libraries, or roll your own; you just need to add the other signing key fingerprints and application IDs to the credential in the project's cloud console.
I could easily be mistaken, but there are numerous open-source projects acting as mail clients through the GMail API, Google has granted them access, and they don't have to use a closed-source client to do it. Most of them don't even target Android.
> That functionality was removed in favor of OAuth.
Huh?
I'm using it right now in order to use Gmail in an email client that doesn't support OAuth.
Huh?
I'm using it right now in order to use Gmail in an email client that doesn't support OAuth.
You're right, that works.
The only blocker is that app passwords are only available if you turn on 2fa (even though the functions aren't related.)
The only blocker is that app passwords are only available if you turn on 2fa (even though the functions aren't related.)
For Gmail, yes. For Outlook, no.
That was removed in May of this year in favor of the SASL XOAUTH2 mechanism.
For Gmail? Mine still seem to working.
You can still enable these protocols per user - Microsoft are disabling these and Basic Authentication by default as most users don’t use them and it’s the primary vector for sending emails from compromised accounts.
Any Microsoft tenant I set up or manage already has policies to block anything but the Outlook desktop or mobile clients with MFA on every account.
> You can still enable these protocols per user
From what I understand, Microsoft will disable basic authentication starting January 2023, and the next few months are sort of a "grace period" to migrate to Microsoft's new authentication protocol [1]:
> On September 1, 2022, we announced there will be one final opportunity to postpone this change. Tenants will be allowed to re-enable a protocol once between October 1, 2022 and December 31, 2022. Any protocol exceptions or re-enabled protocols will be turned off early in January 2023, with no possibility of further use. See the full announcement at Basic Authentication Deprecation in Exchange Online – September 2022 Update.
> Microsoft are disabling these and Basic Authentication as most users don’t use them and it’s the primary vector for sending emails from compromised accounts
Even if most users don't use basic auth, I don't see why Microsoft has to disable it altogether. For people who want to keep using legacy clients, it's not too hard to force the usage of application-specific passwords.
[1] https://learn.microsoft.com/en-us/exchange/clients-and-mobil...
From what I understand, Microsoft will disable basic authentication starting January 2023, and the next few months are sort of a "grace period" to migrate to Microsoft's new authentication protocol [1]:
> On September 1, 2022, we announced there will be one final opportunity to postpone this change. Tenants will be allowed to re-enable a protocol once between October 1, 2022 and December 31, 2022. Any protocol exceptions or re-enabled protocols will be turned off early in January 2023, with no possibility of further use. See the full announcement at Basic Authentication Deprecation in Exchange Online – September 2022 Update.
> Microsoft are disabling these and Basic Authentication as most users don’t use them and it’s the primary vector for sending emails from compromised accounts
Even if most users don't use basic auth, I don't see why Microsoft has to disable it altogether. For people who want to keep using legacy clients, it's not too hard to force the usage of application-specific passwords.
[1] https://learn.microsoft.com/en-us/exchange/clients-and-mobil...
I'm referring to IMAP/POP, you'll be able to use these with OAuth instead of basic auth.
I imagine their stats show that 99 percent of users use Outlook of some sort so to up security they turned basic auth off.
So Microsoft want you to switch from (awful) Basic Auth to a Microsoft-modified version of OAuth, is that it?
I don't use Microsoft mail services, except as SMTP destinations. Does Outlook not support Digest Auth? Digest Auth certainly isn't perfect (I seem to remember that it requires an extra roundtrip), but it's not a security disaster like Basic Auth.
My main problem with OAuth is that it's hard for users to understand. If we expect users to use the internet securely, then they need to be able to know when that's not what they're doing, and I don't know any ordinary Joe that I could explain OAuth to. Hell, I implemented OAuth once, and now I can't remember how it works. It doesn't help that OAuth is a moving target.
I don't use Microsoft mail services, except as SMTP destinations. Does Outlook not support Digest Auth? Digest Auth certainly isn't perfect (I seem to remember that it requires an extra roundtrip), but it's not a security disaster like Basic Auth.
My main problem with OAuth is that it's hard for users to understand. If we expect users to use the internet securely, then they need to be able to know when that's not what they're doing, and I don't know any ordinary Joe that I could explain OAuth to. Hell, I implemented OAuth once, and now I can't remember how it works. It doesn't help that OAuth is a moving target.
Ignoring authentication, POP and IMAP truly are legacy protocols in the sense that they were designed in an era where bandwidth, not latency was the major constraint for accessing email. It made sense to send a notification that the size of your inbox changed, and let the client decide whether or not to fetch your emails. Since then, internet connections have gotten tens of thousands of times more bandwidth, but the speed of light hasn't improved correspondingly.
Now or then, whatever the bandwidth or latency, why couldn't we just use a REST web service which would let a client access whatever the parameter incl. mailbox size, list the messages, read the messages in form of JSON/XML arrays of metadata + message bodies in Markdown format?
Because without a standard protocol they would be N underspecified proprietary variants: the Gmail web service, the Office 365 web service, the Office 365 from last year web service...
All of them with complicated authentication requirements, idiosyncratic URL construction, and other difficulties. You would throw away the baby and keep the bathwater.
All of them with complicated authentication requirements, idiosyncratic URL construction, and other difficulties. You would throw away the baby and keep the bathwater.
I meant a standardized REST protocol. Why does it have (or ever had) to be something obscure like SMTP/POP3/IMAP if it could be just REST (still standardized, name it whatever)?
Hard enough to get people within the same company to agree on something or use consistent API conventions...
Heck you'd probably have a hard time just getting people to agree to use REST. "Why not GraphQL?"
Heck you'd probably have a hard time just getting people to agree to use REST. "Why not GraphQL?"
IMAP is more efficient than REST.
Is it so much more efficient to be worth the obscurity?
IMAP is not obscured, it's quite front and bright if you ask me.
There are Google and Microsoft APIs for exactly this. Well not markdown exactly but since emails are not sent in markdown it would be kind of subjective exactly how to properly convert it
Some context: Microsoft has disabled the use of alternative email providers in Windows' built-in email app since Windows 10, and for 365 users, unless you got one of the more expensive accounts intended for large companies, then no custom domain names for your email unless you use Godaddy as registrar. They have an exclusivity deal with Microsoft.
So sure, one can look at this from an authentication perspective, or simply look at this as one in a line of steps in a specific direction.
So sure, one can look at this from an authentication perspective, or simply look at this as one in a line of steps in a specific direction.
This is completely false, I've just installed the Mail app on my Windows 11 machine, first thing it asks you is what e-mail provider you use [0] and there are options for iCloud, Yahoo and a generic IMAP setup along with the Microsoft offerings.
[0] https://files.catbox.moe/ljil4h.png
[0] https://files.catbox.moe/ljil4h.png
Maybe it depend on which license/tablet? I have worked with customers with that issue in the past and the option for generic imap has not been there.
Double checked and you are right, it was this issue that I recalled: https://support.microsoft.com/en-us/office/add-your-other-em...
Double checked and you are right, it was this issue that I recalled: https://support.microsoft.com/en-us/office/add-your-other-em...
I'm running Pro but I've seen plenty of people with Home/Core machines using the default Mail app, no idea why since it's so much worse than the webmail option
> and for 365 users, unless you got one of the more expensive accounts intended for large companies, then no custom domain names for your email unless you use Godaddy as registrar
I guess that’s US only? With 5 employees we are a pretty small company and this is not the case for us.
I guess that’s US only? With 5 employees we are a pretty small company and this is not the case for us.
https://support.microsoft.com/en-us/office/get-a-personalize...
"At the moment, we only support connecting domains managed by GoDaddy with Outlook.com"
In my market those accounts were also marketed towards small companies, with only Microsoft 365 Business tiers and above having the feature of allowing other providers than godaddy as domain registrars.
You can also read about it here in the press release: https://news.microsoft.com/2014/01/13/microsoft-and-godaddy-...
"Announced on Monday a long-term strategic partnership to offer Office 365 as GoDaddy’s exclusive core business-class email and productivity service to its small-business customers".
Microsoft do however change their tiers and plans regularly, and whom they target them to. In my job, seeing customers being unable to switch to other registrars has been a fairly common occurrence. Microsoft 365 Business plans should be fine to my knowledge, through I recall Microsoft 365 email essential for small business wasn't, which has been rebranded to Microsoft 365 Business basic, but I don't know if that mean it is a Microsoft 365 Business plan now or still the more limited "personal" plan. A customer who bought essential in the past and now is on basic might be able to leave godaddy, but I don't know and it might depend on software versions, updates and who know what.
"At the moment, we only support connecting domains managed by GoDaddy with Outlook.com"
In my market those accounts were also marketed towards small companies, with only Microsoft 365 Business tiers and above having the feature of allowing other providers than godaddy as domain registrars.
You can also read about it here in the press release: https://news.microsoft.com/2014/01/13/microsoft-and-godaddy-...
"Announced on Monday a long-term strategic partnership to offer Office 365 as GoDaddy’s exclusive core business-class email and productivity service to its small-business customers".
Microsoft do however change their tiers and plans regularly, and whom they target them to. In my job, seeing customers being unable to switch to other registrars has been a fairly common occurrence. Microsoft 365 Business plans should be fine to my knowledge, through I recall Microsoft 365 email essential for small business wasn't, which has been rebranded to Microsoft 365 Business basic, but I don't know if that mean it is a Microsoft 365 Business plan now or still the more limited "personal" plan. A customer who bought essential in the past and now is on basic might be able to leave godaddy, but I don't know and it might depend on software versions, updates and who know what.
Ah, we have a business account, that explains it. I also confirmed that it’s the same in the German copy of the text ;)
Any relationship with Godaddy sounds dirty.
They are basically imposing the worst registrar ever on customers, for this particular scenario.
They are basically imposing the worst registrar ever on customers, for this particular scenario.
The protocols are seeing a decline in deployments but they're still very popular. See the below for a trend of the protocol over the past 5 years:
https://imgur.com/a/uIAiM9B
https://imgur.com/a/uIAiM9B
you have to jump through hoops to do basic auth (even over SSL) for IMAP/pop with gmail as well. (this has been true for some years now)
on one level, it's sad to see the open protocols go... on the other, google passwords are a big deal.
on one level, it's sad to see the open protocols go... on the other, google passwords are a big deal.
What hoops are you referring to?
Regarding the password, Google requires you to use an App Password, e.g. a password used solely for POP/IMAP, separate form you Google password. I suppose setting up POP/IMAP nowadays would involve:
- Enable POP/IMAP in GMail settings
- Set an App Password
- Enter email address, full name and App Password in Thunderbird first-time use wizard.
I suppose this can be a pain if you are not aware of these 2 settings, for newcomers they would likely need a tutorial. However this setup is really a one-time process.
I suppose this can be a pain if you are not aware of these 2 settings, for newcomers they would likely need a tutorial. However this setup is really a one-time process.
> google passwords
at my work - they are disabled in our enterprise account - no alternative to oauth. I think they may even be disabled by default in general in gmail.
So glad someone invented davmail: https://davmail.sourceforge.net/index.html
[deleted]
By the way, I wonder if GMail and Microsoft servers still use SMTP to exchange mail between them.
Are there any open standards that Microsoft is still going to support to receive emails, or will you be required to use only their proprietary clients to do so going forward?
[deleted]
Since web apps became the only thing people create anymore
Strange than no one talked about gmailify: that protocol that replaced pop and imap on gmail so that you can't see your email on other providers unless google accepts them.
POP, not IMAP
What about Macrosoft Exchange?
TLDR: when IMAP didn't standardize push, and when people started to use HTTP for everything.
JMAP is the current hotness.
JMAP is the current hotness.
IMAP IDLE exists since 1997 (RFC2177) and works decent enough for single mailboxes.
It is limited to only a single mailbox however, which is not quite ideal if one does server-side filtering (as one then needs N connections for N folders).
But for that there is IMAP NOTIFY (RFC5465) since 2009, which covers all remaining use cases..
Nice
Their plan is to remove old text-only protocols, and force to use XAUTH or similar protocols that requires use of a web browser, so they can spy you with cookies and more metadata. Both Google and Microsoft are announced this movement.
They're removing plain text auth because:
a) password doesn't support 2nd factor.
b) Most configurations keep password is on disk somewhere, often in plaintext.
c) User configurations break on password rotation.
Your tracking theory doesn't really hold up a) they know exactly who you are on your email client anyway as you log in and b) most users are logged in to their google/microsoft account anyway because of o375/workspace/youtube.
a) password doesn't support 2nd factor.
b) Most configurations keep password is on disk somewhere, often in plaintext.
c) User configurations break on password rotation.
Your tracking theory doesn't really hold up a) they know exactly who you are on your email client anyway as you log in and b) most users are logged in to their google/microsoft account anyway because of o375/workspace/youtube.
a) is only relevant once, during setup; b) isn't fixed by Oauth; c) is by design, I'd argue.
I support adding 2FA to email in some way, but I heavily dislike using browsers to do so. What's wrong with adding a simple challenge-response protocol for FIDO2/U2F USB drives? Or a TOTP popup if you don't have a physical security key?
This can all be standardised without a browser ever touching the email client. We already have IMAP authentication methods that use signatures (like most 2FA hardware keys use) or challenge/response methods. You can even do client certificate authentication through STARTTLS when lacking a TPM.
I support adding 2FA to email in some way, but I heavily dislike using browsers to do so. What's wrong with adding a simple challenge-response protocol for FIDO2/U2F USB drives? Or a TOTP popup if you don't have a physical security key?
This can all be standardised without a browser ever touching the email client. We already have IMAP authentication methods that use signatures (like most 2FA hardware keys use) or challenge/response methods. You can even do client certificate authentication through STARTTLS when lacking a TPM.
> What's wrong with adding a simple challenge-response protocol for FIDO2/U2F USB drives? Or a TOTP popup if you don't have a physical security key?
Infrastructure to handle authentication on the web already exists. This is a massive benefit for providers and client developers. Whatever you propose does not. Good luck convincing big email providers to agree on a new standard like that.
GitHub alone has like 5 different ways to handle 2FA. Google has, I think, 3? Using a browser to handle this simplifies things a lot.
b) While it's not fixed by Oauth it greatly limits what can happen:
— First, you only need to store a refresh token that can expire and that expiration can be controlled by administrator
— Second, that token has limited scope: password provides access to entire account
— Third, it's clear where it came from — if token gets compromised, you will know where it happened. With password, it's unclear.
Infrastructure to handle authentication on the web already exists. This is a massive benefit for providers and client developers. Whatever you propose does not. Good luck convincing big email providers to agree on a new standard like that.
GitHub alone has like 5 different ways to handle 2FA. Google has, I think, 3? Using a browser to handle this simplifies things a lot.
b) While it's not fixed by Oauth it greatly limits what can happen:
— First, you only need to store a refresh token that can expire and that expiration can be controlled by administrator
— Second, that token has limited scope: password provides access to entire account
— Third, it's clear where it came from — if token gets compromised, you will know where it happened. With password, it's unclear.
> Infrastructure to handle authentication on the web already exists.
Email does not run over the web, it runs over the internet. It uses a completely different set of protocols from the web, which were all invented at least 5 years before the first web protocol. Why should email clients be required to add HTTP support in order to make email work?
Maybe we should take heed of Zawinski's Law, and make all web browsers implement native email clients instead. Yeah, that's probably it. The Netscape Communicator/Mozilla Suite model should never have been dropped, and it was a mistake to separate Firefox and Thunderbird as separate projects!
/s
Email does not run over the web, it runs over the internet. It uses a completely different set of protocols from the web, which were all invented at least 5 years before the first web protocol. Why should email clients be required to add HTTP support in order to make email work?
Maybe we should take heed of Zawinski's Law, and make all web browsers implement native email clients instead. Yeah, that's probably it. The Netscape Communicator/Mozilla Suite model should never have been dropped, and it was a mistake to separate Firefox and Thunderbird as separate projects!
/s
Well, because it already exists? All email clients need to do:
- Open a link in a browser (don't you dare open it in an embedded browser, I will find you and force you to type 100 characters as I dictate it to you)
- Handle callback.
That's all. That's the entire authentication. There is probably not a single platform (language and maybe a framework) that is used to build an email client and has no library to handle this with a few lines of code.
I think that's a much better and easier solution than make developers of email clients handle the very possible authentication method email providers could come up with (see reply to my comment about 2FA with Google).
Also, old opera with torrent client, calendar, compressing proxy, email client was the best.
- Open a link in a browser (don't you dare open it in an embedded browser, I will find you and force you to type 100 characters as I dictate it to you)
- Handle callback.
That's all. That's the entire authentication. There is probably not a single platform (language and maybe a framework) that is used to build an email client and has no library to handle this with a few lines of code.
I think that's a much better and easier solution than make developers of email clients handle the very possible authentication method email providers could come up with (see reply to my comment about 2FA with Google).
Also, old opera with torrent client, calendar, compressing proxy, email client was the best.
> Google has, I think, 3?
There's at least:
1. SMS
2. TOTP
3. Google Prompt (on Android / iOS)
4. Offline security codes (distinct thing from TOTP, generated from Android settings)
5. Backup codes
6. Security Key
There's at least:
1. SMS
2. TOTP
3. Google Prompt (on Android / iOS)
4. Offline security codes (distinct thing from TOTP, generated from Android settings)
5. Backup codes
6. Security Key
Do you have some documentation for this? All I could find[1] pointed to them only supporting OAuth, similar to Microsoft.
[1]: https://developers.google.com/gmail/imap/imap-smtp
[1]: https://developers.google.com/gmail/imap/imap-smtp
I didn't mean that they had native IMAP support for those, but that these are the 2FA methods they support in general. With browser-based OAuth, it's viable to build support for a new 2FA method in just one place. Needing to build each of these into a protocol + get all popular IMAP clients to implement that support? It'd take an eternity; we'd probably still be stuck on just TOTP.
Ah yes, my misunderstanding.
Indeed, OAuth makes it easy to swap out the actual authentication step. Which is nice, because the service shouldn't really care about that, only that the user is authenticated and authorized.
Indeed, OAuth makes it easy to swap out the actual authentication step. Which is nice, because the service shouldn't really care about that, only that the user is authenticated and authorized.
The security Key could also be a Bluetooth-enabled security key or pixel phone.
> What's wrong with adding a simple challenge-response protocol for FIDO2/U2F USB drives? Or a TOTP popup if you don't have a physical security key?
Our application send mails on behalf of our customers. This is done in an on-prem background service running on one of their servers wherever that might be.
So, anything interactive is a no-go. And installing a physical USB key is probably a no-go for most customers, especially those who have their servers hosted by a provider.
Our application send mails on behalf of our customers. This is done in an on-prem background service running on one of their servers wherever that might be.
So, anything interactive is a no-go. And installing a physical USB key is probably a no-go for most customers, especially those who have their servers hosted by a provider.
Client certificate authentication can be done with any TLS, at least it already was in TLS 1.0 published in January 1999, even before SNI.
> a) password doesn't support 2nd factor.
FWIW, there’s the hacky way reddit clients authenticate: "password:OTP" instead of just your normal password. Not that MS could do that, but I wanted to mention the option ;)
FWIW, there’s the hacky way reddit clients authenticate: "password:OTP" instead of just your normal password. Not that MS could do that, but I wanted to mention the option ;)
Whatever their reasoning, it means i have to have an email client and a browser to log in. Can't say I like that.
Yeah, but they use SMS 2FA which is not secure.
Google offers FIDO, and even has an "advance protection" program to enforce only FIDO as 2nd factor.
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, it'd not even be entirely wrong to migrate.
Lack of HTTPS on the author's site also adds a nice subtle flavour to the blogpost.