I work at a security company in Berlin, and as part of the work we do with clients, we run phishing campaigns to identify and educate our clients’ employees about the risk of phishing. To do so, we create fake login pages for major services and send phishing emails with links to these pages. Employees who attempt to login or reset the password are shown an educational video or flagged for additional security training. The passwords are never sent to the server, and we do not attempt to store the passwords anywhere.
However, we are currently serving this content over HTTP. To help protect our clients and their employees, we want to begin serving this content over HTTPS with an LE cert. However, we don’t want to be blacklisted for “running phishing sites.” Is there permitted by the various ToS and agreements? If not, how can we work with LE to make this happen?
If your clients trust you enough to run a phishing campaign against their employees and let them login with actual passwords over an unencrypted channel, then you could probably arrange with them a temporary deployment of your own cert as trusted. Of course that works best if they have some means of doing that (like a Group Policy).
If the situation is that the names (Fully qualified domain names, like www.example.com) Let’s Encrypt will be signing for are legitimately controlled by your employer, I don’t think this would conflict with the Let’s Encrypt Terms of Service on its own. For example if you control a site https://sounds-like-tech-support.example/ I don’t see a problem with Let’s Encrypt issuing you a certificate for sounds-like-tech-support.example, a name you indeed control.
Obviously if you want to create sites which appear to have names belonging to other people such as google.com or hsbc.co.uk, issuing you with certificates for those names would conflict not only with the Let’s Encrypt ToS, trust store policies and with the Baseline Requirements but even in many places with criminal law. If you want to do that, @leader’s suggestion above is apposite.
If your sites will have FQDNs you legitimately control but the site contents are intended to mislead any visitor into giving away credentials, regardless of whether they received the phishing email - e.g. the site is https://computer-security.example/ but the banner at the top says “Microsoft IT Support” with a Microsoft logo - there is a risk that people who were NOT intentionally targeted by your client are confused by the site and report it as a phishing attack. You should be aware that it is Microsoft policy that CAs wishing to be trusted in their operating system and browsers (which includes Let’s Encrypt and any successful commercial CA) must obey reasonable instructions from Microsoft to revoke certificates issued to these sites. You wouldn’t be able to work around this by choosing a different CA, although @leader’s suggestion would work here too.
To mitigate the above, one possibility is to arrange for the sites NOT to lie to people who are visiting them spontaneously, so that non-target visitors won’t have anything to report. For example you could include a parameter in the links sent out which indicates the client or even the individual email recipient who clicked the link, and if this parameter is not included when a browser accesses the link, just give them a generic message about your company’s service offering. Or you could check the source IP against a list provided by the client, and show the fake login page only to browsers from that list. Employees of a client should be much less likely to make false reports, and their own IT security people can be directed to suppress reports about the test site you’re providing, so that you’re less likely to annoy Microsoft.
Finally, keep in mind that because Let’s Encrypt is fully automated, it will not be possible for them to issue you with certificates for certain “high risk” FQDNs, for example those confusingly like the names of major international banks, or certain famous Internet brands even if you have legitimate control over such a name. At a traditional CA high risk names are supposed to be subject to manual checks (e.g. a human might want to talk to you on the phone about the name you’re requesting) but Let’s Encrypt doesn’t ever do manual checks so it will always refuse high risk issuance outright.
Thanks for the response. This is already the case. We have a backend that looks for a url parameter that is included in the email and checks it against a database. Only these users are shown a phishing page.
Don't underestimate people willing to share everything for no apparent reason nowadays If the employees are not aware of the "experiment", they pretty much may share a link in a chat, twitter, etc. I'm not kidding, I saw tweets linking development environments and internal resources. Unless for example you explicitly define a range of acceptable IPs and make those parameters to be individual one-time-use tickets basically, those URLs can still be triggered by some unsuspecting third-party.
If the employees are not aware of the "experiment", they pretty much may share a link in a chat, twitter, etc. I'm not kidding, I saw tweets linking development environments and internal resources. Unless for example you explicitly define a range of acceptable IPs and make those parameters to be individual one-time-use tickets basically, those URLs can still be triggered by some unsuspecting third-party.