7 ms·

Couldn't you make your own root authority, install it locally, and sign a wildcard cert to cover your dev websites? For example, if they're all *.local that wo

by Navarr 12y ago

Couldn't you make your own root authority, install it locally, and sign a wildcard cert to cover your dev websites? For example, if they're all *.local that wouldn't be easily abusable.

exelius 12y ago
That's a lot of trouble to go through that I don't today. Everything in production is fronted by a load balancer that terminates SSL, so I never have to worry about SSL certs in the course of a normal day.
- 15155 12y ago
  It's a bit of trouble because no project has made it really easy yet. All-in-all, this is something that could easily be made into an app and automated.
  - exelius 12y ago
    No, it's a bit of trouble because security takes time to set up. To automate this, you would need a CA that is trusted by your (and the rest of your team's) browser that also creates arbitrary certs upon request. You can see why this is a bad idea. Secure versions of this exist - and the security requirements they introduce are part of the reason enterprise IT is so much of a pain in the ass.
    - IgorPartola 12y ago
      Honestly, I have no problem with plain HTTP support being available but only enabled via about:config. If you are a developer, sure go for it. Having said that, the suggestion of running your own CA for your dev environments takes less time to grok and set up than Python's VirtualEnvWrapper.
      - exelius 12y ago
        It's not running your own CA that's the problem; it's remembering how to integrate with it for every project you do. Especially considering almost nobody runs SSL on their web apps - you will almost always terminate SSL at a load balancer of some sort, so it's not something web developers normally need to worry about nor is it reflective of how apps run in a production environment.
        15155 12y ago
        Terminate SSL at a local 'load balancer' (nginx, haproxy, vulcand) - voila, your setup is now substantially more similar to production.
        IgorPartola 12y ago
        Turns out, not everybody runs an AWS-style setup with a load balancer and backend servers. In some cases that's not what you want. Regardless, we are talking about users' browsers dropping plain HTTP. These browsers will never hit your backend servers, so you need not worry about them. In your scenario, they'll always use HTTPS. You are worried about your one in a million case as a developer. That's fine, go into about:config and enable plain HTTP. Everyone else isn't an expert in security and shouldn't be allowed to shoot themselves in the foot by default.
        exelius 12y ago
        I would be in favor of more of an alert-based implementation. i.e. if you go to a page that is HTTP, your address bar turns red with an "insecure" icon. A setting in about:config is ok, just a minor pain in the ass because I'll have to Google it any time I need to use it.
        IgorPartola 12y ago
        Good. I guess we are more or less on the same page. My only qualm about permitting plain HTTP and giving a passive alert is that it allows an attacker to run arbitrary JS on your machine before you notice that it was loaded over plain HTTP and decide to disable it. However, this may be a very good transition step.
- tootie 12y ago
  I think easing the setup of personal/enterprise CAs would be hugely useful to gaining adoption. Imagine a CA hosted by Google or the like that's tied your personal or business account where you can authenticate certs. Trusted if it's your own (or vouched by a trusted second party).
cbhl 12y ago
That's a heck of a lot more complicated than python3 -m http.server and then opening http:// http://[::1]:8000/ in your web browser. But then again, carrier-grade NAT means that anyone who is tinkering like this has to do some sort of NAT-punching to show their work off to a friend, so maybe this could be solved by an automated wrapper ala localtunnel or ngrok.
- Ded7xSEoPKYNsDd 12y ago
  openssl s_server -accept 4443 -WWW -cert mycert.pem Is not much more complicated.
  - byuu 12y ago
    Especially not when you pretend mycert.pem magically already exists, costs nothing yet works on all your subdomains, and that Firefox/Chrome trust it.

by Navarr 12y ago

Couldn't you make your own root authority, install it locally, and sign a wildcard cert to cover your dev websites? For example, if they're all *.local that wouldn't be easily abusable.

exelius 12y ago

That's a lot of trouble to go through that I don't today. Everything in production is fronted by a load balancer that terminates SSL, so I never have to worry about SSL certs in the course of a normal day.

15155 12y ago
It's a bit of trouble because no project has made it really easy yet. All-in-all, this is something that could easily be made into an app and automated.
- exelius 12y ago
  No, it's a bit of trouble because security takes time to set up. To automate this, you would need a CA that is trusted by your (and the rest of your team's) browser that also creates arbitrary certs upon request. You can see why this is a bad idea. Secure versions of this exist - and the security requirements they introduce are part of the reason enterprise IT is so much of a pain in the ass.
  - IgorPartola 12y ago
    Honestly, I have no problem with plain HTTP support being available but only enabled via about:config. If you are a developer, sure go for it. Having said that, the suggestion of running your own CA for your dev environments takes less time to grok and set up than Python's VirtualEnvWrapper.
    - exelius 12y ago
      It's not running your own CA that's the problem; it's remembering how to integrate with it for every project you do. Especially considering almost nobody runs SSL on their web apps - you will almost always terminate SSL at a load balancer of some sort, so it's not something web developers normally need to worry about nor is it reflective of how apps run in a production environment.
      - 15155 12y ago
        Terminate SSL at a local 'load balancer' (nginx, haproxy, vulcand) - voila, your setup is now substantially more similar to production.
      - IgorPartola 12y ago
        Turns out, not everybody runs an AWS-style setup with a load balancer and backend servers. In some cases that's not what you want. Regardless, we are talking about users' browsers dropping plain HTTP. These browsers will never hit your backend servers, so you need not worry about them. In your scenario, they'll always use HTTPS. You are worried about your one in a million case as a developer. That's fine, go into about:config and enable plain HTTP. Everyone else isn't an expert in security and shouldn't be allowed to shoot themselves in the foot by default.
        exelius 12y ago
        I would be in favor of more of an alert-based implementation. i.e. if you go to a page that is HTTP, your address bar turns red with an "insecure" icon. A setting in about:config is ok, just a minor pain in the ass because I'll have to Google it any time I need to use it.
        IgorPartola 12y ago
        Good. I guess we are more or less on the same page. My only qualm about permitting plain HTTP and giving a passive alert is that it allows an attacker to run arbitrary JS on your machine before you notice that it was loaded over plain HTTP and decide to disable it. However, this may be a very good transition step.
tootie 12y ago
I think easing the setup of personal/enterprise CAs would be hugely useful to gaining adoption. Imagine a CA hosted by Google or the like that's tied your personal or business account where you can authenticate certs. Trusted if it's your own (or vouched by a trusted second party).

cbhl 12y ago

That's a heck of a lot more complicated than python3 -m http.server and then opening http:// http://[::1]:8000/ in your web browser. But then again, carrier-grade NAT means that anyone who is tinkering like this has to do some sort of NAT-punching to show their work off to a friend, so maybe this could be solved by an automated wrapper ala localtunnel or ngrok.

Ded7xSEoPKYNsDd 12y ago
openssl s_server -accept 4443 -WWW -cert mycert.pem Is not much more complicated.
- byuu 12y ago
  Especially not when you pretend mycert.pem magically already exists, costs nothing yet works on all your subdomains, and that Firefox/Chrome trust it.