- From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
- Date: Mon, 21 Mar 2016 04:34:31 +0000
- To: Mark Nottingham <mnot@mnot.net>, HTTP working group mailing list <ietf-http-wg@w3.org>
- Cc: Kari Hurtta <hurtta-ietf@elmme-mailer.org>, HTTP working group mailing list <ietf-http-wg@w3.org>, Mike Bishop <Michael.Bishop@microsoft.com>
Summary of my previous answers (was not posted to list).
> Hi Kari,
>
>> On 18 Mar 2016, at 5:35 AM, Kari Hurtta <hurtta-ietf@elmme-mailer.org> wrote:
>>
>>
>> https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-04
>> Opportunistic Security for HTTP
>>
>>
>> 1)
>>
>> https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-04#section-3
>> 3. Server Authentication
>>
>>
>> Origin "http://www.example.com" is mentioned on text,
>> Origin "http://www.example.com" is NOT mentioned on /.well-known/http-opportunistic.
>
> Thanks, fixed in -latest.
>
OK.
>> 2)
>>
>> https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-04#section-8
>> 8. Security Considerations
>>
>> For "Attacks from the same host" this makes silent assumption that
>> /.well-known/http-opportunistic indicates that there is not injected
>> bad Alt-Svc: -headers.
>>
>> In other words Alt-Svc: -headers are assumed to be filtered
>> out from attackers (shared hosting), but that assumption is not
>> spelled out on draft.
>
> Yes. Any suggested text here (Kari or someone else)?
>
Not really, but I try anyway
---------------------
CGI [RFC 3875], PHP, and other environments allows page
authors to insert custom headers to HTTP -response. Page
authors may also able listen local ports via these
environments directly or they can execute programs.
These allows attacker to inject Alt-Svc: which specify
local port on control of attacker on same host.
Without precautions this allows attacker masquerade as the
HTTP server.
Presence of /.well-known/http-opportunistic tells
that server is aware of that protocol and have take
precautions so that attacker can not masquerade as the
HTTP server.
Clients can reduce this risk by limiting ports which
them accept as alternative service on same host (without
valid certificate).
Server can reduce this risk by restricting the ability to
advertise alternative services, and restricting who can
open a port for listening on that host.
-----------------------
If you can use CGI to execute scripts, you quite likely
have also ability to listen ports. And PHP have
socket_listen()
http://php.net/manual/en/function.socket-listen.php
Then there is Java based environments also.
I do not claim that shell access is required for that
attack.
I borrowed some text from other drafts.
>
>> 3)
>>
>> I disagree resolution of "Attacks from the same host".
>>
>> My long explanation is on
>>
>> Re: [Moderator Action] #144: Attacks from Same Host (OppSec)
>> https://lists.w3.org/Archives/Public/ietf-http-wg/2016JanMar/0411.html
>> Message-Id: <20160313174847.DD97B389F@welho-filter4.welho.com>
>>
>> Effectively browser's (or http client's) method to defend this
>> attack is still that browser ignores alternative service
>> if port >= 1024
>>
>> If /.well-known/http-opportunistic does not include lists
>> alternatives or list of valid ports where alternative service
>> is supposed to be located, that ignoring port >= 1024 is best
>> guess what browser can do.
>>
>> https://lists.w3.org/Archives/Public/ietf-http-wg/2016JanMar/0111.html
>>
>> Patrick McManus wrote:
>>
>> | I'm actually glad the port number nonsense got called out. It didn't have
>> | real value and its the kind of window dressing only a committee could love
>> | (I say lovingly, as member of said committee.).
>>
>> I'm not sure about that because draft-ietf-httpbis-http2-encryption does not
>> provide other defenses for browser.
>>
>> I originally suggested that:
>>
>> | How about requiring that alternative service are also listed on
>> | /.well-known/alternative-services
>> |
>> | Pre-Alt-Svc servers do not provide /.well-known/alternative-services
>> | and eve can not provide /.well-known/alternative-services on
>> | original service.
>> |
>> | I think that this stops that attack if http client also checks
>> | /.well-known/alternative-services when alternative service
>> | does not provide strong auth. This of course adds additional delay
>> | before alternative service is used.
>
> Does anyone else agree with Kari's concerns around <https://github.com/httpwg/http-extensions/issues/144>? If so, now is the time to speak up.
>
> Mike, please track this issue as potentially contentious.
>
>
>> Current draft does not provide for client means to do check with
>> /.well-known/http-opportunistic resource. Therefore port number
>> check is still on table.
>
> Can you please explain what you mean by "Current draft does not provide for client means to do check with /.well-known/http-opportunistic resource."? The draft requires http-opportunistic to be checked when strong authentication is not available.
I'm not sure that have I left someting out.
/.well-known/http-opportunistic tells that there is SOME
alternative service for that origin.
/.well-known/http-opportunistic does not make possible
to check, if that alternative service, which is
mentioned on Alt-Svc: -header field, is authoritative
for whole origin.
That /.well-known/http-opportunistic may mean some
other alternative service. (And if there is "commit"
member or perhaps(?) some other (future) member,
it even may not mean any same host
alternative service. )
Client just knows that there exists some alternative
service which is authoritative for whole origin.
So client need guess what alternative services
are authoritative.
Possibilities include:
1) It can just trust
Alt-Svc: -header field
2) It can try check that itself,
and make guess that users on web host
can not bind ports < 1024
3) It can decide to trust just
some Alt-Svc: -header fields
on places where is unlikely
that users on web host
can introduce them. For example
GET /
OPTIONS *
GET /.well-known/{anything}
I talk checking that alternative service
mentioned on Alt-Svc: -header field is
same alternative service than what for
/.well-known/http-opportunistic exists.
I talk checks which browser can do
to defend agaist attack (as opposite
just trust that web host knows and
does all defending agaist attack).
( I'm not sure if "authoritative"
is correct term here or if it
also means something else. )
So this perhaps is question that how alternative
service authorize itself to client without
certificate. Can client ask authorization
for alternative service from third party
(that is /.well-known/http-opportunistic ).
If third part ( /.well-known/http-opportunistic )
just gives blanket authorization for all
possible alternative services, I think
that this is murky.
>
>> 4)
>>
>> https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-04#section-5.1
>> 5.1. Opportunistic Commitment
>>
>>
>> | An origin can reduce the risk of attacks on opportunistically secured
>> | connections by committing to provide an secured, authenticated
>> | alternative service. This is done by including the optional "commit"
>> | member in the http-opportunistic well-known resource (see Section 6).
>>
>> This does not make possible to specify "commit" without saying same time that
>> there is also reasonable assurance for alternative services for on same host
>> which does not provide strong authentication.
>>
>> There should be possible to give "commit" for authenticated alternatives
>> WITHOUT giving also reasonable assurances for non-authenticated alternatives
>> (on same host that origin).
>>
>> /.well-known/http-opportunistic SHOULD include separate indication
>> that for reasonable assurances. My suggestion for that parameter is same than
>> for "Attacks from the same host".
>
> Raised as <https://github.com/httpwg/http-extensions/issues/160>. Please discuss.
>
( My replies about this was to another mail. )
>> 5)
>>
>> My suggestion for
>>
>> 3. Server Authentication
>> https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-04#section-3
>>
>> | When the client has a valid http-opportunistic response for an
>> | origin, it MAY consider there to be reasonable assurances when:
>> |
>> | o The origin and alternative service's hostnames are the same when
>> | compared in a case-insensitive fashion, and
>> |
>> | o The chosen alternative service returns the same response as above.
>> +
>> + o The "valid-ports" member of the root object on the http-opportunistic
>> + response has a value of an array of numbers, one of which is same
>> + value than alternative service's port number.
>>
>> 6. The "http-opportunistic" well-known URI
>> https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-04#section-6
>>
>> - This specification defines one additional, optional member of the
>> - root object, "commit" in Section 5. Unrecognised members MUST be
>> - ignored.
>>
>> ⇒
>>
>> + This specification defines two additional, optional members of the
>> + root object, "commit" in Section 5 and "valid-ports" in Section 3.
>> + Unrecognized members MUST be ignored.
>>
>>
>> That "valid-ports" member makes explicit which port numbers are under
>> origin's control. So there not need make assumption like port numbers
>> <= 1024 are safe.
>>
>> This also makes clear for which purpose /.well-known/http-opportunistic is.
>> There is either "commit" or "valid-ports" member on http-opportunistic
>> response. (It is unlikely that both on same time makes sense. )
>>
>> Because this also requires that origin and alternative service's hostnames
>> are same, listing port numbers effectively lists alternative
>> services (except that protocol is not mentioned, "h2" is only
>> protocol which fulfills requirements).
>>
>> That list of port number or alternative services on http-opportunistic
>> response does not indicate that alternative service is provided on these
>> ports, only that alternative services may be provided on these ports
>> without valid certificate. This does not replace Alt-Svc: -header field.
>
> This is a proposal for <https://github.com/httpwg/http-extensions/issues/144>, correct?
Yes, "valid-ports" is my proposal for "Attacks from same host #144"
And it is also for https://github.com/httpwg/http-extensions/issues/160
" Commit without same-host opt-in #160 ":
| /.well-known/http-opportunistic SHOULD include separate indication that for reasonable
| assurances. My suggestion for that parameter is same than for "Attacks from the same host".
Any parameter which explicity says "same-host opt-in" works for #160.
Implicit parameters (aka "same-host opt-in" if there is no "commit")
do not work as well (Martin Thomson seems disagree with this).
>> 6)
>>
>> https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-04#section-5.1
>> 5.1. Opportunistic Commitment
>>
>> 3. Server Authentication requires that
>>
>> | The chosen alternative service returns the same response as above.
>>
>> Should there be same requirement before "commit" is accepted ?
>> Now that is not required for commit.
>
> It's required for server authentication so that there's an assurance that both the origin and alternative opt into the equivalence.
>
> What function would it serve for the commitment?
Does it make sense to use commintment if
alternative service does not provide
equivalent data ?
It may be strange situation for example
if origin says commit but that does not have on
alternative service's response.
>
> Thanks for the feedback,
>
> --
> Mark Nottingham https://www.mnot.net/
>
Correspond mails should be includes on below (may
be visible as attachment on some mail clients. )
/ Kari Hurtta
>> 2)
>>
>> https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-04#section-8
>> 8. Security Considerations
>>
>> For "Attacks from the same host" this makes silent assumption that
>> /.well-known/http-opportunistic indicates that there is not injected
>> bad Alt-Svc: -headers.
>>
>> In other words Alt-Svc: -headers are assumed to be filtered
>> out from attackers (shared hosting), but that assumption is not
>> spelled out on draft.
>
> Yes. Any suggested text here (Kari or someone else)?
>
Not really, but I try anyway
---------------------
CGI [RFC 3875], PHP, and other environments allows page
authors to insert custom headers to HTTP -response. Page
authors may also able listen local ports via these
environments directly or they can execute programs.
These allows attacker to inject Alt-Svc: which specify
local port on control of attacker on same host.
Without precautions this allows attacker masquerade as the
HTTP server.
Presence of /.well-known/http-opportunistic tells
that server is aware of that protocol and have take
precautions so that attacker can not masquerade as the
HTTP server.
Clients can reduce this risk by limiting ports which
them accept as alternative service on same host (without
valid certificate).
Server can reduce this risk by restricting the ability to
advertise alternative services, and restricting who can
open a port for listening on that host.
-----------------------
If you can use CGI to execute scripts, you quite likely
have also ability to listen ports. And PHP have
socket_listen()
http://php.net/manual/en/function.socket-listen.php
Then there is Java based environments also.
I do not claim that shell access is required for that
attack.
I borrowed some text from other drafts.
/ Kari Hurtta
Mark Nottingham <mnot@mnot.net>: (Fri Mar 18 03:19:27 2016)
>> I disagree resolution of "Attacks from the same host".
>>
>> My long explanation is on
>>
>> Re: [Moderator Action] #144: Attacks from Same Host (OppSec)
>> https://lists.w3.org/Archives/Public/ietf-http-wg/2016JanMar/0411.html
>> Message-Id: <20160313174847.DD97B389F@welho-filter4.welho.com>
>>
>> Effectively browser's (or http client's) method to defend this
>> attack is still that browser ignores alternative service
>> if port >= 1024
>>
>> If /.well-known/http-opportunistic does not include lists
>> alternatives or list of valid ports where alternative service
>> is supposed to be located, that ignoring port >= 1024 is best
>> guess what browser can do.
>>
>> https://lists.w3.org/Archives/Public/ietf-http-wg/2016JanMar/0111.html
>>
>> Patrick McManus wrote:
>>
>> | I'm actually glad the port number nonsense got called out. It didn't have
>> | real value and its the kind of window dressing only a committee could love
>> | (I say lovingly, as member of said committee.).
>>
>> I'm not sure about that because draft-ietf-httpbis-http2-encryption does not
>> provide other defenses for browser.
>>
>> I originally suggested that:
>>
>> | How about requiring that alternative service are also listed on
>> | /.well-known/alternative-services
>> |
>> | Pre-Alt-Svc servers do not provide /.well-known/alternative-services
>> | and eve can not provide /.well-known/alternative-services on
>> | original service.
>> |
>> | I think that this stops that attack if http client also checks
>> | /.well-known/alternative-services when alternative service
>> | does not provide strong auth. This of course adds additional delay
>> | before alternative service is used.
>
> Does anyone else agree with Kari's concerns around <https://github.com/httpwg/http-extensions/issues/144>? If so, now is the time to speak up.
>
> Mike, please track this issue as potentially contentious.
>
>
>> Current draft does not provide for client means to do check with
>> /.well-known/http-opportunistic resource. Therefore port number
>> check is still on table.
>
> Can you please explain what you mean by "Current draft does not provide for client means to do check with /.well-known/http-opportunistic resource."? The draft requires http-opportunistic to be checked when strong authentication is not available.
>
I'm not sure that have I left someting out.
/.well-known/http-opportunistic tells that there is SOME
alternative service for that origin.
/.well-known/http-opportunistic does not make possible
to check, if that alternative service, which is
mentioned on Alt-Svc: -header field, is authoritative
for whole origin.
That /.well-known/http-opportunistic may mean some
other alternative service. (And if there is "commit"
member or perhaps(?) some other (future) member,
it even may not mean any same host
alternative service. )
Client just knows that there exists some alternative
service which is authoritative for whole origin.
So client need guess what alternative services
are authoritative.
Possibilities include:
1) It can just trust
Alt-Svc: -header field
2) It can try check that itself,
and make guess that users on web host
can not bind ports < 1024
3) It can decide to trust just
some Alt-Svc: -header fields
on places where is unlikely
that users on web host
can introduce them. For example
GET /
OPTIONS *
GET /.well-known/{anything}
I talk checking that alternative service
mentioned on Alt-Svc: -header field is
same alternative service than what for
/.well-known/http-opportunistic exists.
I talk checks which browser can do
to defend agaist attack (as opposite
just trust that web host knows and
does all defending agaist attack).
( I'm not sure if "authoritative"
is correct term here or if it
also means something else. )
So this perhaps is question that how alternative
service authorize itself to client without
certificate. Can client ask authorization
for alternative service from third party
(that is /.well-known/http-opportunistic ).
If third part ( /.well-known/http-opportunistic )
just gives blanket authorization for all
possible alternative services, I think
that this is murky.
/ Kari Hurtta
Quick note. Not posted to list.
>> 4)
>>
>> https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-04#section-5.1
>> 5.1. Opportunistic Commitment
>>
>>
>> | An origin can reduce the risk of attacks on opportunistically secured
>> | connections by committing to provide an secured, authenticated
>> | alternative service. This is done by including the optional "commit"
>> | member in the http-opportunistic well-known resource (see Section 6).
>>
>> This does not make possible to specify "commit" without saying same time that
>> there is also reasonable assurance for alternative services for on same host
>> which does not provide strong authentication.
>>
>> There should be possible to give "commit" for authenticated alternatives
>> WITHOUT giving also reasonable assurances for non-authenticated alternatives
>> (on same host that origin).
>>
>> /.well-known/http-opportunistic SHOULD include separate indication
>> that for reasonable assurances. My suggestion for that parameter is same than
>> for "Attacks from the same host".
>
> Raised as <https://github.com/httpwg/http-extensions/issues/160>. Please discuss.
>
>
>> 5)
>>
>> My suggestion for
>>
>> 3. Server Authentication
>> https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-04#section-3
>>
>> | When the client has a valid http-opportunistic response for an
>> | origin, it MAY consider there to be reasonable assurances when:
>> |
>> | o The origin and alternative service's hostnames are the same when
>> | compared in a case-insensitive fashion, and
>> |
>> | o The chosen alternative service returns the same response as above.
>> +
>> + o The "valid-ports" member of the root object on the http-opportunistic
>> + response has a value of an array of numbers, one of which is same
>> + value than alternative service's port number.
>>
>> 6. The "http-opportunistic" well-known URI
>> https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-04#section-6
>>
>> - This specification defines one additional, optional member of the
>> - root object, "commit" in Section 5. Unrecognised members MUST be
>> - ignored.
>>
>> ⇒
>>
>> + This specification defines two additional, optional members of the
>> + root object, "commit" in Section 5 and "valid-ports" in Section 3.
>> + Unrecognized members MUST be ignored.
>>
>>
>> That "valid-ports" member makes explicit which port numbers are under
>> origin's control. So there not need make assumption like port numbers
>> <= 1024 are safe.
>>
>> This also makes clear for which purpose /.well-known/http-opportunistic is.
>> There is either "commit" or "valid-ports" member on http-opportunistic
>> response. (It is unlikely that both on same time makes sense. )
>>
>> Because this also requires that origin and alternative service's hostnames
>> are same, listing port numbers effectively lists alternative
>> services (except that protocol is not mentioned, "h2" is only
>> protocol which fulfills requirements).
>>
>> That list of port number or alternative services on http-opportunistic
>> response does not indicate that alternative service is provided on these
>> ports, only that alternative services may be provided on these ports
>> without valid certificate. This does not replace Alt-Svc: -header field.
>
> This is a proposal for <https://github.com/httpwg/http-extensions/issues/144>, correct?
Yes, "valid-ports" is my proposal for "Attacks from same host #144"
And it is also for https://github.com/httpwg/http-extensions/issues/160
" Commit without same-host opt-in #160 ":
| /.well-known/http-opportunistic SHOULD include separate indication that for reasonable
| assurances. My suggestion for that parameter is same than for "Attacks from the same host".
Any parameter which explicity says "same-host opt-in" works for #160.
Implicit parameters (aka "same-host opt-in" if there is no "commit")
do not work as well (Martin Thomson seems disagree with this).
/ Kari Hurtta
>> 6)
>>
>> https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-04#section-5.1
>> 5.1. Opportunistic Commitment
>>
>> 3. Server Authentication requires that
>>
>> | The chosen alternative service returns the same response as above.
>>
>> Should there be same requirement before "commit" is accepted ?
>> Now that is not required for commit.
>
> It's required for server authentication so that there's an assurance that both the origin and alternative opt into the equivalence.
>
> What function would it serve for the commitment?
>
Does it make sense to use commintment if
alternative service does not provide
equivalent data ?
It may be strange situation for example
if origin says commit but that does not have on
alternative service's response.
>
> Thanks for the feedback,
>
> --
> Mark Nottingham https://www.mnot.net/
/ Kari Hurtta
Received on Tuesday, 22 March 2016 13:26:27 UTC