Hi,

I would like to deploy an App but I would like to use it using only https.

What is the way to indicate CF that the Application X will use https only?

Juan Antonio

There isn't a way to tell CF that you want https only at this time. You'll
have to check the x-forwarded-proto header in your application and redirect
to the secure endpoint if needed.

On Tue, Sep 8, 2015 at 6:16 AM, Juan Antonio Breña Moral <
bren(a)juanantonio.info> wrote:

Hi,

I would like to deploy an App but I would like to use it using only https.

What is the way to indicate CF that the Application X will use https only?

Juan Antonio

--
Matthew Sykes
matthew.sykes(a)gmail.com

this related story is in the routing team tracker, not currently scheduled:
https://www.pivotaltracker.com/story/show/80674008

On Tue, Sep 8, 2015 at 4:30 AM, Matthew Sykes <matthew.sykes(a)gmail.com>
wrote:

There isn't a way to tell CF that you want https only at this time. You'll
have to check the x-forwarded-proto header in your application and redirect
to the secure endpoint if needed.

On Tue, Sep 8, 2015 at 6:16 AM, Juan Antonio Breña Moral <
bren(a)juanantonio.info> wrote:

Hi,

I would like to deploy an App but I would like to use it using only https.

What is the way to indicate CF that the Application X will use https only?

Juan Antonio

--
Matthew Sykes
matthew.sykes(a)gmail.com

--
Thank you,

James Bayer

Hi James,

I have just tested and I received this message:

"502 Bad Gateway: Registered endpoint failed to handle the request."

Source:
https://github.com/jabrena/CloudFoundryLab/tree/master/Node_HelloWorld_ssl

I think that it is a very important feature. In the example, I use a local certificate to offer a https connection with an API, but CF doesn't have any support.

My question is: How to deploy in Pivotal a secure application if the platform doesn't that support?

Juan Antonio

juan i don't understand what you are trying to do.

your node app should listen to the $PORT environment variable with a plain
http connection.

the load balancer you use for cloud foundry (HAProxy or a LB you provide
like F5 or ELB) should terminate SSL and add the appropriate
x-forwarded-proto header to indicate whether the originating request was
SSL.

gorouter also supports received https traffic from the load balancer, but
does not re-encrypt the traffic to the backend container.

app client ---HTTPS---> LB ---HTTPS---> GoRouter ---HTTP--->
DEA/DiegoCell

what are you trying to do?

On Tue, Sep 8, 2015 at 11:34 AM, Juan Antonio Breña Moral <
bren(a)juanantonio.info> wrote:

Hi James,

I have just tested and I received this message:

"502 Bad Gateway: Registered endpoint failed to handle the request."

Source:
https://github.com/jabrena/CloudFoundryLab/tree/master/Node_HelloWorld_ssl

I think that it is a very important feature. In the example, I use a local
certificate to offer a https connection with an API, but CF doesn't have
any support.

My question is: How to deploy in Pivotal a secure application if the
platform doesn't that support?

Juan Antonio

--
Thank you,

James Bayer

Hi James,

Yes, you have reason, I returned to test:

https://nodejsssl.MY_IP.xip.io/

and I see the sreeen where Chrome advise the user about a NET::ERR_CERT_AUTHORITY_INVALID so, the node application is running:

https://raw.githubusercontent.com/jabrena/CloudFoundryLab/master/Node_HelloWorld_ssl/docs/firstScreen.png

but if you click to continue, I receive this message:

404 Not Found: Requested route ('nodejsssl.MY_IP.xip.io') does not exist.

My question is CF could fix this issue to deploy applications which it runs with https protocol.

Juan Antonio

the standard way to do this is to terminate SSL at a load balancer, which
then forwards to the CF routing tier. the hop between the load balancer and
the cf router may be done with SSL. the network path from gorouter to the
DEA / Diego Cell backend is only supported with http today. the gorouter
must be able to inspect the request to see the http host header and cookies
(to evaluate session stickiness) to know which app the request is intended
for.

the TCP router which is coming soon and available to preview with lattice.cf
would open up the opportunity to use a random port to identify the app,
which could then pass through to the the backend that had a secure listen
port.

On Wed, Sep 9, 2015 at 1:45 AM, Juan Antonio Breña Moral <
bren(a)juanantonio.info> wrote:

Hi James,

Yes, you have reason, I returned to test:

https://nodejsssl.MY_IP.xip.io/

and I see the sreeen where Chrome advise the user about a
NET::ERR_CERT_AUTHORITY_INVALID so, the node application is running:


https://raw.githubusercontent.com/jabrena/CloudFoundryLab/master/Node_HelloWorld_ssl/docs/firstScreen.png

but if you click to continue, I receive this message:

404 Not Found: Requested route ('nodejsssl.MY_IP.xip.io') does not exist.

My question is CF could fix this issue to deploy applications which it
runs with https protocol.

Juan Antonio

--
Thank you,

James Bayer

Hi James,

Now, understood your technical explanation:

"the standard way to do this is to terminate SSL at a load balancer, which then forwards to the CF routing tier. the hop between the load balancer and the cf router may be done with SSL. the network path from gorouter to the DEA / Diego Cell backend is only supported with http today."

"app client ---HTTPS---> LB ---HTTPS---> GoRouter ---HTTP---> DEA/DiegoCell"

Cloud foundry supports SSL connections, but currently GoRouter only handle http.

I checked the idea and I noticed that when I deploy an application, the platform add the following http headers:

"x-forwarded-for":"CLIENT_REAL_IP, CLOUD_FOUNDRY_IP",
"x-forwarded-proto":"https"

So, if you only want to execute an API for example with https, it is necessary to filter with this header:

"x-forwarded-proto":"https" (The idea from Matthew Sykes)

I think that it is necessary to create another issue to add the support for http2 I checked, but if fails, the same reason:

https://github.com/jabrena/CloudFoundryLab/blob/master/Node_HelloWorld_http2/index.js

@James,

who add the headers?

"x-forwarded-for":"CLIENT_REAL_IP, CLOUD_FOUNDRY_IP",
"x-forwarded-proto":"https"

the load balancer or the GoRouter?

Your edge load balancer should be configured to add x-forwarded-for and
x-forwarded-proto headers.

On Wed, Sep 23, 2015 at 4:24 AM, Juan Antonio Breña Moral <
bren(a)juanantonio.info> wrote:

@James,

who add the headers?

"x-forwarded-for":"CLIENT_REAL_IP, CLOUD_FOUNDRY_IP",
"x-forwarded-proto":"https"

the load balancer or the GoRouter?

Hi Dieu,

many thanks for the technical info.

I will consider this factor to add this restriction in the development.

Juan Antonio