Fedora Linux 43 Exposes 20-Year-Old Microsoft Outlook Security Failure (nerds.xyz) 50
BrianFagioli writes: Fedora Linux 43 users upgrading to the latest Dovecot mail server discovered something rather unsettling: some older Microsoft Outlook configurations may have been silently ignoring SSL/TLS settings for POP3 email connections for years. According to a Fedora community blog post, affected Outlook clients reportedly continued using insecure port 110 connections even when encryption was enabled in the application settings. The issue surfaced after Dovecot 2.4 disabled plaintext authentication on non secure connections by default, causing Outlook users to suddenly lose mailbox access after the Fedora 43 upgrade.
The report suggests the behavior may date back as far as Outlook 2007, although modern Outlook builds were not fully tested. Fedora admins stress that the problem could be limited to legacy account configurations rather than current versions of Outlook itself. Still, the discovery has sparked discussion among Linux admins and security folks because many users likely assumed their email traffic was encrypted simply because Outlook claimed SSL/TLS was enabled. The incident also highlights how stricter defaults in modern open source infrastructure can expose ancient assumptions and questionable behaviors that quietly survived for decades.
The report suggests the behavior may date back as far as Outlook 2007, although modern Outlook builds were not fully tested. Fedora admins stress that the problem could be limited to legacy account configurations rather than current versions of Outlook itself. Still, the discovery has sparked discussion among Linux admins and security folks because many users likely assumed their email traffic was encrypted simply because Outlook claimed SSL/TLS was enabled. The incident also highlights how stricter defaults in modern open source infrastructure can expose ancient assumptions and questionable behaviors that quietly survived for decades.
"Legacy configurations" (Score:3)
limited to legacy account configurations rather than current versions of Outlook
I'm assuming "legacy account configurations" means anyone who hasn't moved to "Outlook (new)" or whatever they're calling it this week. Meaning the vast majority of Outlook users.
Re: (Score:1)
Re: (Score:3)
Re:"Legacy configurations" (Score:5, Interesting)
STARTTLS on port 110 is was a very common configuration. So you wouldn't tell anything in the logs from simply the port number.
Re: (Score:1)
Re: (Score:2)
I think STARTTLS as a concept was stupid. If you supported TLS/SSL then you should have just used the correct port and ignored this confusion in the first place. There was no good reason to start insecure and upgrade when you could have attempted a secure connection in the first place.
I think this kind of configuration was a fuckup waiting to happen.
Re: "Legacy configurations" (Score:2)
It was very common, maybe it made sense originally (I don't think so but anyway) but it hasn't for a long time...
Re: (Score:2)
Not sure, don't ever deal with POP3. Come to think of it, it may be the use of that protocol that they refer to with "legacy account configuration", and not the desktop application.
Re: (Score:3)
Most orgs phased out POP decades ago in favor of IMAP (I know we did).
I suspect POP on Outlook is now rare, and used almost exclusively where there is no security organization to flag its existence. And that means no one there to read the logs. And why even look at the logs when everything's working as expected?
Re: (Score:2)
I'm assuming "legacy account configurations" means anyone who hasn't moved to "Outlook (new)" or whatever they're calling it this week. Meaning the vast majority of Outlook users.
I'm assuming it means people who setup their Outlook accounts years ago and have migrated up through various updates without setting the server settings anew. For one, Outlook (even my quite ancient outdated version) defaults the port away from 110 if you select SSL/TLS as an option on POP3. But it didn't used to in the past, opting instead to default to port 995 requiring a user to manually set the port back to 110 if they do something weird like use encryption on port 110.
The whole idea sounds like a stup
Re: (Score:1)
"Outlook (new)" is even worse at handling passwords. It is not email client. That's phishing app.
Where have all the cowboys ehhh I mean firewalls g (Score:1)
Re: Where have all the cowboys ehhh I mean firewal (Score:2)
Not real. I never had 110 open and outlook would use the ssl port.
Re: (Score:3)
Almost everyone still configures their firewalls to be default permit (or mostly default permit) because it's the easiest way to avoid breaking things. That's true even when it's desirable to break things so that the root cause can be identified and fixed, because quite often management doesn't care about this: they just want things to work, and when a sysadmin
legacy tax (Score:2)
Just unplug the old insecure protocols by default. Break stuff if it is going to be leaking credentials on the wupd Internet. Don't trust that MS tests their software with anything but their own IIS suite. (Which probably dropped unencrypted / unsigned POP3 as a default option decades ago)
Re: legacy tax (Score:2)
Re: (Score:2)
oof. Yea. I think a better policy for StartTLS is to refuse authentication if it isn't activated. Doesn't totally prevent clients from sending their auth over clear text or to a MiM, but at least the bad client won't silently work.
Re: legacy tax (Score:2)
Microsoft want to drive everyone to their proprietary protocols.
Re: (Score:3)
Re: (Score:2)
OK but who uses POP3?
There were some email hosting companies that only offered POP3 on their free (or lowest cost) tier. While many supported pop3/tls, if it ain't broke, most people were not willing to change things (to use pop3/tls) even if they could.
Re: (Score:2)
That's pretty much my setup, except that it is 60 days and a different client (no, not Outlook or anything related) - I did it for substantially the same reasons.
Lookout! (Score:5, Funny)
Re: (Score:2)
Better name for it.
Yep. I've been using that name for it going as far back as when it ignored MIME extensions/headers and attempted to actually decode the attachment(s), thus causing it to forward an email virus or worm simply by opening the main email.
Email guy... (Score:5, Informative)
So I'm an email guy from way back... Literally decades...
Nobody leaves ports 110 & 143 open & exposed anymore. Not just blocked by a firewall rule, the Dovecot daemon's themselves, properly configured, simply don't listen on non-secure ports anymore at all. It's dead technology. You get bit by this, you're just an idiot.
What I found amusing is the bit about modern Outlook vs. Legacy. Modern Outlook, even on your desktop, is a cloud play. You might think you have a local App. You don't. Modern Outlook can't handle a simple "Linux" username as an account. The user "bob@example.com" represented by a "bob" entry in /etc/password cannot be used by a modern Outlook client. It passes the domain to M$ cloud and converts it to "bob@example.com", which a local vanity Dovecot domain will reject. It's intentional... They have placed their cloud between your local App and the email server. You think you're running a local app, but they're hoovering up all your email in a proxy config.
T
Re: (Score:1)
ports aren't insecure, protocols are. The people who block ports pointlessly just because they've been abused in the ancient past are idiots too.
Re: Email guy... (Score:2)
If you do it right you use POP3S and IMAPS, then you have encrypted the traffic so that the data is protected. It's still POP3 and IMAP, but in an envelope.
Re: (Score:2)
Ports have specific purposes, this is what allows applications to connect to each other without the user specifying ports manually. There's a reason you're not connecting to Slashdot's HTTP server on port 80 right now. Not listening on an port dedicated to an insecure protocol explicitly prevents this kind of fuckup in the first place.
Mind you STARTTLS is the problem here. The idea that you connect insecure and upgrade your connection later was dumb and I'm keen to see if anyone can give me a good reason wh
Re: (Score:2)
> good reason why this was ever something which existed.
Firewalls allowing only the non-secure variants (POP on 110), making STARTTLS the only way to retain compatibility while enabling encryption.
Re: (Score:2)
> people who block ports pointlessly just because they've been abused in the ancient past are idiots too.
I agree with that, but in this case you're wrong :
- pop and IMAP have their secure counterpart defined by the IANA. Blocking the non secure variant is a legitimate approach
- Security is layered on by using TLS, not directly by the protocol itself
- The non secure variants have been officially obsoleted by RFC8314
Re: (Score:2)
The people who block ports pointlessly just because they've been abused in the ancient past are idiots too.
You'll want to amplify on this, because blocking a well-known port for an insecure protocol has no downsides. Nothing legitimate is going to be spun up on e.g. 110, why would you leave it open vs blocking it?
Re: (Score:2)
True.
Huh? Blocking inbound ports in which you don't actively host services or outbound ports in which you don't require traffic is just good security.
Re: (Score:1)
StartTLS says hi.
Re: (Score:2)
Can you help me here? Why does StartTLS exist? A client needs to explicitly request a StartTLS session, so why not directly into SSL/TLS? It seems like such a stupid quirk of the past that was inveitably going to lead to just the cases here. We use different ports for different protocols across the internet for a reason.
Re: (Score:2)
I use four email providers for my various addresses (plus gmail which is only for my smartphone) and some of those providers mandated StartTLS for a while, all now insist upon SSL/TLS nowadays but I can't remember when any of them changed their requirements.
Re: (Score:2)
[Citation required]
Certainly there's been blocking of ports and connections, but you claim that a router is intercepting and inspecting traffic to block a specific request sent through on a port for nefarious reasons... that's an extraordinary claim, so back it up with evidence.
Dovecot turned off plain text auth? (Score:1)
I am pretty sure that plain text comms are not enabled in default Dovecot configuration for decades.
Email (Score:2)
Email just needs to die.
That's all there is too it.
It was designed for a different era, and makes many, many terrible assumptions, and throws most of them out of the window in the worst possible way at the worst possible time.
Plus, it's built on "honesty", and everything security, or authentication, or even just claiming who you actually are as an email sender are all bolt-ons that don't work to their full extent.
Even with DNSSEC+SPF+TLS+DKIM+greylisting+limiting.... there's still no way to reliably know wh
Re: (Score:2)
Email just needs to die.
No, it is still the only non-monopolized communication protocol with a very wide audience, where everybody can participate without being at the mercy of some evil corporation. And you can use signed and end-to-end encrypted emails - even though many are too incompetent or ignorant to do so.
The only non-monopolized communication protocols available today are far from being omnipresent enough to be a viable replacement.
Re: (Score:2)
If you are using signed and end-to-end encrypted emails, let me tell you:
You're merely using email as a transport mechanism, where ANY OTHER SUCH MECHANISM would suffice and be just as secure.
Including things like Jabber, etc.
Email is utterly monopolised because if you want to send/receive email to the major players... you MUST abide by whatever ridiculous restrictions they put on things (e.g. 10 DNS lookups for SPF, blacklists, domain verification, spam categorisation, etc.) regardless. Even if you're on
Re: (Score:2)
Email as a protocol needs to die. The stuff we do by email can be done PROPERLY AND BETTER by just basing the same top layers on something else that actually works and does the end-to-end encryption, domain verification, signing, authnetication etc. for you anway).
That something else does not exist and will never exist, because the big Internet companies won't let it exist. SMTP email exists and can be used outside the control of the big companies.
Protocols like Jabber would suffer from the same issues that you claim email has if it were adopted as a replacement for SMTP. .
What you are really proposing is, in effect, that instead of email, people should just use the plethora of proprietary messaging services.
Re: (Score:2)
Just use GMail. Millions of ex-Nigerian finance ministers can't be wrong.
Uhm... (Score:2)
Re: (Score:2)
You focused on the wrong part of the story. The part of the story was that server side disabling of plain text authorisation caused authorisation to fail which very much did mean there was no TLS/SSL for security.
The entire concept of running secure connections on port 110 is stupid from the onset. Yes STARTTLS exists, but it shouldn't. This is precisely the kind of fuckups that this approach leads to. Any partially competent system administrator sets up systems to listen on their specific dedicated ports f
Outlook older than 2016 called STARTTLS "TLS" (Score:1)
This is a ridiculous way of conveying to the world that Outlook 2013 and earlier, which nobody on the planet should be using since it's long since been abandoned, call STARTTLS simply "TLS" or "SSL".
STARTTLS uses normal unencrypted ports, and opportunistically attempt to enable encryption.
There is absolutely nothing to see here.