Except in airgap environments where there is no CA available to check against.
This makes no sense. Do you believe TLS is somehow impossible on “airgap environments”?
Disabling cert checks: we have not learned much
11–20 of 24 posts
Re: Disabling cert checks: we have not learned much
#12Except in airgap environments where there is no CA available to check against.
Create a local root CA.
You mean create a root CA, install it as a trusted CA on _every single_ client that will interact with the client, manage revocations (whole thing in itself), and handle all the other management that goes along with being an authority (local or otherwise, it makes little difference).
Re: Disabling cert checks: we have not learned much
#13Kind of related, but a little off-topic: I think tying name checking to encrypting traffic was a mistake. They are two different use cases, and shouldn't have been so tightly coupled.
Sometimes I care only about my traffic being encrypted, and resent having to jump through hoops to ignore the name mismatch. Sometimes I care only about assurances that the name is correct, and don't care about having the traffic encrypted.
Re: Disabling cert checks: we have not learned much
#14Kind of related, but a little off-topic: I think tying name checking to encrypting traffic was a mistake. They are two different use cases, and shouldn't have been so tightly coupled. Sometimes I care only about my traffic being encrypted, and resent having to jump through hoops to ignore the name mismatch. Sometimes I care only about assurances that the name is correct, and don't care about having the traffic encryp…
Encryption without authentication is not very useful; if unauthenticated, your ISP could middle-man your connection and effectively decrypt everything while making you think you're encrypted.
If that's not in your threat model, and you want encryption for another purpose, then I could understand that, but currently, protecting the endpoints against malicious attackers in the middle is the big value of TLS.
Re: Disabling cert checks: we have not learned much
#15Kind of related, but a little off-topic: I think tying name checking to encrypting traffic was a mistake. They are two different use cases, and shouldn't have been so tightly coupled. Sometimes I care only about my traffic being encrypted, and resent having to jump through hoops to ignore the name mismatch. Sometimes I care only about assurances that the name is correct, and don't care about having the traffic encryp…
> Sometimes I care only about my traffic being encrypted, and resent having to jump through hoops to ignore the name mismatch.
Why do you care about encryption without authentication? Without TOFU, PKI or a preshared key what is the value?
> Sometimes I care only about assurances that the name is correct, and don't care about having the traffic encrypted.
So signing?
Re: Disabling cert checks: we have not learned much
#16I just today reviewed a PR with a default insecure option. But here we’re working on local networks where there’s no way to get a certificate because there’s not a domain name that points to the local IP address. At least with HTTPS over the local network, it can frustrate attempts to break into it. That said we are sure to call it “https-insecure”.
> But here we’re working on local networks where there’s no way to get a certificate because there’s not a domain name that points to the local IP address. There are options for this, that needn't cost. In a company with controlled workstations, have your own CA and push the trust of that through GP or in your standard OS build, point whatever domain you like (“real” or just a local-only DNS entry) at your host and s…
>There are options for this, that needn't cost.
> In a company with controlled workstations, have your own CA and push the trust of that through GP or in your standard OS build
I'd be surprised if this did not cost when done properly. Securing a (even internal) CA is a whole thing that is not trivial.
Re: Disabling cert checks: we have not learned much
#17[deleted]
Re: Disabling cert checks: we have not learned much
#18Except in airgap environments where there is no CA available to check against.
This makes no sense. Do you believe TLS is somehow impossible on “airgap environments”?
If the root CA is in a place that is inaccessible then there are no CRLs to check against for example. Root CA may exist outside of the airgapped env. Especially if the root CA is one that produces self signed certs. You are back to insecure TLS
Re: Disabling cert checks: we have not learned much
#19Earlier quoted context omitted.
This makes no sense. Do you believe TLS is somehow impossible on “airgap environments”?
If the root CA is in a place that is inaccessible then there are no CRLs to check against for example. Root CA may exist outside of the airgapped env. Especially if the root CA is one that produces self signed certs. You are back to insecure TLS
None of this makes any sense.
A lack of CRL doesn’t make TLS insecure.
A root doesn’t produce “self-signed certificates”. That especially doesn’t make any sense. What do you think the “self” references in “self-signed” certificate?
Add the root to your trust store, if you trust it, and you’re done.
What’s more concerning is someone working on (assumingly) secure, sensitive, air-gapped networks knows this little about TLS?
Re: Disabling cert checks: we have not learned much
#20Earlier quoted context omitted.
> But here we’re working on local networks where there’s no way to get a certificate because there’s not a domain name that points to the local IP address. There are options for this, that needn't cost. In a company with controlled workstations, have your own CA and push the trust of that through GP or in your standard OS build, point whatever domain you like (“real” or just a local-only DNS entry) at your host and s…
>There are options for this, that needn't cost. > In a company with controlled workstations, have your own CA and push the trust of that through GP or in your standard OS build I'd be surprised if this did not cost when done properly. Securing a (even internal) CA is a whole thing that is not trivial.
Its free if you value the time for a few skilled employees to spend maintaining it at $0.