(imported comment written by BenKus)
That is true… There is no reason to encrypt the gather traffic because of the fact the gather sites are considered open to all agents and we would have to implement a client authentication system (as mentioned above) before it would matter much…
Ben
(imported comment written by SystemAdmin)
Has anyone with highly customized tasks/baselines/analysis had any complications/attacks on publically facing relays?
And/or has there been more recent discussions than this thread?
Continued:
Let me ask the question a different way. Has anyone done a risk assement for implementing public BES relays? Especially from the software distribution point of view? I think the brute force stuff could be mitigated at the firewall level.
has this been updated? I would like to encrypt all traffic to and from our DMZ relays. Is this still not implemented?
Peter
Authenticating relays which encrypt the communication layers between the client and relays has been available since 9.0.
http://www-01.ibm.com/support/knowledgecenter/SS63NW_9.1.0/com.ibm.tivoli.tem.doc_9.1/Platform/Console/ClientAuthentication.html%23ClientAuthentication?lang=en
The encryption of reports coming from the clients has been available longer.
http://www-01.ibm.com/support/knowledgecenter/SS63NW_9.1.0/com.ibm.tem.doc_9.1/Platform/Config/c_message_level_encryption__mle_.html
I believe one issue with authenticating relays is that the client must have already connected once to a non authenticating relay in order to authenticate.
The client needs to get a certificate.
Either via registration with a non-authenticating (open) relay or via manual key exchange with an authenticating relay.
Could the password be included in the clientsettings.cfg file, or some other similar way to automate it?
It can’t be automated no. Are you talking about “prepopulating” when a machine is set up for a remote user/site?
The idea here is that you can provide a one time password to an end user to run this manually, or the internal relays when someone sets up a laptop that goes outside would be open so it would automatically populate.
I mean that I want IT Admins who don’t know anything about BigFix to double click the BES Client Setup EXE and have it work even if the device happens to be remote without having to explain to them first that this is a special case and they need to specifically get a password from us to make it work. If it could be included in the ClientSettings.cfg file that we place next to the installer that we tell them to use, then it would satisfy this need, or if it could be embedded within the MSI.
Unfortunately its not a “setup” type thing that is easily managed that way. Passwords are relay specific not all over the deployment and we don’t have that automated step as its something that is set up in the way you are posting it. Its not impossible but definitely not on the radar. I’d file an RFE to get it there though as it would be do-able if you have control over certain parts.
But why couldn’t all internet facing relays have the same manual password, and then embed that password in the setup? For the internal / non-authenticating relays, the password would not be needed.
That would mean that everyone had that password and you have just allowed everyone to connect to your relay again somewhat defeating the idea of an authorized user. If endpoints have passwords on them, anyone can get them that can get to that endpoint if its not a one time use
We wouldn’t allow just anyone to get access to the client with the password embedded.
You are incorrect that this would not provide added security. The alternative is that the relays are set to non authenticated and open to anyone in the world. Open to anyone with a copy of our specially modified client installer is a much smaller pool.
The point of this is not to provide perfect security, but to provide better security.
Also, wouldn’t this provide SSL encryption for traffic between relay -> client? That is a benefit even if we made the manual password widely known.
( In other words: Having both encryption and authentication is preferred, but having encryption without authentication is better than no encryption at all )
Clients will try and perform an HTTPS connection to their relays if they are 9.0 or above but it doesn’t encrypt all traffic mostly the registrations etc as the other information is all signed.
For results you can also use encryption on the reports.
Generally adding the overhead of doing HTTPS all the time just means the relays need to be beefier as they are doing a lot more work.
So MLE means reports from clients to relays are encrypted. Are there communications from clients to relays that are never encrypted regardless of configuration? What are they?
Are you saying that 9+ clients will always attempt an SSL connection to their relays, or only if they are authenticating relays?
What traffic from relays to clients is never encrypted?
Signing alone prevents tampering, but it means that the traffic is in the clear and can be sniffed between relay and client, which is not ideal and we might prefer to configure it so this is not the case.
In our organization our relays are all server class hardware that is either completely dedicated to being a relay, or used for 2 or 3 tasks with low performance needs. I believe most have 10gig connections at as well. CPU overhead of SSL is not an issue.
I think it would be a huge advantage if all traffic could be encrypted with the absolute minimum of configuration and limitations over the default, without the restriction of authenticating relays preventing new clients from connecting… either through a manual password that is embedded in the client installer, or by preferring encryption or authentication.
With Authenticating relays, all communication between the Client/Relay is over HTTPS (registration/downloads/uploads etc)
For non authenticating scenarios with 9.0+ Client/Relay combinations when the client has a certificate, the registration is attempted in HTTPS and backs off if it can’t do it. All subsequent traffic until the next registration is over HTTP like older platforms for performance reasons. The Client always has validated everything it receives (as they are either signed documents or hash calculated downloads) so this isn’t a security issue.
For one or both of the Client/Relay being less than 9.0, registration and all communication is over HTTP
If MLE is on of course the reports are encrypted and is available since we added that feature a long time ago. This protects the report up until either a decrypting relay or the root server. It protects it from viewing during communication or on disk storage as relays combine reports.
Thanks for the further explanation, that is what I was looking for.
If there was an option to enable optional SSL encryption for all client/relay communications similar to the authenticating relay scenario, but without the authentication and potential orphaning of clients without certificates, then I would find that valuable and use it.
So the certificate for HTTPS has to come from somewhere and that’s the general problem. No matter what you do you’ll end up with some case that will orphan or you have little to no encryption security. Basically the cert has to come from somewhere.
I think though you don’t mind if the transaction is encrypted to anything in particular but as long as it negotiates for just THIS connection? The issue with that is the hardware requirements for that go up fairly quickly with everyone negotiating unique connections and the concept of a relay being not a large machine goes away rapidly.
Surely with all of the certificate management & signing that’s already happening, it wouldn’t be such a stretch for the BES Server to be an internally-trusted Certificate Authority, and have it sign the certificates generated by each Relay? The CA Signing Certificate on the BES Server could be distributed as part of the client installer, like the masthead.
Having an option for the Relay to handle all traffic over HTTPS would be a great benefit for us, if we could enable/disable the option according to our needs. On internal subnets where we’re distributing relays for LAN traffic management purposes, we might leave HTTPS as optional/registration-only, but for our Internet-facing relays (which is probably dedicated hardware for most people anyway), we could force HTTPS-only.
With the DMZ relay type, the root server can’t be an authority as its not reachable by the clients in question.
The enabling as you mention is exactly what an authenticating relay does. You enable it where you need it and where you have the hardware that can support the extra load