I recommend its better to use both of them together as it doesn't cause any harm. Also, it ensures philosophy of Defense in Depth.
These days people are deploying on cloud and migrations are more often done. So,I think we cannot be sure that the configuration 2 you mentioned for httpd is in place all the time.
You should consider that enabling <secure>true</secure>
in application is mandatory. Explanation given below.
Explanation:
Scenario 1(Assuming secure flag setting missed by TLS proxy/httpd)
I tested a scenario where I have only enabled <secure>true</secure>
in the application itself and not configured secure flag via TLS proxy(httpd).
Now the Response Header has a cookie with secure flag, I observed that Firefox and Chrome process and save the cookie with secure flag.
Set-Cookie: acct=tafats; domain=localhost; Secure;expires=Thu, 16-Mar-2017 15:19:48 GMT; path=/; HttpOnly
From a Security point of view this is what is to be expected from browsers.
This protects you from session-hijacking attempts via packet sniffing.
In this case,If the attacker makes the user to click on http://example.com
, the cookie is not sent because it has a secure flag.
Here, the <secure>true</secure>
came to rescue.
Scenario 2(Assuming secure flag setting missed in the application but configured in TLS proxy/httpd)
Its good enough , as long as you have this secure flag set via TLS proxy. But the catch here is, you need to ensure that this TLS proxy setting is configured for all deployments you do all the time.
To conclude, I recommend its better to use both of them together and
ensure the philosophy of Defense in Depth.
set-cookie JSESSIONID
with the secure flag, but your browser won't create the cookie, so it won't work actually.