- From: Aymeric Vitte <vitteaymeric@gmail.com>
- Date: Fri, 23 Nov 2012 09:07:53 +0100
- To: Mountie Lee <mountie.lee@mw2.or.kr>
- CC: public-webcrypto-comments@w3.org
- Message-ID: <50AF2ED9.8090700@gmail.com>
Hi, Not sure to understand your answer, the request here is to be able to retrieve the certificates used for TLS connections on a web page using javascript in order to check them and detect things such as certificate change for a given domain, not to use it for encryption. See for example same request here (for good or bad reasons) : https://groups.google.com/forum/?fromgroups=#!topic/mozilla.dev.security.policy/hscKxmB6E00 or http://bytes.com/topic/javascript/answers/809180-retrieving-documents-certificate-js This is what are doing some plugins or extensions today, as written below the rationale is that you might want to doublecheck the certificates verification, or do something else with the certificates. Le 23/11/2012 01:08, Mountie Lee a écrit : > TLS connection is not message based. > WebCrypto API is able to handle message based encryption. > > if we use certificate derivated from TLS session for encrypting > message, we can not guarantee the encrypted message can be transfered > to application level safely. > > public-webcrypto-comments@w3.org > <mailto:public-webcrypto-comments@w3.org> is publicly open group mail, > anyone can post message to this groupmail > public-webcrypto@w3.org <mailto:public-webcrypto@w3.org> is W3C member > only groupmail. > > > On Fri, Nov 23, 2012 at 12:43 AM, Aymeric Vitte > <vitteaymeric@gmail.com <mailto:vitteaymeric@gmail.com>> wrote: > > Reading your email again, is what I am suggesting (get via > Webcrypto API the certificates chain for TLS connections and > manage it (detect changes for example)) in your list ? > > PS : what is the difference between the > public-webcrypto-comments@w3.org > <mailto:public-webcrypto-comments@w3.org> and > public-webcrypto@w3.org <mailto:public-webcrypto@w3.org> lists ? > > > Le 16/11/2012 09:56, Aymeric Vitte a écrit : >> Hi, >> >> I have not right now an extensive experience with certificates >> manipulation, then if I understand correctly what is behind your >> summary I would say it is OK assuming that it does include >> certificate generation. >> >> I would add something not specific to certificates only that I >> did not find into the spec if I am correct : handling of format >> conversion such as PEM_to_modulus and vice-versa (see example in >> node-Tor) >> >> And I would add something that I mentioned in the precedent email >> like a getPeerCertificate (used for example in node.js sockets) >> but associated to the page, for example >> window.location.certificate where certificate is the certificate >> used to load the main page. >> >> Beside the fact that I would specifically need it for the >> project, the more global rationale is that you might not >> necessarily trust your browser and then might want to doublecheck >> the certificate verification, or do something else with the >> certificate >> >> Le 16/11/2012 02:49, Mountie Lee a écrit : >>> Hi. >>> >>> the certificate or TLS is belong secondary feature of WebCrypto API. >>> >>> we are slightly moving to secondary features. >>> >>> from the multiple pending secondary features of WebCrypto API >>> I also have interest for certificate related issues. >>> >>> can we list-up the requirements for certificate related issues? >>> >>> followings are my list. >>> - API access X509 certificate extensions >>> - handling encodings from X509 certificate extensions >>> - signature validation with certificate >>> - certificate validation with CRL or OCSP >>> >>> >>> >>> On Thu, Nov 15, 2012 at 5:03 PM, Aymeric Vitte >>> <vitteaymeric@gmail.com <mailto:vitteaymeric@gmail.com>> wrote: >>> >>> The draft project is here : http://www.ianonym.com, the >>> "details" section are not specs but a summary, this is an >>> extension inside the browser of >>> https://github.com/Ayms/node-Tor which is a js >>> implementation over node.js of the Tor project. >>> >>> Assuming that the concept works (it seems to on the paper >>> and from some experimentations I made), here is what is >>> needed accessible with js inside the browser and the status >>> today : >>> >>> - mix node.js Buffers and Typed Arrays --> OK, home made >>> - URL parser --> OK, home made >>> - HTTP parser --> OK, home made >>> - self signed certificates generation (OP) --> NOK >>> - certificates verification (OP) --> NOK >>> - implement TLS protocol (OP, inside websockets, both >>> client and server side) --> NOK >>> - retrieve the certificate used for the first TLS >>> connection between the page and the OP (Evil1 attack) --> NOK >>> - implement Tor protocol and Tor protocol websocket >>> extension (OP, inside websockets) --> OK, home made >>> - Webcrypto like features (hash, encrypt, decrypt, rsa, >>> aes, etc), including Tor specific ones >>> (RSA_PKCS1_OAEP_PADDING, aes-128-ctr) --> NOK (or OK with >>> Webcrypto API but when ?) >>> >>> Beside the overall technical difficulty, one of the problems >>> is not to end up with something obsolete (like most of >>> existing js crypto libraries that are not using Typed >>> Arrays) or not to reinvent what will exist tomorrow. >>> >>> And of course, implementing all of this with js will not be >>> efficient, it should better be part of a standard trustable >>> web api. >>> >>> Even if Webcrypto API was already implemented, we see here >>> that a lot of things are still missing for this project. I >>> don't know if it is so specific, probably people will have >>> some equivalent ideas of use with or without websockets. >>> >>> Unfortunately I did not see other webapis projects >>> implementing for example certificates, TLS protocol. >>> Therefore, maybe it should be considered to extend Webcrypto >>> so it does cover the full chain needed for TLS/SSL >>> communications and crypto tools manipulations (unless you >>> are aware that this does or will exist elsewhere as a standard). >>> >>> Regards >>> >>> A. Vitte >>> >>> -- >>> jCore >>> Email : avitte@jcore.fr <mailto:avitte@jcore.fr> >>> 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> >>> >>> >>> >>> >>> >>> >>> -- >>> Mountie Lee >>> >>> PayGate >>> CTO, CISSP >>> Tel : +82 2 2140 2700 >>> 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> >> 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> > 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> > > > > > -- > Mountie Lee > > PayGate > CTO, CISSP > Tel : +82 2 2140 2700 > 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 Web : www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com
Received on Friday, 23 November 2012 08:05:39 UTC