24
edits
Talk:Software Update: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
No edit summary |
||
| Line 31: | Line 31: | ||
''darin:'' I'm not sure. I suspect that dougt will have some good ideas about this problem. | ''darin:'' I'm not sure. I suspect that dougt will have some good ideas about this problem. | ||
''jmdesp'' We just had a discussion about that in news:npm.crypto. It may require a litle more work to verify what CA the extension is signed under, but it's not really hard. The main point here is that Mozilla would then act as a CA. I emitted the idea that what would be important is not the identity of the person who wants the certificate, but that he has a valuable extension to distribute. We could require that the extension be first made publicly available unsigned, and the certificate granted after a positive community review. | |||
One question then is if we end up issuing many certificates, won't some of the end up badly used ? One solution is that certificate could be linked to an extension, not an individual, so we could use as the id in the cert the GUID of the extension, so that the certificate can be used only for one specific extension. | |||
Then at installation time, we could check the extension by using the Update mechanism and it would restrain us from installing it if it is known that it is dangerous or is a version that has security holes. Peter Gutman raised the issue that for ActiveX, the problem is more the exploitation of vulnerabilities in legit ActiveX than people deliberatly signing evil components. But the mechanism above would cover both. | |||
The one problem left is the risk that the checking of the validity of extension would end up as a major load for the servers. If you can believe it could happen, check the story of Class3SoftwarePublishers.crl at Verisign : | |||
http://www.verisign.com/verisign-inc/news-and-events/news-archive/us-news-2004/page_000738.html | |||
Class3SoftwarePublishers.clr was only 7 Kb, but they would have needed up to 4 Gbit of bandwidth to keep up that day. They minimize the bandwidth by normally restricting the number of request for that file to 1 per month, except that it failed that day and they received ten time the usual number of requests. | |||
---- | ---- | ||
| Line 43: | Line 54: | ||
-look at options for compression of the packages:.... | -look at options for compression of the packages:.... | ||
---- | |||
'''Comments from jmdesp:''' Currently the software update uses an SSL connexion to get the information. How will this scale if we have several millions of clients ? Bouncer will only redirect them after one initial exchange, and with SSL this exchange is a non neglectible amount of data. | |||
It might be better to switch to a model where the security is not insured not through SSL but by sending a signed answer on HTTP, and with DNS level repartition of requests, not http redirect. | |||