Is QUIC allowed to use alternative services with a different hostname from the origin?

[uazo]

Is QUIC allowed to use alternative services with a different hostname and/or port from the origin?

https://source.chromium.org/chromium/chromium/src/+/refs/heads/main:net/third_party/quiche/src/quiche/spdy/core/spdy_alt_svc_wire_format_test.cc;l=455;drc=4f1ca20a5419413f4d141fb1c391876765a992df;bpv=1;bpt=1

  input = absl::string_view("foo:137");
  ASSERT_TRUE(SpdyAltSvcWireFormatPeer::ParseAltAuthority(
      input.begin(), input.end(), &host, &port));
  EXPECT_EQ("foo", host);
  EXPECT_EQ(137, port);

code

• AlternativeServiceInfoVector ProcessAlternativeServices()
• HttpStreamFactory::JobController::GetAlternativeServiceInfoInternal()

config: allow_remote_alt_svc

  // If true, allows QUIC to use alternative services with a different
  // hostname from the origin.
  bool allow_remote_alt_svc = true;                       <--- default

storage: http_server_properties_file_name

I can't find anything quick to verify the behavior (only h3 connections)

see also https://bugs.chromium.org/p/chromium/issues/detail?id=585876#c16

[uazo]

Is QUIC allowed to use alternative services with a different hostname and/or port from the origin?

yes, it seems to be.

Basically, just point an Alt-Svc H3 to any server and any port (under 1024) and chromium attempts to connect to that host. Alt-svc's are also saved to disk, until deleted by ui. I wonder what if anything can be used to track users.

[uazo]

let's assume that you can tell the browser that when you connect to tracking.domain in H2 (tcp) you can tell it to initiate H3 (udp) communication to something.tracking.domain (or even tracking2.domain) transparently to the user.

now, if tracking.domain generated for each individual user <user_number>.tracking.domain i could retrieve the <user_number> information from the call that is made. and even if it were not available (because, for example, the original domain appears in the H3 communication), the udp port request clearly appears on the server.

so, wouldn't that be a way to track users even without using third-party cookies? the information is separated per top domain, so it does not seem to me that there is a possibility of tracking between different domains, but it is saved to disk and retained until deleted by the user (or automatically deleted in bromite).

@PF4Public what do you think about it?

[uazo]

is no longer allowed with https://github.com/uazo/cromite/commit/b3af1b0d37cd3feb88766dcfb272ff5af8505c4a

[PF4Public]

But wouldn't it be apparent in the URL field, that browser is trying to access <user_number>.tracking.domain after some time?

[uazo]

But wouldn't it be apparent in the URL field, that browser is trying to access .tracking.domain after some time?

No. the domain that appears remains that of the request, only the socket is opened on the different endpoint (if the ssl handshake allows it, but in any case, transmission is attempted)

[PF4Public]

This makes it a super-cookie alternative then! Especially if alt-svc's are saved and reused for followup requests until cleaned!

I inspected headers from google and they supply only :443 for now.

[uazo]

This makes it a super-cookie alternative then!

I don't know... and anyway until the cache is cleared. EDIT: perhaps with a good number of ip addresses, because only ports <1024 can be used for each ip.

[PF4Public]

You can have one IP, but in this case you need to have a successful handshake in order to extract target domain information.

[uazo]

to extract target domain information.

I don't think so, after all in the handshake the original host is visible into the SNI. I think only the port is available to the server to distinguish the user