If I request our website using HTTP http://example.com, the reponse is 301 Moved Permanently with the Location header set to https://example.com - which, of course, is insecure due to MIM attack.
Is there not a way to just repond to the browser something along "make the same request again but this time over HTTPS" insted of explicitly telling the browser the URL?
I was expecting to find this kind of solution on Troy Hunt's blog post but the only suggestion there is to use HSTS preload (ie. register our site with Google) which we do not want to do.
HTTP Strict-Transport-Security (HSTS) allows you to send a HTTP Header to say “next time you use this domain - make sure it’s over HTTPS even if the user types http:// or uses a link beginning http://“.
In Apache it is set with the following config:
Header always set Strict-Transport-Security "max-age=60;"
This sends the message telling the browser to remember this header for 60 seconds. You should increase this as you confirm there are no issues. A setting of 63072000 (2 years) is often recommended.
So this is more secure than a redirect as it happens automatically without needing an insecure HTTP request to be sent which could be intercepted, read and even changed on an insecure network.
For example let’s imagine you have logged on to your internet banking previously on your home WiFi, the browser has remembered the HSTS setting and then you visit your local coffee shop. Here you try to connect to the free WiFi but actually connect to a hackers WiFi instead. If you go to your internet banking with a HTTP link, bookmark or by typing the URL, then HSTS will kick in and you will go over HTTPS straight away and the hacker cannot unencrypt your traffic (within reason).
So. All is good. You can also add the includeSubDomains attribute:
Header always set Strict-Transport-Security "max-age= 63072000; includeSubDomains"
Which adds extra security.
The one flaw with HSTS is it requires that initial connection to load this HTTP header and protect you in future. It also times out after the max-age time. That’s where preload comes in. You can submit your domain to the browsers and they will load this domain’s HSTS setting into the browser code and make this permanent so even that first connection is secure.
However I really don’t like preload to be honest. I just find the fact it’s out of your control dangerous. So if you discover some domain is not using HTTPS (e.g. http://blog.example.com or http://intranet.example.com or http://dev.example.com) then as soon as the preload comes into affect - BANG you’ve forced yourself to upgrade these and quickly as they are inaccessible until then. Reversing from browser takes months at least and few can live with that downtime. Of course you should test this, but that requires going to https://example.com (instead of https://www.example.com) and using includeSubDomains to fully replicate what preload will do and not everyone does that. There are many, many examples of sites getting this wrong.
You’ve also got to ask what you are protecting against and what risks you are exposing yourself to? With a http:// link a hacker intercepting could get access to cookies (which the site can protect against by using the secure attribute on cookies) and possibly intercept the traffic by keeping you on http:// instead of upgrading to https:// (which is mostly mitigated with HSTS and is increasingly flagged by the browser anyway). Remember that even on an attackers WiFi network the green padlock means the connection is secure (within reasonable limitations). So as long as you look for this (and your users do, which is more difficult I admit) the risks are reasonably small. This is why the move to HTTPS everywhere and then HTTPS by default is so important. So for most sites I think HSTS without preload is sufficient, and leaves the control with you the site owner.
Related
I've taken over a site that previously used HSTS, but because of some iframes I need to embed, I need to disable it. I'm able to intelligently redirect from one protocol to the other, but Safari, in particular, doesn't want to disregard its HSTS cache.
In this question (Is it possible to ask your users to clear their HTTP Strict Transport Security (HSTS) for your site?) and on other sites, I've seen that I can request browsers to remove my site from their HSTS cache by sending the following header:
Strict-Transport-Security: max-age=0
However, Safari doesn't seem to care about that. On a coworker's computer, which has the site in its HSTS cache, receiving that header is not preventing it from automatically redirecting to https.
Anyone know a way to tell Safari to disregard HSTS?
It could be set on the top level domain.
So if you are looking at www.example.com then maybe the policy has been published from example.com with includeSubDomains option so it affects all subdomains (including www subdomain).
If so the answer is similar. Publish this header from the base domain and make sure you visit the base domain (even if it just redirects to main domain).
Strict-Transport-Security: max-age=0; includeSubDomains
Also check the preload lists for the base domain.
Would also be worth looking through web config and any scripts or dynamic parts of the website (e.g. PHP, Java Servlets... Etc.) to make sure something is not still setting this when you visit a certain page for example.
Anytime a user tries to access our site with http, they are redirected to https via this code in the Application.cfc:
If (CGI.HTTPS != "on") {
location(url="https://#Application.PortalApp.GetDomain()##CGI.SCRIPT_NAME#?#CGI.QUERY_STRING#", addtoken="false");
}
The strange thing is, if they have never accessed the site via http, but happen to click an internal link that points to http instead of https, they are logged out. However, once they login again, they can then access an http link, get redirected to https and stay logged into the system.
I did some line-by-line debugging and the https session gets overwritten when a user access http. But once a user accesses http, the https shares the sessionid.
Is this correct behavior?
In ColdFusion Administrator Session settings, HTTPOnly is set to true, and secure cookie is set to false.
Think of them as two completely separate domains.
The session under HTTPS is a completely different session from the one under HTTP. That's just how that works.
Instead of controlling it at the application code level, you should configure your web server to only allow connections over HTTPS and automatically redirect HTTP requests to HTTPS.
Here's a link for IIS.
Here's a link for Apache.
More info can be found in this Google Developer page, but I'll paste the highlights.
HTTPS protects the integrity of your website
HTTPS helps prevent intruders from tampering with the communications between your websites and your users’ browsers. Intruders include intentionally malicious attackers, and legitimate but intrusive companies, such as ISPs or hotels that inject ads into pages.
HTTPS protects the privacy and security of your users
HTTPS prevents intruders from being able to passively listen in on the communications between your websites and your users.
You'll want to make sure that internal links on your site are never explicitly using HTTPS, so look into setting <base href="https://{yourDomain}" > in your layout files to force all relative URLs to use HTTPS.
I've been having the same problem and this fixed it.
On Server2008, in IIS Manager, open up the ASP properties, expand "session properties", and change "New ID On Secure Connection" to "false".
A couple suggestions:
Easy one first: this may not be the right direction, but what happens if, instead of using CGI.HTTPS, you use CGI.SERVER_PORT_SECURE?
If CF is overwriting the session when you switch from https to http, why not just handle this on the front end with the web server rather than through CF? IIS and Apache all have easy rewrites or redirects that may save you some time over trying to deal with CF, particularly if your whole application is secure anyway.
It seems that the check for user being logged in is before the http to https check and redirect. If possible you should check for https first (redirect if is http) then check for logged in.
I read if the request is authenticated or secure, it won't be cached. We previously worked on our cache and now planning to purchase a SSL certificate.
If caching cannot be done with SSL connection then is that mean our work on caching is useless?
Reference: http://www.mnot.net/cache_docs/
Your reference is wrong. Content sent over https will be cached in modern browsers, but they obviously cannot be cached in intermediate proxies. See http://arstechnica.com/business/2011/03/https-is-great-here-is-why-everyone-needs-to-use-it-so-ars-can-too/ or https://blog.httpwatch.com/2011/01/28/top-7-myths-about-https/ for example.
You can use the Cache-Control: public header to allow a representation served over HTTPS to be cached.
While the document you refer to says "If the request is authenticated or secure (i.e., HTTPS), it won’t be cached.", it's within a paragraph starting with "Generally speaking, these are the most common rules that are followed [...]".
The same document goes into more details after this:
Useful Cache-Control response headers include:
public — marks authenticated responses as cacheable; normally, if HTTP authentication is required, responses are automatically private.
(What applies to HTTP with authentication also applies to HTTPS.)
Obviously, documents that actually contain sensitive information only aimed for the authenticated user should not be served with this header, since they really shouldn't be cached. However, using this header for items that are suitable for caching (e.g. common images and scripts) should improve the performance of your website (as expected for caching over plain HTTP).
What will never happen with HTTPS is the caching of resources by intermediate proxy servers (between the client and your web-server, at least the external part, if you have a load-balancer or similar). Some CDNs will serve content over HTTPS (assuming it's suitable for your system to trust these CDNs). In general, these proxy servers wouldn't fall under the control of your cache design anyway.
If I want a client to always use a HTTPs connection, do I only need to include the headers in the code of the application or do I also need to make a change on the server? Also how is this different to simply redirecting a user to a HTTPs page make every single time they attempt to use HTTP?
If you just have HTTP -> HTTPS redirects a client might still try to post sensitive data to you (or GET a URL that has sensitive data in it) - this would leave it exposed publicly. If it knew your site was HSTS then it would not even try to hit it via HTTP and so that exposure is eliminated. It's a pretty small win IMO - the bigger risks are the vast # of root CAs that everyone trusts blindly thanks to policies at Microsoft, Mozilla, Opera, and Google.
I have a HTTP page with a form. If I set the action to a HTTPS page, is the request secure? Does the browser process all the data before it sends it to the net? Or should I use HTTPS for my entire site?
Yes, it'll be secure if the location your form is posting to is HTTPS.
Users, however, may freak out that there's no lock icon in their browser on the page with the form. You may be better off from a usability standpoint having both pages be HTTPS.
No. Troy Hunt identifies a simple man-in-the-middle attack that shows that posting from HTTP to HTTPS is by no means secure. With the proliferation of free WiFi this attack would be very simple to execute.
http://www.troyhunt.com/2013/05/your-login-form-posts-to-https-but-you.html
Yes. As long as the request that needs to be secure is https, you're good.
That being said, many key sites, including gmail, have stopped bothering carving off small sections of their site to be https and just made their whole site https. It's easier and safer, and you lose little in the way of performance.
Dont do it!
Consider a MITM attack where an attacker sitting on the wire somewhere between the server and client modifies the login form before it reaches the client. The login form now includes a keylogger or points the POST action to a phishing page instead of the authentic server. There is no warning or UI cue for the end-user, so they go ahead and submit the form.
Consider a MITM attack that involves the attacker deploying a "free Wifi" at a coffee shop (via a smartphone hotspot or whatever). When unsuspecting people use this "free Wifi" to login with an HTTP form, even though it does a POST to HTTPS, the attacker can see the user's plaintext credentials by analyzing their hotspot network traffic.
References:
TLS and SSL in the real world
SSL Strip
Your login form posts to HTTPS, but you blew it when you loaded it over HTTP
Is it secure to submit from a HTTP form to HTTPS?
The actual data transfer from your form to the server is encrypted when posting over HTTPS. If that is what you mean by secure, then yes, it is secure.
I think what you are getting at in your question is, what about client-side stuff reading the form prior to post. That is certainly possible, HTTPS or not.
On another note though, you should probably use HTTPS for the actual form. Some browsers warn users as their posts are redirected over the HTTP/HTTPS boundary. Plus, I don't think your users will be happy filling out a form where there is no secure icon showing.
If you set action to HTTPS this will indeed be secure. Before anything can happen over HTTPS a handshake has to occur, and the browser sending the data will have to do this when the action occurs.