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
The certificate does not need to come from somewhere if it is self signed. I’m talking about an untrusted unauthenticated but encrypted connection. Encryption is beneficial even if it conveys no other security other than the encryption itself. I am not talking about a full blown PKI infrastructure with trust.
Clients and relays could use Diffie–Hellman key exchange to encrypt traffic between each other without the need for PKI at all, which would reduce the load. Encryption alone would not prevent man-in-the-middle attacks, but it is still preferred over no encryption at all.
I’m basically asking for something between authenticating relays and regular relays. An option to enable optional encryption on certain relays without the need to authenticate the client’s certificate.
The authenticating relays authenticate the client to make sure that the client is allowed into the system.
A root CA does not need to be reachable by the client, the CA certificate could be distributed as part of the client installer in order for the client to trust it. The CRL could be distributed by Relays as part of the normal BES infrastructure rather than though an online web site; as long as the CRL is properly signed by the root server the client should be able to accept it.
This would allow for an encrypted channel between the client and relay, without the additional overhead of requiring the client first connect to a non-authenticating relay. The client can authenticate the Relay and encrypt traffic, without the Relay necessarily authenticating the client.
Message level encryption would be a good idea, yes, but in particular, configuring the external facing Relays to be authenticating. Please see the following for reference:
While it’s enabled deployment-wide, it is configurable per Client via _BESClient_Report_Encryption. The default for that setting is optional, so, if you’ve enabled MLE via BESAdmin, by default, most/all Clients will encrypt their reports. You can set _BESClient_Report_Encryption to none or required as desired depending on the connectivity of the device.
I guess due to the assumed overhead, there’s no reason to use MLE for the entire deployment except for those traversing the internet. If the clients won’t be traversing the internet but just Relay to Relay communications will be, would MLE still be necessary?
The basics are that https is “on the wire” and MLE is “on the disk”.
MLE prevents reports from being read off of the Relay’s disk storage in the case the Relay itself is stolen or compromised; useful for example if you have deployed Relays to field storefronts or offices where you can’t physically protect the Relay.
The consequence of MLE is that the Relay cannot combine reports from clients, so there can be added network traffic and processing required to decrypt & combine or import the reports upstream. Thus it is common to employ “Decrypting Relays” as top-level relays; these relays need access to the deployment’s private key in order to decrypt the reports and combine them, reducing the processing load on the root server.