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.

Security panel at #edgeconfpic.twitter.com/oFeALlZJDg

— Christian Heilmann (@codepo8) June 27, 2015

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 https://letsencrypt.org/. 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 https://decadecity.net/blog/2015/06/27/edge-conf-security by Orde Saunders