IETF Starts Work On Next-Generation HTTP Standards 82
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."
Re:yay? (Score:5, Informative)
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: (Score:3)
Why should HTTP be the only protocol that DNSSEC can flag? Why not any/all protocols that have been or will be created? Now we're talking about DNSSEC servers having to track a potentially infinite amount of protocols. That won't work.
While HTTP is a popular protocol, it should not get special treatment. The Internet should be protocol agnostic.
Re: (Score:2)
You're right, I mean, imagine if you had to create special DNS entries for different services, like MX records for email, or SRV records for XMPP (and SIP and a few others)!!
Re: (Score:1)
Re: (Score:2)
So, wouldn't a man-in-the-middle be able to intercept HSTS and turn it into plain HTTP?
Re: (Score:1)
Only if the browser has never seen the site before. If the browser has seen the site before and remembers it used HSTS last time, then it will expect HSTS+HTTPS to be used this time too and won't accept anything less.
Re: (Score:2)
Yes, a great mechanism, inform the user over a non-secure channel that he should use a secure channel from now on!
I'm sure there's no way to crack this HSTS, I mean, it's not like anyone would intercept the first communication; that's just unpolite, even for crackers!
Re: (Score:2)
Re: (Score:2)
The first time you access the website from that particular device, with that browser.
I accessed ALL my bank accounts last week from my work PC, and my new bank account last week from my home PC. (I don't use any webmail).
Securing N-1 is a lousy solution: an IETF standard should aim to secure 100%, not N-1.
HTTP 2 (Score:2)
It's official: We're working on HTTP/2.0,
Eh hem, people have been working on "HTTP 2.0" since HTTP/1.1 came out. Just ask Roy Fielding and others.
What's with the summary? (Score:2)
The summary seems a bit confused, like they've misinterpreted the proposed standardisation of HSTS and the beginning of work on HTTP 2.0 as the same thing.
Re: (Score:3)
Right? I had to read it a few times to make sense of it. I'm still not quite clear on what HSTS has to do with HTTP/2.0...
HTTPS Everywhere plugin (Score:5, Informative)
Re: (Score:3)
Because the current solution of a problem is not necessarily the best and it may be possible to improve it.
Re: (Score:1)
"secure" connection (Score:2, Insightful)
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. Legal will put the kabosh on the use of any tech that prevents them from papering over their asses by saying they did everything possible to prevent transmission of confidential/proprietary data. Note: Everything in a corporation i
Re:"secure" connection (Score:5, Informative)
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 (Score:4, Informative)
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.
Re: (Score:1)
I guess you aren't familiar with *cough* proxy servers *cough* which work just fine with SSL being very secure from the organization outward, but able to keep convenient logs of all traffic flowing in and out.
Combine with blocking outbound to 443 from all computers except the proxy. For the truly paranoid, a deep-packet-inspection firewall can be trivially configured to drop all SSL packets.
Problem (mostly) solved, for the sufficiently ethically compromised organization. Private smart phones represent a sig
Re: (Score:2)
It's illegal for companies to spy on their employees in such a manner in most sane countries anyway, so I don't see any issues with this.
Re: (Score:1)
Mod +1 Funny
Can we please get an EXECUTE verb? (Score:2)
Re: (Score:3)
How about "DO" instead? Much shorter.
Anyway, browsers have GET and POST, but does anybody know one that has PUT and DELETE? These should be relatively simple to implement, but the last time I looked, none had any, meaning that if you wanted to use REST APIs from your browser (as opposed from server-to-server), you'd have to do awkward things like
GET "/account/12345/delete"
instead of
DELETE "/account/12345"
Which is a problem because GET is supposed to be "idempotent" (not supposed to have any side effects no
Re: (Score:2)
Re: (Score:2)
What I would like to see is support directly in the FORM element:
<form method="DELETE" action="blah.php" >
See also
http://amundsen.com/examples/put-delete-forms/ [amundsen.com]
http://stackoverflow.com/questions/5177595/why-dont-the-modern-browsers-support-put-and-delete-form-methods [stackoverflow.com]
Re: (Score:2)
(1) you could just use POST and deny GET requests for URLs with side effects. You just end up encoding the "delete key" into the form's target URL instead of using a field, but for most applications that's fine. (2) "Idempotent" means that running once is identical to running many times. Deleting an account is usually idempotent so it's valid (albeit crazy/stupid) fo
Re: (Score:3)
Wrong. GET is supposed to be "nullipotent" [wikipedia.org]. You're correct about GET not supposed to have any side effects.
PUT and DELETE are idempotent [wikipedia.org] - "multiple identical requests should have the same effect as a single request"
The reason browsers don't have them is because of the HTML/XHTML spec - "HTML forms (up to HTML version 4 and XHTML 1) only support GET and POST as HTTP request methods."[1] So if they implemented it, most likely would be done differently by each browser, and more so in IE as usual.
1: http://sta [stackoverflow.com]
Re: (Score:2)
(They are of course present in XMLHttpRequest.)
Re: (Score:2)
Highly interesting, never knew about nullipotent.
>The reason browsers don't have them is because of the HTML/XHTML spec
Well, OK. But XHTML was from about 2000 or so. Now we're at HTML5 and still don't have browser-supported DELETE and PUT? What I mean to say is, if it's not in the spec, they should PUT it there, already.
Re: (Score:2)
My thought: a browser is for viewing content, not performing raw operations. You probably don't want people to be able to delete content nodes on your server just by issuing a DELETE request, you'd want to POST a request to server-side code to perform the operation on the user's behalf so it can do proper filtering (eg. not permitting deletion of "/"). A browser isn't the only client around, and some things are just not things you really want to be doing in a browser. There's too little validation of what's
Re: (Score:2)
You probably don't want people to be able to delete content nodes on your server just by issuing a DELETE request
It's not a problem in reality; just because someone asks to delete something doesn't mean you have to say "yes".
Re: (Score:2)
Regarding security: You, of course, always have a security setup, anyways.
E.g., you can only DELETE items that you created.
>You probably don't want people to be able to delete content nodes on your server just by issuing a DELETE request, you'd want to POST a request to server-side code
Well, it's always going to be handled by server-side code, no matter if it's a simple GET. In fact the server doesn't even have to respond to a GET if you don't have the right security clearance.
Say you have a project mana
Re: (Score:2)
Most browsers support DELETE and PUT through AJAX.
Re: (Score:2)
When implementing RESTful APIs, I've found this Firefox plugin to be quite useful. It allows you to use DELETE and PUT requests (amongst others) from your browser.
https://addons.mozilla.org/en-US/firefox/addon/restclient [mozilla.org]
Re: (Score:2)
The "browser" doesn't "have" GET and POST. Those are used in the HTML forms. You can use PUT and DELETE just fine - but nobody does.
Re: (Score:2)
No, they are "in" the browser. First of all, only GET and POST are supported as values in action for HTML4 [w3.org].
Secondly, the difference between GET, POST, PUT, etc. is not that the browser requests a URL, and merely passes along the "action" parameter, no matter what it is "get", "put", "mickymouse", "goofy".
Rather, what happens is that the browser makes an entirely different type of HTTP request depending on the action param.
GET /path/to/file/index.html HTTP/1.0
POST /path/script.cgi HTTP/1.0
(and then the data)
Re: (Score:2)
Can't you POST an executionRequest?
Re: (Score:2)
Because that isn't even remotely secure. Google 'sslstrip' -- it's not just theoretically possible to defeat such a system, it's been done and is actually quite trivial
Your PHB boss (Score:1)
Will this work in IE 6?
If IE 6 doesn't support it then I am not interested. We do not want to turn down .01% of our visitors as that would cost hundreds!! Now get your ass back to work spemnding thousands to support these hundred of dollars worth of users.
TLS (Score:2)
Isn't that what TLS is for?
Other standards? (Score:1)
CA (Score:3, Interesting)
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 ? ;)
Mod parent up. (Score:3)
I would like to see Multiple CAs; I don't know this is possible now because I only ever saw 1 cert configs on my old server.
I'm less concerned with CA breaches than I am with con-men who often easily can buy CA certs. I think the local government should be a CA for every business that incorporates with them (have you seen the paper certificates they give? you could make them yourself, and the business ID numbers are not secure either...) It was harder to incorporate without showing a ton of legit identifi
Re: (Score:2)
You're getting redundant. How can you secure and verify HSTS origin (to transfer info about allowed CA), if you don't know with whom you established HSTS (there is no authority that has signed it).
Current CA scheme works as it is, because CA information is included in browser, and in order to replace that, there has to be other means to transfer authority information (DNSSEC could theoretically be usable)
Re: (Score:1)
Maybe you should read the article. SPDY will be used as a base for HTTP2.0.