Should I close port 80 forever and ever since the 2018 Google-indicated web-security initiatives?












45















I often establish Ubuntu-LAMP environments on which I host a few Drupal web applications that I myself own (I don't provide any hosting services and never done so in the past).



Whenever I establish such an environment, the most fundamental security steps I take are these:



ufw --force enable
ufw allow 22,25,80,443 # All allowed via both TCP/UPD as no restrictions were given;
apt update -y
apt upgrade unattended-upgrades sshguard


After the 2017-2018 W3C/Google (?) reforms regarding browser support in HTTP, requiring or at least encouraging all of us to use TLS encryption confirmed with an SSL certificate for secured HTTP data transfer (HTTPS), I wonder if unsecured HTTP (typically via port 80) is still relevant at all to any of us.



Notes:




  1. Each of my web apps has its own OpenSSL certificate I create with Certbot.

  2. The only web utility I use besides websites is either PHPMyAdmin/PHPMiniAdmin.


My question



Is it okay for me to remove port 80 from ufw allow 22,25,80,443 thus making my system even a tiny bit less "vulnerable"?



Update per answers



Answers recommend redirecting from port 80 to port 443 instead just blocking port 80. I think Certbot creates these redirects automatically so I'm covered if I keep port 80 open as recommended in the answers.










share|improve this question




















  • 4





    I like Scott Helme's blog answer: 2016-12-09, Why closing port 80 is bad for security (Archived here.)

    – StackzOfZtuff
    Nov 23 '18 at 9:52






  • 2





    i. closing port 80 doesn't save you from web services vulnerabilities. ii. you need to configure the web server to response to port 80 request and redirect user to https. iii. If you are not intend to open some services to other, restrict IP access is a way to reduce malicious bot from skimming your server.

    – mootmoot
    Nov 23 '18 at 11:59






  • 2





    LetsEncrypt still cannot renew HTTPS certificates via HTTPS, and continues to require port 80 (or DNS tricks). So that's one special reason to keep port 80 open for now.

    – MSalters
    Nov 23 '18 at 12:01






  • 3





    Possible duplicate of Why should I offer HTTP in addition to HTTPS?

    – Anders
    Nov 23 '18 at 12:32






  • 6





    Sooo ... do you think you should also close down your-domain.com without redirection because the correct name is www.your-domain.com?

    – Hagen von Eitzen
    Nov 23 '18 at 20:22


















45















I often establish Ubuntu-LAMP environments on which I host a few Drupal web applications that I myself own (I don't provide any hosting services and never done so in the past).



Whenever I establish such an environment, the most fundamental security steps I take are these:



ufw --force enable
ufw allow 22,25,80,443 # All allowed via both TCP/UPD as no restrictions were given;
apt update -y
apt upgrade unattended-upgrades sshguard


After the 2017-2018 W3C/Google (?) reforms regarding browser support in HTTP, requiring or at least encouraging all of us to use TLS encryption confirmed with an SSL certificate for secured HTTP data transfer (HTTPS), I wonder if unsecured HTTP (typically via port 80) is still relevant at all to any of us.



Notes:




  1. Each of my web apps has its own OpenSSL certificate I create with Certbot.

  2. The only web utility I use besides websites is either PHPMyAdmin/PHPMiniAdmin.


My question



Is it okay for me to remove port 80 from ufw allow 22,25,80,443 thus making my system even a tiny bit less "vulnerable"?



Update per answers



Answers recommend redirecting from port 80 to port 443 instead just blocking port 80. I think Certbot creates these redirects automatically so I'm covered if I keep port 80 open as recommended in the answers.










share|improve this question




















  • 4





    I like Scott Helme's blog answer: 2016-12-09, Why closing port 80 is bad for security (Archived here.)

    – StackzOfZtuff
    Nov 23 '18 at 9:52






  • 2





    i. closing port 80 doesn't save you from web services vulnerabilities. ii. you need to configure the web server to response to port 80 request and redirect user to https. iii. If you are not intend to open some services to other, restrict IP access is a way to reduce malicious bot from skimming your server.

    – mootmoot
    Nov 23 '18 at 11:59






  • 2





    LetsEncrypt still cannot renew HTTPS certificates via HTTPS, and continues to require port 80 (or DNS tricks). So that's one special reason to keep port 80 open for now.

    – MSalters
    Nov 23 '18 at 12:01






  • 3





    Possible duplicate of Why should I offer HTTP in addition to HTTPS?

    – Anders
    Nov 23 '18 at 12:32






  • 6





    Sooo ... do you think you should also close down your-domain.com without redirection because the correct name is www.your-domain.com?

    – Hagen von Eitzen
    Nov 23 '18 at 20:22
















45












45








45


14






I often establish Ubuntu-LAMP environments on which I host a few Drupal web applications that I myself own (I don't provide any hosting services and never done so in the past).



Whenever I establish such an environment, the most fundamental security steps I take are these:



ufw --force enable
ufw allow 22,25,80,443 # All allowed via both TCP/UPD as no restrictions were given;
apt update -y
apt upgrade unattended-upgrades sshguard


After the 2017-2018 W3C/Google (?) reforms regarding browser support in HTTP, requiring or at least encouraging all of us to use TLS encryption confirmed with an SSL certificate for secured HTTP data transfer (HTTPS), I wonder if unsecured HTTP (typically via port 80) is still relevant at all to any of us.



Notes:




  1. Each of my web apps has its own OpenSSL certificate I create with Certbot.

  2. The only web utility I use besides websites is either PHPMyAdmin/PHPMiniAdmin.


My question



Is it okay for me to remove port 80 from ufw allow 22,25,80,443 thus making my system even a tiny bit less "vulnerable"?



Update per answers



Answers recommend redirecting from port 80 to port 443 instead just blocking port 80. I think Certbot creates these redirects automatically so I'm covered if I keep port 80 open as recommended in the answers.










share|improve this question
















I often establish Ubuntu-LAMP environments on which I host a few Drupal web applications that I myself own (I don't provide any hosting services and never done so in the past).



Whenever I establish such an environment, the most fundamental security steps I take are these:



ufw --force enable
ufw allow 22,25,80,443 # All allowed via both TCP/UPD as no restrictions were given;
apt update -y
apt upgrade unattended-upgrades sshguard


After the 2017-2018 W3C/Google (?) reforms regarding browser support in HTTP, requiring or at least encouraging all of us to use TLS encryption confirmed with an SSL certificate for secured HTTP data transfer (HTTPS), I wonder if unsecured HTTP (typically via port 80) is still relevant at all to any of us.



Notes:




  1. Each of my web apps has its own OpenSSL certificate I create with Certbot.

  2. The only web utility I use besides websites is either PHPMyAdmin/PHPMiniAdmin.


My question



Is it okay for me to remove port 80 from ufw allow 22,25,80,443 thus making my system even a tiny bit less "vulnerable"?



Update per answers



Answers recommend redirecting from port 80 to port 443 instead just blocking port 80. I think Certbot creates these redirects automatically so I'm covered if I keep port 80 open as recommended in the answers.







tls linux apache ports ubuntu






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Dec 11 '18 at 8:41









Antu

1207




1207










asked Nov 23 '18 at 7:26









JohnDoeaJohnDoea

862620




862620








  • 4





    I like Scott Helme's blog answer: 2016-12-09, Why closing port 80 is bad for security (Archived here.)

    – StackzOfZtuff
    Nov 23 '18 at 9:52






  • 2





    i. closing port 80 doesn't save you from web services vulnerabilities. ii. you need to configure the web server to response to port 80 request and redirect user to https. iii. If you are not intend to open some services to other, restrict IP access is a way to reduce malicious bot from skimming your server.

    – mootmoot
    Nov 23 '18 at 11:59






  • 2





    LetsEncrypt still cannot renew HTTPS certificates via HTTPS, and continues to require port 80 (or DNS tricks). So that's one special reason to keep port 80 open for now.

    – MSalters
    Nov 23 '18 at 12:01






  • 3





    Possible duplicate of Why should I offer HTTP in addition to HTTPS?

    – Anders
    Nov 23 '18 at 12:32






  • 6





    Sooo ... do you think you should also close down your-domain.com without redirection because the correct name is www.your-domain.com?

    – Hagen von Eitzen
    Nov 23 '18 at 20:22
















  • 4





    I like Scott Helme's blog answer: 2016-12-09, Why closing port 80 is bad for security (Archived here.)

    – StackzOfZtuff
    Nov 23 '18 at 9:52






  • 2





    i. closing port 80 doesn't save you from web services vulnerabilities. ii. you need to configure the web server to response to port 80 request and redirect user to https. iii. If you are not intend to open some services to other, restrict IP access is a way to reduce malicious bot from skimming your server.

    – mootmoot
    Nov 23 '18 at 11:59






  • 2





    LetsEncrypt still cannot renew HTTPS certificates via HTTPS, and continues to require port 80 (or DNS tricks). So that's one special reason to keep port 80 open for now.

    – MSalters
    Nov 23 '18 at 12:01






  • 3





    Possible duplicate of Why should I offer HTTP in addition to HTTPS?

    – Anders
    Nov 23 '18 at 12:32






  • 6





    Sooo ... do you think you should also close down your-domain.com without redirection because the correct name is www.your-domain.com?

    – Hagen von Eitzen
    Nov 23 '18 at 20:22










4




4





I like Scott Helme's blog answer: 2016-12-09, Why closing port 80 is bad for security (Archived here.)

– StackzOfZtuff
Nov 23 '18 at 9:52





I like Scott Helme's blog answer: 2016-12-09, Why closing port 80 is bad for security (Archived here.)

– StackzOfZtuff
Nov 23 '18 at 9:52




2




2





i. closing port 80 doesn't save you from web services vulnerabilities. ii. you need to configure the web server to response to port 80 request and redirect user to https. iii. If you are not intend to open some services to other, restrict IP access is a way to reduce malicious bot from skimming your server.

– mootmoot
Nov 23 '18 at 11:59





i. closing port 80 doesn't save you from web services vulnerabilities. ii. you need to configure the web server to response to port 80 request and redirect user to https. iii. If you are not intend to open some services to other, restrict IP access is a way to reduce malicious bot from skimming your server.

– mootmoot
Nov 23 '18 at 11:59




2




2





LetsEncrypt still cannot renew HTTPS certificates via HTTPS, and continues to require port 80 (or DNS tricks). So that's one special reason to keep port 80 open for now.

– MSalters
Nov 23 '18 at 12:01





LetsEncrypt still cannot renew HTTPS certificates via HTTPS, and continues to require port 80 (or DNS tricks). So that's one special reason to keep port 80 open for now.

– MSalters
Nov 23 '18 at 12:01




3




3





Possible duplicate of Why should I offer HTTP in addition to HTTPS?

– Anders
Nov 23 '18 at 12:32





Possible duplicate of Why should I offer HTTP in addition to HTTPS?

– Anders
Nov 23 '18 at 12:32




6




6





Sooo ... do you think you should also close down your-domain.com without redirection because the correct name is www.your-domain.com?

– Hagen von Eitzen
Nov 23 '18 at 20:22







Sooo ... do you think you should also close down your-domain.com without redirection because the correct name is www.your-domain.com?

– Hagen von Eitzen
Nov 23 '18 at 20:22












5 Answers
5






active

oldest

votes


















63














Google, the major search engine of the Internet (dwarfing both Bing and Yahoo), and the browser used by majority of Internet users, has been pushing for an HTTPS-only world by decreasing the page rank for sites that do not HTTPS, and adding a browser warning when a site is not secure. However, the ratio of HTTPS sites to not is still far too low to recommend an HTTPS-first policy for everyone, because users would pretty constantly get scary "certificate error" messages or "connection refused" errors.



So, until Google recommends an HTTPS-first policy for browser connections, it's not likely that Firefox, Apple, or Microsoft will recommend such policies, either, and that is not likely until a decent majority (perhaps 70% or more) of top sites are HTTPS enabled, which would be a huge increase from the ~50% of top sites that have HTTPS today.



Most users that intentionally or accidentally visit your HTTP site, if greeted with a "connection refused" error, will likely move on to another site. I don't have a good way to get concrete numbers here, but it would be likely that 70-90% of Internet users probably wouldn't figure out the site has no HTTP port without an automatic redirect; the remainder are probably either technically competent enough to realize they need HTTPS, or use HTTPS Everywhere, and wouldn't notice anyways.



Definitely use HSTS, definitely 301 redirect to HTTPS resources (the 301 indicates a permanent move to browsers, so they will "remember" this preference), definitely advise your users to make sure they see a padlock and verify the certificate, etc. Do not block port 80 at this point, as the Internet simply is not ready for this yet.



As far as I know, there are no major sites that have disabled HTTP and blocked port 80. If you do this, you'll be breaking user expectation (that the site will forward you to a secure site), and since most users won't know what to do here, because they won't get a friendly error message, will simply assume your site is broken and move on.






share|improve this answer





















  • 1





    I think that Certbot creates these redirections automatically so I'm covered if I keep port 80 open.

    – JohnDoea
    Nov 23 '18 at 9:17











  • @JohnDoea I haven't used it significantly, but it should take care of the situation for you. Even if not, enabling HSTS and HTTPS redirects are pretty trivial in Apache, just a few lines of configuration.

    – phyrfox
    Nov 23 '18 at 9:22






  • 18





    @JohnDoea, I would be very surprised if certbot did that, it is not at all its job. The A part of LAMP is where that would happen.

    – Carsten S
    Nov 23 '18 at 9:25






  • 8





    @CarstenS docs say it supports --redirect and --hsts options for configuring both of these for quick setup. I haven't personally used it, but seems legit.

    – phyrfox
    Nov 23 '18 at 9:35






  • 2





    Why would you ever get certificate errors, if your site is set up correctly? (Also, I've seen connection refused errors, but I'm not sure what causes them. I usually just try reloading the page if I come across one.)

    – SilverWolf
    Nov 23 '18 at 14:46



















60














You should not close off port 80. Instead, you should configure your server to redirect HTTP port 80 to HTTPS port 443 in order to use TLS. You can optionally use HSTS (HTTP Strict Transport Security) to tell browsers to remember to only use TLS when connecting to your site in the future.



There is nothing insecure about port 80 being open. Security issues only occur when the web server is serving requests over an unencrypted connection, especially if those requests contain sensitive data. Having port 80 be open and send nothing more than an HTTP redirect is perfectly safe.






share|improve this answer


























  • Hmm, is this transfer you mention what's called "port forwarding"?

    – JohnDoea
    Nov 23 '18 at 7:29






  • 9





    @JohnDoea No, not port forwarding. You configure Apache to do an HTTP redirect.

    – forest
    Nov 23 '18 at 7:30













  • One last question, please, theoretically if I'll close it just for the sake of minimalism, will I use many many customers in my websites?

    – JohnDoea
    Nov 23 '18 at 7:33






  • 45





    If you close it, you will lose a lot of customers who type in the URL without HTTPS. There is no security issue with leaving port 80 open as long as you redirect it to port 443.

    – forest
    Nov 23 '18 at 7:34








  • 2





    And that would be bad. People use http the same way they use "110 volts". Power has been 120V since the war, but when it was initially mass marketed, it was 110. You'll never get it out of their heads.

    – Harper
    Nov 25 '18 at 16:59



















5














In short: USUALLY, keep it open and use it to redirect everything to HTTPS.



Now onto the complicated stuff: taking away port 80 can stop cookie-thieves that passively look for straggle http://corp.com/some/forgotten/thing requests. The TCP connection does not succeed, the browser does not send the GET and cookies, and the bad guy cannot read them.



Sometimes this is a reasonable thing to protect against, especially thinking of corporate environments: legacy apps, HSTS only partially implemented, cookies that may lack the secure flag or path or host restrictions, third-parties hosted or proxied, ...



Now, should you block it? Probably not.



Like others mentioned, that would complicate setting up Let's Encrypt and prevent redirects (including users that just type your.com in the address bar). If you have set domain-wide HSTS, removing redirects may even be considered counterproductive (you may want to risk one plain HTTP connection so it will protect all future ones).



Also, note that active attackers will not be stopped (they can make the connection complete artificially, MITM proxy tools may even do this by default), there are corner cases (plain HTTP proxies, delegated domains outside your firewall), and you may just consider the passive attack too complicated for your model.



Finally, should you add port 80 to a new server? Well, unless you already have a reason for opening it (see above), no.






share|improve this answer































    4














    In addition to the other forest and phyrfox's answers, ACME http-01 verification uses port 80 to reach your servers. If you close the port, you won't be able to renew or create certificates.






    share|improve this answer



















    • 1





      The TLS-SNI-01 challenge method doesn't require port 80, and neither does the DNS-01 method (though that one isn't supported by Certbot).

      – Mark
      Nov 26 '18 at 1:05






    • 1





      @Mark TLS-SNI-01 has been removed since the shared-hosting incident and DNS-01 automation may not be practical for all users, depending on the infrastructure and dns provider.

      – zakinster
      Nov 26 '18 at 10:55





















    0














    I say it's situational. If your site only serves API, or is a backend content or static file server, where it is very unlikely that your typical users are going to type your server's address to visit your site or make a bookmark to the page (because this server's address never appears in the address bar), then there is probably no harm that could be caused by closing off port 80 for that server.



    If your site is a new site, with no history of people using your site on HTTP ever and no existing bookmark or if your site does not contain content that people are likely to share using the link, then you may consider closing off port 80.



    For servers that serves your home page, you probably still want to keep port 80 for now, because they are much more likely to be visited by people typing URL into the address bar. Also, if you advertise your page address in physical world (e.g. in physical ads) or in medium where people can't easily click, then you may want to keep port 80.






    share|improve this answer
























    • Even if your site is completely new, browsers still try port 80 first and get redirected to port 443. So if you close port 80 the user has to type https://... explicitly

      – Lithilion
      Dec 11 '18 at 13:07












    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "162"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    noCode: true, onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f198263%2fshould-i-close-port-80-forever-and-ever-since-the-2018-google-indicated-web-secu%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    5 Answers
    5






    active

    oldest

    votes








    5 Answers
    5






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    63














    Google, the major search engine of the Internet (dwarfing both Bing and Yahoo), and the browser used by majority of Internet users, has been pushing for an HTTPS-only world by decreasing the page rank for sites that do not HTTPS, and adding a browser warning when a site is not secure. However, the ratio of HTTPS sites to not is still far too low to recommend an HTTPS-first policy for everyone, because users would pretty constantly get scary "certificate error" messages or "connection refused" errors.



    So, until Google recommends an HTTPS-first policy for browser connections, it's not likely that Firefox, Apple, or Microsoft will recommend such policies, either, and that is not likely until a decent majority (perhaps 70% or more) of top sites are HTTPS enabled, which would be a huge increase from the ~50% of top sites that have HTTPS today.



    Most users that intentionally or accidentally visit your HTTP site, if greeted with a "connection refused" error, will likely move on to another site. I don't have a good way to get concrete numbers here, but it would be likely that 70-90% of Internet users probably wouldn't figure out the site has no HTTP port without an automatic redirect; the remainder are probably either technically competent enough to realize they need HTTPS, or use HTTPS Everywhere, and wouldn't notice anyways.



    Definitely use HSTS, definitely 301 redirect to HTTPS resources (the 301 indicates a permanent move to browsers, so they will "remember" this preference), definitely advise your users to make sure they see a padlock and verify the certificate, etc. Do not block port 80 at this point, as the Internet simply is not ready for this yet.



    As far as I know, there are no major sites that have disabled HTTP and blocked port 80. If you do this, you'll be breaking user expectation (that the site will forward you to a secure site), and since most users won't know what to do here, because they won't get a friendly error message, will simply assume your site is broken and move on.






    share|improve this answer





















    • 1





      I think that Certbot creates these redirections automatically so I'm covered if I keep port 80 open.

      – JohnDoea
      Nov 23 '18 at 9:17











    • @JohnDoea I haven't used it significantly, but it should take care of the situation for you. Even if not, enabling HSTS and HTTPS redirects are pretty trivial in Apache, just a few lines of configuration.

      – phyrfox
      Nov 23 '18 at 9:22






    • 18





      @JohnDoea, I would be very surprised if certbot did that, it is not at all its job. The A part of LAMP is where that would happen.

      – Carsten S
      Nov 23 '18 at 9:25






    • 8





      @CarstenS docs say it supports --redirect and --hsts options for configuring both of these for quick setup. I haven't personally used it, but seems legit.

      – phyrfox
      Nov 23 '18 at 9:35






    • 2





      Why would you ever get certificate errors, if your site is set up correctly? (Also, I've seen connection refused errors, but I'm not sure what causes them. I usually just try reloading the page if I come across one.)

      – SilverWolf
      Nov 23 '18 at 14:46
















    63














    Google, the major search engine of the Internet (dwarfing both Bing and Yahoo), and the browser used by majority of Internet users, has been pushing for an HTTPS-only world by decreasing the page rank for sites that do not HTTPS, and adding a browser warning when a site is not secure. However, the ratio of HTTPS sites to not is still far too low to recommend an HTTPS-first policy for everyone, because users would pretty constantly get scary "certificate error" messages or "connection refused" errors.



    So, until Google recommends an HTTPS-first policy for browser connections, it's not likely that Firefox, Apple, or Microsoft will recommend such policies, either, and that is not likely until a decent majority (perhaps 70% or more) of top sites are HTTPS enabled, which would be a huge increase from the ~50% of top sites that have HTTPS today.



    Most users that intentionally or accidentally visit your HTTP site, if greeted with a "connection refused" error, will likely move on to another site. I don't have a good way to get concrete numbers here, but it would be likely that 70-90% of Internet users probably wouldn't figure out the site has no HTTP port without an automatic redirect; the remainder are probably either technically competent enough to realize they need HTTPS, or use HTTPS Everywhere, and wouldn't notice anyways.



    Definitely use HSTS, definitely 301 redirect to HTTPS resources (the 301 indicates a permanent move to browsers, so they will "remember" this preference), definitely advise your users to make sure they see a padlock and verify the certificate, etc. Do not block port 80 at this point, as the Internet simply is not ready for this yet.



    As far as I know, there are no major sites that have disabled HTTP and blocked port 80. If you do this, you'll be breaking user expectation (that the site will forward you to a secure site), and since most users won't know what to do here, because they won't get a friendly error message, will simply assume your site is broken and move on.






    share|improve this answer





















    • 1





      I think that Certbot creates these redirections automatically so I'm covered if I keep port 80 open.

      – JohnDoea
      Nov 23 '18 at 9:17











    • @JohnDoea I haven't used it significantly, but it should take care of the situation for you. Even if not, enabling HSTS and HTTPS redirects are pretty trivial in Apache, just a few lines of configuration.

      – phyrfox
      Nov 23 '18 at 9:22






    • 18





      @JohnDoea, I would be very surprised if certbot did that, it is not at all its job. The A part of LAMP is where that would happen.

      – Carsten S
      Nov 23 '18 at 9:25






    • 8





      @CarstenS docs say it supports --redirect and --hsts options for configuring both of these for quick setup. I haven't personally used it, but seems legit.

      – phyrfox
      Nov 23 '18 at 9:35






    • 2





      Why would you ever get certificate errors, if your site is set up correctly? (Also, I've seen connection refused errors, but I'm not sure what causes them. I usually just try reloading the page if I come across one.)

      – SilverWolf
      Nov 23 '18 at 14:46














    63












    63








    63







    Google, the major search engine of the Internet (dwarfing both Bing and Yahoo), and the browser used by majority of Internet users, has been pushing for an HTTPS-only world by decreasing the page rank for sites that do not HTTPS, and adding a browser warning when a site is not secure. However, the ratio of HTTPS sites to not is still far too low to recommend an HTTPS-first policy for everyone, because users would pretty constantly get scary "certificate error" messages or "connection refused" errors.



    So, until Google recommends an HTTPS-first policy for browser connections, it's not likely that Firefox, Apple, or Microsoft will recommend such policies, either, and that is not likely until a decent majority (perhaps 70% or more) of top sites are HTTPS enabled, which would be a huge increase from the ~50% of top sites that have HTTPS today.



    Most users that intentionally or accidentally visit your HTTP site, if greeted with a "connection refused" error, will likely move on to another site. I don't have a good way to get concrete numbers here, but it would be likely that 70-90% of Internet users probably wouldn't figure out the site has no HTTP port without an automatic redirect; the remainder are probably either technically competent enough to realize they need HTTPS, or use HTTPS Everywhere, and wouldn't notice anyways.



    Definitely use HSTS, definitely 301 redirect to HTTPS resources (the 301 indicates a permanent move to browsers, so they will "remember" this preference), definitely advise your users to make sure they see a padlock and verify the certificate, etc. Do not block port 80 at this point, as the Internet simply is not ready for this yet.



    As far as I know, there are no major sites that have disabled HTTP and blocked port 80. If you do this, you'll be breaking user expectation (that the site will forward you to a secure site), and since most users won't know what to do here, because they won't get a friendly error message, will simply assume your site is broken and move on.






    share|improve this answer















    Google, the major search engine of the Internet (dwarfing both Bing and Yahoo), and the browser used by majority of Internet users, has been pushing for an HTTPS-only world by decreasing the page rank for sites that do not HTTPS, and adding a browser warning when a site is not secure. However, the ratio of HTTPS sites to not is still far too low to recommend an HTTPS-first policy for everyone, because users would pretty constantly get scary "certificate error" messages or "connection refused" errors.



    So, until Google recommends an HTTPS-first policy for browser connections, it's not likely that Firefox, Apple, or Microsoft will recommend such policies, either, and that is not likely until a decent majority (perhaps 70% or more) of top sites are HTTPS enabled, which would be a huge increase from the ~50% of top sites that have HTTPS today.



    Most users that intentionally or accidentally visit your HTTP site, if greeted with a "connection refused" error, will likely move on to another site. I don't have a good way to get concrete numbers here, but it would be likely that 70-90% of Internet users probably wouldn't figure out the site has no HTTP port without an automatic redirect; the remainder are probably either technically competent enough to realize they need HTTPS, or use HTTPS Everywhere, and wouldn't notice anyways.



    Definitely use HSTS, definitely 301 redirect to HTTPS resources (the 301 indicates a permanent move to browsers, so they will "remember" this preference), definitely advise your users to make sure they see a padlock and verify the certificate, etc. Do not block port 80 at this point, as the Internet simply is not ready for this yet.



    As far as I know, there are no major sites that have disabled HTTP and blocked port 80. If you do this, you'll be breaking user expectation (that the site will forward you to a secure site), and since most users won't know what to do here, because they won't get a friendly error message, will simply assume your site is broken and move on.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Nov 23 '18 at 16:09

























    answered Nov 23 '18 at 8:39









    phyrfoxphyrfox

    4,7071421




    4,7071421








    • 1





      I think that Certbot creates these redirections automatically so I'm covered if I keep port 80 open.

      – JohnDoea
      Nov 23 '18 at 9:17











    • @JohnDoea I haven't used it significantly, but it should take care of the situation for you. Even if not, enabling HSTS and HTTPS redirects are pretty trivial in Apache, just a few lines of configuration.

      – phyrfox
      Nov 23 '18 at 9:22






    • 18





      @JohnDoea, I would be very surprised if certbot did that, it is not at all its job. The A part of LAMP is where that would happen.

      – Carsten S
      Nov 23 '18 at 9:25






    • 8





      @CarstenS docs say it supports --redirect and --hsts options for configuring both of these for quick setup. I haven't personally used it, but seems legit.

      – phyrfox
      Nov 23 '18 at 9:35






    • 2





      Why would you ever get certificate errors, if your site is set up correctly? (Also, I've seen connection refused errors, but I'm not sure what causes them. I usually just try reloading the page if I come across one.)

      – SilverWolf
      Nov 23 '18 at 14:46














    • 1





      I think that Certbot creates these redirections automatically so I'm covered if I keep port 80 open.

      – JohnDoea
      Nov 23 '18 at 9:17











    • @JohnDoea I haven't used it significantly, but it should take care of the situation for you. Even if not, enabling HSTS and HTTPS redirects are pretty trivial in Apache, just a few lines of configuration.

      – phyrfox
      Nov 23 '18 at 9:22






    • 18





      @JohnDoea, I would be very surprised if certbot did that, it is not at all its job. The A part of LAMP is where that would happen.

      – Carsten S
      Nov 23 '18 at 9:25






    • 8





      @CarstenS docs say it supports --redirect and --hsts options for configuring both of these for quick setup. I haven't personally used it, but seems legit.

      – phyrfox
      Nov 23 '18 at 9:35






    • 2





      Why would you ever get certificate errors, if your site is set up correctly? (Also, I've seen connection refused errors, but I'm not sure what causes them. I usually just try reloading the page if I come across one.)

      – SilverWolf
      Nov 23 '18 at 14:46








    1




    1





    I think that Certbot creates these redirections automatically so I'm covered if I keep port 80 open.

    – JohnDoea
    Nov 23 '18 at 9:17





    I think that Certbot creates these redirections automatically so I'm covered if I keep port 80 open.

    – JohnDoea
    Nov 23 '18 at 9:17













    @JohnDoea I haven't used it significantly, but it should take care of the situation for you. Even if not, enabling HSTS and HTTPS redirects are pretty trivial in Apache, just a few lines of configuration.

    – phyrfox
    Nov 23 '18 at 9:22





    @JohnDoea I haven't used it significantly, but it should take care of the situation for you. Even if not, enabling HSTS and HTTPS redirects are pretty trivial in Apache, just a few lines of configuration.

    – phyrfox
    Nov 23 '18 at 9:22




    18




    18





    @JohnDoea, I would be very surprised if certbot did that, it is not at all its job. The A part of LAMP is where that would happen.

    – Carsten S
    Nov 23 '18 at 9:25





    @JohnDoea, I would be very surprised if certbot did that, it is not at all its job. The A part of LAMP is where that would happen.

    – Carsten S
    Nov 23 '18 at 9:25




    8




    8





    @CarstenS docs say it supports --redirect and --hsts options for configuring both of these for quick setup. I haven't personally used it, but seems legit.

    – phyrfox
    Nov 23 '18 at 9:35





    @CarstenS docs say it supports --redirect and --hsts options for configuring both of these for quick setup. I haven't personally used it, but seems legit.

    – phyrfox
    Nov 23 '18 at 9:35




    2




    2





    Why would you ever get certificate errors, if your site is set up correctly? (Also, I've seen connection refused errors, but I'm not sure what causes them. I usually just try reloading the page if I come across one.)

    – SilverWolf
    Nov 23 '18 at 14:46





    Why would you ever get certificate errors, if your site is set up correctly? (Also, I've seen connection refused errors, but I'm not sure what causes them. I usually just try reloading the page if I come across one.)

    – SilverWolf
    Nov 23 '18 at 14:46













    60














    You should not close off port 80. Instead, you should configure your server to redirect HTTP port 80 to HTTPS port 443 in order to use TLS. You can optionally use HSTS (HTTP Strict Transport Security) to tell browsers to remember to only use TLS when connecting to your site in the future.



    There is nothing insecure about port 80 being open. Security issues only occur when the web server is serving requests over an unencrypted connection, especially if those requests contain sensitive data. Having port 80 be open and send nothing more than an HTTP redirect is perfectly safe.






    share|improve this answer


























    • Hmm, is this transfer you mention what's called "port forwarding"?

      – JohnDoea
      Nov 23 '18 at 7:29






    • 9





      @JohnDoea No, not port forwarding. You configure Apache to do an HTTP redirect.

      – forest
      Nov 23 '18 at 7:30













    • One last question, please, theoretically if I'll close it just for the sake of minimalism, will I use many many customers in my websites?

      – JohnDoea
      Nov 23 '18 at 7:33






    • 45





      If you close it, you will lose a lot of customers who type in the URL without HTTPS. There is no security issue with leaving port 80 open as long as you redirect it to port 443.

      – forest
      Nov 23 '18 at 7:34








    • 2





      And that would be bad. People use http the same way they use "110 volts". Power has been 120V since the war, but when it was initially mass marketed, it was 110. You'll never get it out of their heads.

      – Harper
      Nov 25 '18 at 16:59
















    60














    You should not close off port 80. Instead, you should configure your server to redirect HTTP port 80 to HTTPS port 443 in order to use TLS. You can optionally use HSTS (HTTP Strict Transport Security) to tell browsers to remember to only use TLS when connecting to your site in the future.



    There is nothing insecure about port 80 being open. Security issues only occur when the web server is serving requests over an unencrypted connection, especially if those requests contain sensitive data. Having port 80 be open and send nothing more than an HTTP redirect is perfectly safe.






    share|improve this answer


























    • Hmm, is this transfer you mention what's called "port forwarding"?

      – JohnDoea
      Nov 23 '18 at 7:29






    • 9





      @JohnDoea No, not port forwarding. You configure Apache to do an HTTP redirect.

      – forest
      Nov 23 '18 at 7:30













    • One last question, please, theoretically if I'll close it just for the sake of minimalism, will I use many many customers in my websites?

      – JohnDoea
      Nov 23 '18 at 7:33






    • 45





      If you close it, you will lose a lot of customers who type in the URL without HTTPS. There is no security issue with leaving port 80 open as long as you redirect it to port 443.

      – forest
      Nov 23 '18 at 7:34








    • 2





      And that would be bad. People use http the same way they use "110 volts". Power has been 120V since the war, but when it was initially mass marketed, it was 110. You'll never get it out of their heads.

      – Harper
      Nov 25 '18 at 16:59














    60












    60








    60







    You should not close off port 80. Instead, you should configure your server to redirect HTTP port 80 to HTTPS port 443 in order to use TLS. You can optionally use HSTS (HTTP Strict Transport Security) to tell browsers to remember to only use TLS when connecting to your site in the future.



    There is nothing insecure about port 80 being open. Security issues only occur when the web server is serving requests over an unencrypted connection, especially if those requests contain sensitive data. Having port 80 be open and send nothing more than an HTTP redirect is perfectly safe.






    share|improve this answer















    You should not close off port 80. Instead, you should configure your server to redirect HTTP port 80 to HTTPS port 443 in order to use TLS. You can optionally use HSTS (HTTP Strict Transport Security) to tell browsers to remember to only use TLS when connecting to your site in the future.



    There is nothing insecure about port 80 being open. Security issues only occur when the web server is serving requests over an unencrypted connection, especially if those requests contain sensitive data. Having port 80 be open and send nothing more than an HTTP redirect is perfectly safe.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Nov 23 '18 at 7:36

























    answered Nov 23 '18 at 7:28









    forestforest

    39.1k18127139




    39.1k18127139













    • Hmm, is this transfer you mention what's called "port forwarding"?

      – JohnDoea
      Nov 23 '18 at 7:29






    • 9





      @JohnDoea No, not port forwarding. You configure Apache to do an HTTP redirect.

      – forest
      Nov 23 '18 at 7:30













    • One last question, please, theoretically if I'll close it just for the sake of minimalism, will I use many many customers in my websites?

      – JohnDoea
      Nov 23 '18 at 7:33






    • 45





      If you close it, you will lose a lot of customers who type in the URL without HTTPS. There is no security issue with leaving port 80 open as long as you redirect it to port 443.

      – forest
      Nov 23 '18 at 7:34








    • 2





      And that would be bad. People use http the same way they use "110 volts". Power has been 120V since the war, but when it was initially mass marketed, it was 110. You'll never get it out of their heads.

      – Harper
      Nov 25 '18 at 16:59



















    • Hmm, is this transfer you mention what's called "port forwarding"?

      – JohnDoea
      Nov 23 '18 at 7:29






    • 9





      @JohnDoea No, not port forwarding. You configure Apache to do an HTTP redirect.

      – forest
      Nov 23 '18 at 7:30













    • One last question, please, theoretically if I'll close it just for the sake of minimalism, will I use many many customers in my websites?

      – JohnDoea
      Nov 23 '18 at 7:33






    • 45





      If you close it, you will lose a lot of customers who type in the URL without HTTPS. There is no security issue with leaving port 80 open as long as you redirect it to port 443.

      – forest
      Nov 23 '18 at 7:34








    • 2





      And that would be bad. People use http the same way they use "110 volts". Power has been 120V since the war, but when it was initially mass marketed, it was 110. You'll never get it out of their heads.

      – Harper
      Nov 25 '18 at 16:59

















    Hmm, is this transfer you mention what's called "port forwarding"?

    – JohnDoea
    Nov 23 '18 at 7:29





    Hmm, is this transfer you mention what's called "port forwarding"?

    – JohnDoea
    Nov 23 '18 at 7:29




    9




    9





    @JohnDoea No, not port forwarding. You configure Apache to do an HTTP redirect.

    – forest
    Nov 23 '18 at 7:30







    @JohnDoea No, not port forwarding. You configure Apache to do an HTTP redirect.

    – forest
    Nov 23 '18 at 7:30















    One last question, please, theoretically if I'll close it just for the sake of minimalism, will I use many many customers in my websites?

    – JohnDoea
    Nov 23 '18 at 7:33





    One last question, please, theoretically if I'll close it just for the sake of minimalism, will I use many many customers in my websites?

    – JohnDoea
    Nov 23 '18 at 7:33




    45




    45





    If you close it, you will lose a lot of customers who type in the URL without HTTPS. There is no security issue with leaving port 80 open as long as you redirect it to port 443.

    – forest
    Nov 23 '18 at 7:34







    If you close it, you will lose a lot of customers who type in the URL without HTTPS. There is no security issue with leaving port 80 open as long as you redirect it to port 443.

    – forest
    Nov 23 '18 at 7:34






    2




    2





    And that would be bad. People use http the same way they use "110 volts". Power has been 120V since the war, but when it was initially mass marketed, it was 110. You'll never get it out of their heads.

    – Harper
    Nov 25 '18 at 16:59





    And that would be bad. People use http the same way they use "110 volts". Power has been 120V since the war, but when it was initially mass marketed, it was 110. You'll never get it out of their heads.

    – Harper
    Nov 25 '18 at 16:59











    5














    In short: USUALLY, keep it open and use it to redirect everything to HTTPS.



    Now onto the complicated stuff: taking away port 80 can stop cookie-thieves that passively look for straggle http://corp.com/some/forgotten/thing requests. The TCP connection does not succeed, the browser does not send the GET and cookies, and the bad guy cannot read them.



    Sometimes this is a reasonable thing to protect against, especially thinking of corporate environments: legacy apps, HSTS only partially implemented, cookies that may lack the secure flag or path or host restrictions, third-parties hosted or proxied, ...



    Now, should you block it? Probably not.



    Like others mentioned, that would complicate setting up Let's Encrypt and prevent redirects (including users that just type your.com in the address bar). If you have set domain-wide HSTS, removing redirects may even be considered counterproductive (you may want to risk one plain HTTP connection so it will protect all future ones).



    Also, note that active attackers will not be stopped (they can make the connection complete artificially, MITM proxy tools may even do this by default), there are corner cases (plain HTTP proxies, delegated domains outside your firewall), and you may just consider the passive attack too complicated for your model.



    Finally, should you add port 80 to a new server? Well, unless you already have a reason for opening it (see above), no.






    share|improve this answer




























      5














      In short: USUALLY, keep it open and use it to redirect everything to HTTPS.



      Now onto the complicated stuff: taking away port 80 can stop cookie-thieves that passively look for straggle http://corp.com/some/forgotten/thing requests. The TCP connection does not succeed, the browser does not send the GET and cookies, and the bad guy cannot read them.



      Sometimes this is a reasonable thing to protect against, especially thinking of corporate environments: legacy apps, HSTS only partially implemented, cookies that may lack the secure flag or path or host restrictions, third-parties hosted or proxied, ...



      Now, should you block it? Probably not.



      Like others mentioned, that would complicate setting up Let's Encrypt and prevent redirects (including users that just type your.com in the address bar). If you have set domain-wide HSTS, removing redirects may even be considered counterproductive (you may want to risk one plain HTTP connection so it will protect all future ones).



      Also, note that active attackers will not be stopped (they can make the connection complete artificially, MITM proxy tools may even do this by default), there are corner cases (plain HTTP proxies, delegated domains outside your firewall), and you may just consider the passive attack too complicated for your model.



      Finally, should you add port 80 to a new server? Well, unless you already have a reason for opening it (see above), no.






      share|improve this answer


























        5












        5








        5







        In short: USUALLY, keep it open and use it to redirect everything to HTTPS.



        Now onto the complicated stuff: taking away port 80 can stop cookie-thieves that passively look for straggle http://corp.com/some/forgotten/thing requests. The TCP connection does not succeed, the browser does not send the GET and cookies, and the bad guy cannot read them.



        Sometimes this is a reasonable thing to protect against, especially thinking of corporate environments: legacy apps, HSTS only partially implemented, cookies that may lack the secure flag or path or host restrictions, third-parties hosted or proxied, ...



        Now, should you block it? Probably not.



        Like others mentioned, that would complicate setting up Let's Encrypt and prevent redirects (including users that just type your.com in the address bar). If you have set domain-wide HSTS, removing redirects may even be considered counterproductive (you may want to risk one plain HTTP connection so it will protect all future ones).



        Also, note that active attackers will not be stopped (they can make the connection complete artificially, MITM proxy tools may even do this by default), there are corner cases (plain HTTP proxies, delegated domains outside your firewall), and you may just consider the passive attack too complicated for your model.



        Finally, should you add port 80 to a new server? Well, unless you already have a reason for opening it (see above), no.






        share|improve this answer













        In short: USUALLY, keep it open and use it to redirect everything to HTTPS.



        Now onto the complicated stuff: taking away port 80 can stop cookie-thieves that passively look for straggle http://corp.com/some/forgotten/thing requests. The TCP connection does not succeed, the browser does not send the GET and cookies, and the bad guy cannot read them.



        Sometimes this is a reasonable thing to protect against, especially thinking of corporate environments: legacy apps, HSTS only partially implemented, cookies that may lack the secure flag or path or host restrictions, third-parties hosted or proxied, ...



        Now, should you block it? Probably not.



        Like others mentioned, that would complicate setting up Let's Encrypt and prevent redirects (including users that just type your.com in the address bar). If you have set domain-wide HSTS, removing redirects may even be considered counterproductive (you may want to risk one plain HTTP connection so it will protect all future ones).



        Also, note that active attackers will not be stopped (they can make the connection complete artificially, MITM proxy tools may even do this by default), there are corner cases (plain HTTP proxies, delegated domains outside your firewall), and you may just consider the passive attack too complicated for your model.



        Finally, should you add port 80 to a new server? Well, unless you already have a reason for opening it (see above), no.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Nov 24 '18 at 8:18









        JacopoJacopo

        1863




        1863























            4














            In addition to the other forest and phyrfox's answers, ACME http-01 verification uses port 80 to reach your servers. If you close the port, you won't be able to renew or create certificates.






            share|improve this answer



















            • 1





              The TLS-SNI-01 challenge method doesn't require port 80, and neither does the DNS-01 method (though that one isn't supported by Certbot).

              – Mark
              Nov 26 '18 at 1:05






            • 1





              @Mark TLS-SNI-01 has been removed since the shared-hosting incident and DNS-01 automation may not be practical for all users, depending on the infrastructure and dns provider.

              – zakinster
              Nov 26 '18 at 10:55


















            4














            In addition to the other forest and phyrfox's answers, ACME http-01 verification uses port 80 to reach your servers. If you close the port, you won't be able to renew or create certificates.






            share|improve this answer



















            • 1





              The TLS-SNI-01 challenge method doesn't require port 80, and neither does the DNS-01 method (though that one isn't supported by Certbot).

              – Mark
              Nov 26 '18 at 1:05






            • 1





              @Mark TLS-SNI-01 has been removed since the shared-hosting incident and DNS-01 automation may not be practical for all users, depending on the infrastructure and dns provider.

              – zakinster
              Nov 26 '18 at 10:55
















            4












            4








            4







            In addition to the other forest and phyrfox's answers, ACME http-01 verification uses port 80 to reach your servers. If you close the port, you won't be able to renew or create certificates.






            share|improve this answer













            In addition to the other forest and phyrfox's answers, ACME http-01 verification uses port 80 to reach your servers. If you close the port, you won't be able to renew or create certificates.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Nov 24 '18 at 9:24









            Umur KontacıUmur Kontacı

            1515




            1515








            • 1





              The TLS-SNI-01 challenge method doesn't require port 80, and neither does the DNS-01 method (though that one isn't supported by Certbot).

              – Mark
              Nov 26 '18 at 1:05






            • 1





              @Mark TLS-SNI-01 has been removed since the shared-hosting incident and DNS-01 automation may not be practical for all users, depending on the infrastructure and dns provider.

              – zakinster
              Nov 26 '18 at 10:55
















            • 1





              The TLS-SNI-01 challenge method doesn't require port 80, and neither does the DNS-01 method (though that one isn't supported by Certbot).

              – Mark
              Nov 26 '18 at 1:05






            • 1





              @Mark TLS-SNI-01 has been removed since the shared-hosting incident and DNS-01 automation may not be practical for all users, depending on the infrastructure and dns provider.

              – zakinster
              Nov 26 '18 at 10:55










            1




            1





            The TLS-SNI-01 challenge method doesn't require port 80, and neither does the DNS-01 method (though that one isn't supported by Certbot).

            – Mark
            Nov 26 '18 at 1:05





            The TLS-SNI-01 challenge method doesn't require port 80, and neither does the DNS-01 method (though that one isn't supported by Certbot).

            – Mark
            Nov 26 '18 at 1:05




            1




            1





            @Mark TLS-SNI-01 has been removed since the shared-hosting incident and DNS-01 automation may not be practical for all users, depending on the infrastructure and dns provider.

            – zakinster
            Nov 26 '18 at 10:55







            @Mark TLS-SNI-01 has been removed since the shared-hosting incident and DNS-01 automation may not be practical for all users, depending on the infrastructure and dns provider.

            – zakinster
            Nov 26 '18 at 10:55













            0














            I say it's situational. If your site only serves API, or is a backend content or static file server, where it is very unlikely that your typical users are going to type your server's address to visit your site or make a bookmark to the page (because this server's address never appears in the address bar), then there is probably no harm that could be caused by closing off port 80 for that server.



            If your site is a new site, with no history of people using your site on HTTP ever and no existing bookmark or if your site does not contain content that people are likely to share using the link, then you may consider closing off port 80.



            For servers that serves your home page, you probably still want to keep port 80 for now, because they are much more likely to be visited by people typing URL into the address bar. Also, if you advertise your page address in physical world (e.g. in physical ads) or in medium where people can't easily click, then you may want to keep port 80.






            share|improve this answer
























            • Even if your site is completely new, browsers still try port 80 first and get redirected to port 443. So if you close port 80 the user has to type https://... explicitly

              – Lithilion
              Dec 11 '18 at 13:07
















            0














            I say it's situational. If your site only serves API, or is a backend content or static file server, where it is very unlikely that your typical users are going to type your server's address to visit your site or make a bookmark to the page (because this server's address never appears in the address bar), then there is probably no harm that could be caused by closing off port 80 for that server.



            If your site is a new site, with no history of people using your site on HTTP ever and no existing bookmark or if your site does not contain content that people are likely to share using the link, then you may consider closing off port 80.



            For servers that serves your home page, you probably still want to keep port 80 for now, because they are much more likely to be visited by people typing URL into the address bar. Also, if you advertise your page address in physical world (e.g. in physical ads) or in medium where people can't easily click, then you may want to keep port 80.






            share|improve this answer
























            • Even if your site is completely new, browsers still try port 80 first and get redirected to port 443. So if you close port 80 the user has to type https://... explicitly

              – Lithilion
              Dec 11 '18 at 13:07














            0












            0








            0







            I say it's situational. If your site only serves API, or is a backend content or static file server, where it is very unlikely that your typical users are going to type your server's address to visit your site or make a bookmark to the page (because this server's address never appears in the address bar), then there is probably no harm that could be caused by closing off port 80 for that server.



            If your site is a new site, with no history of people using your site on HTTP ever and no existing bookmark or if your site does not contain content that people are likely to share using the link, then you may consider closing off port 80.



            For servers that serves your home page, you probably still want to keep port 80 for now, because they are much more likely to be visited by people typing URL into the address bar. Also, if you advertise your page address in physical world (e.g. in physical ads) or in medium where people can't easily click, then you may want to keep port 80.






            share|improve this answer













            I say it's situational. If your site only serves API, or is a backend content or static file server, where it is very unlikely that your typical users are going to type your server's address to visit your site or make a bookmark to the page (because this server's address never appears in the address bar), then there is probably no harm that could be caused by closing off port 80 for that server.



            If your site is a new site, with no history of people using your site on HTTP ever and no existing bookmark or if your site does not contain content that people are likely to share using the link, then you may consider closing off port 80.



            For servers that serves your home page, you probably still want to keep port 80 for now, because they are much more likely to be visited by people typing URL into the address bar. Also, if you advertise your page address in physical world (e.g. in physical ads) or in medium where people can't easily click, then you may want to keep port 80.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Dec 11 '18 at 10:54









            Lie RyanLie Ryan

            23.6k35077




            23.6k35077













            • Even if your site is completely new, browsers still try port 80 first and get redirected to port 443. So if you close port 80 the user has to type https://... explicitly

              – Lithilion
              Dec 11 '18 at 13:07



















            • Even if your site is completely new, browsers still try port 80 first and get redirected to port 443. So if you close port 80 the user has to type https://... explicitly

              – Lithilion
              Dec 11 '18 at 13:07

















            Even if your site is completely new, browsers still try port 80 first and get redirected to port 443. So if you close port 80 the user has to type https://... explicitly

            – Lithilion
            Dec 11 '18 at 13:07





            Even if your site is completely new, browsers still try port 80 first and get redirected to port 443. So if you close port 80 the user has to type https://... explicitly

            – Lithilion
            Dec 11 '18 at 13:07


















            draft saved

            draft discarded




















































            Thanks for contributing an answer to Information Security Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f198263%2fshould-i-close-port-80-forever-and-ever-since-the-2018-google-indicated-web-secu%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            "Incorrect syntax near the keyword 'ON'. (on update cascade, on delete cascade,)

            Alcedinidae

            RAC Tourist Trophy