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




Reply via email to