Should I use HTTPS on a domain that will only be used for redirection?
Clash Royale CLAN TAG#URR8PPP
If I have a domain, https://www.example.com. It has an SSL certificate for that domain only.
I also want to redirect people who only type example.com in their browser's address bar. Should I secure the second domain https://example.com and why, or HTTP only is enough?
I don't use a wildcard SSL certificate.
tls http
edited Mar 7 at 15:00
Anders
49.7k22143164
asked Mar 6 at 10:39
MichelMichel
19625
add a comment |
If I have a domain, https://www.example.com. It has an SSL certificate for that domain only.
I also want to redirect people who only type example.com in their browser's address bar. Should I secure the second domain https://example.com and why, or HTTP only is enough?
I don't use a wildcard SSL certificate.
tls http
edited Mar 7 at 15:00
Anders
49.7k22143164
asked Mar 6 at 10:39
MichelMichel
19625
1
It's already done but my question is should I secure the non www. What is the best practice.
– Michel
Mar 6 at 12:18
1
@DeanMeehan it's better to read and understand the question before commenting.
– ElmoVanKielmo
Mar 7 at 6:44
2
You should use example.org, example.net or example.com for examples. Other domain names like the one you used are often registered commercial domains.
– Martin
Mar 7 at 11:19
A point which has not yet been mentioned : On Chrome it will redirect you without giving any errors, so aside from the other problems mentioned there there is not an issue. On Safari if you go to the non HTTPS version of the site, it gets muddled up and will give an error saying your certificate is invalid.
– Kyle Wardle
Mar 7 at 14:14
Random note: if you did have *.example.com wildcard cert, it still doesn't cover example.com (unless you include example.com as a SAN, which as I think dana alluded to, at least some CA's will either automatically do that or at least remind you)
– Foon
Mar 7 at 15:15
add a comment |
If I have a domain, https://www.example.com. It has an SSL certificate for that domain only.
I also want to redirect people who only type example.com in their browser's address bar. Should I secure the second domain https://example.com and why, or HTTP only is enough?
I don't use a wildcard SSL certificate.
tls http
edited Mar 7 at 15:00
Anders
49.7k22143164
asked Mar 6 at 10:39
MichelMichel
19625
If I have a domain, https://www.example.com. It has an SSL certificate for that domain only.
I also want to redirect people who only type example.com in their browser's address bar. Should I secure the second domain https://example.com and why, or HTTP only is enough?
I don't use a wildcard SSL certificate.
tls http
tls http
edited Mar 7 at 15:00
Anders
49.7k22143164
asked Mar 6 at 10:39
MichelMichel
19625
edited Mar 7 at 15:00
Anders
49.7k22143164
asked Mar 6 at 10:39
MichelMichel
19625
edited Mar 7 at 15:00
Anders
49.7k22143164
edited Mar 7 at 15:00
Anders
49.7k22143164
edited Mar 7 at 15:00
Anders
49.7k22143164
49.7k22143164
asked Mar 6 at 10:39
MichelMichel
19625
asked Mar 6 at 10:39
MichelMichel
19625
asked Mar 6 at 10:39
MichelMichel
19625
19625
1
It's already done but my question is should I secure the non www. What is the best practice.
– Michel
Mar 6 at 12:18
1
@DeanMeehan it's better to read and understand the question before commenting.
– ElmoVanKielmo
Mar 7 at 6:44
2
You should use example.org, example.net or example.com for examples. Other domain names like the one you used are often registered commercial domains.
– Martin
Mar 7 at 11:19
A point which has not yet been mentioned : On Chrome it will redirect you without giving any errors, so aside from the other problems mentioned there there is not an issue. On Safari if you go to the non HTTPS version of the site, it gets muddled up and will give an error saying your certificate is invalid.
– Kyle Wardle
Mar 7 at 14:14
Random note: if you did have *.example.com wildcard cert, it still doesn't cover example.com (unless you include example.com as a SAN, which as I think dana alluded to, at least some CA's will either automatically do that or at least remind you)
– Foon
Mar 7 at 15:15
add a comment |
1
It's already done but my question is should I secure the non www. What is the best practice.
– Michel
Mar 6 at 12:18
1
@DeanMeehan it's better to read and understand the question before commenting.
– ElmoVanKielmo
Mar 7 at 6:44
2
You should use example.org, example.net or example.com for examples. Other domain names like the one you used are often registered commercial domains.
– Martin
Mar 7 at 11:19
A point which has not yet been mentioned : On Chrome it will redirect you without giving any errors, so aside from the other problems mentioned there there is not an issue. On Safari if you go to the non HTTPS version of the site, it gets muddled up and will give an error saying your certificate is invalid.
– Kyle Wardle
Mar 7 at 14:14
Random note: if you did have *.example.com wildcard cert, it still doesn't cover example.com (unless you include example.com as a SAN, which as I think dana alluded to, at least some CA's will either automatically do that or at least remind you)
– Foon
Mar 7 at 15:15
1
1
It's already done but my question is should I secure the non www. What is the best practice.
– Michel
Mar 6 at 12:18
It's already done but my question is should I secure the non www. What is the best practice.
– Michel
Mar 6 at 12:18
1
1
@DeanMeehan it's better to read and understand the question before commenting.
– ElmoVanKielmo
Mar 7 at 6:44
@DeanMeehan it's better to read and understand the question before commenting.
– ElmoVanKielmo
Mar 7 at 6:44
2
2
You should use example.org, example.net or example.com for examples. Other domain names like the one you used are often registered commercial domains.
– Martin
Mar 7 at 11:19
You should use example.org, example.net or example.com for examples. Other domain names like the one you used are often registered commercial domains.
– Martin
Mar 7 at 11:19
A point which has not yet been mentioned : On Chrome it will redirect you without giving any errors, so aside from the other problems mentioned there there is not an issue. On Safari if you go to the non HTTPS version of the site, it gets muddled up and will give an error saying your certificate is invalid.
– Kyle Wardle
Mar 7 at 14:14
A point which has not yet been mentioned : On Chrome it will redirect you without giving any errors, so aside from the other problems mentioned there there is not an issue. On Safari if you go to the non HTTPS version of the site, it gets muddled up and will give an error saying your certificate is invalid.
– Kyle Wardle
Mar 7 at 14:14
Random note: if you did have *.example.com wildcard cert, it still doesn't cover example.com (unless you include example.com as a SAN, which as I think dana alluded to, at least some CA's will either automatically do that or at least remind you)
– Foon
Mar 7 at 15:15
Random note: if you did have *.example.com wildcard cert, it still doesn't cover example.com (unless you include example.com as a SAN, which as I think dana alluded to, at least some CA's will either automatically do that or at least remind you)
– Foon
Mar 7 at 15:15
add a comment |
5 Answers
5
active
oldest
votes
If you don't secure example.com and a user visits that site, a man-in-the-middle attacker can manipulate the traffic and keep the user on example.com, where he can intercept all traffic.
It doesn't matter that your version of example.com redirects to https://www.example.com/. The attacker can change this behavior and offer a HTTP version of your site to the user.
edited Mar 7 at 12:04
a CVn
6,48812245
answered Mar 6 at 11:29
SjoerdSjoerd
20.5k94865
13
Yes. The legitimiate behavior ofhttp://mydomain.com/is not relevant since the attacker can modify that behavior with his man-in-the-middle attack.
– Sjoerd
Mar 6 at 13:18
4
But the first call would still be in http before redirecting to https so the man-in-the-middle can still interfere, can't he?
– Michel
Mar 6 at 13:20
25
@Michel you should enable HSTS to solve that. Certificates are free, no reason not to use them!
– Josef
Mar 6 at 14:30
8
@Fax HSTS isn't fully secure if your site isn't on the preload lists, but it's not useless either, because once a client connects without being MITMed, they'll load the correct HSTS policy, and they're no longer vulnerable. Thus, an attacker must catch the client on first connection, or they've lost their opportunity.
– Gordon Davisson
Mar 7 at 17:05
2
@GordonDavisson and further to that, getting yourself on the preload lists is dead easy - no reason not to do that, either, once you've confirmed HTTPS working. hstspreload.org
– ArtOfCode
Mar 7 at 22:20
|
show 3 more comments
If you don't have a certificate for example.com, anyone trying to access that (without the www. part) on HTTPS will get an error, and very likely not a redirection to www.example.com. With browsers pushing HTTPS as default protocol more and more, this will become a growing issue.
Many certificate authorities allow you to add multiple domain names in one certificate request, so you can get one certificate for both example.com and www.example.com.
edited Mar 7 at 12:04
a CVn
6,48812245
answered Mar 6 at 10:44
Teun VinkTeun Vink
5,63922230
6
Are "browsers pushing HTTPS as default protocol"? Does any browser use HTTPS by default when you enter just mydomain.com?
– Sjoerd
Mar 6 at 12:12
6
@Sjoerd: Yes. Brave tries HTTPS first by default, and many users of other browsers have installed the HTTPS Everywhere extension (eff.org/https-everywhere).
– malexdev
Mar 6 at 20:07
8
@malexdev From what I understand, HTTPS everywhere does not make your browser use HTTPS by default on all sites, despite what its name says. It simply has a whitelist of websites that are redirected to HTTPS. It does nothing to all other sites.
– Federico Poloni
Mar 6 at 23:02
3
@FedericoPoloni EFF's HTTPS Everywhere can be set to force all connections to be made using HTTPS, even when one attempts to use HTTP. My experience is that unless one uses only "big name" sites, that mode unfortunately has a tendency to break more than it helps.
– a CVn
Mar 7 at 12:06
add a comment |
Yes, you should.
In your scenario, the user types the name of your domain into their browser's address bar. No protocol, no www., just example.com. Most browsers will respond by first trying to connect to http://example.com. Now an attacker has the opportunity to interfere with this request and/or the response - preventing any redirect from occurring, or redirecting the user to the wrong destination, or any other bad behaviour.
Simply supporting HTTPS on the base domain doesn't help with this, since the browser will still connect over HTTP first, and the attacker controls what happens from that point on. (Although it does have the minor advantage of providing a better experience for those rare users who type https://example.com into their browsers).
The only way to truly avoid the problem is if, when the user types example.com, the browser immediately connects over HTTPS, without waiting for a redirect. This can be achieved (in most browsers) by getting your domain onto the HSTS preload list. The requirements for adding a domain to the preload list imply that the base domain must be available over HTTPS (you can only submit the base domain for inclusion, and that's what will be checked for the first two requirements; also, the HSTS header as specified in the fourth requirement is only valid over HTTPS).
So, the answer to your question is yes - you should secure the base domain - but you should also consider fulfilling the other requirements and adding the domain to the preload list.
answered Mar 7 at 13:06
John MorahanJohn Morahan
1,511179
Nice point on the HSTS, it actually enforces browser redirection before any result is returned to the user. We can actually check the Chromium's preloaded list in this .json.
– CPHPython
Mar 8 at 10:42
add a comment |
If you have enabled SSL certificate of RapidSSL, GeoTrust, Thawte then you have no need to worry about your domain example.com because they secure both www and non www version of the domain name such as example.com & www.example.com
But yes if you need to keep www domain www.example.com as your preferred domain then you must have to redirect your non www domain example.com using 301 redirect. Same query's solution given in this topic different ssl certificate for www and non www if you are still confused.
edited Mar 7 at 12:05
a CVn
6,48812245
answered Mar 7 at 5:54
DanaDana
213
3
The certificate may cover both the bare domain and the www subdomain, but it doesn't actually secure both unless it's installed correctly.
– TRiG
Mar 7 at 10:02
add a comment |
If you will be redirecting with some information in the URL to the destination domain
then be ware of then there is concern for security
- Clear Text Credentials(https://www.nmmapper.com/st/exploitdetails/44545/39709/sickrage-v20180309-clear-text-credentials-http-response/)
You can use Letsencrypt(https://certbot.eff.org/) and get a free certificate for your domain. even if there are for redirect.
answered Mar 6 at 11:18
wangolo joelwangolo joel
171
3
Please include a summary of the link in your answer. What is the security risk?
– Sjoerd
Mar 6 at 11:30
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%2f204833%2fshould-i-use-https-on-a-domain-that-will-only-be-used-for-redirection%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
If you don't secure example.com and a user visits that site, a man-in-the-middle attacker can manipulate the traffic and keep the user on example.com, where he can intercept all traffic.
It doesn't matter that your version of example.com redirects to https://www.example.com/. The attacker can change this behavior and offer a HTTP version of your site to the user.
edited Mar 7 at 12:04
a CVn
6,48812245
answered Mar 6 at 11:29
SjoerdSjoerd
20.5k94865
13
Yes. The legitimiate behavior ofhttp://mydomain.com/is not relevant since the attacker can modify that behavior with his man-in-the-middle attack.
– Sjoerd
Mar 6 at 13:18
4
But the first call would still be in http before redirecting to https so the man-in-the-middle can still interfere, can't he?
– Michel
Mar 6 at 13:20
25
@Michel you should enable HSTS to solve that. Certificates are free, no reason not to use them!
– Josef
Mar 6 at 14:30
8
@Fax HSTS isn't fully secure if your site isn't on the preload lists, but it's not useless either, because once a client connects without being MITMed, they'll load the correct HSTS policy, and they're no longer vulnerable. Thus, an attacker must catch the client on first connection, or they've lost their opportunity.
– Gordon Davisson
Mar 7 at 17:05
2
@GordonDavisson and further to that, getting yourself on the preload lists is dead easy - no reason not to do that, either, once you've confirmed HTTPS working. hstspreload.org
– ArtOfCode
Mar 7 at 22:20
|
show 3 more comments
If you don't secure example.com and a user visits that site, a man-in-the-middle attacker can manipulate the traffic and keep the user on example.com, where he can intercept all traffic.
It doesn't matter that your version of example.com redirects to https://www.example.com/. The attacker can change this behavior and offer a HTTP version of your site to the user.
edited Mar 7 at 12:04
a CVn
6,48812245
answered Mar 6 at 11:29
SjoerdSjoerd
20.5k94865
13
Yes. The legitimiate behavior ofhttp://mydomain.com/is not relevant since the attacker can modify that behavior with his man-in-the-middle attack.
– Sjoerd
Mar 6 at 13:18
4
But the first call would still be in http before redirecting to https so the man-in-the-middle can still interfere, can't he?
– Michel
Mar 6 at 13:20
25
@Michel you should enable HSTS to solve that. Certificates are free, no reason not to use them!
– Josef
Mar 6 at 14:30
8
@Fax HSTS isn't fully secure if your site isn't on the preload lists, but it's not useless either, because once a client connects without being MITMed, they'll load the correct HSTS policy, and they're no longer vulnerable. Thus, an attacker must catch the client on first connection, or they've lost their opportunity.
– Gordon Davisson
Mar 7 at 17:05
2
@GordonDavisson and further to that, getting yourself on the preload lists is dead easy - no reason not to do that, either, once you've confirmed HTTPS working. hstspreload.org
– ArtOfCode
Mar 7 at 22:20
|
show 3 more comments
If you don't secure example.com and a user visits that site, a man-in-the-middle attacker can manipulate the traffic and keep the user on example.com, where he can intercept all traffic.
It doesn't matter that your version of example.com redirects to https://www.example.com/. The attacker can change this behavior and offer a HTTP version of your site to the user.
edited Mar 7 at 12:04
a CVn
6,48812245
answered Mar 6 at 11:29
SjoerdSjoerd
20.5k94865
If you don't secure example.com and a user visits that site, a man-in-the-middle attacker can manipulate the traffic and keep the user on example.com, where he can intercept all traffic.
It doesn't matter that your version of example.com redirects to https://www.example.com/. The attacker can change this behavior and offer a HTTP version of your site to the user.
edited Mar 7 at 12:04
a CVn
6,48812245
answered Mar 6 at 11:29
SjoerdSjoerd
20.5k94865
edited Mar 7 at 12:04
a CVn
6,48812245
edited Mar 7 at 12:04
a CVn
6,48812245
edited Mar 7 at 12:04
a CVn
6,48812245
6,48812245
answered Mar 6 at 11:29
SjoerdSjoerd
20.5k94865
answered Mar 6 at 11:29
SjoerdSjoerd
20.5k94865
answered Mar 6 at 11:29
SjoerdSjoerd
20.5k94865
20.5k94865
13
Yes. The legitimiate behavior ofhttp://mydomain.com/is not relevant since the attacker can modify that behavior with his man-in-the-middle attack.
– Sjoerd
Mar 6 at 13:18
4
But the first call would still be in http before redirecting to https so the man-in-the-middle can still interfere, can't he?
– Michel
Mar 6 at 13:20
25
@Michel you should enable HSTS to solve that. Certificates are free, no reason not to use them!
– Josef
Mar 6 at 14:30
8
@Fax HSTS isn't fully secure if your site isn't on the preload lists, but it's not useless either, because once a client connects without being MITMed, they'll load the correct HSTS policy, and they're no longer vulnerable. Thus, an attacker must catch the client on first connection, or they've lost their opportunity.
– Gordon Davisson
Mar 7 at 17:05
2
@GordonDavisson and further to that, getting yourself on the preload lists is dead easy - no reason not to do that, either, once you've confirmed HTTPS working. hstspreload.org
– ArtOfCode
Mar 7 at 22:20
|
show 3 more comments
13
Yes. The legitimiate behavior ofhttp://mydomain.com/is not relevant since the attacker can modify that behavior with his man-in-the-middle attack.
– Sjoerd
Mar 6 at 13:18
4
But the first call would still be in http before redirecting to https so the man-in-the-middle can still interfere, can't he?
– Michel
Mar 6 at 13:20
25
@Michel you should enable HSTS to solve that. Certificates are free, no reason not to use them!
– Josef
Mar 6 at 14:30
8
@Fax HSTS isn't fully secure if your site isn't on the preload lists, but it's not useless either, because once a client connects without being MITMed, they'll load the correct HSTS policy, and they're no longer vulnerable. Thus, an attacker must catch the client on first connection, or they've lost their opportunity.
– Gordon Davisson
Mar 7 at 17:05
2
@GordonDavisson and further to that, getting yourself on the preload lists is dead easy - no reason not to do that, either, once you've confirmed HTTPS working. hstspreload.org
– ArtOfCode
Mar 7 at 22:20
13
13
Yes. The legitimiate behavior of
http://mydomain.com/ is not relevant since the attacker can modify that behavior with his man-in-the-middle attack.– Sjoerd
Mar 6 at 13:18
Yes. The legitimiate behavior of
http://mydomain.com/ is not relevant since the attacker can modify that behavior with his man-in-the-middle attack.– Sjoerd
Mar 6 at 13:18
4
4
But the first call would still be in http before redirecting to https so the man-in-the-middle can still interfere, can't he?
– Michel
Mar 6 at 13:20
But the first call would still be in http before redirecting to https so the man-in-the-middle can still interfere, can't he?
– Michel
Mar 6 at 13:20
25
25
@Michel you should enable HSTS to solve that. Certificates are free, no reason not to use them!
– Josef
Mar 6 at 14:30
@Michel you should enable HSTS to solve that. Certificates are free, no reason not to use them!
– Josef
Mar 6 at 14:30
8
8
@Fax HSTS isn't fully secure if your site isn't on the preload lists, but it's not useless either, because once a client connects without being MITMed, they'll load the correct HSTS policy, and they're no longer vulnerable. Thus, an attacker must catch the client on first connection, or they've lost their opportunity.
– Gordon Davisson
Mar 7 at 17:05
@Fax HSTS isn't fully secure if your site isn't on the preload lists, but it's not useless either, because once a client connects without being MITMed, they'll load the correct HSTS policy, and they're no longer vulnerable. Thus, an attacker must catch the client on first connection, or they've lost their opportunity.
– Gordon Davisson
Mar 7 at 17:05
2
2
@GordonDavisson and further to that, getting yourself on the preload lists is dead easy - no reason not to do that, either, once you've confirmed HTTPS working. hstspreload.org
– ArtOfCode
Mar 7 at 22:20
@GordonDavisson and further to that, getting yourself on the preload lists is dead easy - no reason not to do that, either, once you've confirmed HTTPS working. hstspreload.org
– ArtOfCode
Mar 7 at 22:20
|
show 3 more comments
If you don't have a certificate for example.com, anyone trying to access that (without the www. part) on HTTPS will get an error, and very likely not a redirection to www.example.com. With browsers pushing HTTPS as default protocol more and more, this will become a growing issue.
Many certificate authorities allow you to add multiple domain names in one certificate request, so you can get one certificate for both example.com and www.example.com.
edited Mar 7 at 12:04
a CVn
6,48812245
answered Mar 6 at 10:44
Teun VinkTeun Vink
5,63922230
6
Are "browsers pushing HTTPS as default protocol"? Does any browser use HTTPS by default when you enter just mydomain.com?
– Sjoerd
Mar 6 at 12:12
6
@Sjoerd: Yes. Brave tries HTTPS first by default, and many users of other browsers have installed the HTTPS Everywhere extension (eff.org/https-everywhere).
– malexdev
Mar 6 at 20:07
8
@malexdev From what I understand, HTTPS everywhere does not make your browser use HTTPS by default on all sites, despite what its name says. It simply has a whitelist of websites that are redirected to HTTPS. It does nothing to all other sites.
– Federico Poloni
Mar 6 at 23:02
3
@FedericoPoloni EFF's HTTPS Everywhere can be set to force all connections to be made using HTTPS, even when one attempts to use HTTP. My experience is that unless one uses only "big name" sites, that mode unfortunately has a tendency to break more than it helps.
– a CVn
Mar 7 at 12:06
add a comment |
If you don't have a certificate for example.com, anyone trying to access that (without the www. part) on HTTPS will get an error, and very likely not a redirection to www.example.com. With browsers pushing HTTPS as default protocol more and more, this will become a growing issue.
Many certificate authorities allow you to add multiple domain names in one certificate request, so you can get one certificate for both example.com and www.example.com.
edited Mar 7 at 12:04
a CVn
6,48812245
answered Mar 6 at 10:44
Teun VinkTeun Vink
5,63922230
6
Are "browsers pushing HTTPS as default protocol"? Does any browser use HTTPS by default when you enter just mydomain.com?
– Sjoerd
Mar 6 at 12:12
6
@Sjoerd: Yes. Brave tries HTTPS first by default, and many users of other browsers have installed the HTTPS Everywhere extension (eff.org/https-everywhere).
– malexdev
Mar 6 at 20:07
8
@malexdev From what I understand, HTTPS everywhere does not make your browser use HTTPS by default on all sites, despite what its name says. It simply has a whitelist of websites that are redirected to HTTPS. It does nothing to all other sites.
– Federico Poloni
Mar 6 at 23:02
3
@FedericoPoloni EFF's HTTPS Everywhere can be set to force all connections to be made using HTTPS, even when one attempts to use HTTP. My experience is that unless one uses only "big name" sites, that mode unfortunately has a tendency to break more than it helps.
– a CVn
Mar 7 at 12:06
add a comment |
If you don't have a certificate for example.com, anyone trying to access that (without the www. part) on HTTPS will get an error, and very likely not a redirection to www.example.com. With browsers pushing HTTPS as default protocol more and more, this will become a growing issue.
Many certificate authorities allow you to add multiple domain names in one certificate request, so you can get one certificate for both example.com and www.example.com.
edited Mar 7 at 12:04
a CVn
6,48812245
answered Mar 6 at 10:44
Teun VinkTeun Vink
5,63922230
If you don't have a certificate for example.com, anyone trying to access that (without the www. part) on HTTPS will get an error, and very likely not a redirection to www.example.com. With browsers pushing HTTPS as default protocol more and more, this will become a growing issue.
Many certificate authorities allow you to add multiple domain names in one certificate request, so you can get one certificate for both example.com and www.example.com.
edited Mar 7 at 12:04
a CVn
6,48812245
answered Mar 6 at 10:44
Teun VinkTeun Vink
5,63922230
edited Mar 7 at 12:04
a CVn
6,48812245
edited Mar 7 at 12:04
a CVn
6,48812245
edited Mar 7 at 12:04
a CVn
6,48812245
6,48812245
answered Mar 6 at 10:44
Teun VinkTeun Vink
5,63922230
answered Mar 6 at 10:44
Teun VinkTeun Vink
5,63922230
answered Mar 6 at 10:44
Teun VinkTeun Vink
5,63922230
5,63922230
6
Are "browsers pushing HTTPS as default protocol"? Does any browser use HTTPS by default when you enter just mydomain.com?
– Sjoerd
Mar 6 at 12:12
6
@Sjoerd: Yes. Brave tries HTTPS first by default, and many users of other browsers have installed the HTTPS Everywhere extension (eff.org/https-everywhere).
– malexdev
Mar 6 at 20:07
8
@malexdev From what I understand, HTTPS everywhere does not make your browser use HTTPS by default on all sites, despite what its name says. It simply has a whitelist of websites that are redirected to HTTPS. It does nothing to all other sites.
– Federico Poloni
Mar 6 at 23:02
3
@FedericoPoloni EFF's HTTPS Everywhere can be set to force all connections to be made using HTTPS, even when one attempts to use HTTP. My experience is that unless one uses only "big name" sites, that mode unfortunately has a tendency to break more than it helps.
– a CVn
Mar 7 at 12:06
add a comment |
6
Are "browsers pushing HTTPS as default protocol"? Does any browser use HTTPS by default when you enter just mydomain.com?
– Sjoerd
Mar 6 at 12:12
6
@Sjoerd: Yes. Brave tries HTTPS first by default, and many users of other browsers have installed the HTTPS Everywhere extension (eff.org/https-everywhere).
– malexdev
Mar 6 at 20:07
8
@malexdev From what I understand, HTTPS everywhere does not make your browser use HTTPS by default on all sites, despite what its name says. It simply has a whitelist of websites that are redirected to HTTPS. It does nothing to all other sites.
– Federico Poloni
Mar 6 at 23:02
3
@FedericoPoloni EFF's HTTPS Everywhere can be set to force all connections to be made using HTTPS, even when one attempts to use HTTP. My experience is that unless one uses only "big name" sites, that mode unfortunately has a tendency to break more than it helps.
– a CVn
Mar 7 at 12:06
6
6
Are "browsers pushing HTTPS as default protocol"? Does any browser use HTTPS by default when you enter just mydomain.com?
– Sjoerd
Mar 6 at 12:12
Are "browsers pushing HTTPS as default protocol"? Does any browser use HTTPS by default when you enter just mydomain.com?
– Sjoerd
Mar 6 at 12:12
6
6
@Sjoerd: Yes. Brave tries HTTPS first by default, and many users of other browsers have installed the HTTPS Everywhere extension (eff.org/https-everywhere).
– malexdev
Mar 6 at 20:07
@Sjoerd: Yes. Brave tries HTTPS first by default, and many users of other browsers have installed the HTTPS Everywhere extension (eff.org/https-everywhere).
– malexdev
Mar 6 at 20:07
8
8
@malexdev From what I understand, HTTPS everywhere does not make your browser use HTTPS by default on all sites, despite what its name says. It simply has a whitelist of websites that are redirected to HTTPS. It does nothing to all other sites.
– Federico Poloni
Mar 6 at 23:02
@malexdev From what I understand, HTTPS everywhere does not make your browser use HTTPS by default on all sites, despite what its name says. It simply has a whitelist of websites that are redirected to HTTPS. It does nothing to all other sites.
– Federico Poloni
Mar 6 at 23:02
3
3
@FedericoPoloni EFF's HTTPS Everywhere can be set to force all connections to be made using HTTPS, even when one attempts to use HTTP. My experience is that unless one uses only "big name" sites, that mode unfortunately has a tendency to break more than it helps.
– a CVn
Mar 7 at 12:06
@FedericoPoloni EFF's HTTPS Everywhere can be set to force all connections to be made using HTTPS, even when one attempts to use HTTP. My experience is that unless one uses only "big name" sites, that mode unfortunately has a tendency to break more than it helps.
– a CVn
Mar 7 at 12:06
add a comment |
Yes, you should.
In your scenario, the user types the name of your domain into their browser's address bar. No protocol, no www., just example.com. Most browsers will respond by first trying to connect to http://example.com. Now an attacker has the opportunity to interfere with this request and/or the response - preventing any redirect from occurring, or redirecting the user to the wrong destination, or any other bad behaviour.
Simply supporting HTTPS on the base domain doesn't help with this, since the browser will still connect over HTTP first, and the attacker controls what happens from that point on. (Although it does have the minor advantage of providing a better experience for those rare users who type https://example.com into their browsers).
The only way to truly avoid the problem is if, when the user types example.com, the browser immediately connects over HTTPS, without waiting for a redirect. This can be achieved (in most browsers) by getting your domain onto the HSTS preload list. The requirements for adding a domain to the preload list imply that the base domain must be available over HTTPS (you can only submit the base domain for inclusion, and that's what will be checked for the first two requirements; also, the HSTS header as specified in the fourth requirement is only valid over HTTPS).
So, the answer to your question is yes - you should secure the base domain - but you should also consider fulfilling the other requirements and adding the domain to the preload list.
answered Mar 7 at 13:06
John MorahanJohn Morahan
1,511179
Nice point on the HSTS, it actually enforces browser redirection before any result is returned to the user. We can actually check the Chromium's preloaded list in this .json.
– CPHPython
Mar 8 at 10:42
add a comment |
Yes, you should.
In your scenario, the user types the name of your domain into their browser's address bar. No protocol, no www., just example.com. Most browsers will respond by first trying to connect to http://example.com. Now an attacker has the opportunity to interfere with this request and/or the response - preventing any redirect from occurring, or redirecting the user to the wrong destination, or any other bad behaviour.
Simply supporting HTTPS on the base domain doesn't help with this, since the browser will still connect over HTTP first, and the attacker controls what happens from that point on. (Although it does have the minor advantage of providing a better experience for those rare users who type https://example.com into their browsers).
The only way to truly avoid the problem is if, when the user types example.com, the browser immediately connects over HTTPS, without waiting for a redirect. This can be achieved (in most browsers) by getting your domain onto the HSTS preload list. The requirements for adding a domain to the preload list imply that the base domain must be available over HTTPS (you can only submit the base domain for inclusion, and that's what will be checked for the first two requirements; also, the HSTS header as specified in the fourth requirement is only valid over HTTPS).
So, the answer to your question is yes - you should secure the base domain - but you should also consider fulfilling the other requirements and adding the domain to the preload list.
answered Mar 7 at 13:06
John MorahanJohn Morahan
1,511179
Nice point on the HSTS, it actually enforces browser redirection before any result is returned to the user. We can actually check the Chromium's preloaded list in this .json.
– CPHPython
Mar 8 at 10:42
add a comment |
Yes, you should.
In your scenario, the user types the name of your domain into their browser's address bar. No protocol, no www., just example.com. Most browsers will respond by first trying to connect to http://example.com. Now an attacker has the opportunity to interfere with this request and/or the response - preventing any redirect from occurring, or redirecting the user to the wrong destination, or any other bad behaviour.
Simply supporting HTTPS on the base domain doesn't help with this, since the browser will still connect over HTTP first, and the attacker controls what happens from that point on. (Although it does have the minor advantage of providing a better experience for those rare users who type https://example.com into their browsers).
The only way to truly avoid the problem is if, when the user types example.com, the browser immediately connects over HTTPS, without waiting for a redirect. This can be achieved (in most browsers) by getting your domain onto the HSTS preload list. The requirements for adding a domain to the preload list imply that the base domain must be available over HTTPS (you can only submit the base domain for inclusion, and that's what will be checked for the first two requirements; also, the HSTS header as specified in the fourth requirement is only valid over HTTPS).
So, the answer to your question is yes - you should secure the base domain - but you should also consider fulfilling the other requirements and adding the domain to the preload list.
answered Mar 7 at 13:06
John MorahanJohn Morahan
1,511179
Yes, you should.
In your scenario, the user types the name of your domain into their browser's address bar. No protocol, no www., just example.com. Most browsers will respond by first trying to connect to http://example.com. Now an attacker has the opportunity to interfere with this request and/or the response - preventing any redirect from occurring, or redirecting the user to the wrong destination, or any other bad behaviour.
Simply supporting HTTPS on the base domain doesn't help with this, since the browser will still connect over HTTP first, and the attacker controls what happens from that point on. (Although it does have the minor advantage of providing a better experience for those rare users who type https://example.com into their browsers).
The only way to truly avoid the problem is if, when the user types example.com, the browser immediately connects over HTTPS, without waiting for a redirect. This can be achieved (in most browsers) by getting your domain onto the HSTS preload list. The requirements for adding a domain to the preload list imply that the base domain must be available over HTTPS (you can only submit the base domain for inclusion, and that's what will be checked for the first two requirements; also, the HSTS header as specified in the fourth requirement is only valid over HTTPS).
So, the answer to your question is yes - you should secure the base domain - but you should also consider fulfilling the other requirements and adding the domain to the preload list.
answered Mar 7 at 13:06
John MorahanJohn Morahan
1,511179
answered Mar 7 at 13:06
John MorahanJohn Morahan
1,511179
answered Mar 7 at 13:06
John MorahanJohn Morahan
1,511179
answered Mar 7 at 13:06
John MorahanJohn Morahan
1,511179
1,511179
Nice point on the HSTS, it actually enforces browser redirection before any result is returned to the user. We can actually check the Chromium's preloaded list in this .json.
– CPHPython
Mar 8 at 10:42
add a comment |
Nice point on the HSTS, it actually enforces browser redirection before any result is returned to the user. We can actually check the Chromium's preloaded list in this .json.
– CPHPython
Mar 8 at 10:42
Nice point on the HSTS, it actually enforces browser redirection before any result is returned to the user. We can actually check the Chromium's preloaded list in this .json.
– CPHPython
Mar 8 at 10:42
Nice point on the HSTS, it actually enforces browser redirection before any result is returned to the user. We can actually check the Chromium's preloaded list in this .json.
– CPHPython
Mar 8 at 10:42
add a comment |
If you have enabled SSL certificate of RapidSSL, GeoTrust, Thawte then you have no need to worry about your domain example.com because they secure both www and non www version of the domain name such as example.com & www.example.com
But yes if you need to keep www domain www.example.com as your preferred domain then you must have to redirect your non www domain example.com using 301 redirect. Same query's solution given in this topic different ssl certificate for www and non www if you are still confused.
edited Mar 7 at 12:05
a CVn
6,48812245
answered Mar 7 at 5:54
DanaDana
213
3
The certificate may cover both the bare domain and the www subdomain, but it doesn't actually secure both unless it's installed correctly.
– TRiG
Mar 7 at 10:02
add a comment |
If you have enabled SSL certificate of RapidSSL, GeoTrust, Thawte then you have no need to worry about your domain example.com because they secure both www and non www version of the domain name such as example.com & www.example.com
But yes if you need to keep www domain www.example.com as your preferred domain then you must have to redirect your non www domain example.com using 301 redirect. Same query's solution given in this topic different ssl certificate for www and non www if you are still confused.
edited Mar 7 at 12:05
a CVn
6,48812245
answered Mar 7 at 5:54
DanaDana
213
3
The certificate may cover both the bare domain and the www subdomain, but it doesn't actually secure both unless it's installed correctly.
– TRiG
Mar 7 at 10:02
add a comment |
If you have enabled SSL certificate of RapidSSL, GeoTrust, Thawte then you have no need to worry about your domain example.com because they secure both www and non www version of the domain name such as example.com & www.example.com
But yes if you need to keep www domain www.example.com as your preferred domain then you must have to redirect your non www domain example.com using 301 redirect. Same query's solution given in this topic different ssl certificate for www and non www if you are still confused.
edited Mar 7 at 12:05
a CVn
6,48812245
answered Mar 7 at 5:54
DanaDana
213
If you have enabled SSL certificate of RapidSSL, GeoTrust, Thawte then you have no need to worry about your domain example.com because they secure both www and non www version of the domain name such as example.com & www.example.com
But yes if you need to keep www domain www.example.com as your preferred domain then you must have to redirect your non www domain example.com using 301 redirect. Same query's solution given in this topic different ssl certificate for www and non www if you are still confused.
edited Mar 7 at 12:05
a CVn
6,48812245
answered Mar 7 at 5:54
DanaDana
213
edited Mar 7 at 12:05
a CVn
6,48812245
edited Mar 7 at 12:05
a CVn
6,48812245
edited Mar 7 at 12:05
a CVn
6,48812245
6,48812245
answered Mar 7 at 5:54
DanaDana
213
answered Mar 7 at 5:54
DanaDana
213
answered Mar 7 at 5:54
DanaDana
213
213
3
The certificate may cover both the bare domain and the www subdomain, but it doesn't actually secure both unless it's installed correctly.
– TRiG
Mar 7 at 10:02
add a comment |
3
The certificate may cover both the bare domain and the www subdomain, but it doesn't actually secure both unless it's installed correctly.
– TRiG
Mar 7 at 10:02
3
3
The certificate may cover both the bare domain and the www subdomain, but it doesn't actually secure both unless it's installed correctly.
– TRiG
Mar 7 at 10:02
The certificate may cover both the bare domain and the www subdomain, but it doesn't actually secure both unless it's installed correctly.
– TRiG
Mar 7 at 10:02
add a comment |
If you will be redirecting with some information in the URL to the destination domain
then be ware of then there is concern for security
- Clear Text Credentials(https://www.nmmapper.com/st/exploitdetails/44545/39709/sickrage-v20180309-clear-text-credentials-http-response/)
You can use Letsencrypt(https://certbot.eff.org/) and get a free certificate for your domain. even if there are for redirect.
answered Mar 6 at 11:18
wangolo joelwangolo joel
171
3
Please include a summary of the link in your answer. What is the security risk?
– Sjoerd
Mar 6 at 11:30
add a comment |
If you will be redirecting with some information in the URL to the destination domain
then be ware of then there is concern for security
- Clear Text Credentials(https://www.nmmapper.com/st/exploitdetails/44545/39709/sickrage-v20180309-clear-text-credentials-http-response/)
You can use Letsencrypt(https://certbot.eff.org/) and get a free certificate for your domain. even if there are for redirect.
answered Mar 6 at 11:18
wangolo joelwangolo joel
171
3
Please include a summary of the link in your answer. What is the security risk?
– Sjoerd
Mar 6 at 11:30
add a comment |
If you will be redirecting with some information in the URL to the destination domain
then be ware of then there is concern for security
- Clear Text Credentials(https://www.nmmapper.com/st/exploitdetails/44545/39709/sickrage-v20180309-clear-text-credentials-http-response/)
You can use Letsencrypt(https://certbot.eff.org/) and get a free certificate for your domain. even if there are for redirect.
answered Mar 6 at 11:18
wangolo joelwangolo joel
171
If you will be redirecting with some information in the URL to the destination domain
then be ware of then there is concern for security
- Clear Text Credentials(https://www.nmmapper.com/st/exploitdetails/44545/39709/sickrage-v20180309-clear-text-credentials-http-response/)
You can use Letsencrypt(https://certbot.eff.org/) and get a free certificate for your domain. even if there are for redirect.
answered Mar 6 at 11:18
wangolo joelwangolo joel
171
answered Mar 6 at 11:18
wangolo joelwangolo joel
171
answered Mar 6 at 11:18
wangolo joelwangolo joel
171
answered Mar 6 at 11:18
wangolo joelwangolo joel
171
171
3
Please include a summary of the link in your answer. What is the security risk?
– Sjoerd
Mar 6 at 11:30
add a comment |
3
Please include a summary of the link in your answer. What is the security risk?
– Sjoerd
Mar 6 at 11:30
3
3
Please include a summary of the link in your answer. What is the security risk?
– Sjoerd
Mar 6 at 11:30
Please include a summary of the link in your answer. What is the security risk?
– Sjoerd
Mar 6 at 11:30
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%2f204833%2fshould-i-use-https-on-a-domain-that-will-only-be-used-for-redirection%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
1
It's already done but my question is should I secure the non www. What is the best practice.
– Michel
Mar 6 at 12:18
1
@DeanMeehan it's better to read and understand the question before commenting.
– ElmoVanKielmo
Mar 7 at 6:44
2
You should use example.org, example.net or example.com for examples. Other domain names like the one you used are often registered commercial domains.
– Martin
Mar 7 at 11:19
A point which has not yet been mentioned : On Chrome it will redirect you without giving any errors, so aside from the other problems mentioned there there is not an issue. On Safari if you go to the non HTTPS version of the site, it gets muddled up and will give an error saying your certificate is invalid.
– Kyle Wardle
Mar 7 at 14:14
Random note: if you did have *.example.com wildcard cert, it still doesn't cover example.com (unless you include example.com as a SAN, which as I think dana alluded to, at least some CA's will either automatically do that or at least remind you)
– Foon
Mar 7 at 15:15