Application is deployed on AWS and serves on port 80 and ELB forwards that 80 to 443. Spring security is used for session which creates cookie with secure flag set. When I hit the application host name I could see that secure flag is set as shown below.
curl -I target_hostname
Set-Cookie: JSESSIONID=XXXXXXXX; Path=/; Secure; HttpOnly
But when i directly hit EC2 IP (using curl) I could see that secure flag is not set.
curl -I target_ec2_ip
Set-Cookie: JSESSIONID=XXXXXXXX; Path=/; HttpOnly
Why it is happening can anyone explain?
I'm going to assume that you terminate SSL at the ELB, and you're contacting the EC2 instance directly via HTTP (port 80). In that case, the following applies:
RFC 6265:
If the cookie's secure-only-flag is true, then the request-uri's scheme must denote a "secure" protocol (as defined bythe user agent).
NOTE: The notion of a "secure" protocol is not defined by this document. Typically, user agents consider a protocol secure if the protocol makes use of transport-layer security, such as SSL or TLS.
The MDN doc is more explicit:
Insecure sites (http:) can't set cookies with the "secure" directive anymore (new in Chrome 52+ and Firefox 52+).
Related
What happens to secure cookies on http requests. will it be lost over the request? What will happen if the cookie is a secure auth cookie?
RFC 6265 formalizes the behavior of HTTP cookies (as they work in the real world, not as they should ideally work, unlike some previous failed RFC):
Introduction
This document defines the HTTP Cookie and Set-Cookie header fields.
The description of the behavior of the "secure" flag follows:
4.1.2.5. The Secure Attribute
The Secure attribute limits the scope of the cookie to "secure"
channels (where "secure" is defined by the user agent). When a
cookie has the Secure attribute, the user agent will include the
cookie in an HTTP request only if the request is transmitted over a
secure channel (typically HTTP over Transport Layer Security (TLS)
[RFC2818]).
In practice only connections over TLS (that is, HTTP/S) are considered secure. Browsers could conceivably define direct HTTP connections to host "localhost" or an IP address that is by definition "local" (address of that IP stack), like 127.0.0.1 or ::1, or other local addresses, as secure. That would be in the spirit of the specification. (I don't know browsers that actually do so.)
can the proxy server intercept my https request and set cookies before actually sending the request?
I'm going a GET on an url from chrome browser. In the development tools, under "Network", I noticed that the first request, the one that I made, has cookies set. but I did not set any cookies.
any thoughts?
No it can't. To proxy HTTPS requests your browser issues HTTP CONNECT command (https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/CONNECT). Proxy then creates a tunnel between the browser and a target server.
A conventional proxy can neither view nor manipulate a TLS-encrypted data stream, so a CONNECT request simply asks the proxy to open a pipe between the client and server. The proxy here is just a facilitator - it blindly forwards data in both directions without knowing anything about the contents. The negotiation of the TLS connection happens over this pipe, and the subsequent flow of requests and responses are completely opaque to the proxy.
It cannot modify or see what is being transferred as it is protected by TLS encryption.
The only way to modify HTTPS conenctions on the fly is if you install some external CA certificates on your computer. This is known as MITM Attack.
I read many articles cookies are passed over HTTPS connection is encrypted.
I checked with my application, its having SSL connection, but i can read cookie information from request headers. Is anything done for cookie encryption in HTTPS connection?
HTTPS encrypts the entire session, headers included.
But notice that SSL (TLS in fact) works over the Transport Layer. If you are reading the cookies from the Application Layer (for example using javascript or a java servlet to get the HTTP request) the content will be already unencrypted.
See Does SSL also encrypt cookies?
I'm using ELB in front of HA-Proxy. Stickiness is disable on ELB and I have this configuration in HA-Proxy:
backend endpoint
balance leastconn
cookie VALUE insert nocache maxidle 30
I'm using curl to query and I noticed that if I query directly HA-Proxy I get a cookie for each query. However with ELB, I would get a cookie at the first query but not with the next ones, I have to wait few minutes before it give me a cookie.
Any idea why?
HA-Proxy version 1.4.18 2011/09/16
Turned out that I needed to ask HA-Proxy to close the connection as soon as possible using option http-server-close or option forceclose.
More information about ELB keepalive can be found here
ELB's HTTP listeners present an HTTP 1.1 endpoint to clients, which means that:
HTTP Keepalive will be enabled by default for an HTTP 1.1 client
HTTP Keepalive will be disabled by default for an HTTP 1.0 client
In either case, the client can explicitly turn keepalive on or off by including the "Connection: keep-alive" or "Connection: close" headers, respectively, in the request.
Source: https://forums.aws.amazon.com/thread.jspa?messageID=200999𱄧
I understand, we use SSL to encrypt sensitive data like user name and password to transported to server without people in the network eavesdropping. So then server returns a secure token over HTTPS and its stored in cookie. We switch to HTTP after we have secure token, we attach cookie/secure token header to every HTTP request.
Now anybody can see my secure token and they can eavesdrop it and impersonate me. Is my understanding correct?
The cookies can be set per protocol, so that HTTPS cookies are not used for HTTP and vice versa. Also, the properly constructed secure token should include an IP address and have short expiration time.
But in general the best idea is of course to keep the authenticated session in secure channel - SSL is not that heavyweight these days (as computers became much faster than when SSL was first introduced) and also the heaviest part is handshake, which is performed only once if persistent HTTP connection is used (or when SSL session resuming is used).