1274581 - http/2 wrong ip used for CORS request

Status: RESOLVED INVALID

(Core :: Networking: HTTP, defect)

Description

[amrod]

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID: 20160503092831

Steps to reproduce:

I configured 2 servers, both are serving test.example.com (2 DNS A records). One of them also serves test1.example.com and the other serves test2.example.com. Both servers have http2 enabled, have a wildcard certificate for example.com, and are configured with correct CORS headers. 
The site at test.example.com makes a CORS request to both test1.example.com and test2.example.com. 


Actual results:

For both CORS requests the IP address of the chosen host for test.example.com is used.

(I tested it with both nginx and Apache. Notable is that if nginx and Apache are configure to return a 421 code then the following requests are made to the correct IP)


Expected results:

For both CORS request a different IP should have been used, based on the DNS.

Comment 1

[Patrick McManus [:mcmanus]]

this is working as designed if I understand the case correctly.

test.example.com resolves to 1.1.1.1, 2.2.2.2
test1.example.com resolves to 1.1.1.1
test2.example.com resolves to 2.2.2.2

the servers all use valid *.example.com certs.

you are connected to test.example.com (via h2) and need to do a CORS transaction with test1.. test1 is 1.1.1.1 which resolves to a matching address as test.example.com and the existing connection has a cert valid for test1.. so it gets used without a new connection.

you are connected to test.example.com (via h2) and need to do a CORS transaction with test2. test2 is 2.2.2.2 which resolves to a matching address as test.example.com and the existing connection has a valid cert for test2.. so it gets used without a new connection.

This is all laid out in rfc 7540 - section 9.1.1 which talks about hosts having resolved to the same address. (it is not the address of the connection being used - it is the resolution).

If this isn't the behavior you want there are a few options.. the easiest is to use 421 when you get a request where you don't want it as you have found. That's exactly what it is meant for - don't feel bad about using it.

The real signal here is the cert - it would be more efficient to have the host only provide a cert for the origins it is actually serving. so 1.1.1.1 would use a cert for test.example.com and test1.example.com and 2.2.2.2 would use a cert for test2.example.com and test.example.com. Let's Encrypt will give you certs valid for a bunch of names if you like.

let me know if I misunderstand the report.

Comment 2

[amrod]

The case you discribe is exactly the one I was refering to. However I don't agree with your conclusion that it is not about the address of the connection but the resolution.

The RFC states that a connection can be resued if the server is authoritative. In section 10.1 rfc7540, it is stated that server authority is the same as in HTTP/1.1. And if I'm reading/interpreting it correctly this means that a server is authoritative for all domains that can be resolved to its address. I cannot find anything about expanding the authority of a server with all the hosts that are sharing addresses with previously mapped hosts.

Ofcourse an argument that the other kids on the block are also doing things a certain way isn't really an argument, however I think it is worth mentioning that all the other browers are not naming 1.1.1.1 authoritative for test2.

Regarding the solution to return a 421 code, this is only a partial solution. The running webaplication mus be made aware of the 421 and be willing to retry a request. Firefox will correctly retry a GET request after receiving a 421, however it does not automatically retry POST requests (?or it fails in retrying?). The following (POST) requests will succeed in finding the correct server.

Comment 3

[Patrick McManus [:mcmanus]]

The POST thing is a bug specific to release 46. sorry about that - 421 should work with POST (and will other than in 46.)

In general 421 is supposed to be the answer here - but the cert arrangement I mentioned is better on both counts.