Re: TLS-client-cert-auth in .SE
Collective answer to Jean-Marc and Michael. Green messaging :-) Before going too deep into this you should be aware of the fact that Microsoft's recently introduced Information Card scheme also when using a local X.509 certificate to authenticate to the IdP does not specify TLS-client-cert-auth even as an option! Regarding the .SE banks and competency, the issue is rather that their *customers*, the e-governments do not have the necessary knowledge. Understanding TLS state in web- servers and browsers is BTW anyhthing but simple. :-( It's very different in terms of MITM protection. Yes indeed it is, but the end-result is identical, full *RP* protection against on-the-wire MITM attacks assuming that server-side TLS is used in both cases. All of these could be solved IMO, but it would require a joined browser/server effort, and to build bridges between the applicative level and the ssl session management on the web server. Yes, but that is surely not going to happen because the alternatives are already in place and are anyway needed for the signature stuff that no browser vendor has shown any kind of interest in despite the fact that millions of people already use it on a daily basis. it matches poorly with web sessions including logout Why should it match application sessions? Because the web application developers are too dumb to get the session handling right for themselves? Because the logout does not behave like they are used with passwords? You essentially gave the answer yourself. In order to deploy TLS-client-cert-auth you must hire very special people. That MSIE has a button Clear SSL State is a pretty good indication that securing a static tunnel and browsing the web are two quite distinct applications. That Mozilla apparently works completely different (?) is not an argument for TLS-client-cert-auth, it is an argument *against* it. - it is poorly implemented in many browsers with respect to path building Can you explain this? At least in FF 2.x, a PIV user had to *install* the entire cert-path in the browser trust store in order to authenticate since stuff like AIA ca issuers isn't supported in spite of being mandated in PIV. Hopefully this was fixed in FF 3.0 but of course this total misalignment has given TLS-client-cert-auth a *well-deserved* bad reputation. - it offers very limited filtering capability What do you want to filter? At which point? Well, I think that Nelson can testify that there has been a rather long-lasting bug in FF regarding what certificate to show the user in the TLS selection GUI based on [for example] key usage. I don't consider this a bug in FF, but a deficiency in TLS- client-cert-auth which didn't take this issue in consideration. The fat-app alternatives usually offer much better selection facilities like in: http://tinyurl.com/6ot2vz Anders webpki.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: TLS-client-cert-auth in .SE
On Thu, Aug 28, 2008 at 11:59 PM, Anders Rundgren [EMAIL PROTECTED] wrote: Collective answer to Jean-Marc and Michael. Green messaging :-) Before going too deep into this you should be aware of the fact that Microsoft's recently introduced Information Card scheme also when using a local X.509 certificate to authenticate to the IdP does not specify TLS-client-cert-auth even as an option! Regarding the .SE banks and competency, the issue is rather that their *customers*, the e-governments do not have the necessary knowledge. Understanding TLS state in web- servers and browsers is BTW anyhthing but simple. I think that this is partly due to the lack of information presented by the web browsers on how to do something like this properly, and because of it the rest of the world has moved on. The idea is to create a session, then at some point ask the client to authenticate within that session using a private key stored on a smartcard. The server should cache that session until the user hits the 'logout' button, which should eliminate the caching of the session (or at least the credentials associated with the session) on the server. See, under an OS-integrated smart-card system, as soon as the smart card is removed everything associated with the private key on the smart card should be invalidated. (I don't have a smart-card reader to test this, though I do know that smart-card removal can trigger a locked screensaver or a full logout on Windows.) However, only Microsoft has this, and only with IE. The rest of the world has to deal with PKCS#11, which (if session resumption isn't managed by the server properly) requires reauthentication to the token every time the key needs to be used. This is where the idea of PIN caching comes into play. PIN caching is the worst thing that can be done in my opinion, since it opens up the door for many private-key abuses. Instead, the private key should be used to authenticate within the session with a ClientAuthRequest when the client tries to access a part of the site that requires knowledge of exactly whose information to display (since a session renegotiation can happen at any time, initiated by either side). (I still think that a USB keyfob that has a crypto interface would be a good solution, rather than requiring smart cards that require additional readers, since USB ports are ubiquitous and smart-card readers aren't. However, when I suggested this a few years ago, nobody else thought it was worth pursuing... and I'm sick of trying to introduce new ideas for how to make things easier for the users to use when everybody else seems to think that just because something is a standard it's the best thing in the world to develop to. Even when the standard's clearly not being used everywhere it was by now supposed to be.) :-( It's very different in terms of MITM protection. Yes indeed it is, but the end-result is identical, full *RP* protection against on-the-wire MITM attacks assuming that server-side TLS is used in both cases. A server can't request a client authenticate if it doesn't authenticate to the client first. This is one of the fundamental tenets of the SSL and TLS protocols. However, there are proxies that insert themselves as MITMs to clients which have (by administrative policy) been forced to accept a private-label certificate that has '*' as its Subject. The client in this case can't figure out anything's amiss, but if client certificates requirements are in place the server can. All of these could be solved IMO, but it would require a joined browser/server effort, and to build bridges between the applicative level and the ssl session management on the web server. The browser side of the equation is already complete (as long as the browser allows sessions to be cached). The server side is what's missing, and there is little insight into the TLS session management on the server from the webapp layer. Yes, but that is surely not going to happen because the alternatives are already in place and are anyway needed for the signature stuff that no browser vendor has shown any kind of interest in despite the fact that millions of people already use it on a daily basis. This is, I think, a matter of documentation, as I mentioned above. It could be made easier, but the pieces are all there. it matches poorly with web sessions including logout Why should it match application sessions? Because the web application developers are too dumb to get the session handling right for themselves? Because the logout does not behave like they are used with passwords? You essentially gave the answer yourself. In order to deploy TLS-client-cert-auth you must hire very special people. That MSIE has a button Clear SSL State is a pretty good indication that securing a static tunnel and browsing the web are two quite distinct applications. That Mozilla apparently works completely different (?) is not an argument for
Re: TLS-client-cert-auth in .SE
Anders Rundgren wrote: it matches poorly with web sessions including logout Why should it match application sessions? Because the web application developers are too dumb to get the session handling right for themselves? Because the logout does not behave like they are used with passwords? You essentially gave the answer yourself. In order to deploy TLS-client-cert-auth you must hire very special people. Like with any other technology you'd like to deploy you have to know what you're doing. Everyone who is not able to even hire such people should stay out of that business. That MSIE has a button Clear SSL State is a pretty good indication that securing a static tunnel and browsing the web are two quite distinct applications. Yes, they are distinct. But I'm not sure why MS introduced this button in IE. Do you know this? IMO it has nothing to do with web application's session handling. That Mozilla apparently works completely different (?) is not an argument for TLS-client-cert-auth, it is an argument *against* it. I don't understand. - it is poorly implemented in many browsers with respect to path building Can you explain this? At least in FF 2.x, a PIV user had to *install* the entire cert-path in the browser trust store in order to authenticate since stuff like AIA ca issuers isn't supported in spite of being mandated in PIV. Hopefully this was fixed in FF 3.0 but of course this total misalignment has given TLS-client-cert-auth a *well-deserved* bad reputation. I consider this to be a matter of appropriate client enrollment. I guess many CAs are doing it wrong. - it offers very limited filtering capability What do you want to filter? At which point? Well, I think that Nelson can testify that there has been a rather long-lasting bug in FF regarding what certificate to show the user in the TLS selection GUI based on [for example] key usage. I don't consider this a bug in FF, but a deficiency in TLS- client-cert-auth which didn't take this issue in consideration. The fat-app alternatives usually offer much better selection facilities like in: http://tinyurl.com/6ot2vz I fail to see how this could be improved by new shiny XML-based protocol but cannot be improved with the existing protocols (like TLS). Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: TLS-client-cert-auth in .SE
Michael Ströder [EMAIL PROTECTED] wrote I fail to see how this could be improved by new shiny XML-based protocol but cannot be improved with the existing protocols (like TLS). Because the people that works with new shiny XML-based security protocols are often more interested in interoperability and user experience than the overly crypto-oriented people who created schemes like S/MIME and TLS were: http://lists.oasis-open.org/archives/tc-announce/200807/msg00010.html This is probably due to the fact that these efforts are not based on what the US government needs but what the Internet community needs. I couldn't even find the concept of user-experience in the TLS/HTTPS RFCs but I may have read it too quick. Anders - Original Message - From: Michael Ströder [EMAIL PROTECTED] Newsgroups: mozilla.dev.tech.crypto To: dev-tech-crypto@lists.mozilla.org Sent: Friday, August 29, 2008 16:54 Subject: Re: TLS-client-cert-auth in .SE Anders Rundgren wrote: it matches poorly with web sessions including logout Why should it match application sessions? Because the web application developers are too dumb to get the session handling right for themselves? Because the logout does not behave like they are used with passwords? You essentially gave the answer yourself. In order to deploy TLS-client-cert-auth you must hire very special people. Like with any other technology you'd like to deploy you have to know what you're doing. Everyone who is not able to even hire such people should stay out of that business. That MSIE has a button Clear SSL State is a pretty good indication that securing a static tunnel and browsing the web are two quite distinct applications. Yes, they are distinct. But I'm not sure why MS introduced this button in IE. Do you know this? IMO it has nothing to do with web application's session handling. That Mozilla apparently works completely different (?) is not an argument for TLS-client-cert-auth, it is an argument *against* it. I don't understand. - it is poorly implemented in many browsers with respect to path building Can you explain this? At least in FF 2.x, a PIV user had to *install* the entire cert-path in the browser trust store in order to authenticate since stuff like AIA ca issuers isn't supported in spite of being mandated in PIV. Hopefully this was fixed in FF 3.0 but of course this total misalignment has given TLS-client-cert-auth a *well-deserved* bad reputation. I consider this to be a matter of appropriate client enrollment. I guess many CAs are doing it wrong. - it offers very limited filtering capability What do you want to filter? At which point? Well, I think that Nelson can testify that there has been a rather long-lasting bug in FF regarding what certificate to show the user in the TLS selection GUI based on [for example] key usage. I don't consider this a bug in FF, but a deficiency in TLS- client-cert-auth which didn't take this issue in consideration. The fat-app alternatives usually offer much better selection facilities like in: http://tinyurl.com/6ot2vz I fail to see how this could be improved by new shiny XML-based protocol but cannot be improved with the existing protocols (like TLS). Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: TLS-client-cert-auth in .SE
Anders Rundgren wrote: Michael Ströder [EMAIL PROTECTED] wrote I fail to see how this could be improved by new shiny XML-based protocol but cannot be improved with the existing protocols (like TLS). Because the people that works with new shiny XML-based security protocols are often more interested in interoperability and user experience than the overly crypto-oriented people who created schemes like S/MIME and TLS were: http://lists.oasis-open.org/archives/tc-announce/200807/msg00010.html Personally I don't think so. This is probably due to the fact that these efforts are not based on what the US government needs but what the Internet community needs. I fail to see who exactly the Internet community is. Maybe that's the reason I don't understand the problem. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: TLS-client-cert-auth in .SE
This is probably due to the fact that these efforts are not based on what the US government needs but what the Internet community needs. I fail to see who exactly the Internet community is. Maybe that's the reason I don't understand the problem. I don't claim to be the definer of this term so I can only give examples that shows what *I* refer to. S/MIME is a scheme that has failed to deliver value except in local communities. I.e. a typical US government solution. DKIM is a transparent signature scheme that in spite of being 10 years too late is already securing many more messages than S/MIME. The German e-invoice scheme is another example of extreme misuse of technology that will forever (=until the current generation of security experts retire...) make PKI.DE a very expensive and complex solution. I note (with mixed feelings) that some Swedish companies have found a profitable niche by offering support for German e-invoices which among many things involves stacks smart cards emulating an office filled with invoice clerks. We somewhat more lazy people just put a single non- personal certificate (like a Verisign web-server cert) and a key in a HSM to sign outgoing invoices which scales globally without requiring monstrosities like Bridge CAs.. Anders ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: TLS-client-cert-auth in .SE
Anders Rundgren wrote: Today I was in a meeting with Swedish bank-people. They told me that they are planning exodus from TLS-client-cert-auth because it (in their opinion) works really bad. The banks will replace TLS-client-cert-auth with a proprietary auth client that is very similar to their current signature client. :-( It's very different in terms of MITM protection. [...] So what's the problem with TLS-client-cert-auth? Maybe because Hum, don't they have something much more precise than a *maybe* ? - it matches poorly with web sessions including logout - the GUI look like c--p - it offers no branding capability I think the problem is almost exactly the same as the one that has caused form/cookie based authentication to replace Basic Authentication. - it require PIN caching for smart cards Enhancement session cache management should make that not a problem. With the application, they have application level control on how long the initial authentication is considered valid, here they loose it. All of these could be solved IMO, but it would require a joined browser/server effort, and to build bridges between the applicative level and the ssl session management on the web server. - it is poorly implemented in many browsers with respect to path building - it offers very limited filtering capability I'm not sure I very well understand this two points, but I suspect the solution boils down to offering much more flexible, application level control on the client certificate selection. While I clearly understand it's a required added value for the application, it would rises some privacy protection concerns. You don't want random applications to know the exact number and content of all the cert you own, but it would more or less need to be able to see that to help you choose the correct one properly. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: TLS-client-cert-auth in .SE
Anders Rundgren wrote: Today I was in a meeting with Swedish bank-people. They told me that they are planning exodus from TLS-client-cert-auth because it (in their opinion) works really bad. Well, most times I don't count bank-people as IT security experts. So what's the problem with TLS-client-cert-auth? Unfortunately the biggest problem is that it's not used very often. ;-) it matches poorly with web sessions including logout Why should it match application sessions? Because the web application developers are too dumb to get the session handling right for themselves? Because the logout does not behave like they are used with passwords? - the GUI look like c--p ??? - it offers no branding capability Ah, well...frankly I'm very glad that no-one can place banner ads in this UI part. And I'd rather translate this to: It does not offer possibilities for spoofing attacks. ;-) - it require PIN caching for smart cards If you configure your web server properly to do SSL session caching you don't need PIN caching. - it is poorly implemented in many browsers with respect to path building Can you explain this? - it offers very limited filtering capability What do you want to filter? At which point? The only caveat is that the authentication ends at the first SSL end-point. Most times this is a reverse proxy server, not the web application server itself. So the web application server has to fully trust the web frontend server. But behind this web frontend server you can do filtering of requests. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: TLS-client-cert-auth in .SE
Jean-Marc Desperrier wrote: - it matches poorly with web sessions including logout - the GUI look like c--p - it offers no branding capability I think the problem is almost exactly the same as the one that has caused form/cookie based authentication to replace Basic Authentication. Not really. HTTP basic authc is security-wise worse than form-based authc with session handling because the user's credential goes over the wire in clear with each HTTP request and the browser caches it for the whole time it is running. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: TLS-client-cert-auth in .SE
Michael Ströder wrote: Anders Rundgren wrote: Today I was in a meeting with Swedish bank-people. They told me that they are planning exodus from TLS-client-cert-auth because it (in their opinion) works really bad. Well, most times I don't count bank-people as IT security experts. Precisely: This does not mean that I never met real IT security experts in a bank. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
