Hello @_Val_ , Hello @Ethan_Schorer,
sorry if my comment seemed uncivil, that was not my intention. I will try to explain once more, although I have written all of this (multiple times even) in previous posts already.
The situation is as follows. There's an HTTP port that does two things at once:
1. It offers a CRL distribution point, and
2. It offers a web page that is used for downloading certificate files.
Now, to be absolutely and 100% clear, I am not talking about point 1. Spreading the CRL info over HTTP is okay and RFC conform, this was never my point. I am getting the feeling that you are thinking that this is also something I am having problems with. But it is not, I am NOT talking about this.
The problem that I have been talking about from the start is point 2. The web page is used to distribute CA certificate files over an unencrypted and unauthenticated channel. Once the CA file is installed in the users browser, the browser will accept all certificates signed by this CA. A possible attack scenario would be:
- Get the user/victim to surf to the webpage to download and reinstall the CA certificate file with some sort of social engineering technique. For example, tell him that the certificate needs to be renewed for organizational reasons or whatever else you can think of. It is a well known fact that users easily fall for such social engineering techniques. Alternatively, time your attack such that a user will use this portal anyway (more difficult/less chance of success, of course, since you would need precisely time your attack.
- Mount a man-in-the-middle attack on the victim, i.e. the attacker is able to read and manipulate all the traffic between the webpage and the victim. Note that this is only possible because the webpage and certificate files are being distributed over HTTP.
- During the MitM attack, change the CA certificate in transit to a CA certificate file to which you as the attacker know the secret keys. Since you're a MitM and the channel is not authenticated, the victim will not notice this change.
- The victim will now install a malicious CA certificate in his browser.
- Since the attacker knows the secret keys of the CA certificate, he can now easily fake certificates and mount MitM attacks on arbitrary websites and completely read and manipulate the whole internet traffic of the victim.
- Note that in this whole scenario the user/victim probably puts a high level of trust on this page, since it is in the internal network on a company server. Since its original purpose is also to distribue CA certificate files, the user/victim will not be be "surprised" that he needs to download and install a CA certificate from there.
I have described other attacks above, like faking the webpage to look like some login page (since everything is transported over HTTP, attackers can completely change the look and feel of the site) to steal credentials and so on. This is however not really the central problem. The central problem is that users trust this website to distribute CA files.
While the risk might not be extremly high/critical (as I have also stated from the start), it is still an unnecessary risk. Simply offer an option to remove the CA certificate file download from this port and only use it for CRL. Done. That is literally all you need to do and to offer to your users to remove this risk.
"I do not recall a single case of it is being abused or exploited" - I could clearly demonstrate the above attack path to my clients and if this would have been a red team assignment, I would have easily been able to exploit it. Note that this argument can also be used for every type of vulnerability and that it is also notoriously difficult to pinpoint the origin of an attack.