Should I close port 80 forever and ever since the 2018 Google-indicated web-security initiatives?
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:
- Each of my web apps has its own OpenSSL certificate I create with Certbot.
- 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
|
show 4 more comments
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:
- Each of my web apps has its own OpenSSL certificate I create with Certbot.
- 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
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 downyour-domain.com
without redirection because the correct name iswww.your-domain.com
?
– Hagen von Eitzen
Nov 23 '18 at 20:22
|
show 4 more comments
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:
- Each of my web apps has its own OpenSSL certificate I create with Certbot.
- 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
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:
- Each of my web apps has its own OpenSSL certificate I create with Certbot.
- 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
tls linux apache ports ubuntu
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 downyour-domain.com
without redirection because the correct name iswww.your-domain.com
?
– Hagen von Eitzen
Nov 23 '18 at 20:22
|
show 4 more comments
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 downyour-domain.com
without redirection because the correct name iswww.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
|
show 4 more comments
5 Answers
5
active
oldest
votes
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.
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
|
show 7 more comments
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.
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
add a comment |
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.
add a comment |
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.
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
add a comment |
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.
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
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
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
|
show 7 more comments
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.
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
|
show 7 more comments
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.
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.
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
|
show 7 more comments
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
|
show 7 more comments
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.
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
add a comment |
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.
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
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
answered Nov 24 '18 at 8:18
JacopoJacopo
1863
1863
add a comment |
add a comment |
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.
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
add a comment |
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.
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
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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.
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
add a comment |
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.
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
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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 iswww.your-domain.com
?– Hagen von Eitzen
Nov 23 '18 at 20:22