6 ms·

Worth mentioning https://cipherli.st/ https://cipherli.st/ too. But I think more warning about HSTS is needed, since misconfiguring HSTS will cause the domain t

by serialx 10y ago

Worth mentioning https://cipherli.st/ https://cipherli.st/ too. But I think more warning about HSTS is needed, since misconfiguring HSTS will cause the domain to be inaccessible for long periods.

newman314 10y ago
IMO, too many of these websites recommend includeSubdomains as part of the HSTS stanza right out the gate. Personally, I'd deploy HSTS incrementally and wait until such time there is a majority of subdomains that are TLS capable before deploying includeSubDomains. Otherwise, there could likely be some nasty surprises.
- aianus 10y ago
  You can't get on the HSTS preload list included with browsers without includeSubDomains.
  - newman314 10y ago
    To clarify, most of the customers I deal with are enterprise customers and so as such have many internet facing hostnames/domains/subdomains. Arbitrarily enabling includeSubDomains is going to lead to nasty surprises if there is no prior coordination.
- hunter2_ 10y ago
  > majority I'd argue that all, not most, subdomains must be HTTPS capable (I won't say TLS generally, either; this is only dealing with HTTP). Any that aren't will not be accessible by a user agent that recently (within the max-age) visited the parent domain if it had an HSTS header with that flag.
hannob 10y ago
For HPKP that's true, for HSTS not really. It may just force you to deploy HTTPS and not go back - which some might say is a good thing :-)
mdewinter 10y ago
I'm behind https://cipherli.st https://cipherli.st, together with some friends. IMHO there is no reason not to have HTTPS everywhere, especially now Let's Encrypt exists. I did think and discuss a lot with people on how 'strong' the page is, and if we might want to change that. The page is targeted at sysadmins who I expect to do at least some research before bluntly copy-pasting config files off somewhere, there are enough warnings on the page.
- BinaryIdiot 10y ago
  > IMHO there is no reason not to have HTTPS everywhere, especially now Let's Encrypt exists I don't want to disagree with you but I do. I most certainly agree that HTTPS must be everywhere and it's easier than ever before. Where I disagree comes with less experienced developers. I can write a quick PHP / Rails / Node / whatever web server to show some website real fast, deploy by uploading it to a shared hosting package or something fancier like elastic beanstalk, and it's done and up there. Yes it's on HTTP but it's so easy. Now you want to add HTTPS to it? It's not easy. Let's Encrypt makes some aspects of it easier but until the amount of fiction is similar to the process of deploying HTTP you'll never see HTTPS ubiquity in my opinion.
  - pg_is_a_butt 10y ago
    i use let's encrypt on google app engine... it took less than 5 minutes. google could very easily automate it for everyone, but that removes the direct verification between domain owners and certificate authorities. granted, you're already giving up this control when you host with any 3rd party, but the CAs are being reckless if they encourage it.
  - okket 10y ago
    > Now you want to add HTTPS to it? It's not easy. Try Caddy with automatic HTTPS [0] in reverse proxy mode [1]. [0] https://caddyserver.com/docs/automatic-https https://caddyserver.com/docs/automatic-https [1] https://caddyserver.com/docs/proxy https://caddyserver.com/docs/proxy
    - 10y ago
yeukhon 10y ago
Agree. I started with extremely low max-age like 120 seconds, and once I am comfortable I change to a larger value like 6 months.

by serialx 10y ago

Worth mentioning https://cipherli.st/ https://cipherli.st/ too. But I think more warning about HSTS is needed, since misconfiguring HSTS will cause the domain to be inaccessible for long periods.

newman314 10y ago

IMO, too many of these websites recommend includeSubdomains as part of the HSTS stanza right out the gate. Personally, I'd deploy HSTS incrementally and wait until such time there is a majority of subdomains that are TLS capable before deploying includeSubDomains. Otherwise, there could likely be some nasty surprises.

aianus 10y ago
You can't get on the HSTS preload list included with browsers without includeSubDomains.
- newman314 10y ago
  To clarify, most of the customers I deal with are enterprise customers and so as such have many internet facing hostnames/domains/subdomains. Arbitrarily enabling includeSubDomains is going to lead to nasty surprises if there is no prior coordination.
hunter2_ 10y ago
> majority I'd argue that all, not most, subdomains must be HTTPS capable (I won't say TLS generally, either; this is only dealing with HTTP). Any that aren't will not be accessible by a user agent that recently (within the max-age) visited the parent domain if it had an HSTS header with that flag.

hannob 10y ago

For HPKP that's true, for HSTS not really. It may just force you to deploy HTTPS and not go back - which some might say is a good thing :-)

mdewinter 10y ago

I'm behind https://cipherli.st https://cipherli.st, together with some friends. IMHO there is no reason not to have HTTPS everywhere, especially now Let's Encrypt exists. I did think and discuss a lot with people on how 'strong' the page is, and if we might want to change that. The page is targeted at sysadmins who I expect to do at least some research before bluntly copy-pasting config files off somewhere, there are enough warnings on the page.

BinaryIdiot 10y ago
> IMHO there is no reason not to have HTTPS everywhere, especially now Let's Encrypt exists I don't want to disagree with you but I do. I most certainly agree that HTTPS must be everywhere and it's easier than ever before. Where I disagree comes with less experienced developers. I can write a quick PHP / Rails / Node / whatever web server to show some website real fast, deploy by uploading it to a shared hosting package or something fancier like elastic beanstalk, and it's done and up there. Yes it's on HTTP but it's so easy. Now you want to add HTTPS to it? It's not easy. Let's Encrypt makes some aspects of it easier but until the amount of fiction is similar to the process of deploying HTTP you'll never see HTTPS ubiquity in my opinion.
- pg_is_a_butt 10y ago
  i use let's encrypt on google app engine... it took less than 5 minutes. google could very easily automate it for everyone, but that removes the direct verification between domain owners and certificate authorities. granted, you're already giving up this control when you host with any 3rd party, but the CAs are being reckless if they encourage it.
- okket 10y ago
  > Now you want to add HTTPS to it? It's not easy. Try Caddy with automatic HTTPS [0] in reverse proxy mode [1]. [0] https://caddyserver.com/docs/automatic-https https://caddyserver.com/docs/automatic-https [1] https://caddyserver.com/docs/proxy https://caddyserver.com/docs/proxy
  - 10y ago

yeukhon 10y ago

Agree. I started with extremely low max-age like 120 seconds, and once I am comfortable I change to a larger value like 6 months.