There were a plenty of discussions while I was researching how to make my entire site https. The most answers were to redirect http to https (.htaccess file), which is not good, because it's not good to do the same job twice (two requests). Also, the "man in the middle" first takes on http, and I want my site to go directly on https. Is there another way to make your entire site https, and how to do this? For example, when user types in example.com, that example.com automatically goes to https, without redirecting from http or anything else first?
asked Feb 3, 2014 at 15:38
-
if you don't want people to be redirected to https, what do you want to happen instead?– Michael HamptonFeb 3, 2014 at 15:40
-
@MichaelHampton Maybe I'm asking newbie question, but I want to practically "delete" http, and that only thing that exists is https. Or if this isn't possible, I could just use redirection if it is good enough for security. I heard that redirection http->https is not so good because it is still http and the traffic can be intercepted during redirection.– Marko TamburicFeb 3, 2014 at 15:44
-
HTTP 301 permanent redirect is your friend, just don't forget to set expires.– MarcelFeb 3, 2014 at 17:36
-
You can just remove http. But then, the user gets just a connection refused message, if she isn't entering the https:// For some sites this is better, because security is higher. If there is a http version available, it can happen that cookies are sent with the first request unencrypted. For things like a company mail system https only + user training is ok, for a general site you will probably lose a lot of visitors.– JosefMar 3, 2014 at 12:11
-
Afaik it became possible with HTTP2, however it still won't avoid ssl striping attack (described in the answers below).– peterhSep 20, 2018 at 17:09
Add a comment
|
5 Answers
No. You cannot magically make the visitor's browser choose the right protocol. A redirect is the way to do it.
-
1To further expand on this answer, consider using URL rewrite and a 301 status code as Mark Henderson points out here: serverfault.com/questions/570288/… Feb 3, 2014 at 16:01
-
http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security allows your server to indicate that the domain should only be accessed via HTTPS. This only applies to subsequent requests, so there'd be an initial HTTP load, but future requests would load HTTPS even if someone explicitly typed HTTP.
IE doesn't support it yet, but all the other majors do.
-
-
3
-
@JennyD What do you mean by "protect"? A MiM can't do anything against a http -> https redirect, unless they messing with the local dns/routing and faking your entire domain. In that case, it doesn't really matter what you do, since your servers are never being accessed. Feb 3, 2014 at 18:18
-
2@JennyD Well, HSTS is really a better solution than your post, which says "a redirect is the way to do it". A redirect can be MITMed at any time. A redirect with HSTS can only be MITMed once a year per user+browser (or whatever the expiration time is on the header) - all other times it's not requested.– ceejayozFeb 3, 2014 at 23:20
-
1
As others have said, you can't force users to choose the right protocol. But when the user tries to use HTTP, what should you do? A redirect is also insufficient, because an attacker sitting between you and the client can intercept the redirect, so the client never sees it. The client will continue to send plain HTTP, and the attacker will strip away the SSL layer from the server (SSL stripping attack).
The only sure way to prevent that is to not serve HTTP at all. Don't answer on port 80, except maybe to serve a plain text page directing the user to try again with HTTPS (but not providing a link, which the attacker could manipulate). This will force the user to type https:// into their browser, so they'll initiate the connection with SSL and prevent the MITM attack.
answered Feb 3, 2014 at 16:17
-
3It's a trade-off, though, as most users aren't going to type
https://. Instead, they're going to say "huh, the site's broken" and leave. Best case scenario might be havingwww.example.comrespond to both HTTP and HTTPS, but having the app itself running on something likeadmin.example.comwith only HTTPS.– ceejayozFeb 3, 2014 at 16:23 -
-
I don't really see how that would be any more MiM-proof. If the man in the middle can modify your hyperlink to point somewhere else, it means he is in control of the user's incoming packets. He can just as easily redirect to his site, or add in whatever hyperlink he wants, regardless of what the site is supposed to look like. Feb 3, 2014 at 18:26
-
But not, in theory, if the client initiates the connection with SSL. Feb 3, 2014 at 18:31
-
3that's true - but if the client initiates with SSL, OP has no problem. His issue is when they initiate without SSL, and there's no way to reliably get them to SSL if there's a MiM actively sabotaging that. Feb 3, 2014 at 18:36
ceejayoz has the best answer to prevent the specifically mentioned attack here but I want to also point out what a lot of people here are missing which is basically that HTTP has the other part figured out already. You want to do a permanent 301 redirect. This tells the client to make further requests to the new address. So yes, if someone types the wrong URL they will make 2 requests BUT, in the future, a good client is supposed to detect requests to that URL and make the correct request instead to prevent any more wasted requests. The problem is that this is only for that exact URL. HSTS improves upon this scheme by also saying, 'for the next n seconds also do not allow any non-secure connections from this domain'.
Users should not visit sensitive sites at insecure locations. They especially should not signup for them in insecure locations. These are basic user security principals which should be taught just like, 'don't open attachments from untrusted sources'. Which are really the best answer for preventing MiM attacks for sites which have never been visited.
As a side note, some browsers improve upon this by also saying certain known sites always use HSTS. Unfortunately, you can't just add yourself to this list easily.
Further reading: http://coderrr.wordpress.com/2010/12/27/canonical-redirect-pitfalls-with-http-strict-transport-security-and-some-solutions/
Not entirely true: How to use DNS/Hostnames or Other ways to resolve to a specific IP:Port
There is a way, but most browsers don't implement rfc2782.
