5 ms·

So much this. My company just got done shelling out a ton of money for some asshat to tell me that we can't use http on a dev server. <head smashes through desk

So much this. My company just got done shelling out a ton of money for some asshat to tell me that we can't use http on a dev server. <head smashes through desk>

greedo 6y ago
It's worse when the asshat convinces your manager that every internal site, whether dev or not needs https. Certs everywhere. Our team spends a decent % of our time generating and managing certs...
- xenophonf 6y ago
  That’s me. I’m that asshat. It’s called defense in depth. I recommend automating certificate issuance and renewal. It’s totally worth it.
  - triangleman 6y ago
    Book or tutorial recommendations please.
    - jasonladuke0311 6y ago
      https://certbot.eff.org/ https://certbot.eff.org/
      - souprock 6y ago
        How could that work? For security, an internal site lacks a connection to the internet.
        mschuster91 6y ago
        Internal sites? Set up your own CA infrastructure.
        speedgoose 6y ago
        I rather spend my limited time working on other security issues.
        CamperBob2 6y ago
        Or (gasp) shippable features.
        deleted 6y ago
        [deleted]
        skissane 6y ago
        Are you talking about a fully internal site, with not even indirect Internet access? For those kinds of airgapped applications, you should maintain your own CA infrastructure, and update all clients/browsers to trust its certificates. For the more common scenario of internal sites/services which are not accessible from the public Internet, but not fully isolated from it either: You don't need the internal site exposed to the Internet. If you use DNS-01 ACME challenge, you just need to be able to inject TXT records into your DNS. Some DNS providers have a REST API which can make this easier. Another option – to use HTTP-01 ACME challenge, you do need the internal host name to be publicly accessible over HTTP, but that doesn't mean the real internal service has to be. You could simply have your load balancer/DNS set up so external traffic to STAR.internal.example.com:80 gets sent to certservice.example.com which serves up the HTTP-01 challenge for that name. Whereas, internal users going to STAR.internal.mycompany.com talk to the real internal service. (There are various ways to implement this – split horizon DNS, some places have separate external and internal load balancers that can be configured differently, etc) Yet another option is to use ACME with wildcard certs (which needs DNS-01 challenge). Get a cert via ACME for STAR.internal.medallia.com and then all internal services use that. That is potentially less secure, in that lots of internal services may all end up using the same private key. One approach is that the public wildcard cert is on a load balancer, and then that load balancer talks to internal services – end-to-end TLS can be provided by an internal CA, and you have to put the internal CA cert in the trust store of your various components, but at least you don't have the added hassle of having to put it in your internal user's browser/OS trust stores. (In above, for STAR read an asterisk – HN wants to interpret asterisks as formatting and I don't know how to escape them.)
- deleted 6y ago
  [deleted]
- doliveira 6y ago
  Does your organization disable the "Non-secure" prompt in the browser as well? If not, I'd say that it does seem like a security risk to train your users to ignore browser warnings like that.
- searchableguy 6y ago
  I am confused. Isn't that easily automated?
  - souprock 6y ago
    It's not easily automated. Somehow, you have to safely get a certificate across the air gap to the internal network. So I guess an internet-connected system grabs the certificates, then they get burned to DVD-R, then... a robot moves the DVD-R to the internal network? It's not easy. It's all much worse if the networks aren't physically adjacent. One could be behind a bunch of armed guards and interlocking doors.
    - sarakayakomzin 6y ago
      >you have to safely get a certificate across the air gap to the internal network. you can't trust a server on the internal network as root certificate trust? sounds like a scary situation.
    - skissane 6y ago
      An airgapped network can include its own internal CA, and all the airgapped clients can have that internal CA's certificate injected into their trust stores, and all the services on the airgapped network can automatically request certificates from the internal CA – which can even be done using the same protocol which Let's Encrypt uses, ACME, just running it over a private airgapped network instead of over the public Internet.
  - mrweasel 6y ago
    We have a ton of internal stuff, most of it doesn’t even have external DNS. We use long lived certs signed with our own CA. we’d prefer using and automated solution, using a “real” CA, but non seems to be available.
- jogjayr 6y ago
  Not quite so crazy now that everyone's working from home, right? Unless you also use a VPN?
  - dx034 6y ago
    Even with VPN. I don't want any person on the vpn to be potentially able to read traffic between internal services. I think that would fail many audits.
- dx034 6y ago
  Which means if someone gets access to the internal network, they can read all traffic. And even dev systems can send confidential data. With letsencrypt and easy to generate certificates, https everywhere is very reasonable.
- quotemstr 6y ago
  It does though. There's no excuse for unencrypted traffic. Google doesn't have some VPN with squishy unencrypted traffic inside. Everything is just HTTPS. If they can do it, so can you. It's just not that hard to manage a PKI.
scoot_718 6y ago
I mean, I mandate https in dev, but it sure isn't for security. It's so that auth works in dev and no changes are required to push prod
- james_s_tayler 6y ago
  or someone doesn't accidentally just entirely overlook it and wind up with just http in prod.
dx034 6y ago
I actually think that's valid. Sure, http on a dev machine isn't a security risk. But there is a tail risk that it ends up somewhere on a system that sends data between machines. Also, using http on dev and https on prod can lead to unexpected bugs. Banning http is not unreasonable. Same with the md5 complaint. That use of md5 wasn't a problem but there's a perfectly fine alternative and if you can ensure by automated tests that md5 is used nowhere, you also can guarantee that it's never used in a security relevant context.
- skissane 6y ago
  > and if you can ensure by automated tests that md5 is used nowhere You can automatically check for the string "md5" in identifiers, but you can't reliably automatically check for implementations of the MD5 algorithm. All it takes is for someone to copy-paste an implementation of MD5 and rename it to "MyChecksumAlgorithm" and suddenly very few (if any) security scanning tools are going to be smart enough to find it. (Foolproof detection of what algorithms a program contains is equivalent to the halting problem and hence undecidable, although as with every other undecidable problem, there can exist fallible algorithms capable of solving some instances but not others.)

So much this. My company just got done shelling out a ton of money for some asshat to tell me that we can't use http on a dev server. <head smashes through desk>

greedo 6y ago

It's worse when the asshat convinces your manager that every internal site, whether dev or not needs https. Certs everywhere. Our team spends a decent % of our time generating and managing certs...

xenophonf 6y ago
That’s me. I’m that asshat. It’s called defense in depth. I recommend automating certificate issuance and renewal. It’s totally worth it.
- triangleman 6y ago
  Book or tutorial recommendations please.
  - jasonladuke0311 6y ago
    https://certbot.eff.org/ https://certbot.eff.org/
    - souprock 6y ago
      How could that work? For security, an internal site lacks a connection to the internet.
      - mschuster91 6y ago
        Internal sites? Set up your own CA infrastructure.
        speedgoose 6y ago
        I rather spend my limited time working on other security issues.
        CamperBob2 6y ago
        Or (gasp) shippable features.
      - deleted 6y ago
        [deleted]
      - skissane 6y ago
        Are you talking about a fully internal site, with not even indirect Internet access? For those kinds of airgapped applications, you should maintain your own CA infrastructure, and update all clients/browsers to trust its certificates. For the more common scenario of internal sites/services which are not accessible from the public Internet, but not fully isolated from it either: You don't need the internal site exposed to the Internet. If you use DNS-01 ACME challenge, you just need to be able to inject TXT records into your DNS. Some DNS providers have a REST API which can make this easier. Another option – to use HTTP-01 ACME challenge, you do need the internal host name to be publicly accessible over HTTP, but that doesn't mean the real internal service has to be. You could simply have your load balancer/DNS set up so external traffic to STAR.internal.example.com:80 gets sent to certservice.example.com which serves up the HTTP-01 challenge for that name. Whereas, internal users going to STAR.internal.mycompany.com talk to the real internal service. (There are various ways to implement this – split horizon DNS, some places have separate external and internal load balancers that can be configured differently, etc) Yet another option is to use ACME with wildcard certs (which needs DNS-01 challenge). Get a cert via ACME for STAR.internal.medallia.com and then all internal services use that. That is potentially less secure, in that lots of internal services may all end up using the same private key. One approach is that the public wildcard cert is on a load balancer, and then that load balancer talks to internal services – end-to-end TLS can be provided by an internal CA, and you have to put the internal CA cert in the trust store of your various components, but at least you don't have the added hassle of having to put it in your internal user's browser/OS trust stores. (In above, for STAR read an asterisk – HN wants to interpret asterisks as formatting and I don't know how to escape them.)
deleted 6y ago
[deleted]
doliveira 6y ago
Does your organization disable the "Non-secure" prompt in the browser as well? If not, I'd say that it does seem like a security risk to train your users to ignore browser warnings like that.
searchableguy 6y ago
I am confused. Isn't that easily automated?
- souprock 6y ago
  It's not easily automated. Somehow, you have to safely get a certificate across the air gap to the internal network. So I guess an internet-connected system grabs the certificates, then they get burned to DVD-R, then... a robot moves the DVD-R to the internal network? It's not easy. It's all much worse if the networks aren't physically adjacent. One could be behind a bunch of armed guards and interlocking doors.
  - sarakayakomzin 6y ago
    >you have to safely get a certificate across the air gap to the internal network. you can't trust a server on the internal network as root certificate trust? sounds like a scary situation.
  - skissane 6y ago
    An airgapped network can include its own internal CA, and all the airgapped clients can have that internal CA's certificate injected into their trust stores, and all the services on the airgapped network can automatically request certificates from the internal CA – which can even be done using the same protocol which Let's Encrypt uses, ACME, just running it over a private airgapped network instead of over the public Internet.
- mrweasel 6y ago
  We have a ton of internal stuff, most of it doesn’t even have external DNS. We use long lived certs signed with our own CA. we’d prefer using and automated solution, using a “real” CA, but non seems to be available.
jogjayr 6y ago
Not quite so crazy now that everyone's working from home, right? Unless you also use a VPN?
- dx034 6y ago
  Even with VPN. I don't want any person on the vpn to be potentially able to read traffic between internal services. I think that would fail many audits.
dx034 6y ago
Which means if someone gets access to the internal network, they can read all traffic. And even dev systems can send confidential data. With letsencrypt and easy to generate certificates, https everywhere is very reasonable.
quotemstr 6y ago
It does though. There's no excuse for unencrypted traffic. Google doesn't have some VPN with squishy unencrypted traffic inside. Everything is just HTTPS. If they can do it, so can you. It's just not that hard to manage a PKI.

scoot_718 6y ago

I mean, I mandate https in dev, but it sure isn't for security. It's so that auth works in dev and no changes are required to push prod

james_s_tayler 6y ago
or someone doesn't accidentally just entirely overlook it and wind up with just http in prod.

dx034 6y ago

I actually think that's valid. Sure, http on a dev machine isn't a security risk. But there is a tail risk that it ends up somewhere on a system that sends data between machines. Also, using http on dev and https on prod can lead to unexpected bugs. Banning http is not unreasonable. Same with the md5 complaint. That use of md5 wasn't a problem but there's a perfectly fine alternative and if you can ensure by automated tests that md5 is used nowhere, you also can guarantee that it's never used in a security relevant context.

skissane 6y ago
> and if you can ensure by automated tests that md5 is used nowhere You can automatically check for the string "md5" in identifiers, but you can't reliably automatically check for implementations of the MD5 algorithm. All it takes is for someone to copy-paste an implementation of MD5 and rename it to "MyChecksumAlgorithm" and suddenly very few (if any) security scanning tools are going to be smart enough to find it. (Foolproof detection of what algorithms a program contains is equivalent to the halting problem and hence undecidable, although as with every other undecidable problem, there can exist fallible algorithms capable of solving some instances but not others.)