Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

IETF Starts Work On Next-Generation HTTP Standards

samzenpus posted about 2 years ago | from the new-way-of-doing-things dept.

The Internet 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."

cancel ×

82 comments

Sorry! There are no comments related to the filter you selected.

yay? (0)

Anonymous Coward | about 2 years ago | (#41545249)

Maybe I'm stupid, but we already do this with rewrites and/or irules pretty much everywhere.

Re:yay? (5, Informative)

Agent ME (1411269) | about 2 years ago | (#41545335)

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:yay? (0)

Anonymous Coward | about 2 years ago | (#41546643)

Seems it'd be better to signal the HTTPS through DNS secured by DNSSEC, then the MITM wouldn't be able to remove the flag without breaking the DNSSEC - therefore even if the first connection is in the presence of a MITM the access would be either secured with HTTPS or flagged up with an invalid DNSSEC or SSL certificate.

Re:yay? (2)

Bengie (1121981) | about 2 years ago | (#41547785)

One side of me says "that sounds cool", but the other side says "what about other protocols?"

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:yay? (1)

hobarrera (2008506) | about 2 years ago | (#41548817)

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:yay? (1)

ppc_digger (961188) | about 2 years ago | (#41568319)

That's exactly what SRV records are for. They first made MX records for email. Then they realized that other services need special records too, and added the service-independent SRV record.

Re:yay? (1)

mwvdlee (775178) | about 2 years ago | (#41546727)

So, wouldn't a man-in-the-middle be able to intercept HSTS and turn it into plain HTTP?

Re:yay? (1)

Agent ME (1411269) | about 2 years ago | (#41546735)

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:yay? (1)

hobarrera (2008506) | about 2 years ago | (#41548809)

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:yay? (1)

morgauxo (974071) | about 2 years ago | (#41548989)

Yes, if you are already compromised the FIRST time you access the site it doesn't help. So? When was the first time you accessed your bank site, Your web mail? Do you even remember? How often have you accessed them since? Securing every subsequent access is certainly an improvement over never securing them at all!

Re:yay? (1)

hobarrera (2008506) | about 2 years ago | (#41549431)

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 (1)

suso (153703) | about 2 years ago | (#41545443)

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.

Re:HTTP 2 FOR COONS (-1)

Anonymous Coward | about 2 years ago | (#41545749)

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.

are you saying that because you have a problem with NIGGERS ?!?!!?!1111???!111?!?!

All well and good, but... (0)

Anonymous Coward | about 2 years ago | (#41545253)

How long will it be before it's adopted? HTTP/2.0 is pretty badly needed already. If they're going to get the standard out by 2014...

What's with the summary? (1)

jibjibjib (889679) | about 2 years ago | (#41545289)

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:What's with the summary? (2)

Atzanteol (99067) | about 2 years ago | (#41545437)

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 (4, Informative)

Bananatree3 (872975) | about 2 years ago | (#41545291)

The EFF has plugins [eff.org] 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:HTTPS Everywhere plugin (0)

Anonymous Coward | about 2 years ago | (#41546027)

It should be noted that the EFF HTTPS Everywhere plugin works using a hard-coded list of websites, but also supports the HSTS standard mentioned in the summary for websites that are not in its hard-coded list.

RedirectMatch /(.*) https://hostname/$1 (0, Interesting)

Anonymous Coward | about 2 years ago | (#41545323)

Really REALLY hard.

I joke. But seriously, why add more code to a solved problem?

Also, slashdot, you track my karma down to terrible, so I can only post twice a day ... so then I just logout and post to my hearts content and its harder for others to block me, thats pretty dumb don't you think? Seems like you'd be better off letting me post logged in so people could know they don't want to read my posts in advance.

--BitZtream

Re:RedirectMatch /(.*) https://hostname/$1 (2)

master5o1 (1068594) | about 2 years ago | (#41545409)

Because the current solution of a problem is not necessarily the best and it may be possible to improve it.

Re:RedirectMatch /(.*) https://hostname/$1 (0)

Anonymous Coward | about 2 years ago | (#41546183)

slashdot, you track my karma down to terrible, so I can only post twice a day ... so then I just logout and post to my hearts content and its harder for others to block me, thats pretty dumb don't you think? Seems like you'd be better off letting me post logged in so people could know they don't want to read my posts in advance.

--BitZtream

This is just a way of letting you know that people are not interested in reading what you have to say, but you seem not to be getting the message.

Posting as AC to prevent your bad fortune ;)

Re:RedirectMatch /(.*) https://hostname/$1 (0)

Anonymous Coward | about 2 years ago | (#41546345)

Seriously. You look at his posts even after he's been karma'd to oblivion and he's still a douchbag at heart.

Re:RedirectMatch /(.*) https://hostname/$1 (0)

Anonymous Coward | about 2 years ago | (#41546333)

I guess your karma is bad because you post smug comments based on your narrow, incorrect interpretation of the summary,

Re:RedirectMatch /(.*) https://hostname/$1 (0)

Anonymous Coward | about 2 years ago | (#41552905)

Terrible karma?

Awww, is the poor little arrogant opinionated loser upset that he's gotten exactly what he paid for with his dozens of ignorant and abusive posts?

Yup, karma's a bitch.

oh (0)

subao (2741525) | about 2 years ago | (#41545351)

Passing

Re:oh (0)

unixisc (2429386) | about 2 years ago | (#41546225)

Leave that, and let them first address all concerns that people have about IPv6. Too many protocols out there. Leave well enough alone!

"secure" connection (2, Insightful)

girlintraining (1395911) | about 2 years ago | (#41545355)

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 is considered confidential and proprietary, including "Hello, world."

Whatever they're planning will involve some manner of broken certificate issuing authorities, or some backdoor way so that an interested party can "legitimately" spy on the over the wire traffic. You can count on it: A truly secure communications medium is the one thing nobody with money wants to have in existance. It threatens so many (admitedly broken) business models... in fact there's an entire tech ecosystem built around the inherent insecurities of modern information infrastructure. They don't want it fixed: Broken = money. Fixed = broke.

Re:"secure" connection (5, Informative)

Anonymous Coward | about 2 years ago | (#41545397)

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 (0)

Anonymous Coward | about 2 years ago | (#41545417)

A good number of IT places use Bluecoat or another CA which does an automated MITM, with its root cert part of the Active Directory tree. Use a Web browser that doesn't have that cert, and you will get warnings all day long.

It sucks, but better having to deal with that than have no Web access whatsoever at the job.

Re:"secure" connection (0)

Anonymous Coward | about 2 years ago | (#41547383)

Bluecoat proxies also stick their own cookies into browser cookie jars and overwrite others, which proxy servers are forbidden to do. Standards? Fuck 'em!

Re:"secure" connection (3, Informative)

DragonWriter (970822) | about 2 years ago | (#41545767)

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.

Re: False Post (0)

Anonymous Coward | about 2 years ago | (#41545781)

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.

You really haven't put any thought into this.

Even if automated legitimate MITM of SSL connections WEREN'T already commonplace in corporations... and they are ... do 10 seconds of homework next time please ... they control the computer AND the network. You could log the data as the user is viewing it. That could be simple as a screen scraper or a modified browser or it could be something more exotic. There are always ways to do things and there is certainly a market for this at the enterprise level. If you really can't be bothered to Google a topic because ya gotta get that post fast as you can at least take a moment to consider other ways to do the same thing.

Mods, I know she tried and everything but FACTUALLY FALSE INFORMATION does not deserve a +5. Please correct this.

Re:"secure" connection (0)

mcrbids (148650) | about 2 years ago | (#41545879)

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 significant attack vector, forcing exotic techniques like a Faraday Cage [wikipedia.org] , perhaps with special paint? [southgatearc.org]

Re:"secure" connection (0)

Anonymous Coward | about 2 years ago | (#41547003)

I guess you know shit about how SSL connections over a proxy work. Here is a hint: The data is NOT sent unencrypted to the proxy. The proxy will just open a data channel it leaves untouched.

So better shut the fuck up before complaining about others who probably have more insight than you.

Re:"secure" connection (0)

Anonymous Coward | about 2 years ago | (#41547305)

I guess you know shit about how SSL connections over a proxy work. Here is a hint: The data is NOT sent unencrypted to the proxy. The proxy will just open a data channel it leaves untouched.

So better shut the fuck up before complaining about others who probably have more insight than you.

The OP stated we're talking about corporate shit here. Which means they control the endpoint. Do whatever you want with SSL, HTTP/HTTPS, etc. it isn't going to stop their monitoring software from screen capturing what you're up to. The parent's point is completely invalid, corporations already have multiple solutions which they already use so her claim that "There's going to be push-back from corporations on this one unless they break it so it's insecure" is already shot full of holes.

So better shut the fuck up before bitching about others who have already demonstrated they have more insight than you.

Re:"secure" connection (1)

hobarrera (2008506) | about 2 years ago | (#41548839)

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:"secure" connection (0)

Anonymous Coward | about 2 years ago | (#41553711)

What sane country is it where the owner of a computer is not allowed to monitor what the computer is used for, and where the owner of a network is not allowed to monitor the traffic passing over the network? Your definition of "sane" differs from mine.

PS, I'm going to put a virus on your computer; it should be illegal for you to spy on what it's doing (you clicked "I agree" when you went to that malicious web site, after all). Also, I'm going to steal your wireless access (you're broadcasting on a public frequency!), and it's illegal to "spy" on what I'm doing with that. I expect some privacy, darn it!

Summary blows horse cock (0)

Anonymous Coward | about 2 years ago | (#41545365)

Summary is horrible. Goes from HTTP 2.0 to HSTS back to HTTP 2.0 without really explaining the link between the two.

Re:Summary blows horse cock (0)

Anonymous Coward | about 2 years ago | (#41546281)

Here's the horse cock

"The HTTP Strict Transport Security (HSTS), is a security protocol designed to protect Internet users from hijacking"

You see that first H in HSTS? that stands for HTTP. So HTTP2 is incorporated into this new standard.

Simple really

This is not secure (-1)

Anonymous Coward | about 2 years ago | (#41545395)

This is not secure as long as anyone can sign their own certificates or become a certificate authority. Anyone can sign a certificate and make it look official without the end user knowing any better. Furthermore, companies like Verisign have been hacked often, likely allowing rogue certificates to be issued with the appearance they were signed legitimately. If this is going to be secure, only trusted companies like Microsoft should be permitted to sign certificates, so that sites using these secure protocols can really be trusted.

Re:This is not secure (0)

Anonymous Coward | about 2 years ago | (#41545823)

This is not secure as long as anyone can sign their own certificates or become a certificate authority. Anyone can sign a certificate and make it look official without the end user knowing any better. Furthermore, companies like Verisign have been hacked often, likely allowing rogue certificates to be issued with the appearance they were signed legitimately. If this is going to be secure, only trusted companies like Microsoft should be permitted to sign certificates, so that sites using these secure protocols can really be trusted.

AH ahhahahahahaha that was pretty good. You made an effort to sound reasonable for a while there. You had me going right up until I read "Microsoft".

This was a harmless humorous troll. Well done! Sadly they don't appreciate such things here. They get butthurt and mod you down.

Re:This is not secure (1)

atisss (1661313) | about 2 years ago | (#41552891)

Mod +1 Funny

Why? (-1)

Anonymous Coward | about 2 years ago | (#41545487)

subject says it all

No kidding... mod the A/C back up. (0)

Anonymous Coward | about 2 years ago | (#41549623)

We don't need another new set of HTTP standards.

What we need is for someone to finish implementing the standard we already have today.

Everything out there today, is a half-assed unfinished work.

Can we please get an EXECUTE verb? (2)

elabs (2539572) | about 2 years ago | (#41545683)

Not everything in this wide world can be represented as static state. There are lots of dynamic, parallel, and long-running actions happening all around us. It sure would be nice to trigger a processing operation with an EXECUTE verb because PUT and POST just don't make sense in that context.

Re:Can we please get an EXECUTE verb? (2)

Compaqt (1758360) | about 2 years ago | (#41545709)

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 matter how many times you run it).

Re:Can we please get an EXECUTE verb? (1)

zbobet2012 (1025836) | about 2 years ago | (#41545809)

If its not your taking away a whole class of web scalability (caches like varnish/squid). But yet people abuse the shit of GET instead of POST.

Re:Can we please get an EXECUTE verb? (1)

Compaqt (1758360) | about 2 years ago | (#41545865)

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:Can we please get an EXECUTE verb? (1)

smellotron (1039250) | about 2 years ago | (#41546067)

Which is a problem because GET is supposed to be "idempotent" (not supposed to have any side effects no matter how many times you run it).

(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) for GET. Now, HEAD OTOH... I have heard of some server-side scripting systems which execute HEAD by performing a GET and then discarding the output. That would be nasty for /delete/this/account.htm.

Re:Can we please get an EXECUTE verb? (2)

aneroid (856995) | about 2 years ago | (#41546103)

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://stackoverflow.com/a/166501/1431750 [stackoverflow.com]

Re:Can we please get an EXECUTE verb? (1)

aneroid (856995) | about 2 years ago | (#41546123)

(They are of course present in XMLHttpRequest.)

Re:Can we please get an EXECUTE verb? (1)

Compaqt (1758360) | about 2 years ago | (#41549153)

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:Can we please get an EXECUTE verb? (1)

Todd Knarr (15451) | about 2 years ago | (#41546537)

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 going on, and letting ordinary users juggle running chainsaws rarely ends well.

Re:Can we please get an EXECUTE verb? (1)

dkf (304284) | about 2 years ago | (#41546693)

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:Can we please get an EXECUTE verb? (1)

Compaqt (1758360) | about 2 years ago | (#41549217)

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 management web app. You create new projects; you can also delete them. You create new tasks; you can also DELETE them. Currently, web frameworks implement workarounds for the lack of DELETE, but HTML5 is supposed to be about fixing all of that.

E.g., people used all sorts of hacks to do rounded corners; now HTML5 has them native. Finally, DELETE would just be a standard way for sending a delete message. Details are up to your app (same as for GET and POST).

Re:Can we please get an EXECUTE verb? (1)

hobarrera (2008506) | about 2 years ago | (#41548851)

Most browsers support DELETE and PUT through AJAX.

Re:Can we please get an EXECUTE verb? (1)

ianare (1132971) | about 2 years ago | (#41548853)

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:Can we please get an EXECUTE verb? (1)

Atzanteol (99067) | about 2 years ago | (#41550125)

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:Can we please get an EXECUTE verb? (1)

Compaqt (1758360) | about 2 years ago | (#41550707)

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)

and PUT and DELETE.

The browser must support the methods. It will not pass along just whatever.

Re:Can we please get an EXECUTE verb? (0)

Anonymous Coward | about 2 years ago | (#41546691)

Sorry but why isn't POST relevant? You're posting a request to do something, which is validated by the server and may execute stuff.

GET is meant to be fetching (possibly static) read-only data
POST is meant to be submitting something to the server that could change its state, ie read-write. Executing something falls under that just fine.

Re:Can we please get an EXECUTE verb? (0)

Anonymous Coward | about 2 years ago | (#41548079)

Can we also get site aliasing inside of a web page. That way the browser can cache better?

Basically some way of saying 'you may get this picture from 50 machines but it is the same picture'. We can also reference the alias in the page (making it smaller).

Something like a cache-on-alias command?

Re:Can we please get an EXECUTE verb? (1)

hobarrera (2008506) | about 2 years ago | (#41548883)

Can't you POST an executionRequest?

301 Redirect (0)

Anonymous Coward | about 2 years ago | (#41545935)

Why do we need a new protocol?
What's so hard for a webserver to check if a connection is over HTTP then redirect the user to the HTTPS version ?

the IETF are starting to sound like a govenment

and surely the first worm to hit the internet after this is implemented is going to turn that flag on for every small website that doesn't support HTTPS thereby making the website look like its down ?

Re:301 Redirect (0)

Anonymous Coward | about 2 years ago | (#41546721)

What's so hard for a webserver to check if a connection is over HTTP then redirect the user to the HTTPS version?

Because the client needs to make sure it's using HTTPS as well. With HTTP currently, how should the client know that it's really supposed to be connecting with HTTPS, bearing in mind that the attacker can hijack HTTP connections and remove redirects, proxy between the client and server, etc?

Re:301 Redirect (1)

Urza9814 (883915) | about 2 years ago | (#41548479)

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 (1)

Billly Gates (198444) | about 2 years ago | (#41545959)

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.

HTTP 2.0 (0)

Anonymous Coward | about 2 years ago | (#41546095)

Face it, SFTP would be a better candidate, and already exists.

HTTP 2.0? (0)

Anonymous Coward | about 2 years ago | (#41546111)

By the time it's ready, we'll be on web 8.0.

TLS (1)

loufoque (1400831) | about 2 years ago | (#41546125)

Isn't that what TLS is for?

YOU FAIL It... (-1)

Anonymous Coward | about 2 years ago | (#41546189)

Wel0l-known [goat.cx]

Other standards? (1)

FithisUX (855293) | about 2 years ago | (#41546581)

Any for hardware standards? For example a GFX hardware interface? Any hope for an open GiGE like standard for cameras?

Does that make... (0)

Anonymous Coward | about 2 years ago | (#41546713)

Does that make the IETF the HTTP Strict Transport Security... Administration? They protect Internet users from "hijacking"? It all fits! They're evil, I say!

CA (3, Interesting)

fa2k (881632) | about 2 years ago | (#41546801)

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. (2)

bussdriver (620565) | about 2 years ago | (#41549077)

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 identification than it was to get a cert from a cheap CA...

Re:CA (2)

atisss (1661313) | about 2 years ago | (#41553051)

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)

Google already have this - SPDY (0)

Anonymous Coward | about 2 years ago | (#41546907)

Google already have the next HTTP - and it may well be better!

http://en.wikipedia.org/wiki/SPDY [wikipedia.org]

Re:Google already have this - SPDY (1)

Anonymous Coward | about 2 years ago | (#41547345)

Maybe you should read the article. SPDY will be used as a base for HTTP2.0.

soapa built into your browser (0)

xmorg (718633) | about 2 years ago | (#41547581)

you are now safe.

Video from HOPE9 about HSTS. (0)

Anonymous Coward | about 2 years ago | (#41550193)

At HOPE (Hackers On Planet Earth) # 9 this year, Adam Langley (from Google) gave a very interesting talk about HSTS/HTTPS called "The state of HTTPS". If you're not quite understanding what HSTS is, check out his video at:

http://www.youtube.com/watch?v=LBbCec4Bp10

It covers a lot of comments/questions that have been posted about this topic. It's a very good/interesting talk.

Summary mixes-up HSTS and HTTP/2 ? (0)

Anonymous Coward | about 2 years ago | (#41551883)

HSTS and HTTP/2 are separate things.

HTTP/2 is starting out from SPDY's draft-2 where all the current implementations use SSL, true, but there is no link at all to HSTS.

Meta redirect? (0)

Anonymous Coward | about 2 years ago | (#41553747)

I'm glad someone has finally implemented a new protocol to perform the same action that a permanent redirect does. It's so hard to remember what "301" means.

GOD AS MY WITNESS, WHAT IF?? (0)

Anonymous Coward | about 2 years ago | (#41557863)

What if IETF would convene one day and say, "well, it's been a pretty good year -- you know, so many of these protocol recommendations have turned out to be major fiascoes or corporate migration nightmares or browser incompatibility quagmires or loopholes into new penis pump pusher cross site scripting attacks... so many, oh dear..."

"So... we recommend that everyone leave things in the HTTP protocol just as they are."

"So we can all concentrate on improving our lives in other ways. Have a great year!"

[gasp of relief]
[thunderous applause, with tears and laughter]

Except for anything Microsoft wants. That must go through. Windows 10 is just around the corner!

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>