René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Allow ALPN fallback","articleBody":"### What is the problem this feature will solve?\n\nI want to create a TLS server that uses ALPN but accepts _all_ protocols from the client.\r\n\r\nThere's all sorts of interesting cases for this, but the simplest is when the server is really a TLS-terminating proxy of some kind that's just forwarding data upstream. ALPN is necessary in these cases because some clients (e.g. GRPC) will completely fail to connect to a server that does not explicitly support their protocol of choice. I suspect that'll become even more common in future as ALPN becomes widespread outside HTTP/2.\r\n\r\nMy case is a little more specific: my server is a proxy that supports network debugging, and I specifically want to accept all protocols so that I can capture and debug unexpected traffic, rather than rejecting it at the door. I think this applies more widely though.\n\n### What is the feature you are proposing to solve the problem?\n\nAn additional TLS server option like `allowALPNFallback: \u003cboolean>`.\r\n\r\nIf set, at the end of [the SelectALPNCallback callback](https://github.com/tniessen/node/blob/21958e4eaa6d57f4f6afb766ea2cf3a34d7180db/src/crypto/crypto_tls.cc#L221-L256) if `status == OPENSSL_NPN_NEGOTIATED` then `SSL_TLSEXT_ERR_OK` should be returned instead of `SSL_TLSEXT_ERR_ALERT_FATAL`, thereby accepting the `out` value set by `SSL_select_next_proto` in the lines above.\r\n\r\nI believe this works because the feature described is already the default behaviour of OpenSSL's `SSL_select_next_proto` function, which sets `out` in this callback to the client's first protocol preference by default if no matching server protocol is found. Docs here: https://www.openssl.org/docs/man3.0/man3/SSL_select_next_proto.html. The only reason that this doesn't work already is the additional check the Node adds, which sends an alert and kills the connection instead.\n\n### What alternatives have you considered?\n\nI've opened this because this behaviour was recently changed in Node 19 in https://github.com/nodejs/node/pull/44031. Previously in many cases it was possible to at least detect and in some cases fudge these connections because the connection continued (without an ALPN response but without failure) despite the lack of ALPN protocol agreement. Now it will always be rejected explicitly, which makes this use case more complicated.\r\n\r\nI do agree the new behaviour in #44031 is correct as the default, but I just don't think that the RFC quoted there mandates this strict behaviour for _all_ TLS servers. As quoted in that PR, the RFC says:\r\n\r\n> It is expected that a server will have a list of protocols that it supports, in preference order, and will only select a protocol if the client supports it. In that case, the server SHOULD select the most highly preferred protocol that it supports and that is also advertised by the client. In the event that the server supports no protocols that the client advertises, then the server SHALL respond with a fatal \"no_application_protocol\" alert.\r\n\r\nIn my case, the server effectively supports all protocols (i.e. it doesn't care, it's just proxying raw traffic) and so it's not required to send the alert - it's reasonable to accept the client's preference for unknown protocols.\r\n\r\nA more general alternative would be an ALPN callback, to allow TLS servers to implement arbitrary logic like this or other ways to pick the ALPN protocol from JS directly. Imo that's interesting and all very cool, but not really necessary, and quite a bit more complicated, so probably not worthwhile. Could be worth considering if others see a good use cases for this though.","author":{"url":"https://github.com/pimterry","@type":"Person","name":"pimterry"},"datePublished":"2022-10-18T16:52:28Z","url":"https://github.com/nodejs/node/issues/45056"}