2

My questions:

1) Why do I get http as the scheme in the Location-header when the original request from the browser was made with https?

2) Is this an wildfly load balancer problem?

My Request Header is:

method: POST
scheme: https
accept-encoding: gzip, deflate, br
accept-language: en-US,en;q=0.9
content-length: 39
content-type: application/x-www-form-urlencoded
origin: https://10.43.201.207
referer: https://10.43.201.207/myapp/login.html

My Response Header is:

content-length: 0
date: Thu, 03 Jan 2019 04:55:42 GMT
location: http://10.43.201.207/myapp/dashboard.html?init=1
server: WildFly/12
set-cookie: APP_AUTH=leTPWYd1222zsrrtRRtgpuEWEWc7pR0CBuNPYPT5QHbGn_Db7ICK; path=/; secure; HttpOnly
set-cookie: JSESSIONID="leTee33333PWYdSDSDweetRRtgpuc7pR0CBuNPYPT5QHbGn_Db7ICK.master-0:master-server"; Version=1; Path=/myapp; Secure; HttpOnly
status: 302
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-powered-by: Undertow/1
x-xss-protection: 1; mode=block
Pathak
  • 183
  • 5
  • 21
  • 1
    That appears to be a redirect. – Robert Harvey Jan 03 '19 at 05:32
  • Hi Robert , yeah correct it is redirect only , but we are not saying like redirect with http. In our LoginServlet Code we are writing like below in doPost method `response.sendRedirect("dashboard.html" ); ` – Pathak Jan 03 '19 at 05:40
  • I did a bit of research before commenting on your question. It seems to suggest that a redirect can occur before the TLS handshake is realized. – Robert Harvey Jan 03 '19 at 05:42
  • So should I need to change my LoginServlet code something like if it is **http** replace with **https** ? or there is some load balancer configuration am I missing? – Pathak Jan 03 '19 at 06:01
  • Hi I didn't get any clue on this , why response header is coming as http , can anyone suggest me here how can I come out from this problem? – Pathak Feb 19 '19 at 12:46

3 Answers3

3

Is the load balancer stripping the TLS off and forwarding the request to the app as HTTP? If so, then the app, when performing a redirect, it is probably using the same protocol that it received the request on.

If that's the case, either get the app to force https, or get the load balancer to rewrite the responses coming back through.

You may need to set proxy-address-forwarding="true" and/or request_header_add X-Forwarded-Proto https .

user1438038
  • 5,821
  • 6
  • 60
  • 94
Menno Groen
  • 181
  • 7
  • Hi Mennon, how can I check this : - load balancer is stripping the TLS off and forwarding the request to the app as HTTP? – Pathak Mar 12 '19 at 15:08
  • 1
    You could check where the TLS certificate is set up - if it's on the load balancer, then it's dealing with the decryption, if it's on the app (or app server) instead, then that is. Or if it wasn't you setting up TLS, ask the person/team that did. – Menno Groen Mar 13 '19 at 08:42
  • @Mennon and @ Subodh , we have added `proxy-address-forwarding="true"` in wildfly application server configuration , it worked – Pathak Mar 13 '19 at 17:26
  • another simple fix would be not to set the scheme in the Location header field at all – Julian Reschke Jan 23 '20 at 13:28
3

Below is the detailed solution explanation for the above problem:

We have a load-balancer sitting in front of two wildfly servers. The load-balancer handles the SSL handshake and forces all traffic over https , the wildfly nodes do not have certificates on them and traffic between load balancer and servers is unencrypted, the wildfly nodes know nothing about the SSL.The communication between load balancer and wildfly nodes is via http protocol.

When a user hits a protected page e.g. https://someip/app

Request flow is as below:

  • Client browser to load balancer via https
  • Load balancer to wildlfy nodes via http protocol .
  • Added proxy-address-forwarding="true" in wildlfy server node's http listener
Subodh Joshi
  • 12,717
  • 29
  • 108
  • 202
Pathak
  • 183
  • 5
  • 21
1

Another option is to have you load balancer add the Strict-Transport-Security header to the server response, for example:

Strict-Transport-Security max-age=300;

This will effectively tell the client that he should always use https to contact your server.

Olivier
  • 146
  • 2