New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 8 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Jul 2011
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Restricted
  • Only users with Commit permission may comment.



Sign in to add a comment

window.crypto.logout() and login() don't work.

Reported by henry.st...@gmail.com, Jul 27 2011

Issue description

Chrome Version       : 13.0.782.99
OS Version: OS X 10.7.0
URLs (if applicable) : http://lists.w3.org/Archives/Public/public-xg-webid/2011Jul/0120.html
Other browsers tested:
  Add OK or FAIL after other browsers where you have tested this issue:
     Safari 5: fail
  Firefox 5.0.1: succeed
     IE 7/8/9: 

What steps will reproduce the problem?
1. You need a web server behind https with client side certificate auth
2. create a web page with a login/logout link and a onlick="login()" for one and logout() for the other using the javscript shown in the mail and pasted below
3. a. you should get logged in when you go to the site, that site should show you something
     in your certificate
    b. click logout does nothing
    c. click login does nothing

What is the expected result?

   - clicking logout should get the server to ask you for a new certificate - or better to just break the tls
connection. 
   - clicking login should get the browser to ask the user to select a certificate

What happens instead?

    nothing happens. This makes it difficult for servers to offer the option to a user to choose a different certificate. This would probably be a good workaround until  issue 29784  is finished. 29784 is a lot more work, but would put the user in much more control. This would allow services to use TLS in a more friendly way, and get some balls rolling to help improve security on the web.

Please provide any additional information below. Attach a screenshot if
possible.

//this is for xhtml
//these functions are described here http://html5.creation.net/webcrypto-api/
<script language="JavaScript" type="text/javascript">
 <![CDATA[
     function logout() {
     if (document.all == null) // FF, Opera, etc
        {      
           alert('logout in ff,opera...')
           if (window.crypto) window.crypto.logout();
           else alert('no window.crypto')
        }      
      else // MSIE 6+
        {      
           alert('logout in msie') 
           document.execCommand('ClearAuthenticationCache');
        };     
     }
     function login() {
     if (document.all == null) // FF, Opera, etc
        {      
           alert('login in ff,opera...')
           if (window.crypto) window.crypto.logout();
            else alert('no window.crypto')
        }      
      else // MSIE 6+
        {      
           alert('login in msie') 
           document.execCommand('ClearAuthenticationCache');
        };     
     }
 ]]>
 </script>


UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_0) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.99 Safari/535.1



 

Comment 1 by js...@chromium.org, Jul 27 2011

Cc: abarth@chromium.org wtc@chromium.org rsleevi@chromium.org ian@chromium.org
Labels: -OS-Mac OS-All
This shares some non-trivial amount of overlap with Issue 90454.

That said, abarth, I suspect you have more insight into the origin rules, but I cannot imagine a sane and rational world where a site at foo.example should be permitted to, in any way, alter/affect the authentication state/cache of bar.example. 

As I mentioned on Issue 90454, we might consider exposing such functionality to extensions (with some new/suitable permissions), but exposing it directly to webpages does not seem consistent with the work you and others have done regarding cross-origin security and attacks.

There is ongoing discussion in the IETF TLS WG about this, but it's sufficient to say that there is not consensus that the above proposed behaviour is necessarily good or consistent with TLS CCA design goals (transport security vs application security).

abarth, wtc: Are you aware of any compelling reasons to go down this route? Should we close this and let Issue 90454/ Issue 29784  be the path that we improve the client certificate auth user experience? The design/implementation of window.crypto seems to reflect a more... idealistic... time in web security (see window.crypto.addmodule() / window.crypto.deletemodule() - which I am aware of being used in the wild)
See also  Issue 77078 . This is a dupe of that, but a request for only a small, specific subset of window.crypto, hence I left it open to be evaluated independently.
Labels: -Area-Undefined Area-WebKit Area-Internals WebKit-JavaScript Internals-Network-SSL

Comment 5 by abarth@chromium.org, Jul 27 2011

Status: WontFix
What is http://html5.creation.net/webcrypto-api/ ?  We don't implement hardly anything on window.crypto:

http://trac.webkit.org/browser/trunk/Source/WebCore/page/Crypto.idl

If we're doing to implement anything, we're more likely to implement DOMCrypt:

https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest

However, the current feeling in the WebKit community is to wait for that spec to mature a bit before starting to implement it:

http://www.mail-archive.com/webkit-dev@lists.webkit.org/msg16090.html
DomCrypt does not have a logout or a login method. So I don't see how it solves this problem, at least as it is stated now.
yes, I am not sure how I came across http://html5.creation.net/webcrypto-api/ . It seems to describe the way some of the browsers - Firefox in particular - do work. But perhaps there is some better documentation somewhere. 
The webcrypto-api comments are more in line with  Issue 73226 , and completely and wholly unrelated to the SSL certificate/session cache.

Comment 9 by abarth@chromium.org, Jul 27 2011

DOMCrypt seems likely to become the spec for window.crypto.  If we want to support login/logout, that's the route to go.

The higher-level point is that we don't support hardly any of the window.crypto APIs, which are entirely non-standard.  There's interest from a bunch of different directions to flesh these out a bit.  If you're interested in seeing that happen, you should encourage Mozilla to move forward with getting DOMCrypt to the standards track (e.g., a the W3C) and then working through the standards process to make sure your use cases are addressed.
This issue has been set as won't fix. Should I open another issue which asks for a javascript login/logout api without specifying which api it should be? 
Regardless of where the API goes, we'll still want to go through the standards process rather than proliferating non-standard APIs.  Given that there's precedent for this API in window.crypto, the most virtual path forward is probably to interact with the DOMCrypt standards effort.  No bug report here is necessary.
Project Member

Comment 12 by bugdroid1@chromium.org, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 13 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-WebKit -Area-Internals -WebKit-JavaScript -Internals-Network-SSL Cr-Content Cr-Content-JavaScript Cr-Internals-Network-SSL Cr-Internals
Project Member

Comment 14 by bugdroid1@chromium.org, Apr 6 2013

Labels: -Cr-Content Cr-Blink
Project Member

Comment 15 by bugdroid1@chromium.org, Apr 6 2013

Labels: -Cr-Content-JavaScript Cr-Blink-JavaScript

Sign in to add a comment