26

When we enter an URL in a browser, it uses HTTP by default but if the server only support HTTPS, does the traffic redirect to https automatically without the user noticing?

Am I right?

If wrong, please correct me.

unor
  • 1,769
  • 1
  • 19
  • 38
kst
  • 279
  • 1
  • 3
  • 5
  • 2
    Actual example: `online.sberbank.ru` will not load via HTTP, but it works fine with HTTPS. The user will surely notice if they just typed the domain into browser's address line — the browser will do nothing to try HTTPS version, so the page won't load. – Ruslan Jul 29 '17 at 05:40
  • 4
    Do you, by chance, have [HTTPS everywhere](https://www.eff.org/https-everywhere) plugin installed and forgot about it? That one does automatically replace http with https. – Jan Hudec Jul 29 '17 at 18:47
  • @kst - Wondering if a browser can be forced to do so via an Extension or Script? – Alex S Jul 29 '17 at 22:39
  • The proper way to do this is have a non-SSL http server send a redirect to the https URL. Same way you can send example.com to www.example.comm etc – ivanivan Jul 30 '17 at 01:40
  • Related: https://security.stackexchange.com/questions/124633/what-stops-someone-from-just-redirecting-a-https-connection-to-a-http-version-of – Jedi Jul 30 '17 at 03:33

4 Answers4

59

No, at the moment no major browsers would redirect to HTTPS automatically.

The website can set HSTS header to tell browsers that they should redirect to HTTPS automatically for future requests, or they can register themselves into HSTS preload list, and users can install browser plugins to always load HTTPS based on a white list or even to always try HTTPS first. All of these are opt-in, either the website or the user has to do something to make the browser do this. In its default configuration, without explicit action by the user or the web site, no major browsers would automatically use HTTPS.

Lie Ryan
  • 31,089
  • 6
  • 68
  • 93
  • 8
    If you redirect HTTP to HTTPS, make sure to mark your cookies as secure so you don't leak them in the initial accesses through http. – spectras Jul 28 '17 at 07:38
  • 6
    You should always mark cookies as secure unless they are explicitly intended to be presented over HTTP - "if you redirect" is not a consideration, there are other ways to exploit sensitive data in cookies which don't have the secure flag. – symcbean Jul 28 '17 at 11:06
  • This answer makes it sound like HSTS is a future technology (to me anyway), when in fact it's already implemented in [all major browsers](http://caniuse.com/#feat=stricttransportsecurity). – MTCoster Jul 28 '17 at 11:28
  • 5
    @MTCoster The answer is worded a bit ambiguously, but your interpretation is not the intended one; the _"in the future"_ part means that the browser will only automatically redirect to HTTPS **after** it receives the HSTS header, presumably over plain HTTP. Read it as: _"The website can set the HSTS header to tell browsers that they should redirect any future requests to HTTPS automatically, ..."_ – marcelm Jul 28 '17 at 11:33
  • 2
    From Teo (not enough rep to comment): EFF has a browser extension for HTTPS as well. https://www.eff.org/https-everywhere – Serge Ballesta Jul 28 '17 at 12:47
  • "at the moment": there are any plans of browsers defaulting to HTTPS in future? Something like "try to connect via HTTPS, if the server don't responds try HTTP, then if it works show an error and tell the user that the website is only available via an insecure connection". I think it's going to be the default when [browsers start marking all HTTP pages as "Not secure"](https://security.googleblog.com/2017/04/next-steps-toward-more-connection.html). – Gustavo Rodrigues Jul 29 '17 at 14:50
  • Yup, this is exactly right, much my consternation when a government agency completely blocked all traffic on port 80 for public sites (at least in the hosting environment we're using). – jpmc26 Jul 29 '17 at 20:05
  • @marcelm: you should submit your comment as a modification of the answer as it addresses a very good point. – WoJ Jul 30 '17 at 12:51
  • I've edited the answer to address the ambiguity. – Lie Ryan Jul 31 '17 at 00:56
  • @marcelm: To nit, browsers are required to ignore STS header over plain HTTP: "If an HTTP response is received over insecure transport, the UA MUST ignore any present STS header field(s)." ([RFC6797 Sec 8.1](https://tools.ietf.org/html/rfc6797#section-8)) – Lie Ryan Jul 31 '17 at 01:17
  • @LieRyan good point! It's actually HTTP -> HTTPS redirect and _then_ HSTS comes into play. (@WoJ Haha, I keep forgetting I can do that ;) – marcelm Aug 01 '17 at 09:57
  • @GustavoRodrigues theoretically you could block requests to 443 if you can tamper the connection, forcing the browser to access its HTTP counterpart. – Lucca Ferri Sep 09 '19 at 08:15
  • @LuccaFerri Well, at the moment it don't works for websites with HSTS (preload or if the user previously visited the website): the browser just redirects to HTTPS and show an error without allowing bypass. Maybe the future when >90% of websites support HTTPS will be like this: it show a warning for all websites when HTTPS is not available and, if HSTS isn't active, allow users could bypass it. Maybe things like local addresses (like routers) could be excepted from the warning (unless they decide routers should use something like *.discordapp.io). – Gustavo Rodrigues Sep 10 '19 at 11:22
  • @GustavoRodrigues my point being, if you block the HTTPS connection, HSTS will never be set, so it will try to connect to HTTP, unless you preload. But I agree, the only way HTTPS Everywhere would be possible natively is if you warn users connecting to HTTP sites. I think HTTPS Everywhere plugin for chrome would fail to work if MITM block *:443 for sites that aren't preloaded. – Lucca Ferri Sep 10 '19 at 11:40
  • 1
    @LuccaFerri I'm assuming "preload" means using this - https://hstspreload.org/ - not loading the page previously. Using it makes 443 blocking useless: users will see a error, but never a unsafe page. It also stops users from skipping warnings. That's also better than HTTPS Everywhere because users don't need to download a extension to use it. It's easy to use and even IE 11 on a computer that never visited none of my websites before redirects those to HTTPS without opening any HTTP connections because of it. – Gustavo Rodrigues Sep 11 '19 at 12:46
  • @GustavoRodrigues you are correct if it's implemented by default in browser. Blocking 443 would force browser to downgrade if it tried HTTPS first before HTTP, that's why you can't downgrade the connection if the most secure is unavailable. Please don't take my comment as a disagreement with your comment above, just that I think downgrade shouldn't ever be allowed – Lucca Ferri Sep 11 '19 at 13:01
19

No.

You have to explicitly redirect the HTTP traffic to HTTPS which involves configuring your web server with a rule which returns HTTP 301 status code and a location header beginning with https://.

So for example in Nginx you would write something like:

server {
       listen         80;
       server_name    my.domain.com;
       return         301 https://$server_name$request_uri;
}

In addition you could add an Http Strict Transport Security (HSTS) header to the responses of requests which you receive on the HTTPS port. This will ensure that the browser sends all ensuing requests to the HTTPS port.

Again, in Nginx you would do this:

server {
       listen         443 ssl;
       server_name    my.domain.com;
       add_header Strict-Transport-Security "max-age=31536000"; 
}
  • 2
    Note that the part of the question "traffic redirect to https automatically without the user noticing" is often true (despite the correct "no" answers here). It's just that the web server has to be configured to do the redirect. So there is an initial HTTP connection (if the server really only serves HTTPS then it just won't connect, unless the browser has a pre-loaded HSTS list which includes that domain). But such servers do redirect "without the user noticing", so people think it's automagic. – Adam Jul 28 '17 at 13:12
  • You shouldn't send the HSTS header on the initial HTTP connection, but instead on the first HTTPS connection, as it could potentially be tampered with otherwise. – someonewithpc Jul 28 '17 at 22:52
  • 1
    @someonewithpc That's exactly what I've written. The HSTS header is sent when the connection is on port 443, not on port 80. –  Jul 28 '17 at 22:57
  • @Rahul Oh, right. It wasn't very clear – someonewithpc Jul 28 '17 at 22:59
  • Be mindful of SSL Strip though. – Lucca Ferri Sep 09 '19 at 08:13
2

Some website use HSTS which basically do what you're saying. If a user try to access some random http://example.com, HSTS will transform the request into https://example.com. However, the website needs to have a valid certificate in order to function properly.

Anders
  • 64,406
  • 24
  • 178
  • 215
lapinousexy
  • 144
  • 1
  • 1
  • 9
  • @Octopus This is indeed one of the functions of HSTS. If a site is in a HSTS preload list, or you've visited it before and observed an HSTS header that has not yet expired, the browser will automatically issue HTTPS requests, even if HTTP is specified. – Xander Jul 28 '17 at 18:22
  • 2
    Browsers must and do ignore HSTS headers received over plain HTTP. So you cannot rely on that header alone to get HTTPS used automatically. – n0rd Jul 28 '17 at 20:14
-1

"if the server only support HTTPS", then all traffic should be routed to https by the server.

If host server supports both, then preference to https may be given via several methods eg. DNS redirection (by Domain host), server directives (301/302 via .htaccess files) of web host, application redirection (server side scripting eg. perl/php script), or client redirection (javascript/meta refresh). In these cases, if someone was to access pages via http, they will receive pages via https (automatically).

An example of script redirection in a php file (where you don't have control of the host server):

<?php

if ($_SERVER["SERVER_PORT"] == 80 && $_SERVER["REQUEST_SCHEME"] == "http") {
    header('Location: https://your.domain.url', TRUE, 301);
}

?>
<html>
<head>
...
</html>

If neither of the above have been deployed, access to page via unsupported protocol will give 500, 501, 403, or 404 errors or just not load, showing "ERR_CONNECTION_REFUSED" in browsers. In these cases, users may themselves type in https in web browsers to ensure data delivery via ssl/tls, or install helpers like browser plugins (which replace url with https://url)

Zimba
  • 181
  • 5
  • There's no such thing as DNS redirection: redirection is a feature of the HTTP protocol ([RFC 7231, 6.4](https://tools.ietf.org/html/rfc7231#section-6.4)). Also, there's nothing that weren't already told in the other answers. – Esa Jokinen Aug 20 '20 at 14:58
  • @EsaJokinen: To learn about DNS redirects read these: https://totaluptime.com/kb/whats-the-difference-between-a-cname-and-a-web-redirect/, https://www.namecheap.com/support/knowledgebase/article.aspx/9604/2237/types-of-domain-redirects--301-302-url-redirects-url-frame-and-cname, https://community.spiceworks.com/topic/161678-how-to-create-a-dns-entry-that-redirects-to-a-different-site, https://www.imperva.com/learn/application-security/dns-hijacking-redirection/, – Zimba Aug 21 '20 at 14:05
  • https://whatis.techtarget.com/definition/DNS-redirection. I don't see any answer explaining redirection without host server control: one talkes about configuring your own server, the other installs browser plugin. Which one repeats my answer? @EsaJokinen – Zimba Aug 21 '20 at 14:05
  • @EsaJokinen: see RFC 1035, 3.3.1, RFC 2219 – Zimba Aug 21 '20 at 14:23
  • A DNS `CNAME` doesn't perform any redirections, and certainly not protocol upgrades like this! It's merely an alias pointing to the *canonical name*. From the Namecheap link you provided: "CNAME record is actually not a redirect type record but often mistakenly used as such." – Esa Jokinen Aug 21 '20 at 16:42
  • **Serial downvoting of my answers** isn't really a revenge: 1) it **won't get your facts straight** 2) I don't really care 3) the system automatically reverts such childish vandalism. – Esa Jokinen Aug 22 '20 at 04:31
  • `CNAME` points to an `A` record in DNS which redirects web apps to resource location eg. web browsers to web pages. – Zimba Aug 22 '20 at 15:48
  • DNS resolves hostnames to IP addresses, whether directly using `A` records or indirectly through `CNAME` records. The original hostname typed into the browser is the only one the webserver ever sees, and if it's not aware it should serve something from that hostname in the HTTP `Host:` header, it may serve some default virtual host or an error. It certainly won't redirect to the hostname given in the `CNAME` record, but that has to be configured within the web server i.e. using HTTP redirection. https://serverfault.com/a/885121/274176 – Esa Jokinen Aug 22 '20 at 16:28