Re: Improving SSL client auth and bad certificate reporting in non-browser applications
On 26/03/10 19:04, Kai Engert wrote: thanks a lot for your feedback. I've created a graphical presentation for the client authentication part: http://kuix.de/mozilla/sslauth/cli-v1-pres/ I still haven't had a chance to look at this :-(( I'm very sorry. (I do have a good excuse, though: http://weblogs.mozillazine.org/gerv/archives/2010/04/a_speech_for_easter_sunday.html) Gerv -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Improving SSL client auth and bad certificate reporting in non-browser applications
On 26.03.2010 13:44, Gervase Markham wrote: The basic idea is to show an indicator in chrome whenever a site asks for client authentication, and give the user full control over using a personal certificate for authentication (or not using one). The interface should also support persistent configuration, per site. It should be powerful enough to support complex sites and work with appearing/disappearing certs which are stored on smartcards. From reading the documents, it's clear that we do have a difficult simplicity/power tradeoff to make here. In order to help make it, do we have any statistics or ideas how common it is to have scenarios like: - A page whose components and subcomponents together require auth using more than one client certificate - A page where the top level does not require a client certificate but sub-parts do In the previous explanations I proposed to always have the user go through two clicks: - clicks the icon - gets a menu popup with a list of sites - clicks the site name the user want to control While this is powerful enough to handle any sites, it may be unnecessarily complicated when dealing with simple scenarios, e.g. if all content originates from a single host. Here's a modification of that idea, let's consider a site that uses three different hosts, www.site.com, subcontent.site.com, images.site.com User clicks icon and we show this menu: www.site.com (disabled menu item) x Logged out Authenticate using my Certificate... -- Settings for additional sites... (Whenever there is only a single site using client auth, we could hide the Settings for additional sites menu item.) If cou click the Authentication for additional sites... we can open a sub-menu that lists the above for each site involved. www.site.com (disabled menu item) x Logged out Authenticate using my Certificate... -- Settings for additional sites... subcontent.site.com x Logged out Authenticate using... --- images.site.com x Logged out Authenticate using... --- --- --- More sites... If the user authenticates using a certificate, we could show the following menu: www.site.com (disabled menu item) Log out x Authenticated (Kai Engert, StartCom Free Certificate Member) Authenticate using a different Certificate... -- Settings for additional sites... In my earlier proposal I said we should use two separate icons, and group the lists of logged out and logged in sites separately. The above proposal combines both lists into a single list, and may be easier to work with. However, I still believe that we sometimes need to show two icons in parallel, to indicate the some logged in, some logged out scenario. Kai -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Improving SSL client auth and bad certificate reporting in non-browser applications
On 28.03.2010 06:19, Nelson B Bolyard wrote: The sequence of events in the dialog is likely, IMO, to give the users the impression that client authentication is a user-initiated act, rather than a server initiated act. It seems to say to the user, if you want to authenticate to this server with your cert, you select your cert and click here. yes: ... you click here (the icon), you select your cert, then the browser or the user will reload ... I gather that the intent is that the browser will (re)initiate an https request to the server(s) in response to that click. yes, after the user selects a different authentication (use a cert, use a different cert, don't use a cert) in the dialog. But there is no assurance that the server will request client auth when the subsequent requests are sent. I think this is likely to lead to a lot of inquiries/complaints from users, asking why can't I authenticate to this site whenever I want to?. Thanks for making us aware of this scenario (server requests auth on first connect, but doesn't on subsequent connects). I think we can address your scenario with the following application behaviour: If we're connecting to a site and the site requests client auth, we will look up our stored configuration. If we can't find any stored configuration for the site, then, do the same as we do today, and show a prompt (the same prompt as used for the configuration, which is similar to today's client auth prompt). It will be a one-time automatic prompt (for this site). The action chosen by the user (use or cert or do not use a cert) can be remembered as the future default (for this site). In the future, if the user connects to the site, we don't need to bother the user with a prompt. We'll either use a cert or not use a cert, and indicate it showing the respective icon (allowing the user to click and change her mind). Would this work? In addition, a site that requests a client cert only once, and on failure will never ask again, probably isn't very smart. I'd expect any reasonable site must deal with the possibility that a user doesn't send a cert on first attempt. A site must make it possible to retry in some way. If the user notes the request to authentication, then configures to use a cert, then uses the site's mechanisms to retry, I think we have achieved our goal. Does this make sense? Also, what are those icons supposed to represent? The first icon is supposed to show a closed barrier, like the ones used at streets on border crossings, or at railway crossings. It means site requested a cert, but we're not sending a cert to the site. The second icon is supposed to show an open barrier combined with a passport. It means a site requested a cert, and we're sending a cert. It looks to me like a book and a light beam, where the book eventually interrupts the light beam, much as objects on a conveyor belt at a supermarket checkout break the light beam which stops the belt. Perhaps that's not what it's showing me, but if it is, that doesn't suggest to me anything having to do with authentication. But this is a minor point. I'm sure that suitable icons can be found. I'm not a graphics artist. I don't propose to use these icons as is. But people asked for a mockup, and here you are. :-) Kai -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Improving SSL client auth and bad certificate reporting in non-browser applications
On 2010-03-26 12:04 PST, Kai Engert wrote: On 26.03.2010 13:44, Gervase Markham wrote: I've been looking at your documents, but I do think this is a case where a picture is worth a thousand words. Do you have any plans to provide UI mockups? Hi Gerv, thanks a lot for your feedback. I've created a graphical presentation for the client authentication part: http://kuix.de/mozilla/sslauth/cli-v1-pres/ Some more explanations: There isn't a lot of UI involved, besides some icons and a configuration dialog with dynamic content (see ASCII screenshot in the client authentication document, pages 7 and 8). (For each icon there'd be a related menu command for accessibility.) When an icon is clicked, you'd get a popup menu with the list of related sites (connection attempt or currently authenticated). If there's just one related site, we could jump to the config dialog directly. The sequence of events in the dialog is likely, IMO, to give the users the impression that client authentication is a user-initiated act, rather than a server initiated act. It seems to say to the user, if you want to authenticate to this server with your cert, you select your cert and click here. I gather that the intent is that the browser will (re)initiate an https request to the server(s) in response to that click. But there is no assurance that the server will request client auth when the subsequent requests are sent. I think this is likely to lead to a lot of inquiries/complaints from users, asking why can't I authenticate to this site whenever I want to?. Also, what are those icons supposed to represent? It looks to me like a book and a light beam, where the book eventually interrupts the light beam, much as objects on a conveyor belt at a supermarket checkout break the light beam which stops the belt. Perhaps that's not what it's showing me, but if it is, that doesn't suggest to me anything having to do with authentication. But this is a minor point. I'm sure that suitable icons can be found. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Improving SSL client auth and bad certificate reporting in non-browser applications
Hi Kai, I've been looking at your documents, but I do think this is a case where a picture is worth a thousand words. Do you have any plans to provide UI mockups? On 16/03/10 23:12, Kai Engert wrote: In short, we'd like to stop the current prompts and implement a better user interface. I think that it would be extremely wise to include Mozilla's UI design community as we look for a solution to these problems. Do you have any plans to reach out to them? I notice your message was not cross-posted to mozilla.dev.usability... You mentioned Aza's previous post. Has he looked at your proposals? The basic idea is to show an indicator in chrome whenever a site asks for client authentication, and give the user full control over using a personal certificate for authentication (or not using one). The interface should also support persistent configuration, per site. It should be powerful enough to support complex sites and work with appearing/disappearing certs which are stored on smartcards. From reading the documents, it's clear that we do have a difficult simplicity/power tradeoff to make here. In order to help make it, do we have any statistics or ideas how common it is to have scenarios like: - A page whose components and subcomponents together require auth using more than one client certificate - A page where the top level does not require a client certificate but sub-parts do ? Although we have a good solution in the browser (show an error page, allow override), the solution in non-browser applications (e.g. Thunderbird) is inferior. Why do you say that? Non-browser applications are very different to browsers. For mail, for example, you do not add and remove dozens of mail servers on a daily basis. As long as the software allows you to remember an override, I don't think there's an issue in using a popup in this case. Instead, we should use an error status indicator in the chrome (for one or multiple failures), I think the risk is that such an indicator would not be noticed, and the user would be confused when their application didn't work. Gerv I've described both ideas in detail in two documents which I've uploaded here: http://kuix.de/mozilla/sslauth/ -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Improving SSL client auth and bad certificate reporting in non-browser applications
On 26.03.2010 13:44, Gervase Markham wrote: I've been looking at your documents, but I do think this is a case where a picture is worth a thousand words. Do you have any plans to provide UI mockups? Hi Gerv, thanks a lot for your feedback. I've created a graphical presentation for the client authentication part: http://kuix.de/mozilla/sslauth/cli-v1-pres/ Some more explanations: There isn't a lot of UI involved, besides some icons and a configuration dialog with dynamic content (see ASCII screenshot in the client authentication document, pages 7 and 8). (For each icon there'd be a related menu command for accessibility.) When an icon is clicked, you'd get a popup menu with the list of related sites (connection attempt or currently authenticated). If there's just one related site, we could jump to the config dialog directly. I'd put the icons on the status bar, but I'm fine with any location in primary chrome. If neither client auth nor bad certs are involved, all icons are hidden. On 16/03/10 23:12, Kai Engert wrote: In short, we'd like to stop the current prompts and implement a better user interface. I think that it would be extremely wise to include Mozilla's UI design community as we look for a solution to these problems. Sure! Do you have any plans to reach out to them? I notice your message was not cross-posted to mozilla.dev.usability... You mentioned Aza's previous post. Has he looked at your proposals? I made Aza and Johnathan aware the day I posted the documents here, but I'm still waiting for their feedback. I'm fine to cross-post. I believe the concept related the logged in = using authentication state is similar or identical to Aza's post. The differences are: - the location where the indicator is shown (I don't mind where exactly it will be shown, but would highly prefer the same location for both authenticated and not authenticated icons.) - the contents shown in the indicator (I propose an icon, while Aza used a john @ prefix in the URL bar, which may be difficult to do when using client certificates, because of the difficulty to derive a short unique name from a cert containing a potentially very long common name (CN). (Although Axel Hecht had the inspiring idea to allow a user to assign short nicknames to each personal cert.)) From reading the documents, it's clear that we do have a difficult simplicity/power tradeoff to make here. I hope we can find a solution that is acceptable to UI designers for simple scenarios, but powerful enough to cover advanced scenarios, (without requiring background configuration to enable advanced modes). In order to help make it, do we have any statistics or ideas how common it is to have scenarios like: I don't have any statistics. As of today there are probably not too many sites on the web using client authentication, but that may also be related to the fact that it's difficult to use with browsers. It may change once we make it easier to work with. - A page whose components and subcomponents together require auth using more than one client certificate - A page where the top level does not require a client certificate but sub-parts do Even if a single certificate is sufficient to access all components, the components may be located on multiple hosts, like html.site.com and images.site.com and private.site.com, and the user needs to control where to present the site, and where not. I agree it's an advanced scenario that sites should avoid, but some may not. There may be existing complex sites where there's the desire to start using client auth, and where it may be hard to consolidate to single hosts. Automatic sending of client authentication credentials is considered a privacy issue, that's why Mozilla software currently doesn't send it by default. For the same reason I would not automatically send authentication data for sub content on separate domains, even thought the user has agreed to authenticate with the main page. Although we have a good solution in the browser (show an error page, allow override), the solution in non-browser applications (e.g. Thunderbird) is inferior. Why do you say that? Because click-through is being considered bad. Non-browser applications are very different to browsers. For mail, for example, you do not add and remove dozens of mail servers on a daily basis. As long as the software allows you to remember an override, I don't think there's an issue in using a popup in this case. Let's say you have your mail server configured. Now you're in an Internet Cafe, someone MITMs you, and you get a cert warning for your mail server cert. As people tend to click-through warnings, so we should make it more difficult for this attack scenario to work. Instead, we should use an error status indicator in the chrome (for one or multiple failures), I think the risk is that such an indicator would not be
Re: Improving SSL client auth and bad certificate reporting in non-browser applications
On 03/26/2010 10:04 PM, Kai Engert: On 26.03.2010 13:44, Gervase Markham wrote: I've been looking at your documents, but I do think this is a case where a picture is worth a thousand words. Do you have any plans to provide UI mockups? Hi Gerv, thanks a lot for your feedback. I've created a graphical presentation for the client authentication part: http://kuix.de/mozilla/sslauth/cli-v1-pres/ Very enlightening. The differences are: - the location where the indicator is shown (I don't mind where exactly it will be shown, but would highly prefer the same location for both authenticated and not authenticated icons.) My first thought was that this should be really where Larry is. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Improving SSL client auth and bad certificate reporting in non-browser applications
On 17.03.2010 02:40, Wan-Teh Chang wrote: Is your proposal or Aza Raskin's proposal similar to the proposal that Henry Story of the foaf project has been advocating? No, under the assumption you're refering to http://esw.w3.org/Foaf%2Bssl Contrary to foaf+ssl I'm not proposing any new protocols. My proposal covers user interface enhancements and application behavior, related to the existing SSL client auth and server auth protocols. (Should foaf+ssl require that a user actively manages and selects personal client auth certs when visiting sites, then foaf+ssl could even benefit from my proposal, but they would complement one another.) Kai -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Improving SSL client auth and bad certificate reporting in non-browser applications
Kai, Is your proposal or Aza Raskin's proposal similar to the proposal that Henry Story of the foaf project has been advocating? Wan-Teh -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
