W3C home > Mailing lists > Public > public-webcrypto-comments@w3.org > November 2012

Re: Webcrypto - project example (and issues)

From: Ryan Sleevi <sleevi@google.com>
Date: Fri, 23 Nov 2012 02:41:04 -0800
Message-ID: <CACvaWvYaY1Mq1q+yq_J1SxNKP3As9GFcXu4-2DUBPH4Rs8CYag@mail.gmail.com>
To: Aymeric Vitte <vitteaymeric@gmail.com>
Cc: public-webcrypto-comments@w3.org, Anders Rundgren <anders.rundgren@telia.com>
On Nov 23, 2012 2:07 AM, "Aymeric Vitte" <vitteaymeric@gmail.com> wrote:
>
> Indeed it can look surprising but let's take some examples :
>
> - the browser loads https://www.abcdefg.com , abcdefg.com certificate(s)
are received during the TLS handshake, the browser does check it
> - abcdefg.com takes care of my security and wants to check that there is
no man in the middle for example, then abcdefg.com has a script in the page
to retrieve the certificates that were used for the connection and by some
"method" (ie not defeated by potential mim) compare it with its own (server
certificates).

The man in the middle will just remove that script that checks. If you have
a MIM, game over for web security. Period. End of story. No web security
model recovers here.

> - abcdefg.com wants to check that certificates did not change while
loading things on abcdefg.com

Again, loading any active content directly (as opposed to via XHR, which
you presumably would not be loading active content via due to CSP) = game
over. Its too late at that point. The attacker has won.

And we are not redefining the web security model. Absolutely out of scope.

> - abcdefg.com wants to check things too for others outside TLS
connections made by him (https://www.analytics_ads_tracker.com), for
example that the browser is not trusting someone untrusted verifying again
by itself the certificates

This sentence does not parse.

> - abcdefg.com is hosting some "advanced" services (like www.ianonym.com)
which might need to check certificates too (see trivial Evil1 attack)
>

Defeating SOP? No thanks.

> I don't think it's really new, again some existing add-ons are doing the
same (ie implementing some policy on certificates to secure the
connections), now probably with websockets, webrtc, cors or others, it is
needed to have it built-in inside the browser accessible via js.

Doubtful, at least as far as what existing apps are doing. Just because
others practice dubious security snake oil does not mean it needs to be
supported. If there was an actual proposal for a concrete security policy
that is not met in today's browser system, it may be worth contemplating
(but again, *out of scope* for this spec, though within the realm of
secondary features), but there has yet to be such a proposal that didn't
rely on misunderstandings of the existing web security model.

>
> Le 23/11/2012 09:22, Anders Rundgren a écrit :
>
>> On 2012-11-23 09:07, Aymeric Vitte wrote:
>>>
>>> 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,
>>
>> I don't get this. A service provider cannot (would not at least) check
itself.
>> Are you talking about cross-domain data maybe?
>>
>> Anders
>>
>>
>>   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/hscKxmB6E00or
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
>>>
>
> --
> 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 10:41:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 23 November 2012 10:41:38 GMT