Can cookies set using HTTP be read using HTTPS?
Cookies set with the "Secure" keyword will only be sent by the browser when connecting by a secure means (HTTPS). Apart from that there is no distinction - if "secure" is absent, the cookie may be sent over an insecure connection.
In other words, cookies that you want to protect the contents of should use the secure keyword and you should only send them from the server to the browser when the user connects via HTTPS.
HTTP: Cookie with "Secure" will be returned only on HTTPS connections (pointless to do, see note below)
HTTPS: Cookie with "Secure" will be returned only on HTTPS connections
HTTP: Cookie without "Secure" will be returned on HTTP or HTTPS connections
HTTPS: Cookie without "Secure" will be returned on HTTP or HTTPS connections (could leak secure information)
Reference: RFC 2109
See 4.2.2 (page 4), 4.3.1
Note: It is no longer possible to set "secure" cookies over insecure (e.g. HTTP) origins on Firefox and Chrome after they implemented the Strict Secure Cookies specification.
Related
For example, does the URL http://www.google.com/ make the URL less safe, even though the default for this domain is with https?
Accessing a site using http:// (thus the unprotected unecrypted HTTP protocol) means that at least one unprotected HTTP request is sent to the server (most sites that support https will automatically redirect you to the https version).
This unprotected request can be intercepted by an attacker and thus send you arbitrary data back (malicious JavaScript code, redirect to other sites and so on).
The only exception is if you type http://www.google.com/ and you are using Chrome browser because Chrome will for addresses on google.com automatically change the entered URL to https:// before anything is sent on the network.
I have web server IIS, where I have direct access to page like (page.com), so thats the reason why I have allowed HTTP (port 80) and then I am using HTTPS (port 443).
When user enters the page on port 80 (page.com), he will be redirected to HTTPS (443). So my web server uses HSTS with long max-age parameter (defense against ssl strip).
Is my page secure with HSTS header this way? If not, what should I do?
Thanks a lot!
As always, the question is secure against what? Secure against ssl strip after the first response with HSTS (and before it expires)? Yes. Secure against ssl strip on the very first request (or the first after HSTS expired)? No. Secure against a range of different attacks? Not necessarily (dns hijack on the first request, corporate ssl inspection, rogue root cert in clients, malware... the list is endless).
Could you make it more secure? Yes, by disabling plain http altogether. Would that make sense in your scenario? Only you can tell.
Is there a posibillity to check if a remote server supports https?
Currently im requesting https, if it doesnt work retry http and then display an error if this still does not work.
Is there a feature embedded in HTTP which indicates if https is supported?
By this I dont mean redirect etc. because these must be implemented on the server and arent always.
Silently falling back to HTTP sounds dangerous. An attacker (i.e. man-in-the-middle) might be able to force you to use the insecure channel by blocking your requests to HTTPS. Thus, I would not recommend this approach in general.
In general, you should let your users decide which protocol to use. If they specify https, you should not silently downgrade but throw an error. If they specify http however, it might be possible to also try https first and silently fall back to http if that fails (since they requested http in the first place).
An a general answer to your request: you can only try https to check if the server supports https. There is an HTTP(s) extension called HTTP Strict Transport Security (HSTS) which allows servers to indicate that all requests to them should always be performed via secure channels only. If you receive such a header in a response for an HTTPS request, you can force https in the future for the host. Note though that you have to ignore such headers receive over insecure HTTP.
In general, you can't trust any information you received over plaintext HTTP to give you any indication about security options (such as support for TLS) of the server since this information could be arbitrarily spoofed by man-in-the-middle attackers. In fact, preventing such undetectable changes is one of the main reasons to use TLS / HTTPS in the first place.
I don't quite get the difference between UseHsts and UseHttpsRedirection in the configure section of the startup file in .net core. Could anyone explain?
According to the documentation you should use both together:
We recommend all production ASP.NET Core web apps call:
The HTTPS Redirection Middleware (UseHttpsRedirection) to redirect all HTTP requests to HTTPS.
UseHsts, HTTP Strict Transport Security Protocol (HSTS).
ASP.NET Core Enforce HTTPS
The .UseHttpsRedirection() will issue HTTP response codes redirecting from http to https. The .UseHsts() will add the HSTS response header which the client is supposed to obey.
UseHsts adds the Strict-Transport-Security header to the response, which informs the browser that the application must only be accessed with HTTPS.
After this declaration, compliant browsers should automatically convert any http request of the application into an HTTPS request.
UseHttpsRedirection causes an automatic redirection to HTTPS URL when an HTTP URL is received, in a way that forces a secure connection.
Once the first HTTPS secure connection is established, the strict-security header prevents future redirections that might be used to perform man-in-the-middle attacks.
I see facebook sends cookies over http. How are they secure from hijacking? If I were to copy the cookie onto another computer would I be logged in?
You've just described Session Hijacking, and it is a real security issue. It can be avoided in a number of ways. The simplest way to secure the cookies, though, is to ensure they're encrypted over the wire by using HTTPS rather than HTTP.
Cookies sent over HTTP (port 80) are not secure as the HTTP protocol is not encrypted.
Cookies sent over HTTPS (port 443) are secure as HTTPS is encrypted.
So, if Facebook sends/receives cookies via HTTP, they can be stolen and used nefariously.
Cookies sent over HTTP are unsecure, those sent over HTTPS are a bit more secure than HTTP, however they can still be stolen since there are a few methods discovered lately to hack SSL. A complete writeup on session hijacking and all of the session hijacking attacks can be found here: http://cleverlogic.net/tutorials/session-hijacking-0. There is also a bit on preventing Session Hijacking.