6 ms·

> It would be nice if it also worked on local IPs, like 192.168... That would defeat the security purpose. Anyone within your local network (which practicall

by hannob 7y ago

> It would be nice if it also worked on local IPs, like 192.168... That would defeat the security purpose. Anyone within your local network (which practically speaking very often means the next Wifi your device could find) could attack you.

mort96 7y ago
But how do you do local development when you can't get an SSL cert for your dev machine's server? No, self signed certs don't always do what you need, especially on mobile where you can't just add your cert as a trusted cert easily.
- yeukhon 7y ago
  I know localhost is supported by Lets Encrypt but not sure about local lan network. One possible workaround is ssh forwarding. Create a tunnel. But I have not tried it myself.
- comex 7y ago
  If you own a domain, you can add a subdomain that points to the local network IP, and get Let's Encrypt to give you a certificate using the dns-01 validation method (which doesn't require Let's Encrypt to actually access the IP address in the A record). This is clearly more complicated than ideal, but it should work. Edit: You can also use a custom CA root certificate, which can be installed on iOS etc. mkcert is a good starting point: https://github.com/FiloSottile/mkcert https://github.com/FiloSottile/mkcert
  - mort96 7y ago
    > This is clearly more complicated than ideal, but it should work. Exactly. Imagine you're someone who just wants to play around with cool web technologies. Maybe you're fairly new to web dev; maybe you're fairly new to the world of programming in general and you're using the web to learn it, which has historically been one of the huge strengths of the web. You suddenly encounter a brick wall, where you figure out that programming isn't enough; you have to fork over money for a domain and learn how SSL works and how to set up let's encrypt and how to make root certs and how to install them on your phone, just because you wanted to play with something you found interesting. The web looks like it's going away from being a good platform to learn and play with programming in the name of security. It will be annoying but workable for most professional programmers who can just do whatever hacks they need to get by, but we're erecting some monumental barriers to learn this stuff. You already can't even include a fucking javascript module file from an html file without learning how to set up and configure a web server because Chrome blocks modules when using file://.
    - edoceo 7y ago
      The burden is a little higher but not insurmountable and it obligates new folks into things they need to know. I think it's an acceptable forcing function. Especially given the security concerns.
      - mort96 7y ago
        What security concerns though? It's not like accessing the camera on a random attacker controlled HTTP page is less secure than on a random attacker controlled HTTPS page. If the user lets a malicious web page access the camera, that's game over regardless. I'm all for doing stuff to tell users that the HTTP page they're visiting is insecure, but telling people who are new to web dev to get a domain and learn how the world of SSL and domains work is actually a pretty fucking big hurdle. They'll have to get into that if they want to get serious about it, sure, but there's no reason to unnecessarily front-load the frustrating and complicated and unrelated parts. You may think it's acceptable, I value the web's accessibility to new developers. Surely there's better ways to convince sites to use HTTPS than to say they can't use getUserMedia on HTTP.
        comex 7y ago
        > What security concerns though? It's not like accessing the camera on a random attacker controlled HTTP page is less secure than on a random attacker controlled HTTPS page. If the user lets a malicious web page access the camera, that's game over regardless. No. But accessing the camera on a non-attacker-controlled HTTP page is less secure than doing so on a non-attacker-controlled HTTPS page, because an attacker could MitM the former but not the latter. (Even if the camera data itself is sent securely, the attacker could just change the host page's JavaScript to send it to a different server instead.)
    - acdha 7y ago
      This feels pessimistic to me: most people didn’t learn the web that way, instead using shared servers — and there were plenty of similar complaints that it was too hard to learn Unix/Windows admin stuff, too. Today, you can use glitch, github pages, jsbin & a million friends, zeit, etc. or the same cheap Dreamhost account people used $20 years ago and start practicing with HTTPS and many other amenities at minimal cost. JavaScript CDNs make it pretty easy to use a ton of stuff without even needing to learn how to install it, too, and increasingly you can do that as native modules. I’d worry a lot more about how many people are being told they need a J2EE-scale tool chain to run hello world even though the native environment has never been richer.
  - Mister_Snuggles 7y ago
    Another option is xca[0]. It's not as quick to get going as mkcert, but it's quite full featured. I used it to create an internal CA and certificates for my internal services and it works quite well. [0] https://hohnstaedt.de/xca/ https://hohnstaedt.de/xca/
- shkkmo 7y ago
  Easy: 1) Get a signed certificate for a subdomain on a domain you own (e.g. dev.example.com) 2) Change your hosts file to point any local IP you wish, or setup a DNS entry for that subdomain that points to 127.0.0.1
- jonas21 7y ago
  Localtunnel? https://localtunnel.me/ https://localtunnel.me/
- duchenne 7y ago
  Wihtout using any third party service, you could use an SSH tunnel, with autossh for automatic reconnections. autossh -L 2080:localhost:80 192.198.1.14 And then, you'll be able to visit your dev website on http://localhost:2080 http://localhost:2080 Firefox will believe that your service is local, and will allow the activation of the camera and the microphone even though you do not use https.
  - throwamay1241 7y ago
    Browsers have weird behaviors on localhost, such as allowing webcam and microphone on HTTP and iirc, permit cross-origin resource access which is blocked on less trusted domains.
    - bzbarsky 7y ago
      > and iirc, permit cross-origin resource access Firefox does not do that. Safari has some behaviors along those lines last I checked. I can't recall for Chrome whether it does or not.
- zaarn 7y ago
  VSCode in recent versions has the Remote Workspace Function. It can forward ports if you press Ctrl-P and type "ssh forward", enter and the port number, enter again. You can setup the ssh-config for that workspace to also automatically forward ports.
- deleted 7y ago
  [deleted]
- viraptor 7y ago
  > especially on mobile where you can't just add your cert as a trusted cert easily What do you mean? Do some Androids block it? Or iOS? I've got it easily available in settings.
- michaelbrooks 7y ago
  Not sure if you've heard of NGrok, but this tunnels your server and can be accessed outside of your network with or without https. https://ngrok.com/ https://ngrok.com/
- deleted 7y ago
  [deleted]

by hannob 7y ago

mort96 7y ago

But how do you do local development when you can't get an SSL cert for your dev machine's server? No, self signed certs don't always do what you need, especially on mobile where you can't just add your cert as a trusted cert easily.

yeukhon 7y ago
I know localhost is supported by Lets Encrypt but not sure about local lan network. One possible workaround is ssh forwarding. Create a tunnel. But I have not tried it myself.
comex 7y ago
If you own a domain, you can add a subdomain that points to the local network IP, and get Let's Encrypt to give you a certificate using the dns-01 validation method (which doesn't require Let's Encrypt to actually access the IP address in the A record). This is clearly more complicated than ideal, but it should work. Edit: You can also use a custom CA root certificate, which can be installed on iOS etc. mkcert is a good starting point: https://github.com/FiloSottile/mkcert https://github.com/FiloSottile/mkcert
- mort96 7y ago
  > This is clearly more complicated than ideal, but it should work. Exactly. Imagine you're someone who just wants to play around with cool web technologies. Maybe you're fairly new to web dev; maybe you're fairly new to the world of programming in general and you're using the web to learn it, which has historically been one of the huge strengths of the web. You suddenly encounter a brick wall, where you figure out that programming isn't enough; you have to fork over money for a domain and learn how SSL works and how to set up let's encrypt and how to make root certs and how to install them on your phone, just because you wanted to play with something you found interesting. The web looks like it's going away from being a good platform to learn and play with programming in the name of security. It will be annoying but workable for most professional programmers who can just do whatever hacks they need to get by, but we're erecting some monumental barriers to learn this stuff. You already can't even include a fucking javascript module file from an html file without learning how to set up and configure a web server because Chrome blocks modules when using file://.
  - edoceo 7y ago
    The burden is a little higher but not insurmountable and it obligates new folks into things they need to know. I think it's an acceptable forcing function. Especially given the security concerns.
    - mort96 7y ago
      What security concerns though? It's not like accessing the camera on a random attacker controlled HTTP page is less secure than on a random attacker controlled HTTPS page. If the user lets a malicious web page access the camera, that's game over regardless. I'm all for doing stuff to tell users that the HTTP page they're visiting is insecure, but telling people who are new to web dev to get a domain and learn how the world of SSL and domains work is actually a pretty fucking big hurdle. They'll have to get into that if they want to get serious about it, sure, but there's no reason to unnecessarily front-load the frustrating and complicated and unrelated parts. You may think it's acceptable, I value the web's accessibility to new developers. Surely there's better ways to convince sites to use HTTPS than to say they can't use getUserMedia on HTTP.
      - comex 7y ago
        > What security concerns though? It's not like accessing the camera on a random attacker controlled HTTP page is less secure than on a random attacker controlled HTTPS page. If the user lets a malicious web page access the camera, that's game over regardless. No. But accessing the camera on a non-attacker-controlled HTTP page is less secure than doing so on a non-attacker-controlled HTTPS page, because an attacker could MitM the former but not the latter. (Even if the camera data itself is sent securely, the attacker could just change the host page's JavaScript to send it to a different server instead.)
  - acdha 7y ago
    This feels pessimistic to me: most people didn’t learn the web that way, instead using shared servers — and there were plenty of similar complaints that it was too hard to learn Unix/Windows admin stuff, too. Today, you can use glitch, github pages, jsbin & a million friends, zeit, etc. or the same cheap Dreamhost account people used $20 years ago and start practicing with HTTPS and many other amenities at minimal cost. JavaScript CDNs make it pretty easy to use a ton of stuff without even needing to learn how to install it, too, and increasingly you can do that as native modules. I’d worry a lot more about how many people are being told they need a J2EE-scale tool chain to run hello world even though the native environment has never been richer.
- Mister_Snuggles 7y ago
  Another option is xca[0]. It's not as quick to get going as mkcert, but it's quite full featured. I used it to create an internal CA and certificates for my internal services and it works quite well. [0] https://hohnstaedt.de/xca/ https://hohnstaedt.de/xca/
shkkmo 7y ago
Easy: 1) Get a signed certificate for a subdomain on a domain you own (e.g. dev.example.com) 2) Change your hosts file to point any local IP you wish, or setup a DNS entry for that subdomain that points to 127.0.0.1
jonas21 7y ago
Localtunnel? https://localtunnel.me/ https://localtunnel.me/
duchenne 7y ago
Wihtout using any third party service, you could use an SSH tunnel, with autossh for automatic reconnections. autossh -L 2080:localhost:80 192.198.1.14 And then, you'll be able to visit your dev website on http://localhost:2080 http://localhost:2080 Firefox will believe that your service is local, and will allow the activation of the camera and the microphone even though you do not use https.
- throwamay1241 7y ago
  Browsers have weird behaviors on localhost, such as allowing webcam and microphone on HTTP and iirc, permit cross-origin resource access which is blocked on less trusted domains.
  - bzbarsky 7y ago
    > and iirc, permit cross-origin resource access Firefox does not do that. Safari has some behaviors along those lines last I checked. I can't recall for Chrome whether it does or not.
zaarn 7y ago
VSCode in recent versions has the Remote Workspace Function. It can forward ports if you press Ctrl-P and type "ssh forward", enter and the port number, enter again. You can setup the ssh-config for that workspace to also automatically forward ports.
deleted 7y ago
[deleted]
viraptor 7y ago
> especially on mobile where you can't just add your cert as a trusted cert easily What do you mean? Do some Androids block it? Or iOS? I've got it easily available in settings.
michaelbrooks 7y ago
Not sure if you've heard of NGrok, but this tunnels your server and can be accessed outside of your network with or without https. https://ngrok.com/ https://ngrok.com/
deleted 7y ago
[deleted]