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.