Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lcl.host: fast, easy HTTPS in your local dev environment

anchor.dev

Post reply on HN
Print view View original

91–100 of 101 posts

Re: Lcl.host: fast, easy HTTPS in your local dev environment

#91

Post by dspillett »

holoduke wrote: post #63
dspillett wrote: post #3

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 ru…

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

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.

Re: Lcl.host: fast, easy HTTPS in your local dev environment

#92

Post by dspillett »

knallfrosch wrote: post #47
dspillett wrote: post #3

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 ru…

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 p…

> 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!

Re: Lcl.host: fast, easy HTTPS in your local dev environment

#93

Post by cookiengineer »

yoavm wrote: post #90
cookiengineer wrote: post #88

Earlier quoted context omitted.

> you're completely free to run firefox from 5 years ago > Firefox 53 from 2017 not the same. I was talking about post-quantum Firefox releases, which added the mentioned dependencies on Mozilla's SSL certificate. (The grandparent's comment was also about post-quantum, obviously)

The grandparent post is about some malicious tactic used by Mozilla to prevent you from using old Firefox releases. I think it's pretty clear that there isn't such intent - if there was, the very least Mozilla would have done is preventing you from downloading old versions from their own servers. Having a few specific releases that broke over time doesn't mean anyone is trying to stop you from using an older version…

> Having a few specific releases that broke over time doesn't mean anyone is trying to stop you from using an older version of Firefox.

Snakeoil certificates in Enterprise licensing might disagree with this statement, which in my opinion is pretty identical to Mozilla's approach to have control over "who is allowed to use when" of their software.

It's also not a few specific releases over time, it's all releases after Browser Extension signatures were introduced as being mandatory, which made the rest of the Browser rely heavily on their certificate management servers.

I'm not saying it's malicious intent, what I am saying is that this could've been implemented in a much better manner, which wouldn't rely on a centralized certificate signing service.

Re: Lcl.host: fast, easy HTTPS in your local dev environment

#94

Post by btreecat »

cookiengineer wrote: post #93
yoavm wrote: post #90

Earlier quoted context omitted.

The grandparent post is about some malicious tactic used by Mozilla to prevent you from using old Firefox releases. I think it's pretty clear that there isn't such intent - if there was, the very least Mozilla would have done is preventing you from downloading old versions from their own servers. Having a few specific releases that broke over time doesn't mean anyone is trying to stop you from using an older version…

> Having a few specific releases that broke over time doesn't mean anyone is trying to stop you from using an older version of Firefox. Snakeoil certificates in Enterprise licensing might disagree with this statement, which in my opinion is pretty identical to Mozilla's approach to have control over "who is allowed to use when" of their software. It's also not a few specific releases over time, it's all releases afte…

Yeah they don't _have to require SSL_ but I think we can agree that is a worse thing given the benefits of securing extensions and validation of the server hosting them

Re: Lcl.host: fast, easy HTTPS in your local dev environment

#95

Post by holoduke »

dspillett wrote: post #91
holoduke wrote: post #63

Earlier quoted context omitted.

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

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.

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.

Re: Lcl.host: fast, easy HTTPS in your local dev environment

#96

Post by everforward »

dspillett wrote: post #10
zikduruqe wrote: post #5

Earlier quoted context omitted.

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

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 si…

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.

Re: Lcl.host: fast, easy HTTPS in your local dev environment

#97

Post by everforward »

holoduke wrote: post #95
dspillett wrote: post #91

Earlier quoted context omitted.

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.

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.

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

Re: Lcl.host: fast, easy HTTPS in your local dev environment

#98

Post by everforward »

austin-cheney wrote: post #61

Some things I learned about trusted localhost HTTPS: * Windows is the easiest... by far. There is only one trust store and its extremely easy to access at different levels of trust. Firefox has its own trust store so you can either add your certs to both the Windows store AND the Firefox trust store or flip a config in Firefox to tell it to use the Windows trust store like everyone else. * Linux is a challenge becaus…

> * Linux is a challenge because you have to add your certificates to the OS trust store and then each browser has their own trust stores.

I could be wrong, but I could have sworn Firefox trusts the OS' certificate store. Maybe it's just been too long since I've done it.

Re: Lcl.host: fast, easy HTTPS in your local dev environment

#99

Post by austin-cheney »

everforward wrote: post #98
austin-cheney wrote: post #61

Some things I learned about trusted localhost HTTPS: * Windows is the easiest... by far. There is only one trust store and its extremely easy to access at different levels of trust. Firefox has its own trust store so you can either add your certs to both the Windows store AND the Firefox trust store or flip a config in Firefox to tell it to use the Windows trust store like everyone else. * Linux is a challenge becaus…

> * Linux is a challenge because you have to add your certificates to the OS trust store and then each browser has their own trust stores. I could be wrong, but I could have sworn Firefox trusts the OS' certificate store. Maybe it's just been too long since I've done it.

Firefox has its own cert store, even on Windows. You can make it defer to the OS trust store with an option in the about:config.

Re: Lcl.host: fast, easy HTTPS in your local dev environment

#100

Post by everforward »

austin-cheney wrote: post #99
everforward wrote: post #98

Earlier quoted context omitted.

> * Linux is a challenge because you have to add your certificates to the OS trust store and then each browser has their own trust stores. I could be wrong, but I could have sworn Firefox trusts the OS' certificate store. Maybe it's just been too long since I've done it.

Firefox has its own cert store, even on Windows. You can make it defer to the OS trust store with an option in the about:config.

Yeah, I know about that part, but I could have sworn that Firefox on Ubuntu trusts the intersection of it's trust store and the OS trust store (with Firefoxs store having priority).

Were you using the package manager packages? I'm a little surprised if the distro packages don't configure Firefox to use the OS trust store. I would not be surprised if the binaries Firefox provides directly don't trust the OS package store. They probably shouldn't, given that the path to the OS trust store is configurable. I think Ubuntu and Fedora use slightly different paths.

Seems like a security nightmare to try guessing at what directory has the OS trust store. Better to leave it to the package maintainers to specifically customize it for their distro's patterns.

Post reply on HN