On Fri, September 27, 2013 5:51 pm, Robert Relyea wrote: > > > On 09/27/2013 05:01 PM, Ryan Sleevi wrote: > > On Fri, September 27, 2013 4:09 pm, Eddy Nigg wrote: > >> On 09/28/2013 01:59 AM, From Ryan Sleevi: > >>> If your site requires a client certificate, and you know that a client > >>> certificate is stored in a smart card, then you also know that when > >>> using > >>> Firefox, and the smart card is removed, Firefox will invalidate that > >>> SSL/TLS session. > >> Not really - except in case you require the cert authentication on > >> every > >> exchange between the client and server. I don't believe that many do > >> this as it makes it incredible slow and some browser will prompt for > >> the > >> certificate over an over again. > > But Firefox (and Chrome, IE, Safari, and Opera) won't. > > > > I'm not sure FIrefox supporting some non-Web Platform feature on the > > basis > > that some other browser makes it hard, especially when the number of > > browsers that support the feature beyond Firefox is 0. > Ryan is correct. What FF does not do is reload the page when the smart > card is removed. The most common use of smart card events is forcing the > reloading the page. > > NOTE: there is still an issue that Firefox doesn't provide a way for the > web page to flush it's own cache. If you've made a connection without a > cert, there's no way to say try again with the cert. This doesn't affect > removal, but it does affect insertion.
FWIW, Chrome does. We're working on refining this. But that's not a standard behaviour, and if sites want to rely on that, they should rely on standards-defined behaviours. > > > >>> When the user removes their smart card, the SSL/TLS session is > >>> invalidated, and the > >>> user is 'logged out'. > >> Kind of, he'll get the infamous ssl_error_handshake_failure_alert > >> error > >> that nobody knows what it is, but that's not how such web apps are > >> usually implemented. They do the client authentication dance once and > >> continue with a application controlled session. > > Actually FF does a full handshake, what kind of error you get depends on > what bits the server said. If you pass request not require, then the > handshake completes with the server getting no cert for the connection. > > And such webapps could presumably use iframes or XHRs with a background > > refresh to a login domain, and when such a fetch fail, know the smart > > card > > was removed, and thus treat it as the same. All without non-standard > > features being exposed. > You still don't get the page refresh when the smart card is removed. But you don't need that in the iframe/XHR situation. You can implement a variety of techniques (hanging gets, COMET, meta refresh, etc) to accomplish this. > > I don't have a problem with going for an industry standard way of doing > all of these things, but it's certainly pretty presumptuous to remove > these features without supplying the industry standard replacements and > time for them to filter through the internet. > > bob Bob, The fact that these are problems that sites MUST solve for other browsers, I don't see why it's necessary to find a replacement first. I realize that some might find this functionality to make Firefox more compelling. People found ActiveX compelling. That does not mean it's good for the Internet at large, or the Web Platform. I certainly am not one to make decisions about Firefox's goals for the Web Platform, given what I work on, but I applaud efforts to remove non-standard features and to standardize features. But I don't think one must be held hostage to the other - the fact that these problems exist for other UAs means that the only sites that will be affected are those coded *specifically* to be Firefox only - and that does not a good Internet make. Cheers, Ryan -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
