Is it bad to redirect http to https?

Question

Im try to execute this example from VTK, and to do that I most install ffmpeg from this url and all is good, but when I try to build project I get this error:

/Downloads/VTK-8.2.0/CMake/vtkModuleAPI.cmake:140 (message):
Requested modules not available:

vtkIOFFMPEG

I do all step in ffmpeg zipped file which I installed it from VTK download url, and if press ccmake on VTK-build directory I can see these option is enabled

VTK_FFMPEG_INCLUDE_DIR /tmp/ffmpeg_inst/include
VTK_FFMPEG_avcodec_LIBRARY /tmp/ffmpeg_inst/lib/libavcodec.so
VTK_FFMPEG_avformat_LIBRARY /tmp/ffmpeg_inst/lib/libavformat.so
VTK_FFMPEG_avutil_LIBRARY /tmp/ffmpeg_inst/lib/libavutil.so VTK_USE_FFMPEG_ENCODER ON

and all files/directory is found and located under /tmp/ffmpeg_inst, Also I run make -j4 after VTK_USE_FFMPEG_ENCODER is set on.

Why vtkIOFFMPEG module not found now? is there any mistake in configuration or is there any specific configuration for FFMPEG example before build? thanks.

Additional Note:

1. VTK version: 8.2.0
2. cmake version 3.13.2

Solution 1

The [R] flag on its own is a 302 redirection (Moved Temporarily). If you really want people using the HTTPS version of your site (hint: you do), then you should be using [R=301] for a permanent redirect:

RewriteEngine on
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R=301,L] 

A 301 keeps all your google-fu and hard-earned pageranks intact. Make sure mod_rewrite is enabled:

a2enmod rewrite

To answer your exact question:

Is it bad to redirect http to https?

Hell no. It's very good.

Solution 2

Whilst I support the idea of SSL only sites, I would say one drawback is overheads depending on your site design. I mean for example if you are serving lots of individual images in img tags, this could cause your site to run a lot slower. I would advise anyone using SSL only servers to make sure they work on the following.

1. Check the entire site for internal links and ensure they are all using HTTPS if you specific your own domain name in links, so you are not causing your own redirects.
2. Update your <meta property="og:url" to using the https version of your domain.
3. If you use <base href= again update to use HTTPS.
4. Install SPDY protocol if possible
5. Make sure to use CSS Image sprites where possible, to reduce numbers of request.
6. Update your sitemaps to indicate https status, so spiders over time learn this change.
7. Change Search Engine preferences like Google Webmaster Tools to prefer HTTPS
8. Where possible off-load any stactic media to HTTPS CDN servers.

If the above is addressed, then I doubt you will have many issues.

Solution 3

I you've set up https then you should use it everywhere on the site. You will avoid the risk of mixed content issues and if you have the required tools in place, why not make the entire site secure?

Regarding redirection from http to https the answer is not that simple.

Redirecting will make it a lot easier for your users, they just type in whateversite.com and gets redirected to https.

But. What if the user is sometimes on an unsecure network (or is close to Troy Hunt and his Pineapple)? Then the user will request http://whateversite.com out of old habit. That is http. That can be compromised. The redirect could point to https://whateversite.com.some.infrastructure.long.strange.url.hacker.org. To an ordinary user it would look quite legit. But the traffic can be intercepted.

So we have two competing requirements here: To be user friendly and be secure. Fortunately, there is a remedy called the HSTS header. With it you can enable the redirect. The browser will move over to the secure site, but thanks to the HSTS header also remember it. When the user types in whateversite.com sitting on that unsecure network, the browser will go to https right away, without jumping through the redirect over http. Unless you deal with very sensitive data, I think that's a fair tradeoff between security and usability for most sites. (When I recently set up an application handling medical records I went all https without a redirect). Unfortunately Internet Explorer has no support for HSTS (source), so if your target audience is mostly using IE and the data is sensitive you might want to disable redirects.

So if you're not targetting IE users, go ahead and use redirect, but enable the HSTS header as well.

Solution 4

There's nothing wrong with this, and in fact it's best practice (for sites that should be served over a secure connection). In fact, what you're doing is pretty similar to the configuration I'm using:

<VirtualHost 10.2.3.40:80>
  ServerAdmin [email protected]
  ServerName secure.example.com
  RedirectMatch 301 (.*) https://secure.example.com$1
</VirtualHost>

# Insert 10.2.3.40:443 virtual host here :)

The 301 status code indicates a permanent redirect, instructing capable clients to use the secure URL for future connections (e.g. update the bookmark).

If you'll only be serving the site over TLS/SSL, I'd recommend a further directive to enable HTTP Strict Transport Security (HSTS) in your secure virtual host:

<IfModule mod_headers.c>
  Header set Strict-Transport-Security "max-age=1234; includeSubdomains"
</IfModule>

This header instructs capable clients (most of them these days, I believe) that they should only use HTTPS with the provided domain (secure.example.com, in this case) for the next 1234 seconds. The ; includeSubdomains portion is optional and indicates that the directive applies not just to the current domain, but any under it (e.g. alpha.secure.example.com). Note that the HSTS header is only accepted by browsers when served over an SSL/TLS connection!

To test your server configuration against current best practice, a good free resource is Qualys' SSL Server Test service; I'd be aiming to score at least an A- (you can't get more than that with Apache 2.2 due to the lack of support for elliptic curve cryptography).

Solution 5

Is it bad to redirect http to https?

No, not at all. Actually, it is a good thing to do!

On redirects:

It could be more efficient, by completely eliminating the rewrites. Here's my config on a similar situation...

<VirtualHost *:80>
  ServerName domainname.com

  <IfModule mod_alias.c>
    Redirect permanent / https://domainname.com/
  </IfModule>
</VirtualHost>

View more solutions

Comments

[Peter J.]

[WTF - I can't add answer (though seems I have enough rep).] My answer would (in part) be that SOMETIMES IT IS BAD. Consider passing a COOKIE or API Key in a GET over HTTP. If your site redirects HTTP requests to HTTPS requests, these calls would work, but the COOKIE or API Key would be transmitted in the clear - exposed. Some APIs turn HTTP off, a more robust approach - no HTTP at all so you can't even get it working unless you use HTTPS. Example: "All API requests must be made over HTTPS. Calls made over plain HTTP will fail" from stripe.com/docs/api?lang=php#authentication

[MrGigu]

@codingoutloud - the alternative is that the whole thing happens over HTTP with no HTTPS at all. How is that any better?

[PsychoData]

I've seen sites that put up a site over http saying this site must be accessed over SSL and provide a linky with the https:// part

[Ben Crowell]

Google started doing this last year. This seems to have led to the following problem on the wifi network at the college where I work. You pop up a browser and type google.com in the URL bar. It redirects you to a login page where you're supposed to provide your credentials for using the wifi network. But this then leads to an error, apparently because the redirect is detected as some kind of attempt to subvert the ssl connection. I don't claim to understand the full technical analysis of this situation, but it is a real-world problem that has occurred because of redirecting http to https.

[Braiam]

@codingoutloud if you don't have more than 10 reputation in Server Fault you can't answer protected questions.

[Jeffrey Hantin]

@BenCrowell, that's because a captive portal looks an awful lot like an sslstrip-style redirect attack (they're both man-in-the-middle request hijacks) so HSTS-aware browsers will block them both.

[Basic]

be aware that using https means everything you include should also be https or it might not load - eg load jquery using src="://example.com/jquery.js" - note the lack of http or https so the browser loads the appropriate one. I had a nightmare trying to get some embedded Amazon stuff to load properly as the API (loaded via https) produced http links - meaning they didn't work properly until I found the undocumented parameter to toggle https links

[MrGigu]

Jason; your update should be a new question, probably on Webmasters as it's unrelated (technically) to your original question. But it's probably that your style sheets are coming from an insecure domain.

[David Hoelzer]

This is an added comment on an old thread, but there's some misinformation here. If you follow the best practice of marking sensitive cookies (API keys, etc.) as SECURE, the browser will not send them to the server unless the request is made over SSL. This makes the first comment misleading and incorrect. If you have properly marked the cookie as SECURE when it is set (and, obviously, set it while in an SSL channel) then redirecting HTTP to HTTPS is perfectly safe.

[JasonDavis]

Thanks for the information, my boss is telling me the reason he only runs https on certain pages of his site, is that it uses a lot more server resources to run it on every page. Do you know anything about that or if that's true?

[Joe]

Mark, doesn't the comments on the article that you linked to agree that you do lose something in the redirect - just not more than in a normal link (ie, if your page had a 'forward' link)?

[Michael Hampton]

@jasondavis Only if you don't spend a few minutes to optimize it.

[Andy]

@jasondavis The overhead of encryption is unlikely to make much of a difference, especially now that the SSL negotiation is usually cached for a time. The advantage of encryption is that you're not letting the world see your data, passwords, etc.

[Adam Davis]

"it uses a lot more server resources to run it on every page." Modern CPUs have encryption acceleration features that make SSL nearly free. Don't worry about overhead.

[Bhavi]

I should add, sending the header Strict-Transport-Security: max-age=0 will negate any previous directive; as always, this must be sent over HTTPS to be accepted, but it's a handy way of cancelling things if you decide you also need to use HTTP on the domain.

[Icebreaker]

@AdamDavis The crypto algorithm may be lightweight, but the handshake overhead still exists. Also, HTTPS prevents HTTP proxies from caching your content. In most cases, the overhead of HTTPS is minimal and worthwhile, but be careful about over-generalizing.

[MauganRa]

Using "//yourserver.com/some-uri" instead of "yourserver.com/some-uri" resolves issue (1) because the browser will pick the appropriate schema (http or https) depending on the schema the page was loaded with.

[Mołot]

@MauganRa Unless, of course, it's a link from http article page to https login page, for example.

[Jon Hanna]

It kills shared caching, which is useful for some site's usage patterns, and often protects little (is it important that people can know you visited the site, but not the details of what you did? That's the only situation where SSL is useful). The main advantage of SSL on every resource isn't that you need to "secure" e.g. people looking at "about us", but that you can't slip up and fail to use it in a case where you should.

[major-mann]

Upvote for the last line.. well said

[Gilles 'SO- stop being evil']

Entropy doesn't get used up (at least if you're defending against Earth-based attackers rather than doing voodoo). Either you start with insufficient entropy, and you can't do anything that requires randomness, or you start with sufficient entropy, and you keep having sufficient entropy no matter how much randomness you generate.

[Velox]

More people need to pay attention to this as well. Another thing is that people assume they are secure because the end point is HTTPS, ignoring the fact that all the information sent to the page in GETs or POSTs is in plain text.

[atk]

From a security perspective, it's actually a bad practice. There are tools like sslstrip that are specifically designed to take advantage of servers that create an http connection and redirect the victim to the malicious server, while the malicious server plays MitM with the victim and the real server. In this case, it doesn't matter if the malicious redirect is http or https because if it's https, it's a valid, secure connection to the malicious server, who creates their own valid, secure connection to the real server.

[Stephan Kulla]

A question about the 8th point: One reason to use HTTPS only Servers is to protect the visitor's privacy. So I have to use a CDN which also respect it, right? For example, if I decide to use a HTTPS only server, I should not use Google hosted libraries. Do you think this reasoning is right?

[Ada]

@tampis I don't see it as a privacy issue - Google Hosted Libraries or other public CDNs improve speed and caching, and they aren't provided any data about the site you are visiting (if your site includes jQuery from, for example, Google's CDN, google don't see the URL). Further, the use of jQuery itself or other libraries is not a privacy risk as they aren't incriminating in any way, users do not choose them and have no awareness of them, and the resources tend to be extremely common and provide a large number of use cases, so cannot be tied to specific functionality either.

[Stephan Kulla]

Google sees the URL someone is visiting via the Referer header. For example this site uses jQuery from Google's CDN and my browser sends a request to Google every time I reload the site. Thereby a Referer header is also send to Google which is set to the URL of this site. So Google can track the sites I visit during the time my IP address does not change (and if I use a Google service during this time, Google can also connect this information with my Google account).

[Peter J.]

@Velox - I don't think the implication of "people assume they are secure because the end point is HTTPS, ignoring the fact that all the information sent to the page in GETs or POSTs is in plain text" is quite accurate. While there are some gotchas, GET query params don't travel in the clear during transport over HTTPS. See for example: stackoverflow.com/questions/323200/… POST payloads are also protected, while also not vulnerable to logging and referrer headers.

[Velox]

@codingoutloud That's my point. Over HTTPS they are encrypted, but in the initial request to the HTTP page they were not.

[Nick T]

If you really want people to use HTTPS, shouldn't you also set an HSTS header?

[Brilliand]

@atk - Actually, SSLStrip is defeated by an existing bookmark that goes to an HTTPS page in the first place. It works by intercepting an HTTP connection first, and preventing it from ever going to HTTPS. A connection that starts out as HTTPS can only be defeated by a corrupt CA.

[Brilliand]

@Velox - If the whole site is redirecting to HTTPS, then it's unlikely that any GET parameters will get sent before HTTPS has kicked in (and everything will stay HTTPS after that point). There's still the one initial request where cookies will be sent, which can be remedied with HSTS... and a small attack window for SSLStrip, which could possibly be defeated by JavaScript, but that's an arms race of its own.

[atk]

@Brilliand, you are correct about that, but that wasn't my point ;-). The original question is if it is ok to redirect from http to https, which is exactly what sslstrip was designed to exploit.

[Code Maverick]

+1 for the Hell no. It's very good. That was my immediate thought when I read the question title.

[JasonDavis]

I installed the Apache module for SPDY, it caused complete chaos on my server though as you have to disable mod_php anbd instead use fcgid I think it's called...anyways trying to use that handler for PHP was a no go for my site as it broke all my virtualhosts files

[JasonDavis]

For 1) I just did a search and replace in my MySQL database http to https...i'm using WordPress so it made it real easy to update hundreds of links

[ithisa]

@JonHanna : SSL has a huge advantage: it prevents selective blocking by places like China. Plaintext is routinely sniffed and your connection is automatically cut off when sensitive keywords go over the wire. With HTTPS, China needs to manually block the whole site, which they would generally be reluctant to do (collateral damage to the vast majority of non-sensitive things on your site). I would say things like news sites may find this useful.

[Jon Hanna]

@user54609 one doesn't need to force SSL for that scenario, though.

[Jon Hanna]

@user54609 and the case you give is in the set of cases where I said SSL is useful.

[ithisa]

I would say, as a person who have many personal and tiny websites getting autoblocked by the GFW (my friends and I are all in China but I host everything overseas (way cheaper, censorship cannot delete your stuff permanently)), that set of cases is close to "all websites".

[Michael Hampton]

@200_success HTTPS isn't the real problem there, it's not using proper Cache-Control headers. HTTPS is fully cacheable when the appropriate headers are present; if they're absent it's assumed that the page is not cacheable.

[millimoose]

@jasondavis For absolute links to your own site, you could also use the protocol-relative :// prefix. (I.e. without the leading http or https.) Just in case you ever decide to change this back, or someone invents a new web protocol with a different scheme ;)

[ithisa]

@MichaelHampton I think he is referring to Squid intercepting caches at the ISP which saves bandwidth by intercepting HTTP entities and forcing a shared cache on its customers. I don't think those are popular outside of Australia (latency) or Chinese schools (more rigid censorship) though.

[Michael Hampton]

@user54609 He didn't mention an intercepting cache...

[Craig Tullis]

The issue with HTTPS performance is that establishing a new connection is more expensive because there are more round-trips involved and because asymmetrical encryption/decryption is a lot more expensive than symmetrical encryption/decryption. Once the connection handshake establishes a shared symmetrical encryption key, the ongoing overhead is virtually irrelevant (very small). If you read up on SPDY, you'll see that the goal of all the fancy stuff it does is essentially to serve all the content from a URL over a single connection, mitigating the connection handshake overhead.

[MadHatter]

Sorry, what? There are a number of operations on Linux that insist on hardware-derived strong entropy rather than PRNG-based probably-good-enough entropy, and those can indeed block if the pool depth is low. It is most certainly possible to start with sufficient entropy on a Linux system, but by overuse to drain the pool, causing some operations to block.

[joshperry]

Thank you for bringing up the security implications, of which there are many to be aware.

[Håkan Lindqvist]

The thing you can do to actually address sslstrip is to use HSTS (preferrably get your HSTS settings preloaded). Whether you accept requests over plain HTTP or not doesn't actually matter in this regard, a MITM can answer over plain HTTP (possibly proxying to your HTTPS site) even if you only accept HTTPS requests.

[Håkan Lindqvist]

Getting your HSTS settings preloaded is a further step that can be taken to address the issue of the very first request from a client possibly happening over HTTP.

[Håkan Lindqvist]

A problem with solutions like having a plain HTTP landing page, even if properly separated, is that this page is left open to manipulation. Ie, there's no actual guarantee that the link for the HTTPS version of the site is delivered intact to visitors.

[Craig Tullis]

@HåkanLindqvist I really earned a downvote from you? Did I give bad advice or good advice with regard to not authenticating over HTTPS then switching to HTTP for the rest of the session? Did I provide bad counsel with regard to HTTPS performance myths? Also, if the client initially attempts to connect using HTTPS, the MITM cannot intercept and respond without triggering an alert in the browser, because their cert won't match unless they have a stolen or successfully forged cert. On the other hand, if the site accepts an HTTP connection, interception is easier. Either way, HTTPS raises the bar.

[Craig Tullis]

..and of course I agree wholeheartedly with using HSTS.

[Håkan Lindqvist]

My problem with the answer is the first item in the list claiming to address sslstrip while it actually doesn't (speaking of myths). What I was trying to get at in my initial comment is that if you have an active MITM (which is what you need for sslstrip in the first place), the attacker can essentially be "the site" from the perspective of the client; it's the attacker that decides if they want to accept plain HTTP connections from the client, how your actual web server behaves in that regard doesn't affect what the attacker can or will do.

[Craig Tullis]

@HåkanLindqvist Except that if the visitor is intentionally trying to connect with HTTPS, the attacker can't satisfy that request without throwing flags in the browser, unless they have managed to steal a server certificate or somehow successfully forge one, which they would have to do in order to switch the connection to HTTP. HTTPS still raises the bar. Of course if the visitor makes the initial connection attempt over HTTP, all bets are completely off.

[Håkan Lindqvist]

Sure, if the client is using HTTPS from the beginning then the question as well as the first item (about sslstrip) in your answer are not applicable. I'm not sure that I understand the relevance of this argument, though. If you want to fix sslstrip you use HSTS (preferrably preloaded), then the client will know to never issue HTTP requests even if asked to do so, ie the "all bets are off" problem is solved. Disabling HTTP on the server doesn't have the same effect.

[Janus Troelsen]

why not RewriteCond %{HTTPS} off instead of matching on port number?