Kyle Hamilton wrote, On 2009-03-21 15:49: > On Sat, Mar 21, 2009 at 2:58 PM, Nelson B Bolyard <nel...@bolyard.me> wrote:
> I blame NSS for choosing not to adhere to certain aspects of the SSL > 3.0 and TLS 1.0 standards (accepting a ClientCertificateRequest with a > zero-length list of identifiers of acceptable CAs), enforcing others > (including the 'fatal protocol_error alert' I alluded to above) NSS did enforce that for a long time, but then certain misconfigured servers began, in large numbers, to request client auth without sending and issuer names, and browsers simply stopped working with those servers. So, NSS was changed to forgive that error. There seemed to be no down side to doing so. On behalf of the NSS team, I supported the change in TLS 1.1 to allow zero length lists of issuer names. > I *do*, however, blame NSS for requiring client keys and certificates to > be installed in the current user's certificate store in order to use > them. NSS requires them to be in some (any) "device" (could be virtual) that is accessible through the PKCS#11 API. Remember that NSS can use certs and keys from ANY PKCS#11 software module, including those that make the OS's native cert/key store appear to be a PKCS#11 token. There's a PKCS#11 module that looks in the computer's on-board TPM chip. There's even a PKCS#11 module that looks in a directory of PEM files. NSS offers a capable and secure means of storage of keys and certs, and offers an extensible API through which any other scheme you can name can be plugged in. Now, is your complaint still valid? Or have you merely not yet availed yourself of the available solutions? > I still, however, believe that server-auth is -- if not the the worst > feature of TLS -- certainly the most overhyped and misused. You mean, most ignored by users? Absolutely. Most users always blindly assume that they're connected to the server they want to be connected to. They have no CONCEPT of MITM in their heads. They cannot imagine that the server to which they're talking would be an attacker's. They're the ones who say "I don't need authentication, only encryption". They'll type their user name and password into any screen from any server, which is exactly why phishing exists. That's also why user identification and authentication schemes -- wherein the info that the user presents to the remote server CANNOT be used by that server to impersonate the user -- are SO important. SSL client auth is such a scheme. > Interesting. So my friend in Ann Arbor who has a 6-to-4 IPsec tunnel > should be able to use it without problems (and can't, as the tunnel > uses IPsec and is blocked), and my friend in San Jose who needed to > upgrade to a business account so that he could do work from home > (using the Cisco VPN utility) shouldn't have needed to? I suspect so. I use the Cisco VPN utility from home on my ordinary home Comcast cable modem in a suburb of San Jose. I think Comcast customer service reps may be too quick to up sell users who have problems to the more expensive accounts. It's also possible that Comcast doesn't operate uniformly in all markets. > Alright, fair point. I am (and have been) looking at it from the view > of a single webserver providing a single service. Didn't you recently accuse me of that? > I realize that there are other implementations in production If one looks at the number of different products that use SSL/TLS, and counts each product as one (counting products, not instances of products) browsers and web servers are a small percentage of the total applications that use SSL/TLS. That's also true of the products that use NSS. It's very common to use SSL/TLS between servers, acting as clients, and other servers. In such applications of SSL, (in)activity based session lifetimes are unwanted. NSS is useful to all of those classes of products. > This wouldn't particularly work [...] Particularly if the session > has to ask, every time it wants to switch credentials, what > certificate to use for it. NSS supports having multiple simultaneous sessions between a client and a server, each bearing different credentials. >> The problem here is that people so desperately (or ignorantly) want the >> TLS sessions to be application sessions, that they configure the TLS >> sessions as if they WERE application sessions. They configure TLS >> sessions with an upper bound of a few minutes (or seconds), thinking >> (or wishing) that TLS sessions are based on inactivity times. The >> solution is not to change TLS to work the way that some single application >> wants its sessions to work, and it is not to misconfigure TLS sessions >> with absurdly short maximum lifetimes. That is a server problem, perhaps >> a server admin problem. It is not a browser problem. > > Is it? Or is it something that, like the CA/B forum, needs a S/B forum? If TLS was a standard only for browsers and web servers, then browsers and web server representatives could get together and define to work just for them. But it isn't. > Rather than making all the assumptions from the RFCs and > standards that exist, which have been shown to have failed in the > underlying goal of interoperability, All the interoperation that happens on the internet is on the basis of those IETF standards. That's hardly "shown to have failed". > perhaps the most important thing would be to settle down, stop blaming > the other, sit down, and negotiate on exactly what the various things > *mean*. (I swear, this is almost worse than the Hatfields and McCoys...) Here's an idea. Settle down, stop blaming the browser, and get the developers and admins of the products to start using the standards as they exist, configuring their products to use the standard protocol features as they are actually defined, rather than perpetually whining that the standards don't work the way they'd personally like. >> Configuring TLS session lifetimes in the server with absurdly short maximum >> lifetimes (including zero lifetimes) is THE SOLE CAUSE of all that >> re-prompting for TLS client auth. It's stupid. To all the admins who do >> that, and then whine that the browser prompts often, I repeat: "Doctor, >> it hurts when I do this". > > Maybe, just maybe, you should get off your high-horse. You are > describing this as if it is The Way Things Are And Cannot Be Changed > (like the human body). This isn't the human body, it's software. > It's insanely configurable. It's insanely re-editable. > > It may be THE SOLE CAUSE as far as YOUR IMPLEMENTATION goes... There is no other cause for browsers (or any TLS client, regardless of implementation) to ever need to choose a client cert, by any means, other than to receive a client auth request from the server, which BY DEFINITION only happens when the server has chosen not to reuse an existing session. > but if there's enough people who don't understand the configuration, > that means that there's a major disconnect in communication somewhere. OK, so the server products don't educate their users (admins) how to properly configure them. Hey, let's insist that the browser change instead! > Yes, the problem exists on the servers -- but until you sit down and > explain *why* certain decisions on the client have been made, to the > people working with the servers, so that they can go "oh, but what > about *this?*" and explain why certain decisions on the server have > been made, and you can come to a real workable compromise that > addresses your concerns AND the concerns on the server side... See, there are these things called standards. Interoperation on the Internet is a function of conformance to standards. They've already been negotiated. It's not an endless renegotiation of protocols to accommodate every Johnny Come Lately. Now people (including developers and admins) must take the time to learn to use them properly. There will always be those who, when confronted with the fact that they're abusing the standards, will revile the standards to save face. And there will always be those who imagine that the product they use *IS* the standard. (I am reminded of a comment I read recently, saying that there must be a flaw in the RFC, because OpenSSL doesn't work the way the RFC says. :) Standards do evolve. If people want to change the standards, the place to do that is in the IETF working groups, not in the NSS mailing list. >>> Yes. It's just the fact that die-hard "This Is The Way The Standard Is >>> And This Is The Way The Standard Shall Always Be" viewpoint-holders, like >>> you, insist on relying on a paradigm which has been shown to be >>> fundamentally useless in the every-day usage of the protocol. I guess that would be the paradigm of following the standards, eh? You'd rather have every thing be constantly renegotiated, I gather? Let me suggest that you clearly separate UI issues from protocol issues. There are standards for the security protocols. Those standards govern practically every aspect of security protocols. By contrast, there are far fewer standards for UI. UI is infinitely malleable. So, perhaps you should expend you efforts on trying to get browser UI to change. IMO, this list is not the place to do that, because this is not where the UI guys hang out. (One of them lurks here sometimes, but ...) >>> (The DoD also doesn't use Firefox, so >>> they don't end up filing bugs against it anyway.) >> Actually, they do. That's a big reason why NSS gets the funding it does. >> Why do you think Suite B support went into NSS for FF2? > > Interesting. So my friends and contacts in the various IT > substructures in the Navy, Marines, and Air Force have been > misrepresenting that to me all these years. They have stated to me > that Firefox doesn't go on computers that connect to the Official > Network, but only on the Morale & Recreation machines. There are FF web browsers on subs and in tanks. Is that M&R? (Do tank operators play first person shooter games between battles? :) Seriously, there are DoD installations that are still running FF2 because FF3 uses a newer version of NSS that has not yet been FIPS 140 certified. The certification of NSS 3.12.x (the version in FF3) begins next month. > -Kyle H -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
