- From: Aymeric Vitte <vitteaymeric@gmail.com>
- Date: Thu, 31 Jan 2013 17:30:56 +0100
- To: Eric Rescorla <ekr@rtfm.com>
- CC: Ryan Sleevi <sleevi@google.com>, Harry Halpin <hhalpin@w3.org>, Mountie Lee <mountie.lee@mw2.or.kr>, public-webcrypto-comments@w3.org
- Message-ID: <510A9C40.2010306@gmail.com>
Yes, the most concise and simplified I can make is : 1- for [4] (copy of part of some emails I sent) : - the proxy (OP which communicates with the anonymizer network) and the page (loading a fake domain let's say https://moc.elgoog.www.com for http://www.google.com (that the user did request), please note that http becomes https) are inside the browser and can communicate using js - both communicate with an anonymizer router via the socks proxy interface, the router sends the https responses to the browser, the proxy sends instructions to the router via websosckets (using the socks proxy channel too) - when the page starts loading https://moc.elgoog.www.com, it establishes a TLS connection with the proxy relayed by the router - the proxy generates "on the fly" a certificate, it can not be a valid one because the fake domain (here moc.elgoog.www.com) is different each time the user requests a different domain and even if we could import/store valid certificates I don't see how we could hide/protect the private key - handshake happens between the proxy and the page, the browser does display a warning, the user acknowledges it The problem of course is that a MITM attack is easy (see Evil 1 on the drawing). But since the proxy and the page can communicate inside the browser, the idea is simply for the page to retrieve the certificates and to check with the proxy that it is the good one, all of this with js, therefore a MITM attack looks impossible. It can look like a paradox, the non valid certificate protects the communication... The warnings are not very esthetical but impossible to avoid, and if you don't get it you are sure that you have a problem. 2- for [3] : The client (browser) sets a wss connection with a router, pub_key is used. The client does not really care about the TLS connection because it does implement another secure protocol, but he wants to be absolutely sure that he is discussing with the friendly router he requested. For this, the server sends back to the client a certified_key. The client identifies the server by checking that the pub_key used in the TLS handshake matches the certified_key received from the server, where the certified_key is the pub_key signed with the id_priv_key of the server and therefore verified with its public id_pub_key. That's a kind of tls handshake on top of the normal one. Regards, Le 31/01/2013 16:54, Eric Rescorla a écrit : > > > On Thu, Jan 31, 2013 at 7:53 AM, Aymeric Vitte <vitteaymeric@gmail.com > <mailto:vitteaymeric@gmail.com>> wrote: > > I don't know what examples were given before and your replies, but > the two last examples I gave have nothing to do with > double-checking certificates against browser's checks, we just > need to retrieve them for other checks. > > > The example you provide in your previous message: > "A common point is that you might not trust the browser's checks > and/or (are not using)/(can not) use valid certificates and/or do not > trust a site, but there might be some other uses, I have seen on the > web some posts from people requesting it and it was put in your Use > cases chart far before I mentioned it." > > Appears to be exactly double-checking the browser. > > Do you have a concise description (i.e., not a link to a paper) of > some use case that > doesn't have the property that it simultaneously trusts and distrusts > the browser's > cert checking? > > -Ekr > > Regards > > Le 31/01/2013 16:37, Eric Rescorla a écrit : >> FWIW, I agree with Ryan. >> There no doubt are scenarios in which certificate processing >> functionality >> is useful in JS on the client, but I don't believe that >> double-checking >> that the browser has correctly evaluated the certificate chain is >> one of >> them, for the security reasons Ryan and I have both argued before. >> (Of course, whether that means that the processing needs to be in >> the browser is yet another story). >> >> At this time, I don't see sufficient use cases to add a new pile >> of complexity >> to a draft which is already quite complex. Moreover, certificate >> verification >> is conceptually quite different, so deserves to be in a separate >> spec in >> any case. >> >> -Ekr >> >> >> On Thu, Jan 31, 2013 at 6:29 AM, Ryan Sleevi <sleevi@google.com >> <mailto:sleevi@google.com>> wrote: >> >> Harry, >> >> Surely when you said "put in the spec" you meant "put in a >> spec" - that is, some other spec entirely. Right? >> >> Because I absolutely positively do not see anything like this >> making it in to our current work - both for reasons of >> interest (I have explained several times the problems with >> what is being asked) and for reasons of complexity. >> >> On Jan 31, 2013 5:46 AM, "Harry Halpin" <hhalpin@w3.org >> <mailto:hhalpin@w3.org>> wrote: >> >> On 01/31/2013 01:57 PM, Aymeric Vitte wrote: >>> Hi, >>> >>> I think it's not in your list, then I would add : >>> >>> "Exposing the server certificate (possibly structured, >>> if not we'll need a bullet-proof, signed, X.509 library) >>> and path of the TLS connection as JavaScript objects." >>> (http://www.w3.org/2012/webcrypto/wiki/Use_Cases#Miscellaneous) >>> >>> I have given examples already why it's needed [1], see >>> another use case here [2] chapter 4.2 (and [3] for more >>> details - the client identifies the server by checking >>> that the pub_key used in the TLS handshake matches the >>> certified_key received from the server in CERTS >>> messages, where the certified_key is the pub_key signed >>> with the id_priv_key of the server and therefore >>> verified with its public id_pub_key) >> >> What is missing from these proposals is concrete, >> well-specified proposals. In other words, WebIDLs that we >> could put in the spec. Also, implementers would have to >> agree its reasonable to implement this functionality >> within the current WG's timeframe. >> >> So, please specify some example code! >> >> cheers, >> harry >> >>> >>> Regards, >>> >>> [1] >>> http://lists.w3.org/Archives/Public/public-webcrypto-comments/2012Nov/0037.html >>> [2] >>> https://gitweb.torproject.org/torspec.git?a=blob_plain;hb=HEAD;f=tor-spec.txt >>> [3] http://archives.seul.org/or/dev/Jan-2011/msg00052.html >>> >>> Le 31/01/2013 02:17, Mountie Lee a écrit : >>>> Hi. >>>> at WebCrypto WG Charter >>>> (http://www.w3.org/2011/11/webcryptography-charter.html) >>>> following secondary features are listed. >>>> >>>> * control of TLS session login/logout >>>> * derivation of keys from TLS sessions >>>> * a simplified data protection function >>>> * multiple key containers >>>> * key import/export >>>> * a common method for accessing and defining >>>> properties of keys >>>> * the lifecycle control of credentials such >>>> enrollment, selection, and revocation of >>>> credentials with a focus enabling the selection of >>>> certificates for signing and encryption >>>> >>>> as discussed in previous concall, >>>> we need to set priority for secondary features. >>>> >>>> I feel certificate related features has more priority >>>> than others. >>>> also TLS related features also have relationship with >>>> certificates. >>>> so with my view, I listed following certificate related >>>> secondary features >>>> >>>> * certificate enrollment >>>> o this is different from key generation >>>> o CMP can be considered. >>>> * certificate validation >>>> o certificate chain validation >>>> o CRL or OCSP validation >>>> * certificate selection with binded private key >>>> o has UI related requirement >>>> * access certificate extension fields >>>> o including optional fields >>>> * multi-origin crypto operation with certificate >>>> associated. >>>> * control of TLS session login/logout >>>> * derivation of keys from TLS sessions. >>>> >>>> any comments? >>>> >>>> regards >>>> mountie. >>>> >>>> -- >>>> Mountie Lee >>>> >>>> PayGate >>>> CTO, CISSP >>>> Tel : +82 2 2140 2700 <tel:%2B82%202%202140%202700> >>>> E-Mail : mountie@paygate.net <mailto:mountie@paygate.net> >>>> ======================================= >>>> PayGate Inc. >>>> THE STANDARD FOR ONLINE PAYMENT >>>> for Korea, Japan, China, and the World >>>> >>>> >>>> >>>> >>> >>> -- >>> jCore >>> Email :avitte@jcore.fr <mailto:avitte@jcore.fr> >>> iAnonym :http://www.ianonym.com >>> node-Tor :https://www.github.com/Ayms/node-Tor >>> GitHub :https://www.github.com/Ayms >>> Web :www.jcore.fr <http://www.jcore.fr> >>> Webble :www.webble.it <http://www.webble.it> >>> Extract Widget Mobile :www.extractwidget.com <http://www.extractwidget.com> >>> BlimpMe! :www.blimpme.com <http://www.blimpme.com> >> >> > > -- > jCore > Email :avitte@jcore.fr <mailto:avitte@jcore.fr> > iAnonym :http://www.ianonym.com > node-Tor :https://www.github.com/Ayms/node-Tor > GitHub :https://www.github.com/Ayms > Web :www.jcore.fr <http://www.jcore.fr> > Webble :www.webble.it <http://www.webble.it> > Extract Widget Mobile :www.extractwidget.com <http://www.extractwidget.com> > BlimpMe! :www.blimpme.com <http://www.blimpme.com> > > -- jCore Email : avitte@jcore.fr iAnonym : http://www.ianonym.com node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms Web : www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com
Received on Thursday, 31 January 2013 16:28:33 UTC