search

Upinel / localhost.direct

localhost with public CA signed SSL certificate
392 stars 12 forks source link

Violation of CA/Browser Forum Baseline Requirements #19

Open BenBE opened 1 day ago

BenBE commented 1 day ago

Without trying to spoil your fun, but the way this project is setup is in violation of the CA/Browser Forum Baseline Requirements section 9.6.3. In particular:

The Subscriber Agreement or Terms of Use MUST contain provisions imposing on the Applicant itself (or made by the Applicant on behalf of its principal or agent under a subcontractor or hosting service relationship) the following obligations and warranties:

  1. Accuracy of Information: An obligation and warranty to provide accurate and complete information at all times to the CA, both in the certificate request and as otherwise requested by the CA in connection with the issuance of the Certificate(s) to be supplied by the CA;
  2. Protection of Private Key: An obligation and warranty by the Applicant to take all reasonable measures to assure control of, keep confidential, and properly protect at all times the Private Key that corresponds to the Public Key to be included in the requested Certificate(s) (and any associated activation data or device, e.g. password or token);
  3. Acceptance of Certificate: An obligation and warranty that the Subscriber will review and verify the Certificate contents for accuracy;
  4. Use of Certificate: An obligation and warranty to install the Certificate only on servers that are accessible at the subjectAltName(s) listed in the Certificate, and to use the Certificate solely in compliance with all applicable laws and solely in accordance with the Subscriber Agreement or Terms of Use;
  5. Reporting and Revocation: An obligation and warranty to: a. promptly request revocation of the Certificate, and cease using it and its associated Private Key, if there is any actual or suspected misuse or compromise of the Subscriber’s Private Key associated with the Public Key included in the Certificate, and pg. 114 b. promptly request revocation of the Certificate, and cease using it, if any information in the Certificate is or becomes incorrect or inaccurate;
  6. Termination of Use of Certificate: An obligation and warranty to promptly cease all use of the Private Key corresponding to the Public Key included in the Certificate upon revocation of that Certificate for reasons of Key Compromise.
  7. Responsiveness: An obligation to respond to the CA’s instructions concerning Key Compromise or Certificate misuse within a specified time period.
  8. Acknowledgment and Acceptance: An acknowledgment and acceptance that the CA is entitled to revoke the certificate immediately if the Applicant were to violate the terms of the Subscriber Agreement or Terms of Use or if revocation is required by the CA’s CP, CPS, or these Baseline Requirements.

Furthermore you can take this even as far a section 4.9.1.1 of the same document:

4.9.1.1 Reasons for Revoking a Subscriber Certificate

The CA MAY support revocation of Short‐lived Subscriber Certificates. With the exception of Short‐lived Subscriber Certificates, the CA SHALL revoke a Certificate within 24 hours and use the corresponding CRLReason (see Section 7.2.2) if one or more of the following occurs:

  1. The Subscriber requests in writing, without specifying a CRLreason, that the CA revoke the Certificate (CRLReason “unspecified (0)” which results in no reasonCode extension being provided in the CRL);
  2. The Subscriber notifies the CA that the original certificate request was not authorized and does not retroactively grant authorization (CRLReason # 9, privilegeWithdrawn);
  3. The CA obtains evidence that the Subscriber’s Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise (CRLReason # 1, keyCompromise); pg. 44
  4. The CA is made aware of a demonstrated or proven method that can easily compute the Subscriber’s Private Key based on the Public Key in the Certificate (such as a Debian weak key, see https://wiki.debian.org/SSLkeys) (CRLReason # 1, keyCompromise);
  5. The CA obtains evidence that the validation of domain authorization or control for any Fully‐Qualified Domain Name or IP address in the Certificate should not be relied upon (CRLReason # 4, superseded). With the exception of Short‐lived Subscriber Certificates, the CA SHOULD revoke a certificate within 24 hours and MUST revoke a Certificate within 5 days and use the corresponding CRLReason (see Section 7.2.2) if one or more of the following occurs:
  6. The Certificate no longer complies with the requirements of Section 6.1.5 and Section 6.1.6 (CRLReason # 4, superseded);
  7. The CA obtains evidence that the Certificate was misused (CRLReason # 9, privilegeWithdrawn);
  8. The CA is made aware that a Subscriber has violated one or more of its material obligations under the Subscriber Agreement or Terms of Use (CRLReason # 9, privilegeWithdrawn);
  9. The CA is made aware of any circumstance indicating that use of a Fully‐Qualified Domain Name or IP address in the Certificate is no longer legally permitted (e.g. a court or arbitrator has revoked a Domain Name Registrant’s right to use the Domain Name, a relevant licensing or services agreement between the Domain Name Registrant and the Applicant has terminated, or the Domain Name Registrant has failed to renew the Domain Name) (CRLReason # 5, cessationOfOperation);
  10. The CA is made aware that a Wildcard Certificate has been used to authenticate a fraudulently misleading subordinate Fully‐Qualified Domain Name (CRLReason # 9, privilegeWithdrawn);
  11. The CA is made aware of a material change in the information contained in the Certificate (CRLReason # 9, privilegeWithdrawn);
  12. The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA’s Certificate Policy or Certification Practice Statement (CRLReason # 4, superseded);
  13. The CA determines or is made aware that any of the information appearing in the Certificate is inaccurate (CRLReason # 9, privilegeWithdrawn);
  14. The CA’s right to issue Certificates under these Requirements expires or is revoked or terminated, unless the CA has made arrangements to continue maintaining the CRL/OCSP Repository (CRLReason “unspecified (0)” which results in no reasonCode extension being provided in the CRL);
  15. Revocation is required by the CA’s Certificate Policy and/or Certification Practice Statement for a reason that is not otherwise required to be specified by this section 4.9.1.1 (CRLReason “unspecified (0)” which results in no reasonCode extension being provided in the CRL); or
  16. The CA is made aware of a demonstrated or proven method that exposes the Subscriber’s Private Key to compromise or if there is clear evidence that the specific method used to generate the Private Key was flawed (CRLReason # 1, keyCompromise).

Emphasis mine …

Or let's summarize:

In particular: Even if you were to implement a portal website where each user would receive their own key/certificate pack (good luck with rate limits on Lets Encrypt services), you are violating the first point. The current implementation of things violates the second point.

TL;DR: Just don't do this. Learn how to run ACME, certbot, Caddy, dehydrated, or any of the many alternatives locally for yourself without relying on third parties to generate a key for you.

NB: All globally issued certificates that are trusted in browsers by default are publicly visible. For this project's domain that list can be seen here.

Upinel commented 1 day ago

Thanks for your contribution and summarized. It is so nice to have you to summarize those

Yes, I've read the requirements and consulted some CA repo about that. Although using a private key that you didn't create yourself is doing it wrong, in reality, it is more like an ethical suggestion, not a regulation. As an example, you can share the key and cert bundle with your outsourcing developers, which is also violating the first one de facto. (and technically, if you use Cloudflare or Github Pages or Wix, you are not using a private key created by yourself anyway) If we assume we are virtually in the same development group, that will make sharing the same key for development a totally sensible action, although you may argue the "hidden agenda" of the development group’s act is not truly sincere.

The reason behind our key being revoked is based on "suffered a Key Compromise to the public", which is totally sensible. As the CA nature, I totally support the act of the CA revoking the key due to "potential" harm to the client as the private key being compromised to the public, which makes the key no longer secure. So we are looking for a solution in this angle. In fact, I am keeping in communication with three major CA, and we all agreed as long as the "key is not compromised to the public", it will not be their business to control how their subscribers use their key pairs.

Thus, one of the main possible ways is, which I hope in the long run can achieve, is signing with a major CA with an unlimited issuing on the same domain name pricing, but it could be slightly expensive. (but actually not rocket expensive, more like a corporate plan level pricing), so it can provide different users with their own key pair. (again, using a private key that you didn't create yourself is just a "should do" suggestion, not really a regulation or the reason why the key revoke, Cloudflare technically doing the same thing)

But anyway, the worst situation will be (lack of money), we can still use as a non-HTTPS tools. :D

p.s. I have a law background. It is ethically not correct (not truly sincere using something), but not sincere doesn't make it illegal or breaking the regulations.

But still, I think you are really helpful and I truly thank you for your work. It takes me many hours to do the research, but you helped us to summarize it for everyone, which is really important. For a production environment, we must let all developers know it is extremely important to protect your private key, and leaking a private key can really result in damage to your product. So, your summary is so important, that's why I tag a Star in this discussion.

BenBE commented 10 hours ago

I thought, that by pointing at the very document that causes your certificates to get revoked repeatedly, I could maybe cause some rethinking of why the overall project is a bad idea, but well … Hope dies last, but it dies.

That said, counter to your point regarding being a lawyer, I should maybe add, that I have worked for a CA as software lead. So if you can stop sputtering my name all over the place, representing things as if I were to endorse this project, I'd be most grateful. This also includes removing mentions of my name in any Git commits.

Formal stuff aside, on to the technical stuff.

Unless the only thing you see of a "LHD developer" is a CSR with their public key, you still do not have an improvement over the status quo. And even then, any "LHD developer" can technically impersonate and MITM any traffic on your domain: This includes spoofing your get.localhost.direct website. Thus the more (private) keys exist for your domain, the more likely is a risk of compromise and attack. The current risk analysis for this project is (to put it mildly) lacking.

On to your "ToS": Legally they are "interesting"; and that's not the positive kind … The construct you create effectively creates an unregistered entity with shared, unlimited liability, where anyone could be sued just because someone else did something wrong. And I doubt they are actually enforceable.

Which leaves the other point regarding the CABF BR: Not part of the text I quoted (but just around the corner in section 9.6) are some requirements for CAs regarding applicants, one of which is that the CA should be able to enforce their ToS against the applicant. The applicant on the other hand is required to ensure the private key is kept under their (sole) control, which you simply cannot if you are distributing it to random people. I your earlier reply you mentioned hosting and cloud providers. While these technically do the same (generate a key, request the certificate), they are acting on behalf of the applicant and thus also need to ensure, that the documents they see (including private keys) are properly protected. In your current setup, you are not acting on behalf of some "LHD developer", but as a service provider who offers the service of leaking their own private key to anyone who asks (BTW: you might have noticed my mail regarding keys used in the past, looking forward to a reply on that one).

Also, by providing a service, you technically fall under the GDPR and similar regulations.

And one last point: One thing currently mostly brushed under the carpet is the whole question of revocation, which going back to the CABF BR, requires the applicant to cease using the certificate once it's revoked. You can't enforce this even if you were to put it in the "ToS" unless you had proper controls in place.

TL;DR: Teach people how to do ACME to setup proper certificates automatically instead.

Upinel commented 8 hours ago

Hi BenBE,

You've got some good points. And for me, it is a very good learning experience to discuss with you. localhost.direct is a non-revenue project, and I am happy to use it on my own so I make it accessible to everyone. A bad idea doesn't make an idea that should be terminated. Let's Encrypt is also a bad idea, but it doesn't make it a helpful service.

  1. Regarding MITM attacks, yes, I do think there is a risk of DNS pollution and MITM attacks happening at the same time. Developers might be directed to a MITM website. But, due to the nature of localhost.direct, it is just pointing to 127.0.0.1 and is only for developers, which makes it a very tricky and different situation compared to general MITM website. In theory, even if hackers or government bodies polluted the DNS record, developers using this might be guided to a third-party server, but it is still impossible to fake a site that they don't have the idea of what it originally is. So the risk is minimal, although it is “technically” possible.
  2. In terms of GDPR, as an expert in this field, it doesn't seem like GDPR is doing anything on this. GDPR cares about data leaks (data leak =/= certificate leak, and if a project is designed to do so, you cannot call it a leak). It is the same as using localhost (which lives in every computer’s hosts file) with poor security code. Simply put, GDPR does not care about SSL or certificates; they only care about data leaks and data processor, and data leaks are on the code and operation level.
  3. In terms of "unregistered entity", it really depends on where you live. If you live in a country such as China, having a website itself might require registration, but in my country, it doesn't. And what you've mentioned of unlimited liability, in fact, also challenging MIT/Apache license liability on their open-source project "contributor". Tort law doesn’t work like that.

Despite our discussion, I still think you've provided me with many insights, and I do think you are in good faith and a good developer. IT IS A BAD IDEA, of course, but it WORKS. ACME sometime is really not a choice for some people, so early-stage developers are using their company computers to learn coding, and they are unfortunately really not supposed to focus certificate stuff at this early learning stage. Programming is a very steep learning curve; it is extremely difficult at the beginning. And they really need something like this. As an ex-software lead in CA, the community really needs your insight on helping us find out a way that works within the scope and working "just OK", even if it isn't a perfect idea.

//Upinel

Upinel commented 8 hours ago

Personally, this project is non-revenue project for the developers' community. I have nothing to lose if it ceases to exist. Ultimately, I can still use it for my development work regardless how it goes. The only downside is the community that genuinely needs it.

So, please share your knowledge to help it become "just OK". The community needs you.