Hacker News Reader

I find this comment extremely unhelpful.

There's a reason why everyone uses microsoft exchange, despite all its myriad of flaws, and the flaws of its major client Outlook.

And it's because it offers so much functionality, precisely because it so much more complicated.

It's like saying you can secure your house if you build a 20ft wall round it with no gate.

Sure you can, but it becomes pretty useless.

I don’t think that’s true at all. Exchange is awful. It’s slow, hard to configure and doesn’t offer anything you can’t do better with simpler tools.

Like the majority of awful “enterprise” products on the market, the primary reason that it’s popular is because it’s from a megacorp who speaks the language of the buyers, who are all aspiring megacorps. I was horrified the first time I used exchange and couldn’t wait to change providers the moment I had the chance.

So it’s more like saying you can secure your house if you use a security service who sets security targets instead of sales targets.

It’s pretty bad, but it’s probably the best of the available tools at the time. Serious competitors like Groupwise and Lotus were kind of nightmares. Open source alternatives offered great individual components, but not the integrated solution you got with Exchange/Outlook/Sharepoint.

Sometimes being the least worst option is all it takes.

Exchange ... doesn’t offer anything you can’t do better with simpler tools.

I call maximum shenanigans on this. Exchange is a fully-integrated groupware suite with a single-pane-of-glass on both the management and the user side. I am aware of precisely zero feature-complete alternatives, let alone anything "better".

Feature completeness doesn't mean the software is better. I think, many of those companies affected or the poor people there certainly wished for at least a moment they didn't use Exchange.

...with a huge army of engineers who can do basic admin jobs on it because of the AD integration...with a full suite of structured training programmes to bring up more of those engineers and keep them current.

I suppose if, as has been my experience, “feature complete” actually means “whatever features ship with Exchange” then you’re right. But isn’t that the tautology of enterprise software? Vendors build a moat of features which end up in enterprise RFPs and ultimately lock out other vendors - not because the features are necessary or even useful, but just because they exist and, perhaps, some department head thinks it might be useful one day - or, more likely in my experience, the consulting firm involved in procurement gets a cut of the action. Having been on both sides of this process, I know exactly how it works in practice.

So I’m sure that for some huge enterprises, the complete feature set from Exchange is actually necessary, or at least desirable. But for everyone else - including many companies I’ve worked in at a senior level, and almost certainly many of the victims of this vulnerability - I’d call shenanigans right back at you.

I think the point is that you can provide a lot of functionality by using back-end APIs to communicate to servers in different trust zones rather than having a big ball of trust - especially an internet facing big ball of trust.

And you are right, loose coupling does rule out a very small set of functionality. For example an email sent to a user might have an smb: link, and then Outlook used to do a preview of the email, automatically loading all the links, which would cause your credentials to be sent to the smb:// server just by previewing the email, thereby allowing malicious attacker to steal password hashes by sending emails to victims (no click was needed).

So that would be an example of excessively tight integration and a design philosophy that was fast and loose with shipping both credentials and executables across the network. I think we have learned from those lessons.

In terms of why it is dominant today, it is because of fairly rational C level decisions, not users clamoring for it as opposed to some generic email/calendaring solution. Microsoft still knows how to do support, there is a large pool of cheap IT admins certified to work on it, and it allows you to run your own server instead of buying a service from gsuite. Really if Google could shed their disdain for human beings and learn to think of them as customers, they could take a lot of market share away from Exchange, because right now it is a trade off of security versus support - the functionality is basically the same.

If you don't want outbound smb, don't allow outbound smb. Your bad firewall policy isn't exchanges fault. Bonus, blocking outbound smb also blocks the myriad other vectors for this same issue.

Gsuite doesn't need to be the same as Exchange in functionality. It needs to be the same as AD + Exchange +Teams +onedrive +Sharepoint.

Gsuite email doesn't even have good support for things like delegated access to shared mailboxes, treating them more like a distribution group. On Outlook they appear by magic on your sidebar.

Source: I am currently migrating some acquired users from gsuite to 365

It is unhelpful to your business, if you get hacked and your customers lose trust into your ability not losing confidential data. The daily toil of using Outlook and Exchange is also substantial.

You conflate functionality and complexity. If you think about it for a minute, complexity actually hinders functionality. There is some intrinsic minimal complexity to useful features of a software system for it to be functional. Exchange could be way more useful, if it wasn't so complicated and it could be a lot easier to keep somewhat secure.

Exchange in many circumstances feels more like a banks vault but instead of steel door with a wooden one with the cheapest padlock you can buy and a sign "we go here once a year to check everything is in order" where real banks usually work a bit differently... There are many cases, where an attacker gained access to the complete Active Directory through Exchange. At least so I was told by a company that did the consulting afterwards to clean up the mess.

"access to active directory" is granted to every user account in a domain (how do you think address lookups work?) and isn't nearly as scary as it sounds.

The default installation of Exchange 2013 and 2016 make changes to security descriptors in Active Directory that can make privilege escalation attacks easier. Presumably this is what the parent is referring to, rather than just "plain old" user access to Active Directory.

I know. It really is quite scary, if you have been in a for-real security audit actually. We wouldn't be creating admin workstations if the security story with AD would be so great, hint - it isn't. Exchange must communicate with AD with much higher permissions than most users. It really is scary how many barriers will be crossed just so anything you would expect, like contacts, works.

I've been a part of many for-real security audits. This is largely incorrect scare-mongering. Separate admin workstations are symptomatic of a bad security posture and check-box security, they are absolutely not necessitated by nebulous concerns about the directory being readable.

Of course a server process which is designed to modify (among other things) group memberships needs different permissions than a user, why would that not be the case...?

If you don't like it being highly privileged, don't grant it the permissions. Or hire someone who can.

"It doesn't help Exchange Server is most likely developed using programming languages and approaches that more or less demand complecting the solution with OOP-related ceremony."

This statement certainly doesn't help the credibility of your comment.

Cause you could never have exploits in functional...ever.

Exchange product architecture was absolutely to blame for this. Very particualrly, the "/ECP" directory should have never been allowed to be Internet accessible. (I believe the upcoming version finally rectifies that in a "supported" way.) In general, though, Microsoft hasn't focused enough on making Exchange more compartmentalized. The servers' privileges in Active Directory are too high (though this is supposedly being addressed in the upcoming version too.)

Thank you for the insight.

Certainly, "in the upcoming version" is a bit late for those affected and most of those other Exchange-related hacks in the past. The thinking around Exchange is still more or less left in the 20th century and it shows.

>"It doesn't help Exchange Server is most likely developed using programming languages and approaches that more or less demand complecting the solution with OOP-related ceremony"

What on Earth OOP has to do with the quality / security of the Exchange? This reads like someone is on crusade.

Well, I kind of am to be frank. OOP really mostly obscures an implementation and is often taught almost religiously as "the true one way". In the end, Exchange is a stellar example of the obscured and therefore unfathomable implementation.

You should really watch "Simple Made Easy" by Rich Hickey and think really hard about it. If you don't come to the conclusion that most software development could be way more sustainable in the long run would we use simpler tools and approaches instead of complecting everything especially with questionable OOP balast then maybe we have very different experiences.

>"OOP really mostly obscures an implementation "

I see nothing wrong with OOP. It is convenient for many things. It is not a silver bullet though. Nothing is. Personally I do not adhere to any concept / programming paradigm. They're just tools. I use many. Depends on what I am doing.

Generally one can take a tool and put it to good use while the other will fuck things up regardless.

I think OOP is useful where you need to have state and functions kept together.

It's a little easier to have foobar.update(), rather than update(foobar, state).

I started off mostly programming in R, so using mostly bare functions, but I have to admit that objects are really, really useful when you need to maintain state. Yes, you can do it with closures, but it's a little harder and a little uglier.

That being said, the mutability that makes objects useful is also problematic in that you can end up with magically updating references without defensive copying.

I feel that many of the theories concerning software developer's practice are concocted concocted mostly out of the author's desire to show that their way is the only one and capitalize on that. It is their own business. Not mine. I have bigger fish to fry and do not dwell on my screwdrivers.

The point is exactly, it is somewhat easier exactly in that one case when you have a single state _foobar_ somewhere and work with it all the time. In almost all other cases the second case is actually simpler.

I don't know R and I don't really want to know it. For me, it doesn't seem to bring anything extra to the table that I couldn't do in Clojure or ClojureScript much more consistently and simply. If in my project, I have a number of transformation functions for my state, passing it around isn't a huge deal as it is just a nested map usually. It forces you to be very consistent and helps you as the project grows. Also, most of the functions are easily transferable between projects even when the state would have a very different structure.

Of course the whole thing is a complicated topic and in some cases you want mutability and local state e.g. because the performance is a bit better. Usually, that involves a few simple transformations.

See, this is because you don't deal with data and statistics on a regular basis, which I do.

And if you figure out how to fit a generalised additive model in clojure with one line of code, please let me know :)

So, in DS/stats you end up needing mutability because the datasets are really large, and the models take a long time to run, so copying is generally bad.

What s even more complicated than convincing a company simplifying is necessary?

Convincing a developper to add features rather than remove requirement when the feature has no simple implementation in view :D

I know it was meant as fun. I had a bitter laugh. :-)

Actually, you want to work in a setting where you understand the need and value of a feature and how it fits into the overall design and feel of the (software/ hardware) solution to a problem. Is such a case, you understand that there is no requirement but a need or pain point that needs to be addressed, if you want to deliver more value to the user, some of which may turn into financial or other benefit for you.