Some of these will automatically switch if 80 is not available, like Inventory. Others won't/don't, like Activation. If you want LANDESK to enable 443 for everything, please create an Enhancement Request n the Ideas area.
What Frank said, essentially. And a bit more for context.
Long story short - it's very much NOT just a case of "change the IIS setting to require SSL and that's it" - there's a LOT more to the client comms.
As it is, ongoing security improvements are working towards SHA-2 and better certs, but
Also ... bear in mind that we "need" to keep a certain amount of leeway for "old agents" to be able to communicate with a newer core (as not all customers can upgrade their clients right away for a variety of reasons). So this sort of "massive switch over" is more likely to be of a "trickle introduction" than a "on/off" switch.
LANDesk Management Suite 2016 introduces the "high security" www-service comms - which is one such improvement ... and we didn't make it mandatory / enabled by default because it'd break older clients reporting in to the Core. Because this isn't just "a web browser app" it's got (quite) a bit more work & consideration involved.
Also - not "all port 80" comms is bad.
For instance, one of the reasons why port 80 is listed for inventory, is that clients download the LDAPPL3 configuration file from an HTTP share.
That's a "public file" which doesn't need any special sauce treatment / securing by and large. So - it's not all "a concern" in that regard. HTTP-shares are used for packages too and other things, so hence why / where those are listed.
If you'd list your concerns with more specificity, we can address them.
Hi phoffmann, We have a customer that needs to eliminate communication by port 80 due to PCI compliance. Says that the tool is not in compliance with said standard.
2 of 2 people found this helpful
That's a bit of a "it doesn't work" description which doesn't really help.
First off - what features does your customer use & which one's of those make use of HTTP? Not all uses of HTTP are "bad" (PCI isn't something that should be followed blindly - educated decisions are there for a reason).
- The LDAPPL3 file that the clients pull down to read what software lists the Core is presently aware of (so if there's new stuff, they know to send more detail) as well as pull certain configuration data across ... is done via HTTP. There's no sensitive data there.
- Software distribution CAN be done via HTTP or HTTPS ... depends on how you / they've configured their packages to be (IIRC, HTTP does require version 2017).
- The LDLOGON share by default is an HTTP share ... because clients (for instance - MAC, Linux, Unix) need an open, easily accessible place to access the agent files. You can change it over to HTTPS, but by and large there's no real reason to - because all it holds is just agent config files and "at best" a public cert file. Assuming you've got the enhanced certificate security enabled, the relevant client(s) need to be accepted by the Core first anyway.
- A bunch of provisioning stuff talks via HTTP-based www-services. COULD probably be switched over to HTTP, but that comes with its own headaches. There's enough things to go wrong during the provisioning of a device (say - DNS, slow responding DB, etc) so as to lose out on debugging what's going on with WWW-server commuications. (Oh yes - dealing with HTTPS makes it virtually impossible to get sensible data out of IIS. All you'd see is essentially "Bzzzt - something went wrong / Forbidden" type errors, instead of something more helpful than say "hey, he failed authentication" / "hey, I timed out".)
Not saying that "Oh, it's our provisioning that's crap" - just that "the OS Provisioning stage(s) of a device are *VERY* sensitive to even the slightest things being out of whack - that's applicable to whoever's OS Provisioning you're using. It's in the nature of the stage."
- Or - let's say - they're talking about XTraction. XTraction (out of the box) doesn't use HTTPS - correct. But it can be re-configured to do so in about 5-10 minutes. Very simple ... (and all you need is a cert).
... so - long story short. PCI is "all well and good" - but please think things through. Not everything *HAS* to run on HTTPS all the time.
If there's specific items they would like to switch over from HTTP to HTTPS that can be done / can be easy in some cases (for instance - ticking the "use secure web service" checkbox to cover inventory & vulnerability scans).
There'll have to be a lot more detail than "it doesn't use HTTPS" for there to be a more useful response, really. It's a bit like saying "but my car has a steering wheel". Yeah - OK ... so ... that's a problem how/where exactly?
If there's parts of the product they want/use that presently use HTTP where we haven't yet moved to HTTPS, then there may also be a genuine case for enhancement requests.
But - as indicated with the Provisioning stuff ... HTTPS doesn't "make everything better" all the time. It can make your life VERY painful in terms of troubleshooting stuff ... so where there's no sensitive data flying around, I'm not always a proponent of using it without thinking things through. Everything is about context, at the end of the day.
Hope that helps?
We are not on the client's side with respect to your opinion in fact our opinion is the same as yours.
The subject here is the kind of clients that exist. This is a client that closes and wants to blindly follow PCI as you say.
We will try to talk and make him aware of the topic although I do not see that it ends well.
Thanks for the support.
Yeah - familiar with that situation (hence the reason that your question triggered various warning bells) .
Yeah - it's an uphill battle to explain to people that certain standards are NOT / quite a bit MORE than just a "tickbox" exercises.
Well - if there's anything else we can help out with, let us know. Maybe pointing them to this thread and (hopefully?) getting them to see that there's a lot more than a "yes/no" flag in the reality of things may work.
Never know - sometimes it does work .