4 ms·

As a developer I likely won't use this feature much, considering most of our internal development sites are http only. For the general public it might be useful

As a developer I likely won't use this feature much, considering most of our internal development sites are http only. For the general public it might be useful though, especially the auto-upgrade feature, protecting them from the lazy network operators that didn't add a proper auto-redirect.

conradludgate 6y ago
According to another comment, you can still allow certain sites through http, so your Internet dev sites are still fine but the global sites will be blocked by default
- Deukhoofd 6y ago
  Sure, but we have like 50 different internal domains for different customers, so that would get annoying real fast ;)
  - ffpip 6y ago
    Well, you have to specifically enable this feature. So don't enable it.
    - Deukhoofd 6y ago
      Which indeed is why I said I likely will not use the feature above.
    - iso1631 6y ago
      For now. These features tend to migrate from being optional to being default to being default and hard to turn off
  - speedgoose 6y ago
    You could use a self signed certificate.
  - kevincox 6y ago
    I haven't tried out the release UX yet but if it is just a couple of clicks inline when you fist visit this doesn't sound that bad. I would go though it for the added feeling of privacy and security whenever I am on a public connection.
abraxaz 6y ago
Maybe try https://www.eff.org/https-everywhere https://www.eff.org/https-everywhere then.
dspillett 6y ago
> As a developer … most of our internal development sites are http only. As a developer, should you not work against an environment closer to production behaviours? Otherwise you might miss performance issues (due to different caching behaviours between http/https) or other problems until your code is released.
- nickik 6y ago
  Its not always the code you work on. It might be other internal services or sites.
  - dspillett 6y ago
    All our internal services are HTTPS. Then if a new hack is found to weaken wireless protocols we have that extra line of protection. Security in depth. We serve strongly regulated industries and are subject to in-depth audits by clients on occasion, so perhaps my level of paranoia would be less warranted elsewhere. I'd still HTTPS everything though, even if the potential payoff is small because the required effort is too.
    - iso1631 6y ago
      public certificates? Do you use wildcards, or are you unconcerned by leaking information like servernames via CT?
      - dspillett 6y ago
        Public wildcard cert for centrally managed things. Of course only a trusted few have access to the private parts of the certificate that covers centrally managed things. For local dev instances I suggest having a local only meaningless domain and a wildcard off that, If we were using per name certs and name leaking were a significant issue we could instead sign with a local CA and push the signing cert out as trusted to all machines we manage.

conradludgate 6y ago

According to another comment, you can still allow certain sites through http, so your Internet dev sites are still fine but the global sites will be blocked by default

Deukhoofd 6y ago
Sure, but we have like 50 different internal domains for different customers, so that would get annoying real fast ;)
- ffpip 6y ago
  Well, you have to specifically enable this feature. So don't enable it.
  - Deukhoofd 6y ago
    Which indeed is why I said I likely will not use the feature above.
  - iso1631 6y ago
    For now. These features tend to migrate from being optional to being default to being default and hard to turn off
- speedgoose 6y ago
  You could use a self signed certificate.
- kevincox 6y ago
  I haven't tried out the release UX yet but if it is just a couple of clicks inline when you fist visit this doesn't sound that bad. I would go though it for the added feeling of privacy and security whenever I am on a public connection.

abraxaz 6y ago

Maybe try https://www.eff.org/https-everywhere https://www.eff.org/https-everywhere then.

dspillett 6y ago

> As a developer … most of our internal development sites are http only. As a developer, should you not work against an environment closer to production behaviours? Otherwise you might miss performance issues (due to different caching behaviours between http/https) or other problems until your code is released.

nickik 6y ago
Its not always the code you work on. It might be other internal services or sites.
- dspillett 6y ago
  All our internal services are HTTPS. Then if a new hack is found to weaken wireless protocols we have that extra line of protection. Security in depth. We serve strongly regulated industries and are subject to in-depth audits by clients on occasion, so perhaps my level of paranoia would be less warranted elsewhere. I'd still HTTPS everything though, even if the potential payoff is small because the required effort is too.
  - iso1631 6y ago
    public certificates? Do you use wildcards, or are you unconcerned by leaking information like servernames via CT?
    - dspillett 6y ago
      Public wildcard cert for centrally managed things. Of course only a trusted few have access to the private parts of the certificate that covers centrally managed things. For local dev instances I suggest having a local only meaningless domain and a wildcard off that, If we were using per name certs and name leaking were a significant issue we could instead sign with a local CA and push the signing cert out as trusted to all machines we manage.