@diankj27 wrote:
There is a requirement to apply message-level (payload) encryption, where the API consumer/client will encrypt the payload before it sends to proxy HTTPS endpoints in Apigee.
ok, that sounds good. Many customers want to rely solely on the transport-layer security - that is to say, TLS - to encrypt messages between clients and the Apigee endpoint. There are some implications here. TLS necessarily means that the message gets auto-decrypted at the transport layer. This is good, because you don't have to modify your app or endpoint to handle the encryption - it just happens automatically when you use a TLS-savvy library (like the HTTP capability in Python, Java, nodejs, or C# libraries) or when you use a TLS-savvy system like Apigee. That's good, but.... if either endpoint wants to store the information, that information is in the clear. It's cleartext, no secrecy. And secondly, if the endpoint wants to share that information with some other party - something on an asynchronous (not HTTPS) mechanism like a pub/sub system, then the message won't be encrypted. And finally, there is the low but real likelihood of TLS 0-day exploits. If you rely solely on TLS, then an exploit would expose your data.
This all assumes your TLS implementation is good - you're using TLS 1.2 at least (no TLS 1.1), and you have disabled weak ciphersuites, and your keys are secure. All of that is just assumed.
@diankj27 wrote:
We're still in discussion whether to use PGP encryption type.
Whoa. That would be ... very surprising. I haven't seen PGP used much in API calls. PGP was an attractive idea when it was launched, but maybe over ambitious. It hasn't worked out that well. I haven't seen much adoption of PGP. The ecosystem for PGP is pretty thin and not very dynamic. Modern language platforms like Golang debate removing support for PGP, because it's brittle, and has drawbacks compared to more modern crypto.
If you want to encrypt, why not use something that's more modern, more commonly used, and better understood? Like XML Encryption, or JWE? Either of these will depend on X509 certs and keys, which are well understood. (none of this PGP chain of trust stuff). XML Encryption can encrypt only XML. But JWE can encrypt any payload type - any bytestream. XML, JSON, or some binary bytestream like an image. Or a composite.
If I were building app- or message-level encryption, I would look there.
@diankj27 wrote:
What is the practice to implement encryption/decryption in Apigee X? Shall we go with Java callout policy? Or shall we create a microservice to handle this?
It depends on the crypto approach you take. If you want to use Encrypted JWT - your payload is JSON and you're happy with selecting one of the JWA algorithms - then use the builtin policy in Apigee X that generates encrypted JWT. This won't work for the general case JWE.
If you want to use NaCL or something with a cool library available in Rust or golang, then I would build a GRPC service and call from Apigee to that service via ExternalCallout. If you are using JWE or XML Encryption or AES or something that can be more easily implemented in Java, then I would use a Java Callout. There are existing callouts for any of those final three. JWE, AES, XML Encryption.
Apigee does not have builtin policies for encrypting payloads, beyond the policy for encrypted JWT.
LinkedIn
Twitter
