5 ms·

I feel like I'm going to be denounced as a heretic, but here goes: I don't care about HTTPS for localhost When developing locally I'll aim to run without HTTPS

I feel like I'm going to be denounced as a heretic, but here goes: I don't care about HTTPS for localhost When developing locally I'll aim to run without HTTPS / HSTS etc - whilst I'm generally fairly passionate about narrowing the gap between local development and your deployed setup, using HTTPS locally often results in hours of yak shaving. There. I said it.

wonnage 4y ago
Lots of stuff like service workers will only work over https
- magicalist 4y ago
  localhost is considered a secure context by browsers so service workers will work from there even without https.
  - eternityforest 4y ago
    I always worry someone is going to take this away, but it seems they haven't yet, and all is well so far.
    - bugmen0t 4y ago
      localhost is in the Secure Context specification. It won’t be taken away.
      - TedDoesntTalk 4y ago
        Specifications can change.
  - d1sxeyes 4y ago
    Although this is true, it's also true that not all 'secure' functionality is enabled for localhost without HTTPS. One such example is secure cookies. There's a longer list here: https://web.dev/when-to-use-local-https/ https://web.dev/when-to-use-local-https/
    - bawolff 4y ago
      The cookie one is the only semi-legit one. And it would be kind of weird that setting the https only flag wouldnt mean what it says. Everything else on that list is you can't test https without https. How could you possibly test mixed content without using https? Http/2 is so tied to TLS that the insecure version that nobody has implemented isn't really the same thing. Etc
      - d1sxeyes 4y ago
        You’re right. But my point was just that although localhost is a secure origin, there are still differences between localhost and sites loaded over HTTPS.
  - gernb 4y ago
    Except I'm trying to debug a mobile webpage so it's not localhost
johnchristopher 4y ago
I did the yak shaving and I am glad I did. I only needed to inject my own CA into Firefox/Chrome and my self signed certificates now works like any other, no fiddling with about:config, no websocket mismatches or app complaining of not running on https. I can even curl and all that since I added this CA to my machine. edit: I only self sign localhost subdomains (app1.localhost, www.site1.localhost, etc.) and each project has its own self signed certificate (by the same CA) with needed domains (usually traefik.localhost, www.site.localhost, api.site.localhost, etc.). localhost becomes basically my presonnal tld.
- midasuni 4y ago
  And now any security mishap with your CA compromises your entire browser because you can’t just trust a custom root certificate for “*.my stuff.com” without trusting for mybank.com
  - CGamesPlay 4y ago
    That’s a small phish to spear! And if the CA very is kept on local host, compromising it means you’ve already compromised my system.
  - jeroenhd 4y ago
    If you're that much of a target, you'll find your devices hacked soon enough regardless. I can't speak about your threat model, but "exfiltrating my private CA keys to phish my browser" isn't really something I worry about in practice. For those still checking certificate validity, Firefox will warn you that the certificate used is not in the system database when you click the little lock in the address bar. That said, I'd absolutely love a system where I could restrict my private CA to certain domains.
    - iso1210 4y ago
      You can use name constraints on the CA, but they are a bit hit and miss when it comes to client support. For a local CA with the CA only on one machine you're perhaps OK if you are careful, but once you share the server with a couple of collegues you are potentially into a world of hurt. On OSX you can choose "Always Trust" or "Never Trust" for various purposes (code signing, SSL, EAP, etc). Why can't I have "Ask first time", or "Trust only for specific domains" Same with built in ones. That "Hong Kong Post" root CA raises some eyebrows with me, I'd love to set that to "Ask first time" on it.
draw_down 4y ago
Well sure, it’s localhost. Transport security is ridiculous overkill in that case. The benefit of doing it is eliminating one more variable between dev and other environments. One may certainly decide that benefit is not worth jumping through too many hoops, but in any case the point of doing it is not the actual TLS. At this point browsers have all sorts of behavioral differences between secure and insecure, so you’re kinda just choosing which poison to drink: “wow this setup is a pain” vs “why does this work locally but not in staging”
01acheru 4y ago
I was in your camp for long but after getting burned once I decided to change my dev env to be as close as possible to a production env. It just takes caddy, a domain you own so you can get certificates via DNS challenge and point those domains to 127.0.0.x in your hosts file. It is not a big challenge and it is worth it once you finish setting it up.
- usrn 4y ago
  Localhost shouldn't look like production. You should have a remote QA environment for testing deployments etc that looks as close to production as possible. Ideally other people should depend on it for testing their software so you have motivation not to break it.
  - gregoriol 4y ago
    Testing is great, but developing with the same characteristics is important: some behaviours are different when you use https.
  - 01acheru 4y ago
    Your local environment is not the same as localhost. Having your dev environment set up like a production env from this point of view doesn't mean you don't have a remote test env, it means you can debug stuff that only break on that test env or even better that you finish your work without that problem even showing up.
  - Spivak 4y ago
    This logic makes no sense because surely you want to catch bugs as early in the process as possible and the more your local environment looks like qa looks like prod the fewer issues you’ll run into when running your app in a different environment. Why would you wait for your development cycle to slow down from seconds to minutes to catch problems that could be caught beforehand?

wonnage 4y ago

Lots of stuff like service workers will only work over https

magicalist 4y ago
localhost is considered a secure context by browsers so service workers will work from there even without https.
- eternityforest 4y ago
  I always worry someone is going to take this away, but it seems they haven't yet, and all is well so far.
  - bugmen0t 4y ago
    localhost is in the Secure Context specification. It won’t be taken away.
    - TedDoesntTalk 4y ago
      Specifications can change.
- d1sxeyes 4y ago
  Although this is true, it's also true that not all 'secure' functionality is enabled for localhost without HTTPS. One such example is secure cookies. There's a longer list here: https://web.dev/when-to-use-local-https/ https://web.dev/when-to-use-local-https/
  - bawolff 4y ago
    The cookie one is the only semi-legit one. And it would be kind of weird that setting the https only flag wouldnt mean what it says. Everything else on that list is you can't test https without https. How could you possibly test mixed content without using https? Http/2 is so tied to TLS that the insecure version that nobody has implemented isn't really the same thing. Etc
    - d1sxeyes 4y ago
      You’re right. But my point was just that although localhost is a secure origin, there are still differences between localhost and sites loaded over HTTPS.
- gernb 4y ago
  Except I'm trying to debug a mobile webpage so it's not localhost

johnchristopher 4y ago

I did the yak shaving and I am glad I did. I only needed to inject my own CA into Firefox/Chrome and my self signed certificates now works like any other, no fiddling with about:config, no websocket mismatches or app complaining of not running on https. I can even curl and all that since I added this CA to my machine. edit: I only self sign localhost subdomains (app1.localhost, www.site1.localhost, etc.) and each project has its own self signed certificate (by the same CA) with needed domains (usually traefik.localhost, www.site.localhost, api.site.localhost, etc.). localhost becomes basically my presonnal tld.

midasuni 4y ago
And now any security mishap with your CA compromises your entire browser because you can’t just trust a custom root certificate for “*.my stuff.com” without trusting for mybank.com
- CGamesPlay 4y ago
  That’s a small phish to spear! And if the CA very is kept on local host, compromising it means you’ve already compromised my system.
- jeroenhd 4y ago
  If you're that much of a target, you'll find your devices hacked soon enough regardless. I can't speak about your threat model, but "exfiltrating my private CA keys to phish my browser" isn't really something I worry about in practice. For those still checking certificate validity, Firefox will warn you that the certificate used is not in the system database when you click the little lock in the address bar. That said, I'd absolutely love a system where I could restrict my private CA to certain domains.
  - iso1210 4y ago
    You can use name constraints on the CA, but they are a bit hit and miss when it comes to client support. For a local CA with the CA only on one machine you're perhaps OK if you are careful, but once you share the server with a couple of collegues you are potentially into a world of hurt. On OSX you can choose "Always Trust" or "Never Trust" for various purposes (code signing, SSL, EAP, etc). Why can't I have "Ask first time", or "Trust only for specific domains" Same with built in ones. That "Hong Kong Post" root CA raises some eyebrows with me, I'd love to set that to "Ask first time" on it.

draw_down 4y ago

Well sure, it’s localhost. Transport security is ridiculous overkill in that case. The benefit of doing it is eliminating one more variable between dev and other environments. One may certainly decide that benefit is not worth jumping through too many hoops, but in any case the point of doing it is not the actual TLS. At this point browsers have all sorts of behavioral differences between secure and insecure, so you’re kinda just choosing which poison to drink: “wow this setup is a pain” vs “why does this work locally but not in staging”

01acheru 4y ago

I was in your camp for long but after getting burned once I decided to change my dev env to be as close as possible to a production env. It just takes caddy, a domain you own so you can get certificates via DNS challenge and point those domains to 127.0.0.x in your hosts file. It is not a big challenge and it is worth it once you finish setting it up.

usrn 4y ago
Localhost shouldn't look like production. You should have a remote QA environment for testing deployments etc that looks as close to production as possible. Ideally other people should depend on it for testing their software so you have motivation not to break it.
- gregoriol 4y ago
  Testing is great, but developing with the same characteristics is important: some behaviours are different when you use https.
- 01acheru 4y ago
  Your local environment is not the same as localhost. Having your dev environment set up like a production env from this point of view doesn't mean you don't have a remote test env, it means you can debug stuff that only break on that test env or even better that you finish your work without that problem even showing up.
- Spivak 4y ago
  This logic makes no sense because surely you want to catch bugs as early in the process as possible and the more your local environment looks like qa looks like prod the fewer issues you’ll run into when running your app in a different environment. Why would you wait for your development cycle to slow down from seconds to minutes to catch problems that could be caught beforehand?