Re: New article on root certificate problems with Windows
Paul Hoffman [EMAIL PROTECTED] writes: At 2:45 AM +1200 7/20/07, [EMAIL PROTECTED] wrote: |From a security point of view, this is really bad. From a usability point of |view, it's necessary. As you can see from my list of proposed solutions, I disagree. I see no reason not to to alert a user *who has removed a root* that you are about to put it back in. It depends on what you mean by user. You're assuming that direct action by the wetware behind the keyboard resulted in its removal. However given how obscure and well-hidden this capability is, it's more likely that a user agent acting with the user's rights caused the problem. So the message you end up communicating to the user is: Something you've never heard of before has changed a setting you've never heard of before that affects the operation of something you've never heard of before and probably wouldn't understand no matter how patiently we explain it. (those things are, in order some application or script, the cert trust setting, certificates, and PKI). I guess we'd need word from MS on whether this is by design or by accident, but I can well see that quietly unbreaking something that's broken for some reason would be seen as desirable behaviour. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: New article on root certificate problems with Windows
At 7:58 PM +1200 7/20/07, [EMAIL PROTECTED] wrote: Paul Hoffman [EMAIL PROTECTED] writes: At 2:45 AM +1200 7/20/07, [EMAIL PROTECTED] wrote: |From a security point of view, this is really bad. From a usability point of |view, it's necessary. As you can see from my list of proposed solutions, I disagree. I see no reason not to to alert a user *who has removed a root* that you are about to put it back in. It depends on what you mean by user. You're assuming that direct action by the wetware behind the keyboard resulted in its removal. Correct, I was. However given how obscure and well-hidden this capability is, it's more likely that a user agent acting with the user's rights caused the problem. So the message you end up communicating to the user is: Something you've never heard of before has changed a setting you've never heard of before that affects the operation of something you've never heard of before and probably wouldn't understand no matter how patiently we explain it. (those things are, in order some application or script, the cert trust setting, certificates, and PKI). Very good point. Bigger picture takeaway: when both a user and an application can change a crypto setting in an application (or OS), any later messages relating to that event are likely to be confusing because they can't be directly linked to the action. This applies to all of our crypto-in-the-real-world, not just the trust anchor issue at hand. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: New article on root certificate problems with Windows
(I don't have access to windoze... cannot verify if my suggestion would work...) Can't you replace the installed root certs with empty files or bogus content such that they will fail path validation and still trick MS not to re-install them? -Frank. Jeffrey Altman wrote: [EMAIL PROTECTED] wrote: The executive summary, so I've got something to reply to: In the default configuration for Windows XP with Service Pack 2 (SP2), if a user removes one of the trusted root certificates, and the certifier who issued that root certificate is trusted by Microsoft, Windows will silently add the root certificate back into the user's store and use the original trust settings. While I don't agree with this behaviour, I can see why Microsoft would do this, and I can't see them changing it at any time in the future. It's the same reason why they ignore key usage restrictions and allow (for example) an encryption-only key to be used for signatures, and a thousand other breaches of PKI etiquette: There'd be too many user complaints if they didn't. The real flaw that I see in their design is that they permit certificates that they installed to be removed. Instead they should have provided a disabled feature so that those who wish to disable installed certs can do so and thereby ensure that in the future they won't be restored. Jeffrey Altman -- Frank Siebenlist [EMAIL PROTECTED] The Globus Alliance - Argonne National Laboratory - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: New article on root certificate problems with Windows
Paul Hoffman [EMAIL PROTECTED] writes: I posted a new security research article at http://www.proper.com/root-cert-problem/. It is not directly related to crypto (although not so much of the traffic on this list is...), it does relate to some PKI topics that are favorites of this list. The executive summary, so I've got something to reply to: In the default configuration for Windows XP with Service Pack 2 (SP2), if a user removes one of the trusted root certificates, and the certifier who issued that root certificate is trusted by Microsoft, Windows will silently add the root certificate back into the user's store and use the original trust settings. While I don't agree with this behaviour, I can see why Microsoft would do this, and I can't see them changing it at any time in the future. It's the same reason why they ignore key usage restrictions and allow (for example) an encryption-only key to be used for signatures, and a thousand other breaches of PKI etiquette: There'd be too many user complaints if they didn't. The people designing this stuff aren't the ones who have to man the tech helpdesk when users find that things break because of some action that they don't even understand (see e.g. the Xerox PARC study where a bunch of people with PhDs in computer science, after following paint-by-numbers instructions to install certs on their machines, had absolutely no idea what they'd just done to their computers). From a security point of view, this is really bad. From a usability point of view, it's necessary. The solution is to let the HCI people into the design process, something that's very rarely, if ever, done in the security field [0]. Peter. [0] Before people jump up and down about this: Yes, HCISec has become a very active and productive field in the last few years. Unfortunately far too little of the work that's being done is making it into products though. We have lots of data saying X is unusable in practice and The best way to handle this is Y, but developers keep on pushing X and avoiding (or don't even know about) Y. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: New article on root certificate problems with Windows
At 2:45 AM +1200 7/20/07, [EMAIL PROTECTED] wrote: From a security point of view, this is really bad. From a usability point of view, it's necessary. As you can see from my list of proposed solutions, I disagree. I see no reason not to to alert a user *who has removed a root* that you are about to put it back in. Note that I did not criticize the practice of starting with a zillion roots that Microsoft trusts. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: New article on root certificate problems with Windows
[EMAIL PROTECTED] wrote: From a security point of view, this is really bad. From a usability point of view, it's necessary. I agree with all the above, including deleted. The solution is to let the HCI people into the design process, something that's very rarely, if ever, done in the security field [0]. To jump up and down ... if that was the solution, it would have been done by now :) I would instead state that the solution was whatever Skype and SSH did. And the opposite of whatever IPSec, SSL, Clipper, S/MIME, DRM, and all the other failures did. HCI was one of the things, but others were as important: lack of open critique, service-before-security, crypto-for-free, total solution, narrow problem, etc. iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: New article on root certificate problems with Windows
[EMAIL PROTECTED] wrote: The executive summary, so I've got something to reply to: In the default configuration for Windows XP with Service Pack 2 (SP2), if a user removes one of the trusted root certificates, and the certifier who issued that root certificate is trusted by Microsoft, Windows will silently add the root certificate back into the user's store and use the original trust settings. While I don't agree with this behaviour, I can see why Microsoft would do this, and I can't see them changing it at any time in the future. It's the same reason why they ignore key usage restrictions and allow (for example) an encryption-only key to be used for signatures, and a thousand other breaches of PKI etiquette: There'd be too many user complaints if they didn't. The real flaw that I see in their design is that they permit certificates that they installed to be removed. Instead they should have provided a disabled feature so that those who wish to disable installed certs can do so and thereby ensure that in the future they won't be restored. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
