Kyle Hamilton wrote, On 2009-03-22 04:40: > On Sat, Mar 21, 2009 at 5:57 PM, Nelson B Bolyard <nel...@bolyard.me> > wrote: >> 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. > > So, essentially, you allowed servers to dictate client behavior, and it's > turning around and biting you in the ass. LOL. We decided that a malformed client cert request was not a reason to deny the browser user access to the site. We worked around a wide spread server bug, because we decided it wasn't such a heinous bug. > This explains why you're so averse to changing the client/browser at > this point -- because you already made one change to appease the server > crowd, and it's simply opened an additional can of worms. I'm averse to people demanding changes to transport layer security when their problems are not transport layer problems. (UI is not a transport layer issue, ever.) > Oh wait, I'm bitching about the UI again. (Have I not tried to explain > before this that all of these problems are interconnected? Yes, but bitching about UI to people who don't work on UI and can't change the UI is just bitching, and it's not appreciated. >> 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. > > Perfect! Now how does one install it? Each product has one way to install PKCS#11 modules. All modules are installed in that product by that method, whatever it is. In Firefox, you go to the Options dialog (exact method varies by platform, on Windows you find Options in the Tools menu) select the "Advanced" tab, and the "Encryption" sub-tab, then click "Security Devices". This brings up the "Device Manager" dialog which lists the PKCS#11 modules you have installed, and the "devices" (called "tokens" in PKCS#11 speak) or "slots" (for pluggable tokens) that are managed by each module. In that dialog, the "Load" button brings up a misnamed "Load PKCS#11 Device" (should be module) dialog. There, you type in the name of the shared library (DLL, Dylib, or .so) which is the PKCS#11 module, and you enter a name by which you want to remember that module (it will be displayed in the device manager dialog), and click OK. Voila. > PKCS#11 has at least two major flaws, neither of which has been addressed > at all to my knowledge. > > 1) It is platform/OS specific -- you're provided a binary module which > you must trust to not do anything inimicable with your certificates or > keys. Its API is entirely platform independent, the same on every platform. That's why Firefox uses it, because it's the same on every platform. Yes, you need an executable file (DLL, Dylib, SO) that is peculiar to your platform. And if you use hardware, you need hardware that works on your platform. PKCS#11 hides those differences from the application by providing an API that is the same on all. > 1a) Platform unsupported by the provider of the token? You're SOL. That's a fault of PKCS#11? > 1b) You think the binary module is spyware-laden? You're SOL. That's a fault of PKCS#11? > 2) The installation into each environment is different. The Firefox dialog is the same on every platform. > 2a) I don't know how to install such a module in OSX for its key manager > to use. 2b) I don't know how to install such a module in OSX for Firefox > to use (other than secmod) 2c) I don't know how to install such a module > in Windows for CryptoAPI to use. 2b is a different thing than 2a and 2c. The PKCS#11 API is the same on all platforms. It is an alternative to platform dependent/proprietary APIs, such as CryptoAPI and whatever Mac uses. You don't install a PKCS#11 module for CryptoAPI to use. You install a PKCS#11 module to be used instead of CryptoAPI. Firefox uses PKCS#11 on all platforms, rather that using a different platform- dependent API on each platform. > Even EFI (Extensible Firmware Interface) has addressed problem #1: it > defines a platform-independent bytecode for drivers which conforming > implementations must interpret in a manner which will allow the device to > initialize and begin providing services. LOL. Where have I heard that before? Java? Forth? > I've already stated my thoughts as to why this is a bogus argument -- > including "there's no branding of CAs" -- so I'm not going to repeat it > here. (They don't recognize the importance of the CA because the CA is > never actually presented to them as being something worth noticing.) Yes, Please don't repeat your UI complaints here. >> I use the Cisco VPN utility from home on my ordinary home Comcast cable >> modem in a suburb of San Jose. [...] It's also possible that Comcast >> doesn't operate uniformly in all markets. > > Alright, thank you (very much!) for the information. I'll see if I can't > help him troubleshoot what's going on. By googling, I have learned that, in some markets, Comcast blocks IPSec over UDP but allows IPSec over TCP. However, I use it over UDP (IINM). > I'm failing to understand how sessions (negotiated before any data, > including the GET header, is sent to the server) can be separated at the > path level while still allowing each path to separate its authentication > requirement -- meaning, allowing the session ID to be changed during a > renegotiation, for a specific path. I don't understand what you wrote there. I don't know what you meant by "path" (application?). A "Session ID" is just a big arbitrary number that identifies a session, and it changes with every session, including with every session renegotiation (which actually establishes a new TLS session). I think that, when you used that term, you meant the user ID associated with a session. > It'd work wonderfully for one of the things I'm working on, except I have > to use OpenSSL for because it's the one TLS implementation that I know > well enough to comment out the "protocol_error fatal alert" for the issue > related to TLS servers asking clients for authentication before they > choose to identify themselves. You're not using TLS. You're using Kyle's TLS-ish protocol. >>> 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. > Well, yes. The question is as I asked above: How can a client know that > it's not supposed to reuse the same session, with the same credentials, > with a different path on the server? In general, a client opens a connection to the server of the client's choice, and the client decided what identity it wants to present to that server for that connection. In NSS, we have named client session caches, which allow the client to have a separate cache for each of the client's different identities. So, whenever the application wants to start a TLS connection to be identified as "Kyle", it should tell TLS to use the "Kyle" client cache. That way, it can be sure that, if any old session is reused, it will be a session previously authenticated as "Kyle" and not as (say :) "Ian" or whatever other identities by which this client identifies itself. Now, perhaps, in response to that, you're going to say "Huzzah! Firefox needs UI that lets me select the client cache associated with each of my identities, something like a drop down identity selector that lives in chrome near the address bar." If you think that, I encourage you to pursue that IN A UI list. > What I'm proposing is that they try to work out the semantics of the > protocol -- what each part and interaction *means* -- and then write to > those semantics, those assumptions. I think some of the application/server developers should read a good book on TLS, like (say) Eric Rescorla's book. (He's the chair of the TLS WG). Maybe some admins should read it, too. I don't agree with some of his explanations of the history of TLS and why certain things are as they are, but his understanding of how TLS works today is excellent. > Client certificates have "shown to have failed", simply because they're > not in common use for the common person that the Mozilla Foundation > exists to build a browser for. The capability has existed for fifteen > years. As it happens, I do not believe that UI issues for client auth are the BIG stopper of client auth. Sure, I agree that UI could be improved, but before you get to experience those UI issues, you must actually have a cert and a server that you think might accept that cert as authenticating you. Today, few such servers exist. I think the absence of a single uniform user ID space is actually a greater impediment than UI. That's why I find Eddy's idea (if I understand it right) of using OpenID identities as that single space, and using certs to authenticate them, is so intriguing. When we get to the point where there are more users trying to use certs, and the average common Joe FF User is whining about cert UI in the ordinary FF user groups (rather than here in these esoteric back waters) THEN the FF UI folks will sit up and take notice. >> 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. > > No, actually. A server can send ClientCertificateRequest at any time, > including when a client has requested a resource that the server's > security policy states must have an underlying certificate > authentication. A server can send ClientCertificateRequest when the > current authentication doesn't have the proper access rights to the > underlying resource. This can all be done within the single session. No. That's incorrect. Yes, a server can ask the client at any time to initiate a new handshake, and it can do so with the intention of requesting client authentication. But it cannot request client auth in the same TLS session it is already using. SSL/TLS has two kinds of handshakes: those that establish new sessions, and those that reuse old sessions. They're quite different. They share only the first pair of hello messages, and the final change_cipher_spec record and Finished messages. In between, all is different. The Certificate Request message can ONLY occur in a "full" handshake, the type that establishes a new session with a new session ID. So, to request a client cert in the middle of a connection, a server must ask the client to initiate a new handshake, and then the server MUST refuse to reuse the old session, and go down the path of negotiating a new session. That's the ONLY way the server can request client auth. Kyle, I think maybe you should read Eric's book. The standards were written years ago, and they have well defined meaning. The people who don't understand them don't need to dialog with the people who wrote them. They need to take a class or read a book and learn how they actually work. The "impedance mismatch" of which I often hear is simply the gap between the reality of how the protocols are defined and the imaginations of those who want to use the protocols without really understanding them. > Funny, the "HTTP over TLS" RFC isn't a standard. It's an "informational > RFC". It is, nonetheless, THE standard, just as THE standard for SSL 3.0 is still just an (expired) Internet Draft. > You're even the one who pointed out that it was an "informational" RFC. Yes, I did so to forestall arguments such as the one you just made, saying "don't bother to tell me this because I already know it". Didn't work though. :-/ >> 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 ...) My point is that for each issue, there is a right place to address it. UI issues should be addressed in the fora where UI folks hang out. Issues with the TLS protocol should be addressed in the IETF TLS WG. Issues with NSS's implementation of the standards (which are NOT issues with the standards themselves) should be addressed here. You must separate the issues. > (There may be other issues raised during a discussion between the web > browsers and web servers that might suggest that it should be modified in > other ways, in later updates to the protocol, to enable certain things > that might be found useful -- I don't know, because I'm not at the table, > because the table doesn't exist yet.) It's called the IETF TLS Working Group. > The technical dialect of HTTP over TLS, though, is not functional. There > are assumptions that you make (as a browser vendor) that are not the same > as the assumptions that others make (as server vendors). There are well defined standards. Some products conform to them better than others. > Mozilla neé Netscape has spent millions of dollars on a feature which > isn't used by the people it's chartered to support. NSS is developed by developers who work for Sun Microsystems, Red Hat, and Google, and occasionally by open source contributions from others. It is used in many products, including Mozilla products. Mozilla allows NSS to share its infrastructure: the source code repository, the bug tracking system, the wiki servers, and this news group server and mailing list (and assorted other servers). Mozilla also runs the root CA program. There are LOTS of "enterprises" that use client auth. I know because I get called to help them diagnose their occasional problems with it. Their willingness to keep buying products that offer that feature is why there is funding to keep developing it. One reason for the popularity of LDAP Directory servers is their role in confirming authorization of users identified by the Directory Names in their SSL client certificates. > So, please forgive me, but I must seriously doubt this assertion. Doubt it all you like. But trust me that I know where the funding for my paycheck comes from. > (Especially since DES was dropped from FIPS-140-1 validity several years > ago.) Yes, and MD5 has never been in it, and its unlikely that SEED or Camellia ever will be, but NSS has those things, and had (some of) them when it last got FIPS certified. Of course, the FIPS certification doesn't cover the non-FIPS algorithms, but their presence does not stop the modules from being certified. Go see the FIPS cert list for yourself.. The thing named "Suite B" changed a lot of the rules, because the Suite B algorithms are also allowed for Secret use. Suite B has been in FF since FF2. /Nelson B - co-author RFC 4492: ECC (including Suite B) in TLS -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
