IETF Starts Work On Next-Generation HTTP Standards

alphadogg writes "With an eye towards updating the Web to better accommodate complex and bandwidth-hungry applications, the Internet Engineering Task Force has started work on the next generation of HTTP, the underlying protocol for the Web. The HTTP Strict Transport Security (HSTS), is a security protocol designed to protect Internet users from hijacking. The HSTS is an opt-in security enhancement whereby web sites signal browsers to always communicate with it over a secure connection. If the user is using a browser that complies with HSTS policy, the browser will automatically switch to a secure version of the site, using 'https' without any intervention of the user. 'It's official: We're working on HTTP/2.0,' wrote IETF Hypertext Transfer Protocol working group chair Mark Nottingham, in a Twitter message late Tuesday."

Comments

HTTPS Everywhere plugin

[Bananatree3]

The EFF has plugins for Chrome and Firefox to force HTTPS on as many sites as it can. Will be nice to have it formally in HTTP 2.0, but that feature is available for many sites with the plugin it seems.

Re:yay?

[Agent ME]

Those only work while the user is on a non-man-in-the-middled connection. With HSTS, the user access the site once over a non-MITM connection, and then his browser remembers to always connect over HTTPS. Then later, the user attempts to access the site over a connection where a man-in-the-middle is running SSLstrip to try to force the user to connect unsecurely, but the user's browsers remembers to never accept unsecured connections to the site.

Re:"secure" connection

[Anonymous Coward]

You can already install a local certificate and proxy HTTPS traffic and there are commercial solutions allowing such for corporate monitoring. It also ''adds security'' by removing the desktop or mobile devices need for certificate authentication and management by moving it the proxy. In short, monitoring HTTPS traffic is routine in the enterprise and has been standard practice for many years.

Re:"secure" connection

[DragonWriter]

There's going to be push-back from corporations on this one unless they break it so it's insecure. Truly secure browser-to-server communication resistant to man in the middle attacks would mean IT can't record and document what information is being sent from employees' computers.

Untrue. MITM-proof communication doesn't protect you from someone who has control over either endpoint, so it doesn't prevent monitoring of corporate computers.

CA

[fa2k]

Please, can HSTS also get an option to limit the acceptable certificates for a domain?
We have this:
- There have been multiple breaches of CAs already.
- Any CA can sign a certificate for any domain name

How about these options:
- parent: accept any certificate which is signed by a certificate given in the "HSTS" header and stored on the user system. Option to require a direct descendent.
- direct: specify just one allowable certificate.
- You can specify multiple alternative certificates in the "HSTS" headers.
If the parent or direct certificate expired and the browser didn't know about an alternative, it would fall back to accepting any valid certificate. Thus, people who forgot to update their "HSTS" headers wouldn't be SOL. There could be another flag to reject servers which didn't have any HSTS headers, even after all known certs expired.

Big companies could have an internal CA and require that as their parent. They would thus be completely immune to CA breaches. Small-time users could use the direct mode, and thus also be immune to all CA breaches. One could also set the CA root (e.g. VeriSign) as the parent, in which case they would be immune to all breaches except for the CA they chose, and it woudn't require intervention unless they change CA. My proposal should also work for self-signed certs, with the normal caveats.

Now where do I post my suggestion ? ;)