9. Security Considerations
9.1. Changing Ports
Using an alternative service implies accessing an origin's resources on an alternative port, at a minimum. Therefore, an attacker that can inject alternative services and listen at the advertised port is able to hijack an origin. On certain servers, it is normal for users to be able to control some personal pages available on a shared port and also to accept requests on less-privileged ports.
For example, an attacker that can add HTTP response header fields to some pages can redirect traffic for an entire origin to a different port on the same host using the Alt-Svc header field; if that port is under the attacker's control, they can thus masquerade as the HTTP server.
This risk is mitigated by the requirements in Section 2.1.
On servers, this risk can also be reduced by restricting the ability to advertise alternative services, and restricting who can open a port for listening on that host.
9.2. Changing Hosts
When the host is changed due to the use of an alternative service, this presents an opportunity for attackers to hijack communication to an origin.
For example, if an attacker can convince a user agent to send all traffic for "innocent.example.org" to "evil.example.com" by successfully associating it as an alternative service, they can masquerade as that origin. This can be done locally (see mitigations in Section 9.1) or remotely (e.g., by an intermediary as a man-in-the-middle attack).
This is the reason for the requirement in Section 2.1 that clients have reasonable assurances that the alternative service is under control of and valid for the whole origin; for example, presenting a certificate for the origin proves that the alternative service is authorized to serve traffic for the origin.
Note that this assurance is only as strong as the method used to authenticate the alternative service. In particular, when TLS authentication is used to do so, there are well-known exploits to make an attacker's certificate appear as legitimate.
Alternative services could be used to persist such an attack. For example, an intermediary could man-in-the-middle TLS-protected communication to a target and then direct all traffic to an alternative service with a large freshness lifetime so that the user agent still directs traffic to the attacker even when not using the intermediary.
Implementations MUST perform any certificate-pinning validation (such as [RFC7469]) on alternative services just as they would on direct connections to the origin. Implementations might also choose to add other requirements around which certificates are acceptable for alternative services.
9.3. Changing Protocols
When the ALPN protocol is changed due to the use of an alternative service, the security properties of the new connection to the origin can be different from that of the "normal" connection to the origin, because the protocol identifier itself implies this.
For example, if an "https://" URI has a protocol advertised that does not use some form of end-to-end encryption (most likely, TLS), this violates the expectations for security that the URI scheme implies. Therefore, clients cannot use alternative services blindly, but instead evaluate the option(s) presented to ensure that security requirements and expectations of specifications, implementations, and end users are met.
9.4. Tracking Clients Using Alternative Services
Choosing an alternative service implies connecting to a new, server-supplied host name. By using unique names, servers could conceivably track client requests. Such tracking could follow users across multiple networks, when the "persist" flag is used.
Clients that wish to prevent requests from being correlated can decide not to use alternative services for multiple requests that would not otherwise be allowed to be correlated.
In a user agent, any alternative service information MUST be removed when origin-specific data is cleared (typically, when cookies [RFC6265] are cleared).
9.5. Confusion regarding Request Scheme
Some server-side HTTP applications make assumptions about security based upon connection context; for example, equating being served upon port 443 with the use of an "https://" URI and the various security properties that implies.
This affects not only the security properties of the connection itself, but also the state of the client at the other end of it; for example, a Web browser treats "https://" URIs differently than "http://" URIs in many ways, not just for purposes of protocol handling.
Since one of the uses of Alternative Services is to allow a connection to be migrated to a different protocol and port, these applications can become confused about the security properties of a given connection, sending information (for example, cookies and content) that is intended for a secure context (such as an "https://" URI) to a client that is not treating it as one.
This risk can be mitigated in servers by using the URI scheme explicitly carried by the protocol (such as ":scheme" in HTTP/2 or the "absolute form" of the request target in HTTP/1.1) as an indication of security context, instead of other connection properties ([RFC7540], Section 8.1.2.3 and [RFC7230], Section 5.3.2).
When the protocol does not explicitly carry the scheme (as is usually the case for HTTP/1.1 over TLS), servers can mitigate this risk by either assuming that all requests have an insecure context, or by refraining from advertising alternative services for insecure schemes (for example, HTTP).