Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
The Internet Security Technology

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."
This discussion has been archived. No new comments can be posted.

IETF Starts Work On Next-Generation HTTP Standards

Comments Filter:
  • by Anonymous Coward on Wednesday October 03, 2012 @10:27PM (#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

  • CA (Score:3, Interesting)

    by fa2k ( 881632 ) <pmbjornstad@gm[ ].com ['ail' in gap]> on Thursday October 04, 2012 @05:36AM (#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 ? ;)

One possible reason that things aren't going according to plan is that there never was a plan in the first place.

Working...