just some background - you might know this, but let's all get all the same page.
HTTP is a protocol, a way of requesters and responders to exchange information. It was originally defined in IETF RFC 2616, which has since been updated or obsoleted by successive RFCs. a requester sends a request with a VERB and a URL, and some headers, and an optional payload. Then the responder can reply with a status line, and some headers and an optional payload. Obviously there's more to it than that, but that is the basic idea.
You can run that protocol over a bare socket. It's wide open communication, any observer can see it. Worse, any party handling the traffic (like a network router) could modify it, and neither the requester nor the responder would be aware. From that, we can say that HTTP over a socket is insecure. HTTPS is just a way of running HTTP over a secure transport layer, TLS. TLS establishes a secured socket layer, in which all communication between the requester and responder is encrypted, using the keys the two peers have been provisioned with. This allows the requester and responder to rely on the integrity of the communication. They can be assured that no one else has observed the cleartext data, and no other party has modified it.
You probably know all of this.
When using HTTPS, the encryption happens at the transport layer. If I have two systems that intercommunicate via HTTPS (or any TLS connection), the data in my application code is in cleartext, but when the app sends data over the network, the TLS library for that application encrypts the data before sending it. On the receiving side, the converse happens: the TLS library on the receiver side receives the encrypted data (ciphertext), then decrypts it before passing it up to the application code. When using TLS, data on the network (in transit) is encrypted, data in the app is not encrypted.
OK with that out of the way, let's get to your question. Apigee, when you configure it as an API proxy, allows two HTTP connections, one for the inbound request, and one for the upstream request. Inbound is client-to-Apigee, upstream is Apigee-to-target-server. And those are distinct connections, distinct transactions. Strictly speaking, the two transactions are not completely "independent" because Apigee relates them internally, so that for example an error on the upstream request will cause the message context to enter fault state, which then causes a fault message to be sent back as response to the inbound request. So Apigee itself introduces a dependency between the two transactions, but the details of those transactions are still distinct.
The verb, headers, payload, and URI path can be different between the inbound request and the upstream request. By default they are the same but you can configure your API proxy to modify the verb, inject or remove a header, change the payload, and so on.
Likewise, the scheme - http or https - can be different. You can configure your proxy to use https inbound and http upstream. Or https on both ends. You can configure it to use 1-way or 2-way TLS. on either end. Even if you choose to use TLS on both transactions, the keys and truststore are different on each end. There are different TLS handshakes. You could use different TLS protocols, different cipher suites.
If you use TLS on the inbound request, the data from the client to the Apigee endpoint will be encrypted in transit. Before your API proxy receives the inbound request (GET /foo/bar, etc), the TLS library will decrypt the data and pass on the cleartext to the API proxy. Similarly, if you use TLS on the upstream link, then your API proxy just invokes the upstream via HTTP (eg, GET /bah/baz) and the TLS layer encrypts it before sending it over the wire. If the upstream is not HTTPS, then the TLS layer does not intercept the message, and Apigee transmits the cleartext HTTP message over the network.
So, YES, it is possible to configure your Apigee API proxy to accept https request inbound, and then initiate an HTTP transaction with no transport security to the upstream target. You can do that.
Why would you want to do that, though? It's a bad idea to be connecting to an HTTP endpoint with no TLS. Always use HTTPS. At this point, TLS ought to be something you can do easily, and you should probably rethink your life choices if you believe that connecting to an upstream system via HTTP is a good idea.
LinkedIn
Twitter
