Cookies with secure flag can not be accessed when the SSL channel is not secure.
What about cookies without the secure flag? Are they sent to server when the certificate doesn't match the domain?
Thank you for your responses.
Yes, they are, which is consistent with RFC 6265 (A. Barth, HTTP State Management Mechanism)
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.)
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 setting these cookies for a single sign on solution where I have one app running at foo.example.com and a different app running at bar.example.com.
I know that I can set a cookie from foo.example.com for .example.com.
If I had control over bar.example.com I'd just have it recognize a cookie from .example.com. But I have very little control of it.
For what it's worth, the app at foo.example.com is in python and the app at bar.example.com is java.
You can certianly try. However, browsers should not honor this behavior as it is a cross-site cooking attack.
This is not possible. SSO is done using protocols such as OAuth or SAML that imply sending signed messages between the endpoints and/or communication between them. There is no way to do this on the "client side".
I'm attempting to write a simple HTTP/HTTPS proxy using Boost ASIO. HTTP is working fine, but I'm having some issues with HTTPS. For the record this is a local proxy. Anyway so here is an example of how a transaction works with my setup.
Browser asks for Google.com
I lie to the browser and tell it to go to 127.0.0.1:443
Browser socket connects to my local server on 443I attempt to read the headers so I can do a real host lookup and open a second upstream socket so I can simply forward out the requests.
This is where things fail immediately. When I try to print out the headers of the incoming socket, it appears that they are already encrypted by the browser making the request. I thought at first that perhaps the jumbled console output was just that the headers were compressed, but after some thorough testing this is not the case.
So I'm wondering if anyone can point me in the right direction, perhaps to some reading material where I can better understand what is happening here. Why are the headers immediately encrypted before the connection to the "server" (my proxy) even completes and has a chance to communicate with the client? Is it a temp key? Do I need to ignore the initial headers and send some command back telling the client what temporary key to use or not to compress/encrypt at all? Thanks so much in advance for any help, I've been stuck on this for a while.
HTTPS passes all HTTP traffic, headers and all, over a secure SSL connection. This is by design to prevent exactly what you're trying to do which is essentially a man-in-the-middle attack. In order to succeed, you'll have to come up with a way to defeat SSL security.
One way to do this is to provide an SSL certificate that the browser will accept. There are a couple common reasons the browser complains about a certificate: (1) the certificate is not signed by an authority that the browser trusts and (2) the certificate common name (CN) does not match the URL host.
As long as you control the browser environment then (1) is easily fixed by creating your own certificate authority (CA) and installing its certificate as trusted in your operating system and/or browser. Then in your proxy you supply a certificate signed by your CA. You're basically telling the browser that it's okay to trust certificates that your proxy provides.
(2) will be more difficult because you have to supply the certificate with the correct CN before you can read the HTTP headers to determine the host the browser was trying to reach. Furthermore, unless you already know the hosts that might be requested you will have to generate (and sign) a matching certificate dynamically. Perhaps you could use a pool of IP addresses for your proxy and coordinate with your spoofing DNS service so that you know which certificate should be presented on which connection.
Generally HTTPS proxies are not a good idea. I would discourage it because you'll really be working against the grain of browser security.
I liked this book as a SSL/TLS reference. You can use a tool like OpenSSL to create and sign your own certificates.
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).