4 ms·

It surprises me how few people dev/test against HTTPS, given that it isn't exactly hard to setup manually (with tools like this making it even easier). Just poi

It surprises me how few people dev/test against HTTPS, given that it isn't exactly hard to setup manually (with tools like this making it even easier). Just point a wildcard DNS entry at 127.0.0.1 or some other useful address if your dev copy is actually not that local, and chuck a web server there acting as a proxy to what-ever apps, with a LetsEncrypt wildcard cert. It isn't zero work, but saves time in the long run as soon as you hit unexpected issues caused by small differences between dev and prod.

zikduruqe 3y ago
You don't even need to mess with a wildcard from Lets Encrypt, just use https://github.com/FiloSottile/mkcert https://github.com/FiloSottile/mkcert
- dspillett 3y ago
  I've always been a bit wary of a local trusted CA, especially with the signing cert on the same dev box as the certificates it signs which is how I've seen things done a lot. It feels like opening up a trust issue that could allow an uncooperative entity to play games with me… Maybe that is just paranoia from the practical jokes played back in CompSci at Uni! Admittedly an external attacker getting close enough to sign a cert using such a CA, in order to trick me into something, means they probably have such high access already that they don't really need the CA to do that or worse, so perhaps it is unnecessary caution.
  - zikduruqe 3y ago
    [flagged]
  - nucleardog 3y ago
    The way I handle this in the dev tooling I put together is to run a totally separate browser profile that (1) trusts the certificate and (2) can only connect to localhost. It also launches with a totally different colour scheme. With chrome, that's something like: google-chrome --user-data-dir="${HOME}/.config/ourlocaldev/google-chrome" --install-autogenerated-theme=85,63,9 --host-rules="MAP * 127.0.0.1, EXCLUDE localhost, EXCLUDE fonts.googleapis.com, EXCLUDE fonts.gstatic.com" --ignore-certificate-errors-spki-list="0oKw9nasIS7qRQD1CYXe5bmi22/mnHjZP++f6G+VM88=" "https://my.dev.thing" This will launch a separate copy of chrome with a fresh/separate profile. It will have a different colour (RGB values set in there) so it's visually distinct when it's running and I don't get the windows mixed up. Any request made from the browser will be rewritten to connect to 127.0.0.1 (except a couple google font domains). The danger if someone got their hands on my local key/cert is basically nil. They would only be able to MITM connections from this one specific browser window to localhost. And that browser is incapable of connecting to anything besides localhost. I can never accidentally open my banking site in there. Also fresh profile so no saved passwords, credit cards, or anything else. (As an added benefit, I don't really need to worry about reconfiguring URLs for projects. If I open "testing.mysite.com" in that browser, it will force the connection to localhost, so I can just run my services at our test URLs and steal configs as-is from the testing environment. Taking it further, I then have a controller set up in k3s/Rancher Desktop that rewrites the service on all annotated ingresses to point to its own service, which runs nginx, which the controller then configures to proxy the requests on to the local service or the actual upstream testing service depending on whether the local container is running. It also configures CoreDNS to point the upstream URLs at the same proxy. End result is that from the browser or anything running in k3s you can hit our testing URLs and it will hit your local container if it's running or fall back to the testing environment if not.) If you want to try the browser thing, you can generate the fingerprint for a certificate with: echo "" | openssl s_client -connect 127.0.0.1:443 -prexit 2>/dev/null | openssl x509 -pubkey -noout -in /dev/stdin | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64
    - djbusby 3y ago
      This is an awesome trick, thanks, I'm copying you.
  - dpkirchner 3y ago
    I figure you could create the CA, have your browser trust it, create and sign your localhost cert, and then nuke the CA private key so no other carts may be signed. It'd be annoying if you need to make a new localhost certificate, but totally manageable.
  - everforward 3y ago
    I think this is primarily FUD down by SSL cert companies. If you have appropriate permissions on the private keys, it would require the same level of access to read the private key as it would for the attacker to create their own CA and install it on your PC. My general rule of thumb is to use private certificates unless a) users interact with it directly, cuz they won't install my cert, or b) financial or other highly sensitive data flows through it. I'm not convinced that commercial CAs are more secure, but for the price of an SSL cert, it's worth it to have it not be my fault if something happens.
- javajosh 3y ago
  You don't even need that. See https://simpatico.io/devops/deploy.sh#generateSelfSignedCert https://simpatico.io/devops/deploy.sh#generateSelfSignedCert() and also #generateRootCA() Then point your server to the output files. If you want, you can also modify `/etc/hosts` to point a "production name" to localhost (something I actually don't do and never wrote a script for). Far fewer moving parts than the OP. (parts of Simpatico uses subtle.crypto and so requires https to run even locally)
afavour 3y ago
> It surprises me how few people dev/test against HTTPS For dev at least it’s mostly because web browsers treat localhost as a special domain that gets the HTTPS treatment even when loaded over HTTP. I have set up local HTTPS certs before now, can’t remember exactly what required it. But I still load most web projects on localhost over HTTP just out of habit.
- hk1337 3y ago
  I've always thought the need for local HTTPS was unnecessary for at least 90% of the projects and brought no real value other than making the developer "feel" better. localhost with HTTP should be sufficient for most things. It's when you start doing stuff like "app.localhost" like what was mentioned in the article which, despite it having "localhost" is not the same as http://localhost http://localhost. Develop basic in local and do all the hostname + https on actual server where you can easily do something like letsencrypt route DNS to it.
  - chuckadams 3y ago
    There are a number of APIs, such as geolocation, that only work over https. It's also very common to accidentally generate non-https urls for assets, which is a bug most people would rather catch in local dev and not production when the browser refuses to fetch them. I use traefik to serve my apps in dev, which generates self-signed certs by default if you don't hook it up to ACME. Slightly more cumbersome because it means clicking through a warning screen and disabling verification in CLI tools (actually those are where I do drop to plain http). I'm sure this lcl.host product smooths this process considerably, but when it comes to local dev tools, I have an absolute requirement that they actually run locally and don't tether me to some cloud service, so I'll be sticking with traefik regardless for now.
    - afavour 3y ago
      > There are a number of APIs, such as geolocation, that only work over https And localhost https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts#when_is_a_context_considered_secure https://developer.mozilla.org/en-US/docs/Web/Security/Secure...
knallfrosch 3y ago
It is hard to set up. Creating a cert and trusting it is easy – a Powershell script can do that in 3 lines. But then, trouble begins. You have to configure every server to use the certificate (or use a proxy) and every client to accept the certificate. Sometimes the proxies eat headers, or they have trouble with WebSockets and hot reloading or whatever. We also use IPs instead of domains to find our locally running prod servers so that our customers don't have to configure anything DNS on their maybe-offline WiFi network. We also have to test with external devices, such as iPads. How do you automate getting your certificate onto them? ..And then your IP changes and all is lost again. Yeah, if you have a 50 line Svelte "app" that you serve as site it's easy. But who does that?
- dspillett 3y ago
  > It is hard to set up. Really? > You have to configure every server to use the certificate A couple of lines in apache/nginx/other config? The same lines each time. You probably don't want your dev box to be doing things required for LE renewal (allowing external in for HTTP(S) validation, making public DNS changes for DNS01, …) but I have a small container doing that and other boxes pull the resulting cert from there (a small cron task, again the same in each instance). > and every client to accept the certificate > external devices, such as iPads. How do you [get] your certificate onto them? I suggested using a public name and an LE cert or similar. Clients will trust without extra effort. > We also use IPs instead of domains I did say “more devs don't” not “all devs don't”, there will of course be special cases. Though using addresses rather than names just feels broken. > And then your IP changes and all is lost again That is an argument against using address based config rather than name based config, not an argument against using HTTPS!
holoduke 3y ago
I never work locally. Always remote. Dev.xxx.com, stg.xxx.com etc
- dspillett 3y ago
  Whether you dev/test on localhost or a remote instance (or a local instance with a public name etc.), is separate from whether your dev/test instances present via HTTPS.
  - holoduke 3y ago
    Its a bit easier to use letsencrypt on a remote host. In less than 5 minutes i can setup a remote host with domains and certificates attached to it. Localhost with certs and hostnames is always a pita. Thats why i always work on a remote box. For my local editors it doesnt matter. Just attach remote disks to my local machine.
    - everforward 3y ago
      I think the relevant part here is that remote hosts have public IPs. I'm assuming you're doing HTTP-01 verification on Lets Encrypt, which does basically require a public IP. FYI, you can get Lets Encrypt certs easily on non-public hosts by using the DNS-01 challenges. They rely on setting particular DNS records rather than HTTP responses, so they don't rely on public IPs
tonetheman 3y ago
[dead]

zikduruqe 3y ago

You don't even need to mess with a wildcard from Lets Encrypt, just use https://github.com/FiloSottile/mkcert https://github.com/FiloSottile/mkcert

dspillett 3y ago
I've always been a bit wary of a local trusted CA, especially with the signing cert on the same dev box as the certificates it signs which is how I've seen things done a lot. It feels like opening up a trust issue that could allow an uncooperative entity to play games with me… Maybe that is just paranoia from the practical jokes played back in CompSci at Uni! Admittedly an external attacker getting close enough to sign a cert using such a CA, in order to trick me into something, means they probably have such high access already that they don't really need the CA to do that or worse, so perhaps it is unnecessary caution.
- zikduruqe 3y ago
  [flagged]
- nucleardog 3y ago
  The way I handle this in the dev tooling I put together is to run a totally separate browser profile that (1) trusts the certificate and (2) can only connect to localhost. It also launches with a totally different colour scheme. With chrome, that's something like: google-chrome --user-data-dir="${HOME}/.config/ourlocaldev/google-chrome" --install-autogenerated-theme=85,63,9 --host-rules="MAP * 127.0.0.1, EXCLUDE localhost, EXCLUDE fonts.googleapis.com, EXCLUDE fonts.gstatic.com" --ignore-certificate-errors-spki-list="0oKw9nasIS7qRQD1CYXe5bmi22/mnHjZP++f6G+VM88=" "https://my.dev.thing" This will launch a separate copy of chrome with a fresh/separate profile. It will have a different colour (RGB values set in there) so it's visually distinct when it's running and I don't get the windows mixed up. Any request made from the browser will be rewritten to connect to 127.0.0.1 (except a couple google font domains). The danger if someone got their hands on my local key/cert is basically nil. They would only be able to MITM connections from this one specific browser window to localhost. And that browser is incapable of connecting to anything besides localhost. I can never accidentally open my banking site in there. Also fresh profile so no saved passwords, credit cards, or anything else. (As an added benefit, I don't really need to worry about reconfiguring URLs for projects. If I open "testing.mysite.com" in that browser, it will force the connection to localhost, so I can just run my services at our test URLs and steal configs as-is from the testing environment. Taking it further, I then have a controller set up in k3s/Rancher Desktop that rewrites the service on all annotated ingresses to point to its own service, which runs nginx, which the controller then configures to proxy the requests on to the local service or the actual upstream testing service depending on whether the local container is running. It also configures CoreDNS to point the upstream URLs at the same proxy. End result is that from the browser or anything running in k3s you can hit our testing URLs and it will hit your local container if it's running or fall back to the testing environment if not.) If you want to try the browser thing, you can generate the fingerprint for a certificate with: echo "" | openssl s_client -connect 127.0.0.1:443 -prexit 2>/dev/null | openssl x509 -pubkey -noout -in /dev/stdin | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64
  - djbusby 3y ago
    This is an awesome trick, thanks, I'm copying you.
- dpkirchner 3y ago
  I figure you could create the CA, have your browser trust it, create and sign your localhost cert, and then nuke the CA private key so no other carts may be signed. It'd be annoying if you need to make a new localhost certificate, but totally manageable.
- everforward 3y ago
  I think this is primarily FUD down by SSL cert companies. If you have appropriate permissions on the private keys, it would require the same level of access to read the private key as it would for the attacker to create their own CA and install it on your PC. My general rule of thumb is to use private certificates unless a) users interact with it directly, cuz they won't install my cert, or b) financial or other highly sensitive data flows through it. I'm not convinced that commercial CAs are more secure, but for the price of an SSL cert, it's worth it to have it not be my fault if something happens.
javajosh 3y ago
You don't even need that. See https://simpatico.io/devops/deploy.sh#generateSelfSignedCert https://simpatico.io/devops/deploy.sh#generateSelfSignedCert() and also #generateRootCA() Then point your server to the output files. If you want, you can also modify `/etc/hosts` to point a "production name" to localhost (something I actually don't do and never wrote a script for). Far fewer moving parts than the OP. (parts of Simpatico uses subtle.crypto and so requires https to run even locally)

afavour 3y ago

> It surprises me how few people dev/test against HTTPS For dev at least it’s mostly because web browsers treat localhost as a special domain that gets the HTTPS treatment even when loaded over HTTP. I have set up local HTTPS certs before now, can’t remember exactly what required it. But I still load most web projects on localhost over HTTP just out of habit.

hk1337 3y ago
I've always thought the need for local HTTPS was unnecessary for at least 90% of the projects and brought no real value other than making the developer "feel" better. localhost with HTTP should be sufficient for most things. It's when you start doing stuff like "app.localhost" like what was mentioned in the article which, despite it having "localhost" is not the same as http://localhost http://localhost. Develop basic in local and do all the hostname + https on actual server where you can easily do something like letsencrypt route DNS to it.
- chuckadams 3y ago
  There are a number of APIs, such as geolocation, that only work over https. It's also very common to accidentally generate non-https urls for assets, which is a bug most people would rather catch in local dev and not production when the browser refuses to fetch them. I use traefik to serve my apps in dev, which generates self-signed certs by default if you don't hook it up to ACME. Slightly more cumbersome because it means clicking through a warning screen and disabling verification in CLI tools (actually those are where I do drop to plain http). I'm sure this lcl.host product smooths this process considerably, but when it comes to local dev tools, I have an absolute requirement that they actually run locally and don't tether me to some cloud service, so I'll be sticking with traefik regardless for now.
  - afavour 3y ago
    > There are a number of APIs, such as geolocation, that only work over https And localhost https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts#when_is_a_context_considered_secure https://developer.mozilla.org/en-US/docs/Web/Security/Secure...

knallfrosch 3y ago

It is hard to set up. Creating a cert and trusting it is easy – a Powershell script can do that in 3 lines. But then, trouble begins. You have to configure every server to use the certificate (or use a proxy) and every client to accept the certificate. Sometimes the proxies eat headers, or they have trouble with WebSockets and hot reloading or whatever. We also use IPs instead of domains to find our locally running prod servers so that our customers don't have to configure anything DNS on their maybe-offline WiFi network. We also have to test with external devices, such as iPads. How do you automate getting your certificate onto them? ..And then your IP changes and all is lost again. Yeah, if you have a 50 line Svelte "app" that you serve as site it's easy. But who does that?

dspillett 3y ago
> It is hard to set up. Really? > You have to configure every server to use the certificate A couple of lines in apache/nginx/other config? The same lines each time. You probably don't want your dev box to be doing things required for LE renewal (allowing external in for HTTP(S) validation, making public DNS changes for DNS01, …) but I have a small container doing that and other boxes pull the resulting cert from there (a small cron task, again the same in each instance). > and every client to accept the certificate > external devices, such as iPads. How do you [get] your certificate onto them? I suggested using a public name and an LE cert or similar. Clients will trust without extra effort. > We also use IPs instead of domains I did say “more devs don't” not “all devs don't”, there will of course be special cases. Though using addresses rather than names just feels broken. > And then your IP changes and all is lost again That is an argument against using address based config rather than name based config, not an argument against using HTTPS!

holoduke 3y ago

I never work locally. Always remote. Dev.xxx.com, stg.xxx.com etc

dspillett 3y ago
Whether you dev/test on localhost or a remote instance (or a local instance with a public name etc.), is separate from whether your dev/test instances present via HTTPS.
- holoduke 3y ago
  Its a bit easier to use letsencrypt on a remote host. In less than 5 minutes i can setup a remote host with domains and certificates attached to it. Localhost with certs and hostnames is always a pita. Thats why i always work on a remote box. For my local editors it doesnt matter. Just attach remote disks to my local machine.
  - everforward 3y ago
    I think the relevant part here is that remote hosts have public IPs. I'm assuming you're doing HTTP-01 verification on Lets Encrypt, which does basically require a public IP. FYI, you can get Lets Encrypt certs easily on non-public hosts by using the DNS-01 challenges. They rely on setting particular DNS records rather than HTTP responses, so they don't rely on public IPs

tonetheman 3y ago

[dead]