Mozilla plans to ask all certificate authorities to review their subordinate CA certificates and revoke those that could be used by companies to inspect SSL-encrypted traffic for domain names they don’t control.
The plan, for which details are still being worked out, is Mozilla’s response to Trustwave’s recent claim that the use of such certificates for SSL (Secure Sockets Layer) traffic management within corporate networks is a common practice.
After a week of debating whether to punish Trustwave for violating its CA Certificate Policy, Mozilla has decided to send out a communication to all certificate authorities requesting them to come clean about similar certificates and to revoke them.
“My intent is to make it clear that this type of behaviour will not be tolerated for subCAs chaining to roots in NSS [Mozilla’s Network Security Services], give all CAs fair warning and a grace period, and state the consequences if such behaviour is found after that grace period,” said Kathleen Wilson, the owner of Mozilla’s CA Certificates Module.
The grace period extended to CAs, for the revocation of sub-CA certificates currently used for the inspection of SSL-encrypted traffic on corporate networks, has not been decided yet, but according to Wilson, a time frame of two or three months is being considered.
After that, anyone caught with such a certificate would have their root key removed from Mozilla’s products and all certificates they ever signed would result in an error when opened in the browser.
A grace period is necessary because the companies that deployed traffic-monitoring products with sub-CA certificates on their networks are probably very large enterprises that would need time to implement alternative solutions, Wilson said on the mozilla.dev.security.policy mailing list.
However, according to Amichai Shulman, chief technology officer at security firm Imperva, three months will probably not be enough to accommodate such changes. Six months would be more reasonable, he said.
Many companies that inspect SSL-encrypted traffic on their networks in order to prevent data leaks or detect internal policy violations, generate their own root certificate and deploy it on all of their end-point devices. The time required to do this varies depending on the number of devices and their type.
Shulman was surprised to hear Trustwave’s claim that this is a common practice in the industry, because in his opinion the use of sub-CA certificates for the purpose of monitoring enterprise communications is irresponsible, given the worldwide implications of such a certificate being stolen.
Mozilla is right in demanding this practice to stop, he said. However, he doubts that the company can enforce a change without help from other browser vendors.
That’s because removing a CA certificate from its products for a policy violation will result in users not being able to access websites secured with certificates issued by that particular CA. Unless users will receive similar certificate errors in other browsers, they’ll think it’s a problem will Firefox and switch to something else, Shulman said.
Other people participating in the discussion on the mozilla.dev.security.policy mailing list don’t agree that CAs should be offered a grace period. One argument is that companies engaged in man-in-the-middle SSL traffic inspection could simply stop doing it until they roll out an alternative solution.
Others feel that Mozilla shouldn’t send a communication to CAs for the sole purpose of requesting disclosure of something that clearly violates their policy.
“Look, Mozilla has a policy, there is no reason to require something that doesn’t comply to the policy anyway,” said Eddy Nigg, CTO of StartCom and StartSSL in an email to the mailing list. “The policy hasn’t changed and I’d advise Mozilla to apply its own policy, simply as that.”
View full post on National Cyber Security » Computer Hacking