8

I develop applications on my local computer that I later deploy to a TLS production server. Should I develop with TLS on or off?

Jonathan
  • 2,288
  • 13
  • 16
  • 1
    Security is not a product but a process. It is better to start by taking into account security measures right at the beginning instead of trying to bolt them on afterwards. Some interesting reading about TLS in applications outside of the web realm and some frequent errors: https://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf – Patrick Mevzek May 30 '18 at 23:14

1 Answers1

13

The answer is simple - yeah, dev using TLS. Here's why:

  1. You need to set the secure flag on cookies
  2. You want to make sure all resources accessed are https
  3. You might forget to turn on TLS dependencies when you deploy your code to production
  4. It's easy to do this. Go use acme.sh to register a let's encrypt cert using DNS for domain verification. Create a DNS A record that points to 127.0.0.1. Done.
  5. Don't use self signed certs because I don't want you forming a habit of clicking past TLS warnings

If you really really don't want to....

Then you need a post deploy compensating control. That means scan your website looking for TLS dependancies like the cookie secure flag. Use qualys free scanner to probe your site for issues like this.

Jonathan
  • 2,288
  • 13
  • 16
  • I sort of agree that it's a good "best practice" for most people Regarding "let's encrypt" however, very few developers either have their development environments directly accessible on the internet, or have direct control over the DNS records. The point being, creating a Lets Encrypt Cert isn't really something many/most developers can possibly even do. – Steve Sether May 30 '18 at 21:15
  • 1
    I myself could likely do this, though I work in an extremely free environment. When I worked for a Fortune 100 company however, there's no way I could have done this. – Steve Sether May 30 '18 at 21:19
  • You _could_ install your self signed cert in your browser to avoid the clickthrough issue. That implies you have root or admin permissions, which many developers don't. – Steve Sether May 30 '18 at 21:21
  • Hmm. These are good points. In the past, I've created a dns name like localhost.company.com pointed to 127.0.0.1 and bought a 1 or 2 year long cert, and distributed that. – Jonathan May 30 '18 at 22:03
  • 1
    "Create a DNS A record that points to 127.0.0.1. Done." this is exactly **NOT** recommended by Let's Encrypt, see: https://letsencrypt.org/docs/certificates-for-localhost/. Self-signed certificates are completely fine for local development. They are not a bad habit per se. The bad habit is not checking the issuer of a certificate and not acting correctly upon it. – Patrick Mevzek May 30 '18 at 23:13
  • 1
    @SteveSether nothing prevents you to buy a domain name (so that you are sure they will be no collision) let us say `example.com` and then just use locally (`/etc/hosts`, `dnsmasq`, `bind views`, etc...) whatever name you fancy, like `dev.example.com`. Making it that way makes sure you do not create false assumptions that would stick more or less consciously when you release the work in the wild... – Patrick Mevzek May 30 '18 at 23:23
  • @PatrickMevzek I read their advice and agree with it. Do not ship an app with a cert for a local host. Nothing suggests you can’t develop using one and I personally prefer teaching staff no exceptions to the bypass tls warnings. I disagree with adding Certs to a trusted store because they get forgotten. – Jonathan May 30 '18 at 23:39
  • @SteveSether I don’t recommend this as the cert could get stolen, forgotten about, checked into code, passed to a friend, or any number of unfortunate events. But after you trust it, you forget about it. I’ve seen this too often – Jonathan May 30 '18 at 23:41
  • 1
    @SteveSether quoting the page: "Sometimes people want to get a certificate for the hostname “localhost”, either for use in local development, or for distribution with a native application that needs to communicate with a web application. Let’s Encrypt can’t provide certificates for “localhost” because nobody uniquely owns it, and it’s not rooted in a top level domain like “.com” or “.net”. It’s possible to set up your own domain name that happens to resolve to 127.0.0.1, and get a certificate for it using the DNS challenge. However, this is generally a bad idea and there are better options." – Patrick Mevzek May 30 '18 at 23:44
  • @PatrickMevzek yes. The “better options” are decidedly worse. And no, you cannot get a cert for localhost as it isn’t a dns name. Can you tell me what the better options are? I am curious. – Jonathan May 30 '18 at 23:48
  • @Jonathan read the link in full the better options are pretty much very detailed... starting with self signed certificates but you are against them for whatever reason. – Patrick Mevzek May 31 '18 at 00:12
  • @PatrickMevzek I didn't know anyone could get a signed localhost cert. I'd suspect you'd really want to use this only on your real "local host" loopback though. So it likely wouldn't work very well when you need to use it on a remote environment. But that's a good tip. – Steve Sether May 31 '18 at 02:42
  • @PatrickMevzek I don't think I'd want to pay for a domain and a certificate for my employer. Gettings things reimibursed like that at large corporations can be difficult to impossible. The thing you have to keep in mind is that often times large fortune 500 companies put employees in almost literal handcuffs. There's a lot you just can't do. – Steve Sether May 31 '18 at 02:45
  • 1
    @SteveSether Domains can be found for a few dollars and Let's Encrypt delivers certificates for free. So I am not sure the finance is really the problem here... – Patrick Mevzek May 31 '18 at 02:47
  • @PatrickMevzek So what do you do when the in multiple places in the developer environment is dependent on one developers domain they bought in 2016, and the developer left in 2017, and now you cant renew the lets encrypt cert? Ad-Hoc solutions where you've gone around the normal procedures can bite you in the long run. Beyond that, Just trust me. if you haven't worked in one of these Fortune 500 environments, you'd understand the pain and of trying to do creative things like you suggest, with companies that actively work to diss-empower employees with procedures, policies, etc. – Steve Sether May 31 '18 at 02:53
  • @PatrickMevzek yes. I detailed a few reasons not to use self signed Certs. I’m looking for reasons supporting their claim that there are better options (or the option of self signed cert) for the local dev environments. – Jonathan May 31 '18 at 02:57
  • If you are an employee you should ask to your organization to provide you the certs... for example, we develop `ourproduct.com`, I registered also `ourproduct.dev` and every 3 months I renew the `*.ourproduct.dev` wildcard cert and I send it to all my developers – the_nuts Mar 16 '20 at 16:47