Hi Willy > Le 27 févr. 2018 à 15:57, Willy Tarreau <w...@1wt.eu> a écrit : > > Hi Manu, > > On Mon, Feb 26, 2018 at 12:31:13PM +0100, Emmanuel Hocdet wrote: >> >> Hi, >> >> According to openssl documentation: "SSL_get0_alpn_selected() returns >> a pointer to the selected protocol in data with length len. It is not >> NUL-terminated". It consern ssl_sock_get_alpn and smp_fetch_ssl_fc_alpn >> functions and impact send-proxy-v2 with alpn. The expected get is not >> an array of char but a string like other similar functions. > > Hmmm I'm sorry but I'm failing to find where it is used as a null-terminated > string. Everywhere I looked, it's used as a pointer+len, including in the > functions above. > > Unfortunately your fix is not correct, as it forces to modify a purposely > marked read-only location and overflows it by one char (to add the zero). > And in the case of the sample fetch, the resulting string will be wrong > as it will include a trailing zero as part of its value. >
Indeed, at least len should not be incremented. In ssl_sock_get_alpn(), return can be SSL_get0_next_proto_negotiated (null terminated) or SSL_get0_alpn_selected (not null terminated). I was hoping to unify this, but as you sugest, the interface is array of char + len, not string. > Where exactly did you face the problem ? I'm pretty sure that it's this > specific place which needs to be fixed. > Is for make_tlv with PP2_TYPE_ALPN. I will look at this place. Thank you for watching. Manu