On Tue, Mar 16, 2021 at 6:02 PM Pablo Díaz via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> Said "additional" confirmation email, addressed to the domain > administrator, informs them that [Applicant Data] has requested an SSL > certificate for their domain [Domain] by [Request ID] request, and > instructs them to access a link (valid for 29 days, the email indicates the > expiration date) where they can manually confirm or reject the request by > clicking Confirm/Reject buttons. Can you describe more here? There are gaps here which seem to allow any number of insecure implementations. For example: - Sending a link that must be accessed to approved is known-insecure, as automated mail scanning software may automatically dereference links in e-mail (in order to do content inspection). Confirm/Reject buttons alone shouldn't be seen as sufficient to mitigate this, as that may vary based on how the crawler works. Requiring explicit entry of the random value is a necessary "human" measure (aka similar to a CAPTCHA) - You haven't described how the email address is constructed for these cases. The BRs only permit you to reuse the Random Value for 3.2.2.4.2, and if and only if the domain contact is the same for all of the requested domains. If, for example, you're using 3.2.2.4.4 (your #1 example), it would be inappropriate if hostmaster@apex1.example could approve a request for apex2.example, yet, as currently described, that seems to be possible, in that both hostmaster@apex1.example and hostmaster@apex2.example will receive the same Request ID to approve/reject the request. The reliance on 3.2.2.4.2 is also known to be dangerous (in that it relies on human inspection or OCR of otherwise unstructured text), which is why it's discouraged compared to other methods (like .7, .19, or .20, and if using e-mail, .13, .14). It's unclear how you extract the emails from the WHOIS results that you provide, and whether that's something the IRM performs or whether that's somehow programmatically driven. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
