When using a HTTPS connection are browser cookies and HTTP headers visible as plain text? That is, is only the body of the HTTP content encrypted?
Both the request and response are fully encrypted – so the cookies and all headers are protected. About the only thing visible to an external sniffer is the host and remote address (IP) that you're requesting.
All https is http over an encrypted connection i.e. the contents of the TCP/IP packets are encrypted.
Related
I'm using gssapi/Kerberos authentication in my web application, and I want single sign on via the browser.
The problem is, Firefox sends an initial request to the server with no authentication, and receives a 401. But it includes a keep-alive header:
Connection: keep-alive
If the server respects this keep-alive request, and returns a WWW-Authenticate header, then Firefox behaves correctly and sends the local user's Kerberos credentials, and all is well.
But, if the server doesn't keep the connection alive, Firefox will not send another request with the credentials, even though the response has the WWW-Authenticate header.
This is a problem because I'm using Django, and Django doesn't support the keep-alive protocol.
Is there a way to make Firefox negotiate without the keep-alive? In the RFC that defines the Negotiate extension, there's nothing about requiring that the same connection be re-used.
Alternatively, is there a way to make Firefofx preemptively send the credentials on the first request? This is explicitly allowed in the RFC.
That header is HTTP 1.0, wake up, fast-forward 15 years and your problems will go away. Firefox works very well with SPNEGO.
As far as I know, HTTPS requests are regular HTTP requests encrypted with the public key provided by the server during the initial handshake.
I have been reading about HSTS but have not been able to find anything related to the public key of sites that are in preloaded HSTS lists. Are the public keys of these sites also preloaded? Or is this key sent by the server on initial handshake like in any HTTPS request?
is this key sent by the server on initial handshake like in any HTTPS request?
Yes. HSTS just says “always use HTTPS for this domain so automatically correct any http:// calls to https:// before it is sent”.
It says nothing about how that HTTPS connection is set up, which is done through the usual manner.
My questions is simple, but I cannot find an answer and I haven't got any resources to test it myself.
Can I make HTTPS CORS request from one domain to another HTTPS domain?
Can I make HTTP CORS request from one domain to another HTTPS domain?
I know that I can do HTTP CORS request from one domain to another HTTP domain, but I don't know if there is any difference when I use HTTPS.
Yes you can do a CORS request from a HTTPS domain to another HTTPS domain.
The only difference is because HTTPS is a secure origin, you can only make call to secure origin, so not to HTTP, the browser will block it with a message like:
Mixed Content: The page at 'https://example.com/index.html' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://example2.com/endpoint'. This request has been blocked; the content must be served over HTTPS.
Warning: If you allow http requests to call your https webpage, it will be insecure because it means an attacker can force requests to your https webpage with the cookies of a victim and read the answer
Beware if you still need to support IE8/IE9 and are using XDomainRequest as it does not support cross-protocol requests. As per MDN:
The origin's security protocol must match that of the requested URL. (http to http, https to https). If these do not match, the request will error "Access is Denied".
How can I make sure only a script hosted on a specific list of domains is allowed to connect to my WebSocket application?
Or to prevent opinion based closevotes, is there a state-of-the-art or native way?
I do not intend to implement user authentication.
The mechanism for this with WebSocket is the origin header.
This HTTP header is set by browsers to the domain of the host that served the HTML that contained the JavaScript which opened the WebSocket connection.
A WebSocket server can inspect the origin header during the initial opening handshake of the WebSocket protocol. The server can then only allow proceeding of the connection if the origin matches a known whitelist.
The header cannot be modified from JavaScript, and all browsers are required by the RFC6455 specification to include it.
Caution: a non-browser WebSocket client can of course fake the origin header to any value it likes.
#oberstet gave you the right answer.
If you are worried about bots or programmatic HTTP agents, then you are going to have a bad time. Everything in a HTTP request can be spoofed. Your only option is to use cookies to attach a token with limited time validity that certify the user went through an allowed website to get that script. Get that cookie in the WebSocket handshake and decide if you allow it or not.
E.g.: When a user visit your site, or one of your sites, return a cookie with a symmetrically encrypted token based on the user IP address, User-Agent header, and Origin header; when the user initiates a WebSocket connection, if it is in the same 2nd domain, it will send the cookie, then if the data adds up allow the connection, otherwise, reject it. If the WS is in another domain, then you will have to forget about cookies and rely on a web socket message once the connection is established to check the validity of the connection.
When someone arrives on my site, I want to check whether they came from Gmail, Outlook.com or Hotmail.com.
I installed Fiddler, but I can't find a the referrer hostname anywhere when I come from Gmail.
Is a referrer hostname even passed for these mail clients?
Browsers don't pass the URL in the Referer field if it is an https:// URL, because it might contain private information. From RFC 2616 section 15.1.3:
Clients SHOULD NOT include a Referer header field in a (non-secure)
HTTP request if the referring page was transferred with a secure
protocol.
I found that if both the host and the linked to url are over the same protocols it does pass the HTTP_REFERER.
Outlook.com passes http_referer even if the link is non-secure (http). Looks like they just pass "https://outlook.live.com/" as the referer for all requests, which is great. I wish all the major providers would do this.