Paris Web : de la sécu et de la qualité


L’été bat son plein. Cigales et soleil (enfin, pour moi). Je me penche sur le programme Paris-Web, la conf du web programmée en Octobre (oui, déjà, je sais, certains disent que je suis très prévoyante), et joie, bonheur, extase : de la sécu, il y en aura à gogo chez Paris Web cette année. Rendez-vous compte, pas moins de 6 interventions relatives au sujet.

– Votre cauchemar ressemble peut-être à une invasion de script malicieux sur vos sites, Nicolas Hoffman vous racontera que CSP est un anti dote pour ce genre de situation embarrassante.

– Vous avez envie de rendre un peu plus robustes vos applications web ? Il existe des outils pour cela. Mathias Dugué partagera son retour d’expérience sur l’usage de ces outils obscurs de sécurité et de la Web Crypto API.

– Une bonne authentification est la garantie d’un service deployé sûrement. L’administration française l’a compris. Francois Petitit partagera son retour d’expérience sur le déploiement de FranceConnect, de OpenID, de l’OAuth2, du bonheur…

– Les bots sur le net générèrent du traffic, et vous embêtent probablement en tant que webmaster, François Hodierne vous expliquera comment gérer ce petit détail, et comment reconnaître les bons des mauvais robots.

La sécurité du web et des internets, c’est un sujet sérieux, que les organismes de standardization discutent, je viendrai vous raconter les avancées faites dans ces consortiums d’industriels au W3C, à l’IETF, et à FIDO.

– La sécurité, c’est aussi une question sous-jacente dans les enjeux de la liberté des usagers du web. Adrienne Charmet, de la Quadrature du Net, viendra plaider pour un engagement des acteurs du numériques en plénière d’ouverture..

On se croise donc à Paris-Web les 1/2/3 Octobre ! #bisous

The security question at Edge

Take 250 web developers, seat in front of them experts, and let them interact. This is EDGE conference. While being my first edge conference experience, I cross finger I will attend the next one. I went there to be part of a panel dedicated to security. And by having that lively and passionate debate, I have learned things, specially, how to move forward on security aspects on the web.

What was it about ? It was about HTTPS and certificate usage. The panelist were Yan (from Yahoo), Mike (from Google), Alex (from University of Michigan, Let’s Encrypt promoter), Patrick (from Financial Times) and all of us being moderated by Dan.

Yan setup the stage by reminding what are the attacks on the web (MITM, XSS, …) that HTTPS and CSP can help to solve. CSP is a way to control that only authorised resources are accessed (authorized means coming from a url you trust). At the same time Yan announced also a renaming of CSP into BATSHIELD to make it attractive, we hope you will enjoy it. Then came the origin question. HTTPS is a way for the browser to make sure that the service your are accessing is the one it pretends to be. And from there, we entered into the debate, here is a take away.

So what is it that we know about HTTPS ?

HTTPS allows point to point authentication and communication confidentiality, between the browser and the server. It helps to prove that Steve’s service is from Steve. HTTPS relies on public and private key management, which means key pairs, generated and certified by a certification authority (CA). In other words, CA will help blessing Steve’s key pair. CAs are recognized by browsers and this recognition relies on reputation. If a CA is reliable (aka known for doing Steve’s identity check properly and making sure to repudiate his certificate if he behaves badly on the internet) then browser will add it in its recommended CA. And all services associates with certificates and key pairs delivered by trustable CAs will be operated under HTTPS. Key pair generation and certificate issuance are a painful process for the web developers. In addition to migrate to HTTPS, they need to pay, few tenth of dollars and find a CA kind enough to have their certificate. In September, Let’s encrypt project is arriving It will make the certificate and key pair distribution automated, free and seamless. Thus it will reduce the barrier to entre the HTTPS world. The way this process will be reliable and automated is still to be discussed, but this initiative could be a serious enablers towards an HTTPS everywhere scenario.

And what is it that we don’t know ?

Does HTTPS really need to be end to end ? Some services may require some arrangement in the middle of the path, between the server serving the request and the browser. The kind of arrangement could be advertising loading, load balancing management, ….). If we were to open some non-HTTPS path in a HTTPS request, to favor the work on the intermediate elements, in charge of those arrangement, this would imply the risk to have middle box for monitoring also enabled. So on one hand there are some business interest to let some path HTTPS free, on the other hand, the breach opened here could favor pervasive monitoring… So one should ask if this is reasonable to only protect the last miles on the communication.

How should users be involved in the security cursor ? Users are warned today when a site is safe, with a green lock. It pushes him into a perception of security that may be over estimated. Some browser vendors would be in favor for waking up the user only if something is at risk. This opens the question to how far security should be visible to the user. It is the responsibility of the browser today to accept CAs and to operate HTTPS normally. Including an educated user could be good, but what if the user is not skilled enough and accept any CA ?

Does HTTPS make the entire web safe ? No. HTTPS is a mean to increase the security communication between a server and a browser. But it does not protect from (1) threat happening on the server side (what is server’s data are corrupted), (2) what is happening on the device side (what if some malicious application can explore and alter broser data), (3) the web developer private key protection (what is the service has his private key being compromised). So a complete answer to securing web business is also about answering those questions. But we dont know yet how to do that and have information about security context of the entire service.

What about restricting sensitive features of the web through HTTPS only connection ? This could become a possible way to increase user privacy and control. But some are claiming that this would force web developers and services to migrate to HTTPS for accessing specific features. Putting a higher technical barrier for deploying services (providing that certificates become free commons). Those last questions staid unanswered. Nevertheless this very good dialog with experienced web developers at #edgeconf allowed to hear pain points and fears from the audience. My take is a beginning of action plan to answer to those questions. Being involved in” problem solving by standard”, I would recommend that we create some fair places to discuss and solve the following questions :

  • HTTPS end to end best practices – including the middle box problem.
  • User involvement in security indication and management – including user experience concern and creating a standard for making the users indication clear
  • Guidelines and supporting tools for web developers to deploy HTTPS and endorse certificate usage (from whatever CA it comes from).

I guess that W3C and IETF may hear in the coming weeks about those suggestions about for keeping our web safe.   Note : extensive notes are available here by Orde Saunders

First Web Crypto implementations : expecting your imagination to play with !

Being chair of a W3C Working Group puts you in a nice situation that you are aware of any brand new implementations of the specifications your working group is supposed to design. In the case of the Web Crypto WG, I must confess I am quite lucky : the group has started one year ago, the first public working drafts were fired 10 months ago, last call is planned for October (planned, I said, no blood signed promise here) and there are already several implementations and prototypes disclosed :

Which specification are we talking about ?

The Web Cryptography API is an API, edited by Ryan from Google. Once implemented natively in browser, it will provide web apps with primitive for cryptographic operations. Generate strong random number, generate a key (or a key pair), manage data ciphering of data signature with it. This is a nice toy to design the security model of your web application. Identified use cases are data synchronization between client and server, signing legal documents, protecting banking transactions, … See the Web Cryptography Use Cases, edited by Arun from Mozilla, for more information. The Working Group is also working on an API to discover keys available in the key store of the browser, but this API, edited by Mark from Netflix, named Web Cryptography Key Discovery does not have yet any implementation available.

What are the available implementations ?

As several companies have interest in that security feature, several implementations or experiments are made available to web developers.

A polyfill designed by BBN. BBN is a research laboratory sponsored by US government. It has issued a polyfill, a pure javascript implementation of the Web Crypto API (based on the version from December 2012). It is compatible with a large number of browsers, including Chrome, Firefox, Safari, Internet Explorer 10, Opera, iCab. You can grab more by visiting the Polycrypt project : and the related github : .

A plugin by Netflix for Chrome. Netflix is working hard those day on delivering a complete solution to protect its streamed content over the combination of the Encrypted Media Extension and Web Crypto API (based on the version from April 2013). The current native plug-in has been designed and successfully tested in Chrome on Linux amd64 – but do not dream, it will not allow you to watch Netflix catalog for free ! All material and explanations are available under Netflix github.

A Microsoft IE 11 Preview feature. Microsoft has included the Web Crypto API in Internet Explorer 11 Preview (build date: 6/14/2013). This pre-release version is available to web developers.

A Chromium announced feature. Google has announced that the Web Crypto API would be available in Chromium. If you want to witness the on-going work, you can have a look at the chromium issue tracker.

A Firefox open feature**. Mozilla is working since this spring on the implementation of the Web Crypto API and progresses can be monitored under Bugzilla @ Mozilla tracker.

A teasing implementation from Inventive Designers.

One in another what can you do, now. And what are the limits ?

You can play with those prototypes, which are here to fill the gap, while browser makers embed the final feature in their final products. Note that none of the available plug-in, polyfill, pre-release do rely on Promises, which is the new taste of DOM, while the final version as lots of chance to  : the most recent draft already embeds it, and it is expecting review of the javascript and W3C Technical Architecture Group community. In addition the referenced plug-in, polyfill, pre-release features are relying on old version of the specification which is submitted to changes, as the Working Group is still managing some open issues. Nevertheless by having some tools today, it gives you a chance to play with crypto primitives on different platforms.

Which one to choose ? If your project is just about creating a key and using it for the basic operations such as generate key, sign, encrypt and corresponding operations, then the BBN polyfill will perfectly match. If you want to experience more with key wrapping (in order to protect your keys when being stored in your client), then, the Netflix and Microsoft tools will make the job.

Each of the implementations made some choices in algorithms supported, but in most of the cases, if your project does not require exotic algorithm, you will find what you need inside.

If you are having fun with it, who should you report it to ?

As you may imagine all W3C crypto community and implementers are expecting your report on your experiment. Feel free to tell us more on or by reporting directly to the implementation providers…

You can also read a more recent post related to Web Crypto API development here :

** Thanks @clochix for the info.