Mirrors/libwebsockets
1
0
Fork 0
mirror of https://github.com/warmcat/libwebsockets.git synced 2025-03-16 00:00:07 +01:00
Code Issues Releases Wiki Activity
libwebsockets/lib/secure-streams/protocols/ss-h2.c

209 lines
5.8 KiB
C
Raw Normal View History

client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
/*
* libwebsockets - small server side websockets and web server implementation
*
* Copyright (C) 2019 - 2020 Andy Green <andy@warmcat.com>
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the "Software"), to
* deal in the Software without restriction, including without limitation the
* rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
* sell copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice shall be included in
* all copies or substantial portions of the Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
* AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
* IN THE SOFTWARE.
*/
#include <private-lib-core.h>
extern int
secstream_h1(struct lws *wsi, enum lws_callback_reasons reason, void *user,
void *in, size_t len);
static int
secstream_h2(struct lws *wsi, enum lws_callback_reasons reason, void *user,
void *in, size_t len)
{
lws_ss_handle_t *h = (lws_ss_handle_t *)lws_get_opaque_user_data(wsi);
ss: improve callback return consistency Formalize the LWSSSSRET_ enums into a type "lws_ss_state_return_t" returned by the rx, tx and state callbacks, and some private helpers lws_ss_backoff() and lws_ss_event_helper(). Remove LWSSSSRET_SS_HANDLE_DESTROYED concept... the two helpers that could have destroyed the ss and returned that, now return LWSSSSRET_DESTROY_ME to the caller to perform or pass up to their caller instead. Handle helper returns in all the ss protocols and update the rx / tx calls to have their returns from rx / tx / event helper and ss backoff all handled by unified code.
2020-08-26 11:05:41 +01:00
lws_ss_state_return_t r;
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
int n;
switch (reason) {
case LWS_CALLBACK_ESTABLISHED_CLIENT_HTTP:
#if defined(LWS_WITH_SECURE_STREAMS_PROXY_API)
if (h->being_serialized) {
/*
* We are the proxy-side SS for a remote client... we
* need to inform the client about the initial tx credit
* to write to it that the remote h2 server set up
*/
lwsl_info("%s: reporting initial tx cr from server %d\n",
__func__, wsi->txc.tx_cr);
ss_proxy_onward_txcr((void *)&h[1], wsi->txc.tx_cr);
}
#endif
n = secstream_h1(wsi, reason, user, in, len);
if (!n && (h->policy->flags & LWSSSPOLF_LONG_POLL)) {
lws_lifecycle This adds some new objects and helpers for keeping and logging info on grouped allocations, a group is, eg, SS handles or client wsis. Allocated objects get a context-unique "tag" string intended to replace %p / wsi pointers etc. Pointers quickly become confusing when allocations are freed and reused, the tag string won't repeat until you produce 2^64 objects in a context. In addition the tag string documents the object group, with prefixes like "wsi-" or "vh-" and contain object-specific additional information like the vhost name, address / port or the role of the wsi. At creation time the lws code can use a format string and args to add whatever group-specific info makes sense, eg, a wsi bound to a secure stream can also append the guid of the secure stream, it's copied into the new object tag and so is still available cleanly after the stream is destroyed if the wsi outlives it.
2020-12-25 05:54:19 +00:00
lwsl_notice("%s: h2 client %s entering LONG_POLL\n",
__func__, lws_wsi_tag(wsi));
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
lws_h2_client_stream_long_poll_rxonly(wsi);
}
return n;
ss: h2: dont report nwsi close SS protocol doesn't want to hear about the nwsi closing after any streams on the protocol closed.
2020-12-15 16:05:37 +00:00
case LWS_CALLBACK_CLOSED_CLIENT_HTTP:
if (lws_get_network_wsi(wsi) == wsi)
return 0;
break;
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
case LWS_CALLBACK_COMPLETED_CLIENT_HTTP:
// lwsl_err("%s: h2 COMPLETED_CLIENT_HTTP\n", __func__);
lws_lifecycle This adds some new objects and helpers for keeping and logging info on grouped allocations, a group is, eg, SS handles or client wsis. Allocated objects get a context-unique "tag" string intended to replace %p / wsi pointers etc. Pointers quickly become confusing when allocations are freed and reused, the tag string won't repeat until you produce 2^64 objects in a context. In addition the tag string documents the object group, with prefixes like "wsi-" or "vh-" and contain object-specific additional information like the vhost name, address / port or the role of the wsi. At creation time the lws code can use a format string and args to add whatever group-specific info makes sense, eg, a wsi bound to a secure stream can also append the guid of the secure stream, it's copied into the new object tag and so is still available cleanly after the stream is destroyed if the wsi outlives it.
2020-12-25 05:54:19 +00:00
if (h->hanging_som)
r = h->info.rx(ss_to_userobj(h), NULL, 0, LWSSS_FLAG_EOM);
ss: static policy: dynamic vhost instantiation Presently a vh is allocated per trust store at policy parsing-time, this is no problem on a linux-class device or if you decide you need a dynamic policy for functionality reasons. However if you're in a constrained enough situation that the static policy makes sense, in the case your trust stores do not have 100% duty cycle, ie, are anyway always in use, the currently-unused vhosts and their x.509 stack are sitting there taking up heap for no immediate benefit. This patch modifies behaviour in ..._STATIC_POLICY_ONLY so that vhosts and associated x.509 tls contexts are not instantiated until a secure stream using them is created; they are refcounted, and when the last logical secure stream using a vhost is destroyed, the vhost and its tls context is also destroyed. If another ss connection is created that wants to use the trust store, the vhost and x.509 context is regenerated again as needed. Currently the refcounting is by ss, it's also possible to move the refcounting to be by connection. The choice is between the delay to generate the vh being visisble at logical ss creation-time, or at connection-time. It's anyway not preferable to have ss instantiated and taking up space with no associated connection or connection attempt underway. NB you will need to reprocess any static policies after this patch so they conform to the trust_store changes.
2020-07-20 07:28:28 +01:00
/* decouple the fates of the wsi and the ss */
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
h->wsi = NULL;
h->txn_ok = 1;
lws_cancel_service(lws_get_context(wsi)); /* abort poll wait */
lws_lifecycle This adds some new objects and helpers for keeping and logging info on grouped allocations, a group is, eg, SS handles or client wsis. Allocated objects get a context-unique "tag" string intended to replace %p / wsi pointers etc. Pointers quickly become confusing when allocations are freed and reused, the tag string won't repeat until you produce 2^64 objects in a context. In addition the tag string documents the object group, with prefixes like "wsi-" or "vh-" and contain object-specific additional information like the vhost name, address / port or the role of the wsi. At creation time the lws code can use a format string and args to add whatever group-specific info makes sense, eg, a wsi bound to a secure stream can also append the guid of the secure stream, it's copied into the new object tag and so is still available cleanly after the stream is destroyed if the wsi outlives it.
2020-12-25 05:54:19 +00:00
if (h->hanging_som && r == LWSSSSRET_DESTROY_ME)
ss: client_connect and request_tx also return dispositions Since client_connect and request_tx can be called from code that expects the ss handle to be in scope, these calls can't deal with destroying the ss handle and must pass the lws_ss_state_return_t disposition back to the caller to handle.
2020-12-22 15:56:41 +00:00
return _lws_ss_handle_state_ret_CAN_DESTROY_HANDLE(r, wsi, &h);
lws_lifecycle This adds some new objects and helpers for keeping and logging info on grouped allocations, a group is, eg, SS handles or client wsis. Allocated objects get a context-unique "tag" string intended to replace %p / wsi pointers etc. Pointers quickly become confusing when allocations are freed and reused, the tag string won't repeat until you produce 2^64 objects in a context. In addition the tag string documents the object group, with prefixes like "wsi-" or "vh-" and contain object-specific additional information like the vhost name, address / port or the role of the wsi. At creation time the lws code can use a format string and args to add whatever group-specific info makes sense, eg, a wsi bound to a secure stream can also append the guid of the secure stream, it's copied into the new object tag and so is still available cleanly after the stream is destroyed if the wsi outlives it.
2020-12-25 05:54:19 +00:00
h->hanging_som = 0;
ss: h2: ACK/NACK missing in H2 state flow
2020-11-02 17:37:32 +08:00
break;
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
case LWS_CALLBACK_WSI_TX_CREDIT_GET:
/*
* The peer has sent us additional tx credit...
*/
lwsl_info("%s: LWS_CALLBACK_WSI_TX_CREDIT_GET: %d\n",
__func__, (int32_t)len);
#if defined(LWS_WITH_SECURE_STREAMS_PROXY_API)
if (h->being_serialized)
/* we are the proxy-side SS for a remote client */
ss_proxy_onward_txcr((void *)&h[1], (int)len);
#endif
break;
default:
break;
}
return secstream_h1(wsi, reason, user, in, len);
}
const struct lws_protocols protocol_secstream_h2 = {
"lws-secstream-h2",
secstream_h2,
0,
0,
};
/*
* Munge connect info according to protocol-specific considerations... this
* usually means interpreting aux in a protocol-specific way and using the
* pieces at connection setup time, eg, http url pieces.
*
* len bytes of buf can be used for things with scope until after the actual
* connect.
*/
int
secstream_connect_munge_h2(lws_ss_handle_t *h, char *buf, size_t len,
struct lws_client_connect_info *i,
union lws_ss_contemp *ct)
{
ss: allow url style endpoint addresses The endpoint field in streamtype policy may continue to just be the hostname, like "warmcat.com". But it's also possible now to be a url-formatted string, like, eg, "https://warmcat.com:444/mailman/listinfo" If so (ie, if it contains a : ) then the decoded elements may override if tls is enabled, the endpoint address, the port, and the url path. No ABI change.
2020-03-14 06:56:41 +00:00
const char *pbasis = h->policy->u.http.url;
size_t used_in, used_out;
lws_strexp_t exp;
/* i.path on entry is used to override the policy urlpath if not "" */
if (i->path[0])
pbasis = i->path;
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
if (h->policy->flags & LWSSSPOLF_QUIRK_NGHTTP2_END_STREAM)
i->ssl_connection |= LCCSCF_H2_QUIRK_NGHTTP2_END_STREAM;
if (h->policy->flags & LWSSSPOLF_H2_QUIRK_OVERFLOWS_TXCR)
i->ssl_connection |= LCCSCF_H2_QUIRK_OVERFLOWS_TXCR;
if (h->policy->flags & LWSSSPOLF_HTTP_MULTIPART)
i->ssl_connection |= LCCSCF_HTTP_MULTIPART_MIME;
if (h->policy->flags & LWSSSPOLF_HTTP_X_WWW_FORM_URLENCODED)
i->ssl_connection |= LCCSCF_HTTP_X_WWW_FORM_URLENCODED;
i->ssl_connection |= LCCSCF_PIPELINE;
i->alpn = "h2";
/* initial peer tx credit */
if (h->info.manual_initial_tx_credit) {
i->ssl_connection |= LCCSCF_H2_MANUAL_RXFLOW;
i->manual_initial_tx_credit = h->info.manual_initial_tx_credit;
lwsl_info("%s: initial txcr %d\n", __func__,
i->manual_initial_tx_credit);
}
ss: allow url style endpoint addresses The endpoint field in streamtype policy may continue to just be the hostname, like "warmcat.com". But it's also possible now to be a url-formatted string, like, eg, "https://warmcat.com:444/mailman/listinfo" If so (ie, if it contains a : ) then the decoded elements may override if tls is enabled, the endpoint address, the port, and the url path. No ABI change.
2020-03-14 06:56:41 +00:00
if (!pbasis)
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
return 0;
/* protocol aux is the path part */
i->path = buf;
ss: allow url style endpoint addresses The endpoint field in streamtype policy may continue to just be the hostname, like "warmcat.com". But it's also possible now to be a url-formatted string, like, eg, "https://warmcat.com:444/mailman/listinfo" If so (ie, if it contains a : ) then the decoded elements may override if tls is enabled, the endpoint address, the port, and the url path. No ABI change.
2020-03-14 06:56:41 +00:00
buf[0] = '/';
lws_strexp_init(&exp, (void *)h, lws_ss_exp_cb_metadata, buf + 1, len - 1);
if (lws_strexp_expand(&exp, pbasis, strlen(pbasis),
&used_in, &used_out) != LSTRX_DONE)
return 1;
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
return 0;
}
static int
secstream_tx_credit_add_h2(lws_ss_handle_t *h, int add)
{
lws_lifecycle This adds some new objects and helpers for keeping and logging info on grouped allocations, a group is, eg, SS handles or client wsis. Allocated objects get a context-unique "tag" string intended to replace %p / wsi pointers etc. Pointers quickly become confusing when allocations are freed and reused, the tag string won't repeat until you produce 2^64 objects in a context. In addition the tag string documents the object group, with prefixes like "wsi-" or "vh-" and contain object-specific additional information like the vhost name, address / port or the role of the wsi. At creation time the lws code can use a format string and args to add whatever group-specific info makes sense, eg, a wsi bound to a secure stream can also append the guid of the secure stream, it's copied into the new object tag and so is still available cleanly after the stream is destroyed if the wsi outlives it.
2020-12-25 05:54:19 +00:00
lwsl_info("%s: %s: add %d\n", __func__, lws_ss_tag(h), add);
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
if (h->wsi)
return lws_h2_update_peer_txcredit(h->wsi, LWS_H2_STREAM_SID, add);
return 0;
}
static int
secstream_tx_credit_est_h2(lws_ss_handle_t *h)
{
if (h->wsi) {
lws_lifecycle This adds some new objects and helpers for keeping and logging info on grouped allocations, a group is, eg, SS handles or client wsis. Allocated objects get a context-unique "tag" string intended to replace %p / wsi pointers etc. Pointers quickly become confusing when allocations are freed and reused, the tag string won't repeat until you produce 2^64 objects in a context. In addition the tag string documents the object group, with prefixes like "wsi-" or "vh-" and contain object-specific additional information like the vhost name, address / port or the role of the wsi. At creation time the lws code can use a format string and args to add whatever group-specific info makes sense, eg, a wsi bound to a secure stream can also append the guid of the secure stream, it's copied into the new object tag and so is still available cleanly after the stream is destroyed if the wsi outlives it.
2020-12-25 05:54:19 +00:00
lwsl_info("%s: %s: est %d\n", __func__, lws_ss_tag(h),
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
lws_h2_get_peer_txcredit_estimate(h->wsi));
return lws_h2_get_peer_txcredit_estimate(h->wsi);
}
lws_lifecycle This adds some new objects and helpers for keeping and logging info on grouped allocations, a group is, eg, SS handles or client wsis. Allocated objects get a context-unique "tag" string intended to replace %p / wsi pointers etc. Pointers quickly become confusing when allocations are freed and reused, the tag string won't repeat until you produce 2^64 objects in a context. In addition the tag string documents the object group, with prefixes like "wsi-" or "vh-" and contain object-specific additional information like the vhost name, address / port or the role of the wsi. At creation time the lws code can use a format string and args to add whatever group-specific info makes sense, eg, a wsi bound to a secure stream can also append the guid of the secure stream, it's copied into the new object tag and so is still available cleanly after the stream is destroyed if the wsi outlives it.
2020-12-25 05:54:19 +00:00
lwsl_info("%s: %s: Unknown (0)\n", __func__, lws_ss_tag(h));
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
return 0;
}
const struct ss_pcols ss_pcol_h2 = {
"h2",
ss: h2: set alpn In order to force h2, we need to specify the client acceptable alpn as h2
2020-12-15 11:50:46 +00:00
"h2",
ss: server: h1, h2, ws basic support Add initial support for defining servers using Secure Streams policy and api semantics. Serving h1, h2 and ws should be functional, the new minimal example shows a combined http + SS server with an incrementing ws message shown in the browser over tls, in around 200 lines of user code. NOP out anything to do with plugins, they're not currently used. Update the docs correspondingly.
2020-07-27 10:03:12 +01:00
&protocol_secstream_h2,
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
secstream_connect_munge_h2,
secstream_tx_credit_add_h2,
secstream_tx_credit_est_h2
};
Reference in a new issue Copy permalink