cherokee at googlecode
Nov 13, 2011, 5:20 PM
Post #1 of 4
(202 views)
Permalink
|
|
Issue 1302 in cherokee: HSTS in wrongly implemented
|
|
Status: Accepted
Owner: ----
Labels: Type-Defect Priority-Medium Component-Logic Security
New issue 1302 by ste...@konink.de: HSTS in wrongly implemented
http://code.google.com/p/cherokee/issues/detail?id=1302
What steps will reproduce the problem?
1.
http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security#Implementation
2. look at handler_error.c
3. Notice that we are actually sending it when we find the URL not being
TLS.
4. http://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec-03
5. I think when a user enables HSTS what should happen:
a) There is a virtual rule inserted that checks TLS, if it is not TLS the
user gets an external redirect to the TLS resource.
b) HSTS is send as a second virtual rule non-final with add-headers, strict
transport security
Based on:
6.2. HTTP Request Type
If a HSTS Host receives a HTTP request message over a non-secure
transport, it SHOULD send a HTTP response message containing a
Status-Code of 301 and a Location header field value containing
either the HTTP request's original Effective Request URI (see
Section 12 "Constructing an Effective Request URI", below) altered as
necessary to have a URI scheme of "https", or a URI generated
according to local policy (which SHOULD employ a URI scheme of
"https").
6.1. HTTP-over-Secure-Transport Request Type
When replying to an HTTP request that was conveyed over a secure
transport, a HSTS Host SHOULD include in its response message a
Strict-Transport-Security HTTP Response Header that MUST satisfy the
grammar specified above in Section 5.1 "Strict-Transport-Security
HTTP Response Header Field". If a Strict-Transport-Security HTTP
Response Header is included, the HSTS Host MUST include only one such
header.
_______________________________________________
Cherokee-dev mailing list
Cherokee-dev [at] lists
http://lists.octality.com/listinfo/cherokee-dev
|
