Re: Client Certificate UI for Chrome?
Steven Bellovin wrote: Several other people made similar suggestions. They all boil down to the same thing, IMO -- assume that the user will recognize something distinctive or know to do something special for special sites like banks. Not if he only does it for special sites like banks, but if something special is pretty widely used, he will notice when things are different. Peter, I'm not sure what you mean by good enough to satisfy security geeks vs. good enough for most purposes. I'm not looking for theoretically good enough, for any value of theory; my metric -- as a card-carrying security geek -- is precisely good enough for most purposes. A review of user studies of many different distinctive markers, from yellow URL bars to green partial-URL bars to special pictures to you-name-it shows that users either never notice the *absence* of the distinctive feature I never thought that funny colored url bars for banks would help, and ridiculed that suggestion when it was first made, and said it was merely an effort to get more money for CAs, and not a serious security proposal The fact that obviously stupid and ineffectual methods have failed is not evidence that better methods would also fail. Seems to me that you are making the argument We have tried everything that might increase CA revenues, and none of it has improved user security, so obviously user security cannot be improved. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Client Certificate UI for Chrome?
On Wed, 09 Sep 2009 15:42:34 +1000 James A. Donald jam...@echeque.com wrote: Steven Bellovin wrote: Several other people made similar suggestions. They all boil down to the same thing, IMO -- assume that the user will recognize something distinctive or know to do something special for special sites like banks. Not if he only does it for special sites like banks, but if something special is pretty widely used, he will notice when things are different. We conducted a small-scale controlled user study -- it didn't work. Peter, I'm not sure what you mean by good enough to satisfy security geeks vs. good enough for most purposes. I'm not looking for theoretically good enough, for any value of theory; my metric -- as a card-carrying security geek -- is precisely good enough for most purposes. A review of user studies of many different distinctive markers, from yellow URL bars to green partial-URL bars to special pictures to you-name-it shows that users either never notice the *absence* of the distinctive feature I never thought that funny colored url bars for banks would help, and ridiculed that suggestion when it was first made, and said it was merely an effort to get more money for CAs, and not a serious security proposal The fact that obviously stupid and ineffectual methods have failed is not evidence that better methods would also fail. Seems to me that you are making the argument We have tried everything that might increase CA revenues, and none of it has improved user security, so obviously user security cannot be improved. Not quite. I'm not saying it cannot be improved. I'm saying that controlled studies thus far have demonstrated none of the proposed methods have worked, against fairly straight-forward new attacks. And if we've learned one thing over the last ten years, it's that the attackers are as good as we are at what they do. There's money to be made and the market has worked its wonders: there is a demand for capable hackers, and they're making enough money to attract good people. What I am saying is twofold. First -- when you invent a new scheme, do a scientific test: does it actually help? Don't assume that because pure reason tells you it's a good idea, it actually is in the real world. Second -- you may very well be right that tinkering with the password entry mechanisms cannot succeed, because users are habituated to many different mechanisms and to login screens that regularly change because some VP in charge of publicity has decided that the site's web presence looks old-fashioned and needs to be freshened. In that case, we have to look at entirely different approaches. (How many different experiments will it take to convince people that you can't make gold by mixing chemicals together?) --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Client Certificate UI for Chrome?
On Thu, Sep 03, 2009 at 04:26:30PM +1200, Peter Gutmann wrote: Steven Bellovin s...@cs.columbia.edu writes: This returns us to the previously-unsolved UI problem: how -- with today's users, and with something more or less like today's browsers since that's what today's users know -- can a spoof-proof password prompt be presented? Good enough to satisfy security geeks, no, because no measure you take will ever be good enough. [...] Well, if you're willing to reserve screen real estate, keyboard key combinations, and so on, with said reserved screen space used to indicate unambiguously the nature of other things displayed, and reserved input combinations used to trigger trusted software paths, then yes, you can solve that problem. That's the premise of trusted desktops, at any rate. There are caveats, like just how large the TCB becomes (including parts of the browser), the complexity of the trusted information to be presented to users versus the limited amount of screen real estate available to convey it, the need to train users to understand the concept of trusted desktops, no fullscreen apps can be allowed, accessibility issues, it all falls apart if the TCB is compromised, ... Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Client Certificate UI for Chrome?
Ian G i...@systemics.com writes: If one is trying to solve the whole thing, then using the much-commented secure-bookmarks model would do this. Within the secure bookmark, record the user's certificate and cache enough info on the server's cert to deal with replacements (like, cert, name, CA). There's a variant of this, the site-specific browser (SSB), that takes you to (for example) your bank in a strongly sandboxed, hardened environment. This reduces the cognitive load on the user from a more or less impossible-to- follow set of instructions to only ever do your banking by clicking on this desktop icon. This isn't by any means a general solution, but by solving for the most common cases (your bank, Paypal, eBay, Amazon) you'd address a fairly large chunk of the problem. See Breaking out of the Browser to Defend Against Phishing Attacks by Smetters and Stewart for more details on this. Others have suggested some ideas, so I'll just add: the problem isn't IMO how to do it. There are lots of good ideas. Actually that does point out one problem, which I alluded to in my previous post: we have lots and lots of good ideas, but little hard data to indicate which ones will work and which won't, or which ones work better than others (although the cynical response to this might be that almost anything would work better than what we've got now). Specifically, there are a pile of papers along the lines of here's an experiment showing that what we're doing now doesn't work, here's a completely new security mechanism we've invented that involves redesigning the browser and server authentication back-end, and as a side-effect here are some UI ideas to go with it. What we don't have however is here's a real-world evaluation of various ideas that have been proposed for fixing what we already have built into browsers and servers. Unfortunately without this data we (including myself) are to some extent just people wanking around with their opinions [0]. It's also not certain how such data would be published. Which journal or conference would accept a paper with no new ideas in it, just a straightforward evaluation of existing material? Peter. [0] A Linus quote, brought about by a discussion on the difference between OS secheduler design and security design: the *discussion* on security seems to never get down to real numbers. So the difference between them is simple: one is 'hard science'. The other one is 'people wanking around with their opinions'. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Client Certificate UI for Chrome?
On Sep 3, 2009, at 12:26 AM, Peter Gutmann wrote: This returns us to the previously-unsolved UI problem: how -- with today's users, and with something more or less like today's browsers since that's what today's users know -- can a spoof-proof password prompt be presented? Good enough to satisfy security geeks, no, because no measure you take will ever be good enough. However if you want something that's good enough for most purposes then Camino has been doing something pretty close to this since it was first released (I'm not aware of any other browser that's even tried). When you're asked for credentials, the dialog rolls down out of the browser title bar in a hard-to-describe scrolling motion a bit like a supermarket till printout I'm not sure what version of Camino you're running. The most recent versions use a standard Mac OS GUI element to prompt for passwords - it's indistinguishable from what you get from Safari. In both cases, a special prompt window scrolls down out of the chrome, covering some of the main body of the window. It has a distinctive look: After it's scrolled down, it appears to be under the chrome but over the top of the body. In Safari - I didn't experiment with Camino - it's physically tied to the browser window, moving and iconifying with it, and is fully modal at the window level - you can't switch to another tab in the same window. (Curiously, you *can* switch to a different window.) The loading indicator in the address bar remains active while you're being prompted. The *intent* is clearly to create something hard to spoof, but I don't know enough Flash to say if one could produce an accurate, or even plausible, fake. (Of course, *most* passwords on the Web are entered into some random web page. A distinctive secure prompt that only appears in a minority of cases doesn't help much.) The most common MacOS password prompts are from the keychain program, since you typically store your passwords there. (There are configurations in which it just asks for permission, not for a password; and configurations in which it just sends the password. But if you want to be careful, you only want keychains unlocked when you intend to use them.) Since *any* program - including programs with no visible GUI - can use keychains, these prompts are necessarily stand- alone windows at least sometimes (and for uniformity, they are so all the time). Those could be spoofed more easily (though if you're really cautious, you can unlock the necessary keychain by hand ahead of time and arrange to just give permission to use the entry later, so you're never entering your password into a window that just pops up on its own). -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Client Certificate UI for Chrome?
On Sep 7, 2009, at 8:58 AM, Jerry Leichter wrote: ...standard Mac OS GUI element to prompt for passwords ... I should expand on that a bit: This GUI element is used for all kinds of things tied to a window, not just passwords. For example, if you try to close a window that contains stuff you haven't saved, the same element is used to ask you to confirm, save now, or cancel. So it's a pretty familiar thing to Mac users -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Client Certificate UI for Chrome?
On Aug 26, 2009, at 6:26 AM, Ben Laurie wrote: On Mon, Aug 10, 2009 at 6:35 PM, Peter Gutmannpgut...@cs.auckland.ac.nz wrote: More generally, I can't see that implementing client-side certs gives you much of anything in return for the massive amount of effort required because the problem is a lack of server auth, not of client auth. If I'm a phisher then I set up my bogus web site, get the user's certificate-based client auth message, throw it away, and report successful auth to the client. The browser then displays some sort of indicator that the high-security certificate auth was successful, and the user can feel more confident than usual in entering their credit card details. All you're doing is building even more substrate for phishing attacks. Without simultaneous mutual auth, which -SRP/-PSK provide but PKI doesn't, you're not getting any improvement, and potentially just making things worse by giving users a false sense of security. I certainly agree that if the problem you are trying to solve is server authentication, then client certs don't get you very far. I find it hard to feel very surprised by this conclusion. If the problem you are trying to solve is client authentication then client certs have some obvious value. That said, I do tend to agree that mutual auth is also a good avenue to pursue, and the UI you describe fits right in with Chrome's UI in other areas. Perhaps I'll give it a try. This returns us to the previously-unsolved UI problem: how -- with today's users, and with something more or less like today's browsers since that's what today's users know -- can a spoof-proof password prompt be presented? --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Client Certificate UI for Chrome?
Steven Bellovin wrote: This returns us to the previously-unsolved UI problem: how -- with today's users, and with something more or less like today's browsers since that's what today's users know -- can a spoof-proof password prompt be presented? When the user clicks on a button generated by a particular special kind of html tag, perhaps loginbutton logintype=SRP loginurl=/customers/loginpage.scriptlogin/loginbutton A not quite rectangular login form which is not an html page rolls out of the url, with a motion like a blind or toilet paper unrolling, and partially covers the browser chrome, thus associating the form with the browser and the url, rather than the web page. The form will be decorated and prominently watermarked in manner that is customizable by the end user, and if the end user does not customize it, which he probably will not, a customization was randomly selected at install time. A phisher could do a flash animation that looks almost like the form rolling out, but the flash animation will not roll out of the url, and will not partially cover the browser chrome, and is unlikely to match the customization. If the url is http://exampledomain.com/somedirectory/somepage.html Then the content of the login form is controlled by script at login://exampledomain.com//customers/loginpage.script The login form will be associated with a public key. If the user has logged in before using this browser, there will be an entry in his bookmarks list for the url *and* public key If the login form is the browser's bookmark list, the title on the login form will be the petname, that is to say, the name under which it appears in the bookmark list. If the login form is *not* in the browser's bookmark list, the title on the login form will be No Previous Login at this site using this browser by this user, with script supplied title and or certificate supplied title somewhere else in smaller print. The loginpage.script will tell the browser what fields and fieldnames to request from the user - typically username and password, but this needs to be scriptable - for example it could be credit card number, etc. The script will tell the server what database table and what database fields to associate these user supplied fields with when the client responds. Peter Gutmann has, he believes, a much simpler solution. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Client Certificate UI for Chrome?
Steven Bellovin s...@cs.columbia.edu writes: This returns us to the previously-unsolved UI problem: how -- with today's users, and with something more or less like today's browsers since that's what today's users know -- can a spoof-proof password prompt be presented? Good enough to satisfy security geeks, no, because no measure you take will ever be good enough. However if you want something that's good enough for most purposes then Camino has been doing something pretty close to this since it was first released (I'm not aware of any other browser that's even tried). When you're asked for credentials, the dialog rolls down out of the browser title bar in a hard-to-describe scrolling motion a bit like a supermarket till printout. In other words instead of a random popup appearing in front of you from who knows what source and asking for a password, you've got a direct visual link to the thing that the credentials are being requested for. You can obviously pepper and salt this as required (and I wouldn't dream of deploying something like this without getting UI folks to comment and test it on real users first), but doing this is a tractable UI design issue and not an intractable business-model/political/social/etc problem. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Client Certificate UI for Chrome?
On Mon, Aug 10, 2009 at 6:35 PM, Peter Gutmannpgut...@cs.auckland.ac.nz wrote: More generally, I can't see that implementing client-side certs gives you much of anything in return for the massive amount of effort required because the problem is a lack of server auth, not of client auth. If I'm a phisher then I set up my bogus web site, get the user's certificate-based client auth message, throw it away, and report successful auth to the client. The browser then displays some sort of indicator that the high-security certificate auth was successful, and the user can feel more confident than usual in entering their credit card details. All you're doing is building even more substrate for phishing attacks. Without simultaneous mutual auth, which -SRP/-PSK provide but PKI doesn't, you're not getting any improvement, and potentially just making things worse by giving users a false sense of security. I certainly agree that if the problem you are trying to solve is server authentication, then client certs don't get you very far. I find it hard to feel very surprised by this conclusion. If the problem you are trying to solve is client authentication then client certs have some obvious value. That said, I do tend to agree that mutual auth is also a good avenue to pursue, and the UI you describe fits right in with Chrome's UI in other areas. Perhaps I'll give it a try. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Client Certificate UI for Chrome? [OT anonymous-transaction bull***t]
[Moderator's note: this is getting a bit off topic, and I'd prefer to limit followups. --Perry] On Wed, 2009-08-19 at 06:23 +1000, James A. Donald wrote: Ray Dillinger wrote: If there is not an existing relationship (first time someone uses an e-tailer) then there has to be a key depository that both can authenticate to, with a token authorizing their authentication to authenticate them to the other, which then vouches to each for the identity of the other. Actually not. What the seller wants to know is that the buyer's money is good, not what the true name of the buyer is - a service provided by Visa, or Web-money, or some such. No. This juvenile fantasy is complete and utter nonsense, and I've heard people repeating it to each other far too often. If you repeat it to each other too often you run the risk of starting to believe it, and it will only get you in trouble. This is a world that has not just cryptographic protocols but also laws and rules and a society into which those protocols must fit. That stuff doesn't all go away just because some fantasy-world conception of the future of commerce as unlinkable anonymous transactions says it should. In any transaction involving physical goods, the seller also wants to know to whom to ship the product. Since the laws in most nations do not require the recipient of an erroneous shipment to return the goods and *do* require the seller to give back the buyer's money if the shipment doesn't go where the buyer wants it, sellers really care that the correct recipient will receive the package and really need some way to contact the buyer in case there's a mistake about the recipient address or identity. Otherwise you'd get people playing silly buggers with the shipping address to get out of paying for million-dollar equipment. The law usually requires that the recipient of defective goods or services has the ability to return those goods for a refund or obtain a refund in the event of seller nonperformance of services or nonshipment of goods. Since such returns can be used to launder money from illegal enterprises, laws usually restrict anonymous returns. Therefore the seller needs the buyer's (or client's) identity in order to comply with the law. In information-based transactions involving IP that's subject to copyright or trade secret protection (which is effectively all of them since other IP can be had for free) the seller also wants to know who is the licensee that's bound by the terms of the license and who now poses a risk of copyright breakage. In both cases this is a liability taken on by the buyer, and not something that his money being good for just the transaction price can ameliorate. In financial transactions The seller also wants to know that s/he can comply with, eg, know your customer laws and avoid liability for gross negligence in, eg, money laundering cases. In many transactions the seller wants the buyer's identity and a liability waiver signed by the buyer so as to keep track of or avoid liability for what the customer is going to do with his/her products. Most sellers want the ability to offer the buyer credit terms, especially when large sums are involved. And even where money is supposedly firm (like the money Bernie Madoff's clients had in their accounts) it is subject to catastrophic vanishment in extraordinary circumstances. The seller needs to know whom to sue or at least whose name to put on the forms for their insurance claim if contrary to expectations the buyer's money turns out not to be good. If the cert authority does not provide the identity of the buyer but asserts that the buyer's money is good, and this turns out not to be true (as in the case of Madoff's clients), then in most legal systems the cert authority is either liable, or can expect to be sued in a very expensive empirical test of liability. So the cert authority doesn't want to be in the business of vouching for the ability of anonymous people to pay. The only way for the money to be truly firm for these purposes is that the cert authority has it in escrow. This makes the cert authority a financial institution and therefore subject to know your customer mandatory reporting, data retention laws, subpeonas, and so on. Also, it introduces a needless delay and complication to the transaction that legitimate buyers and sellers would mostly rather not have. Also, in any large transaction the seller or cert authority or both must retain buyer identity information in order to be able to comply with subpeonas, inquests, or equivalent writs, for periods ranging from zero in a few undeveloped african nations to five years in much of the rest of the world. In most of the nations on earth, there is such a thing as sales tax or use tax on goods or services, and any transaction involving more than a tiny sum must be reported (with the names of buyer and seller) to
Re: Client Certificate UI for Chrome? -- OT anonymous-transaction
On 08/20/09 00:11, Ray Dillinger wrote: No. This juvenile fantasy is complete and utter nonsense, and I've heard people repeating it to each other far too often. If you repeat it to each other too often you run the risk of starting to believe it, and it will only get you in trouble. This is a world that has not just cryptographic protocols but also laws and rules and a society into which those protocols must fit. That stuff doesn't all go away just because some fantasy-world conception of the future of commerce as unlinkable anonymous transactions says it should. most of the financial industry digital certificate specifications were relying party only digital certificates ... effectively only containing an account number ... because of privacy (both in us and europe) and liability issues. some of this was also about the time that EU-DPD made statements that electronic retail transactions should be w/o names (i.e. remove person names from payment cards ... also a form of relying party only instrument). this somewhat side-stepped whether it was linkable or not ... since it then was back at the financial institution whether the account number was linked to a person or anonymous ... but did meet privacy requirements for retail payments depending on gov. financial institution with regard to any possible know your customer mandates ... a court order to the financial institution had the potential of revealing any linkage There were a couple issues: 1) even as a relying-party-only digital certificate ... the digital certificate gorp resulted on the order of 100 times payload bloat for typical payment transaction payload size. there were two approaches a) strip the digital certificate off the payment transaction as early as possible to minimize the onerous payload penalty; b) financial standards looked at doing compressed relying-party-only digital certificates ... possibly getting the payload bloat down to only a factor of ten times (instead of one hundred times). 2) it was trivial to show that the issuing financial institution already had a superset of information carried in the relying-party-only digital certificate ... so it was redundant and superfluous to repeatedly send such a digital certificate back to the issuing financial institution appended to every payment transactions (completely redundant and superfluous was separate issue from representing factor of 100 times payload bloat). so there were two possible solutions to the enormous payload bloat a) just digital sign the transaction and not bother to append the redundant and superfluous relying party only certificate b) the standards work on compression included eliminating fields that the issuing financial institution already possessed ... since it was possible to demonstrate that the issuing financial institution had a superset of all information in a relying-party-only digital certificate ... it was possible to compress the size of the digital certificate to zero bytes. then it was possible to mandate that zero byte digital certificates be appended to every payment transaction (also addressing the enormous payload bloat problem). the x9.59 financial transaction standard ... some refs http://www.garlic.com/~lynn/x959.html#x959 just specified requirement for every payment transaction to be authenticated ... and didn't really care whether there was no digital certificate appended ... or whether it was mandated that zero-byte digital certificates were appended. -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Client Certificate UI for Chrome?
James A. Donald jam...@echeque.com writes: [Incredibly complicated description of web scripting plumbing deleted] Peter Gutmann wrote: We seem to be talking about competely different things here. For a typical application, say online banking, I connect to my bank at www.bank.com or whatever, the browser requests my credential information, and the TLS-SRP or TLS-PSK channel is established. That's all. There's no web application framework and PHP and scripting and other stuff at all, in fact I can't even see how you'd inject this into the process. I cannot see how you could create a bank web page without a web application framework (counting mod-php as a very primitive web application framework) and scripting and a database, which scripting and database has to know who it is is that logged in - which is indeed a great deal of complicated plumbing to ensure that the script knows at script execution time, *after* the connection has been made, which user, which database primary key, is connected. The information about which user, which database primary key is logged in, has to be passed up through one layer after another and from one process to another. The toe bone is connected to foot bone, the foot bone is connected to the ankle bone, the ankle bone is connected ... The plumbing really is that complicated. Further, if we do the SRP dance every single page, it is a huge performance hit, with many additional round trips. One loses about 20 percent of one's market share for each additional round trip. You only do it once when the TLS session is set up, it's exactly as for standard TLS except that instead of PKI-based non-authentication you use cryptographic mutual authentication. How do you get an SRP exchange for every web page? Because keep-alive usually fails for plumbing reasons, standard TLS usually does the PKI-based non-authentication dance every page, resulting in additional round trips, resulting in painfully bad performance for SSL web sites such as https://www.cia.gov/library/publications/the-world-factbook/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Client Certificate UI for Chrome?
James A. Donald jam...@echeque.com writes: I cannot see how you could create a bank web page without a web application framework (counting mod-php as a very primitive web application framework) and scripting and a database, which scripting and database has to know who it is is that logged in We really are talking about completely different things here. The scripting and whatnot has nothing to do with TLS or TLS auth mechanisms. The only thing you need to care about (if you really want to go this way) is channel binding. The information about which user, which database primary key is logged in, has to be passed up through one layer after another and from one process to another. Yeah, and that's what channel binding is for. The plumbing really is that complicated. Only if you deliberately choose to make it so. Read the RFCs I mentioned earlier. Because keep-alive usually fails for plumbing reasons, standard TLS usually does the PKI-based non-authentication dance every page, resulting in additional round trips, resulting in painfully bad performance for SSL web sites But TLS doesn't work like that. If it did, you'd get a cert popup every time you clicked on a link on a TLS-protected web site. Unless you somehow manage to flush the TLS session cache on the server (which seems unlikely unless you're DoS'ing it) there's no additional round-trip(s), or additional anything for that matter. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Client Certificate UI for Chrome?
James A. Donald jam...@echeque.com writes: [Incredibly complicated description of web scripting plumbing deleted] We seem to be talking about competely different things here. For a typical application, say online banking, I connect to my bank at www.bank.com or whatever, the browser requests my credential information, and the TLS-SRP or TLS-PSK channel is established. That's all. There's no web application framework and PHP and scripting and other stuff at all, in fact I can't even see how you'd inject this into the process. Further, if we do the SRP dance every single page, it is a huge performance hit, with many additional round trips. One loses about 20 percent of one's market share for each additional round trip. You only do it once when the TLS session is set up, it's exactly as for standard TLS except that instead of PKI-based non-authentication you use cryptographic mutual authentication. How do you get an SRP exchange for every web page? Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Client Certificate UI for Chrome?
James A. Donald wrote: For password-authenticated key agreement such as TLS-SRP or TLS-PSK to work, login has to be in the chrome. Regrettably, login in the (non-customizable) chrome is unusable; this is why *everyone* now uses cookies instead of HTTP authentication. Just asking the user for a username instead of an email address can trip them up. SSL has a worse problem AFAIK, which is that the server either always asks for a client cert (before the login page) or never asks, but I think we want to show a login page over SSL, *then* ask the user for their cert or password. Despite its complexity, I'm thinking that something like infocards -- where some HTML tag or JS API can trigger the browser to perform secure authentication with an unspoofable UI -- is the way to go. Wes Felter - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
RE: Client Certificate UI for Chrome?
From: James A. Donald [jam...@echeque.com] Sent: Sunday, August 09, 2009 1:21 AM To: Thomas Hardjono Cc: Ben Laurie; Cryptography Subject: Re: Client Certificate UI for Chrome? Thomas Hardjono wrote: In this UI discussion, I think its less relevant whether trust is hierarchical or flat/p2p. The hard part is always certificate management, which has to be launched off existing trust and connections. So the question is, do we have certificate management that assumes that everyone has boundless trust in Verisign, and no trust in existing connections and existing shared knowledge, or do we have certificate management designed make use of any existing connections, trust, and shared knowledge, wherever it is to be found? [bottom-posted] Agree. Unfortunately (or fortunately) some browsers have shipped with root CA certs for a number of years now, which does force the end-user to trust the CA. This has been great for sales of SSL certs for VeriSign and other CAs but there is still that fundamental problem of educating the average user (Mom/Dad) about equating trust with certs (or root CA certs).=20 I'm not sure if the Chrome folks would be prepared to ship their browser without any CA certs loaded, but that would be an interesting and perhaps even revolutionary idea. Assuming the Chrome UI had a nice and easy way for users to download and install certs (trust anchors), this approach could level the playing field and allows other modes of trust to be played-out. Both LinkedIn and FaceBook could in fact be CAs that issue certs based on the number of verified connections that a person had. /thomas/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Client Certificate UI for Chrome?
Thomas Hardjono wrote: I'm not sure if the Chrome folks would be prepared to ship their browser without any CA certs loaded, Excessive distrust is inconvenient, excessive trust is vulnerable. It is better to remedy flaws by expanding functionality rather than restricting it. On the one hand, something like Verisign is very useful to signify that an entity that calls itself a bank is in fact regarded as a bank by governments and other major banks, on the other hand, it is pretty useless for designating membership of a group to other members of the group, which is the major function of client side certificates. The number of globally important entities is necessarily small, therefore a global namespace of globally unique human memorable names, (such as Bank Of America) works well for them. The number of entities that have or need keys is quite large, therefore Zooko's triangle applies - globally unique human memorable names work very badly for the vast majority of keyholders, therefore a business whose job is enforcing global uniqueness of human memorable names (such as Verisign) is going to be a pain to deal with, for it is trying to do something that really cannot be done, therefore in practice will merely make it sufficiently difficult for clients that scammers do not bother. Even for banks, globally unique names are problematic. A remarkably large number of banks are called something National Bank, or First National Bank of something. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Client Certificate UI for Chrome?
James A. Donald jam...@echeque.com writes: [In order to implement strong password based encryption and authentication] on the server side, we need a request object in the script language that tells the script that this request comes from an entity that established a secure connection using shared secrets associated with such and such a database record entered in response to such and such a web page Peter Gutmann wrote: Ah, that is a good point, you now need the credential information present at the TLS level rather than the tunneled-protocol level (and a variation of this, although I think one that way overcomplicates things because it starts diverting into protocol redesign, is the channel binding problem (see RFC 5056 and, specific to TLS, draft-altman-tls-channel-bindings-05.txt)). On the other hand is this really such an insurmountable obstable? Consider what would be involved in building the UI into the Google browser, and also building the necessary scripting support into Web2Py on Google App Engine. It is not a small job. I don't really see why you'd need complex scripting interfaces though, just return the shared-secret value associated with this ID in response to a request from the TLS layer. This request is issued when the connection is being established, before the URL is specified. So it is impossible to service that request from the script that generates the web page. So where are we servicing that request? Presumably, need to service it somewhere within the Web Application Framework, for example within Mod PHP or Web2Py. Further, some applications, for example banks and share registries, typically have several different ID tables at a single domain, and several different kinds of shared human memorable secret information associated with each ID. And, having established that association, then when the URL is specified, and the script associated that URL is finally invoked by the Web Application Framework, then that script needs to be invoked with the relevant ID, or better, the script then needs to be provided with a database cursor pointing at the relevant ID. Further, if we do the SRP dance every single page, it is a huge performance hit, with many additional round trips. One loses about 20 percent of one's market share for each additional round trip. So we only want to do the SRP dance on session establishment, only want to do it once per human session, once per logon, not once per TLS session. Which means that the TLS layer has to cache the the transient strong shared secret constructed from the weak durable human memorable secret for the duration of the Web Application Framework's logon and logoff and provide the cached database cursor to the web page script at every page request during a single logon session, which requires a higher level of integration between TLS and the Web Application Framework than either one was originally designed for. Which means a significant amount of work integrating this stuff with any given web application framework. Further, suppose, as is typical with banks, a given domain name hosts multiple ID tables each with different kinds of shared secret information. In that case, we can obtain multiple different kinds of SRP logons, each relevant to certain web pages but not others, each with different privilege levels, and the framework has to enforce that, has to provide to each web page information about the logon type, and ensure that inappropriate web pages are never invoked at all, but are 403ed when the user attempts to access a url through a logon of inappropriate type. We cannot rely on the server side web page script to 403 itself in response to inappropriate logon type, since when a new kind of logon was introduced, no one would ever go back and make sure that all the old web pages correctly checked the logon type. If the web page script contains a line of code that says If such and such, then do a 403, then sooner or later someone will delete that code and say Hey, it still works just fine.. This is starting to sound depressingly like a great deal of work rewriting lots of complex, bugridden stuff in web application frameworks that are already designed to handle logons in a quite different way. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Client Certificate UI for Chrome?
James A. Donald jam...@echeque.com writes: For password-authenticated key agreement such as TLS-SRP or TLS-PSK to work, login has to be in the chrome. Sure, but that's a relatively tractable UI problem (and see the comment below on Camino). Certificates on the other hand are an apparently intractable business, commercial, user education, programming, social, and technical problem. I'd much rather try and solve the former than the latter. The problem with password auth is that no browser (with the exception of Camino) has made even the most basic attempt to do the UI for this properly. In all cases the browser pops up a dialog box, unconnected to the underlying operation or web page, that says Gimme your password in one way or another. This could be coming from anywhere, the browser, Javascript on the web page, another web page, who knows where, but since everyone knows that passwords are insecure there's no point in expending any effort to try and make them secure, and that's been the status quo for fifteen years. What Camino does (and it's been awhile since I played with it, so I'll qualify that with what I hope it still does) is roll the password-entry box down out of the browser menu bar in a circular motion that's both hard to spoof and that unmistakably ties the credential-entry request both to the web page that it's associated with and to the browser rather than being some floating popup coming from who knows where or what. This can no doubt be nitpicked, but it's better than any other browser (that I've seen) does. More generally, I can't see that implementing client-side certs gives you much of anything in return for the massive amount of effort required because the problem is a lack of server auth, not of client auth. If I'm a phisher then I set up my bogus web site, get the user's certificate-based client auth message, throw it away, and report successful auth to the client. The browser then displays some sort of indicator that the high-security certificate auth was successful, and the user can feel more confident than usual in entering their credit card details. All you're doing is building even more substrate for phishing attacks. Without simultaneous mutual auth, which -SRP/-PSK provide but PKI doesn't, you're not getting any improvement, and potentially just making things worse by giving users a false sense of security. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Client Certificate UI for Chrome?
-- James A. Donald jam...@echeque.com writes: For password-authenticated key agreement such as TLS-SRP or TLS-PSK to work, login has to be in the chrome. Peter Gutmann wrote: Sure, but that's a relatively tractable UI problem Indeed. You know how to solve it, and I know how to solve it, yet the solution is not out there. As you say, shared secrets should be entered a form that implements password-authenticated key agreement such as TLS-SRP or TLS-PSK, that cannot easily be spoofed, that is clearly associated with the browser and with a particular url and web page (you suggest that the form should roll out of the browser bar with an eye catching motion and land on top of the web page) and an encrypted connection should be established by that shared knowledge, which cannot be established without that shared knowledge. This, however, requires both client UI software, and an api to server side scripts such as PHP, Perl, or Python (the P in LAMP). On the server side, we need a request object in the script language that tells the script that this request comes from an entity that established a secure connection using shared secrets associated with such and such a database record entered in response to such and such a web page, an object to which the script generating a page can associate data that persists for the duration of the session - an object that has session scope rather than page scope, scope longer and broader than that of the thread of execution that generates the page, but shorter and narrower than that of the database record containing the shared secrets, a script accessible object that can only be associated with one server, one server side process and one server side thread at a time. This is non trivial to implement in an environment where servers are massively multithreaded, and often massively multiprocess. Certificates on the other hand are an apparently intractable business, commercial, user education, programming, social, and technical problem. I'd much rather try and solve the former than the latter. What makes certificates such a problem is that there is someone in the middle issuing the certificate - usually someone who does not know or trust either of the entities trying to establish a trust relationship. While certificates frequently makes cryptography unnecessarily painful and complicated, certificate issue offers the opportunity to make money out of providing encryption by being that someone in the middle, hence the remarkable enthusiasm for this technology, and stubborn efforts to apply it to cases where its value is limited, and it is far from being the most convenient, practical, and straightforward solution. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Client Certificate UI for Chrome?
[Moderator's note: top posting considered harmful: http://www.mail-archive.com/cryptography@metzdowd.com/msg09287.html --Perry] Just to complicate things a little... we're working with a number of groups now who are using onlineCAs that issue short-lived x509 certs derived from a primary authN mechanism like passwords or OTP. It would be great to bake that functionality into chrome: use TLS-SRP/ PSK to authN to an onlineCA to obtain your short-lived cert in real- time. -Frank. On Aug 6, 2009, at 5:49 AM, Peter Gutmann wrote: Ben Laurie b...@google.com writes: So, I've heard many complaints over the years about how the UI for client certificates sucks. Now's your chance to fix that problem - we're in the process of thinking about new client cert UI for Chrome, and welcome any input you might have. Obviously fully-baked proposals are more likely to get attention than vague suggestions. This is predicated on the assumption that it's possible to make certificates usable for general users. All the empirical evidence we have to date seems to point to this not being the case. Wouldn't it be better to say What can we do to replace certificates with something that works?, for example TLS-SRP or TLS-PSK? Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com --- Frank Siebenlist - fra...@mcs.anl.gov The Globus Alliance | Argonne National Laboratory | University of Chicago - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Client Certificate UI for Chrome?
James A. Donald jam...@echeque.com writes: This, however, requires both client UI software, and an api to server side scripts such as PHP, Perl, or Python (the P in LAMP). On the server side, we need a request object in the script language that tells the script that this request comes from an entity that established a secure connection using shared secrets associated with such and such a database record entered in response to such and such a web page, an object to which the script generating a page can associate data that persists for the duration of the session - an object that has session scope rather than page scope, scope longer and broader than that of the thread of execution that generates the page, but shorter and narrower than that of the database record containing the shared secrets, a script accessible object that can only be associated with one server, one server side process and one server side thread at a time. This is non trivial to implement in an environment where servers are massively multithreaded, and often massively multiprocess. Ah, that is a good point, you now need the credential information present at the TLS level rather than the tunneled-protocol level (and a variation of this, although I think one that way overcomplicates things because it starts diverting into protocol redesign, is the channel binding problem (see RFC 5056 and, specific to TLS, draft-altman-tls-channel-bindings-05.txt)). On the other hand is this really such an insurmountable obstable? For client-cert usage you already need to perform a lookup based on a given cert (well, unless you blindly trust anyone displaying a cert coming from a particular CA or set of CAs, which I know some sites do), so now all you'd be doing is looking up a shared-secret value instead of a cert based on a client ID. I don't really see why you'd need complex scripting interfaces though, just return the shared-secret value associated with this ID in response to a request from the TLS layer. The only problem I can see is if you have an auth system built around is this authenticator valid rather than return the authenticator for this ID. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Client Certificate UI for Chrome?
Thomas Hardjono wrote: Having worked at a large CA for along time (trying to push for client-side certs with little luck), here are some thoughts on what Chrome could provide: There are use cases where a centralized authority is useful. Client side is not one of them. Typical usage is is this client one of our gang?. Obviously the CA just gets in the way. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Client Certificate UI for Chrome?
Ben Laurie wrote: So, I've heard many complaints over the years about how the UI for client certificates sucks. Now's your chance to fix that problem - we're in the process of thinking about new client cert UI for Chrome, and welcome any input you might have. Obviously fully-baked proposals are more likely to get attention than vague suggestions. The fundamental problem with certificates is getting them. OK, suppose you hit a web site that wants a client side certificate, maybe it wants a claimed email address with proof that you can receive email at that address, maybe it wants proof you are over 18, maybe it is run by the company you work for and wants proof you are an employee and wants to know which employee you are. Maybe it wants evidence that you a member in good standing of the committee to slay infidels. If we suppose your browser *has* such a certificate, and merely needs permission from you, the user, to show it, then the problem is relatively easy - which however does not stop existing browsers from fouling up mightily, perhaps because they are designed around verisign's business model, rather than anything the user might actually want to do. But the problem is much harder, much much harder, if we suppose you do *not* have the certificate. I will ignore the easy problem, because I am sure that anyone worth talking to can figure out the solution, even though existing browser writers have failed to do so. OK. Hard Problem: You the user have hit a website that wants a certificate with certain characteristics, and either you do not have it, or you have it somewhere, but your browser does not know you have it, perhaps because it is on another browser on another computer. It appears to me that existing solutions to this problem are designed around Verisign's business model, rather than user needs. If a client certificate is to identify you to examplecorp as an employee of examplecorp, why does Verisign need to get involved? It's easier for examplecorp to issue its own @#$%^ certificates. So, assuming you are pretty smart, as I know you to be, and assuming your boss is not evil and not in Verisign's pocket, which I do not know at all ... So where *would* you have a certificate? Where would you keep it, and what would it look like? The kind of things that people are used to storing in a browser are bookmarks: Bookmarks have the convenient property that they implement Zooko's triangle: petname, nickname, and guid. They also have the property that if you click on them they take you somewhere. So a certificate should act like some kind of smart bookmark and look to the user like a smart bookmark, which if clicked on should bring you to your logged in web page with the authority issuing the certificate. Your secret key is something like a a secret link or bookmark that automatically logs you in to something like your facebook page, and your public key is something like a link or bookmark that enables other people to view something like your facebook page. Maybe it is your employee page at examplecorp, which shows any records pertaining to you in the company database, some of which, such as contact information, are editable by you, but most of which are not. And the something like your facebook page as seen by others is almost the same link the live authorization that your certificate is still valid. So how do you *get* a certificate? Suppose, for example, your certificate identifies you to your company, in which case your boss probably gave it to you. What would he give you? Well, obviously, he would give you a username and password, or more likely you would create an account, a username and password, which he would then authorize. Which username and password would I expect enable you to get to that logged in web page with the authority issuing the certificate, in this case some location on the company web server. And you get to that web page, you would then get an install certificate title dialog, and if you accept, get something that looks and acts like a bookmark, though it is in fact a company issued certificate, certifying that you are username, where username is also a primary key in the company employee database. But the trouble with this, of course, is that usernames and passwords can be phished. The solution to that is password login and account creation in the chrome, not in the web page implementing password-authenticated key agreement, so that the phisher can gain nothing, so long as the user attempting to use the chrome login facilities, rather than html web page login facilities. It should have been obvious that logging in on a user interface provided by a web page, provided by html code, was entirely insecure - the problem of spoofed logins was well known at the time. So what we needed, from day one, was a secure login that was in the browser chrome, not the web page - and no other form of
Re: Client Certificate UI for Chrome?
Ben Laurie b...@google.com writes: So, I've heard many complaints over the years about how the UI for client certificates sucks. Now's your chance to fix that problem - we're in the process of thinking about new client cert UI for Chrome, and welcome any input you might have. Obviously fully-baked proposals are more likely to get attention than vague suggestions. This is predicated on the assumption that it's possible to make certificates usable for general users. All the empirical evidence we have to date seems to point to this not being the case. Wouldn't it be better to say What can we do to replace certificates with something that works?, for example TLS-SRP or TLS-PSK? Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Client Certificate UI for Chrome?
On 08/06/09 07:33, James A. Donald wrote: The fundamental problem with certificates is getting them. digital certificate design point supposedly was the dial-up email of the early 80s, dial-up, exchange email, hang-up ... and then faced with how to deal with first time email from complete stranger. basically electronic analog for letters of credit/introduction from sailing ship days. in the 90s, because of numerous privacy and liability issues ... there was some number of relying-party only certificates; individual registered their public key with the institution, institution then created a digital certificate with the public key, archived it, and returned a copy to the individual. the individual, in communication with the institution would digitally sign the communication and then append the digital certificate. However, it was trivial to prove that the institution/relying-party already had a copy of the information ... and the appended digital certificate was redundant and superfluous. misc. past posts discussion relying-party only digital certificates http://www.garlic.com/~lynn/subpubkey.html#rpo furthermore, major foreys into this sector were by financial institutions for the purpose of payment transactions. a complicating factor ... besides the digital certificates being redundant and superfluous ... they added a 100 times payload size bloat to the typical payment transactions. misc. past posts http://www.garlic.com/~lynn/subpubkey.html#bloat there was a financial standards effort that looked at possibly doing compressed digital certificates (trying to achieve only ten times bloat) ... eliminating redundant fields and information already in the possession of the individual's financial institution. we showed that the individual's financial institution already had superset of the information in the digital certificate ... so it was possible to compress digital certificates to zero bytes ... and then mandate that financial transactions would always have zero-byte certificates appended (as opposed to no appended digital certificate). Something similar was demonstrated for RADIUS and Kerberos ... registering a public key in lieu of password ... some past references http://www.garlic.com/~lynn/subpubkey.html#radius and http://www.garlic.com/~lynn/subpubkey.html#kerberos and also something similar for registering public key with domain name registration with domain name infrastructure ... for use in lieu of SSL digital certificates http://www.garlic.com/~lynn/subpubkey.html#catch22 that left institutions and relying party with no-value business processes as digital certificate opportunities ... i.e. no-value transactions where the relying party couldn't justify the cost of their own entity repository and/or justify the cost of doing an online transactions to obtain such entity information ... and of course ... the original design point, the offline email scenario with first time communication with complete strangers. One of the problems with no-value market segment is that it is hard for institutions and individuals to justify paying for things without any value ... and therefor it is hard to find entities looking at selling things for nothing. -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
RE: Client Certificate UI for Chrome?
Ben, Having worked at a large CA for along time (trying to push for client-side certs with little luck), here are some thoughts on what Chrome could provide: (a) Association with net identities: Provide some way for the user to associate his/her X.509 cert with an internet identity string (eg. OpenID, email address, etc etc) in the browser. (Yes, we could add such an identity in the SubjAltName, but that's outside the control of the end-user). This would allow the user to choose which cert to deliver to the server when the user is engaging the server using one of his/her identities. (PS. being able to associate with a small image/icon/photo of the user would also be nice). The UI should be a simple as click cert and click identity, and then click associate. (b) Export of certs: Provide an easy way to export client-certs to other apps. Currently some CAs use the browser as the primary means for cert enrollment. Currently in IE this is somewhat a lengthy process and the response (ie. export of cert successful or not) is also not very clear to the end-user. The UI should not even talk about export. It should say something along the lines of Do you want to make your certificate available to the following Apps. (c) Lock showing which cert/identity used: It would be useful if in addition to the Lock symbol (ie. SSL session established) there is a string (next to the Lock symbol) showing which client-side cert the browser is using for that SSL session. This is related to item (a) above, where a human-readable net identity is associate with the cert. This helps the user in distinguishing which identity he/she is using when connecting to a Bank versus a Blog versus a corporate web-mail (all of which could be using distinct cert/identity). If there is a mismatch, the user can see this visually. (d) Notification of expired certs: It would be good if the browser could somehow notify the user if there are some expired certs (belonging to the user) in the browser. I'm finding that some browsers deliver the first cert in the list even when it has expired (thus causing the server to reject). (e) Better notification/alerts of errors regarding server-certs: This is a hard one as the average user (eg. my Mom) does not understand about certs to begin with. Since one of the main aims of SSL server-certs today is to prevent phishing, perhaps those messages should be phishing-oriented. This one need further thought, but perhaps a third button/option could be provided (in addition to the Cancel and Continue buttons). This third button could provide the user with some alternate sites with similar sounding domain names but with proven/valid server-certs. (f) Better graphical representation of cert hierarchy: Perhaps not crucial, but a nice graphical representation of the cert hierarchy/tree might help educate the average user (my Mom/Dad) about what a CA is and where the user is located in the hierarchy. This would even help the average employee when his/her company is using a subordinate CA off a public CA. When the user clicks on a node in the tree, it should show the organization name and other human friendly details. (g) Easy check button for server-certs: It would be great if I could right-click the Lock symbol on the browser and be able to choose an action along the lines of Validate Server Certificate. The browser would then hit the corresponding OCSP Responder (as denoted in the server-cert) and report the status to the user using some graphical notation (eg. icon of server with a big X if the server-cert is invalid or status unknown). That's all for now. Will send more thoughts if any come up :) /thomas/ -Original Message- From: owner-cryptogra...@metzdowd.com [mailto:owner- cryptogra...@metzdowd.com] On Behalf Of Ben Laurie Sent: Wednesday, August 05, 2009 9:59 AM To: Cryptography Subject: Client Certificate UI for Chrome? So, I've heard many complaints over the years about how the UI for client certificates sucks. Now's your chance to fix that problem - we're in the process of thinking about new client cert UI for Chrome, and welcome any input you might have. Obviously fully-baked proposals are more likely to get attention than vague suggestions. I imagine I may well hear what about the UI around server certificates? - fair enough, feel free, and I'll see what I can do. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
