PR to set SNI during boost lib websocket next_layer() SSL handshake process happen during launch of app tunneling.

[jaiswal-sumit]

This PR to set SNI during boost lib websocket next_layer() SSL handshake process happen during launch of app tunneling.

Motivation

• We have a use case for running AWS IoT secure tunnel within a Customer Managed VPN, along with a proxy service infrastructure to route multiple external services on a single domain. During the Customer Managed VPN setup, we noticed that the SSL handshake was failing when launching the local proxy. After a detailed investigation of the issue, we found that the code was not setting the Server Name Indication (SNI) during the initial SSL handshake call in the 'Client Hello' of the next_layer() SSL handshake code.
• This issue is linked to the Boost Beast WebSocket Secure (WSS) stream library code, which does not supply SNI by default during the next_layer() async_ssl_handshake() function. Therefore, following the example provided by the Boost library, it is suggested to use the SSL_set_tlsext_host_name function to set the SNI.
• This PR aims to resolve the SSL handshake issue and ensure that the code functions correctly in both non-VPN and VPN application tunnels.
• Issue number: AWS Case id: 13813696371

Modifications

Change summary

Supplied host string From TcpAdapter which initiates async_ssl_hanshake
Extend WebSocketStream async_ssl_hanshake to take host string and use that to set SNI.
WebSocketSteam async_ssl_hanshake() code added with SSL_set_tlsext_host_name to set SNI with host string.

Revision diff summary

NA

Testing

**Is your change tested? Yes
Please list your testing steps and test results.
Login into CMVPN infra,
Deploy the fixed code localproxy execuable
open the tunnel.
Check the connection status
Connection status found connected at both sides

• CI test run result: NA

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[RogerZhongAWS]

Hey, thanks the description of your issue and for your contribution. This looks fine to me, will merge as soon as we get a second approval on this.

[abeytr]

We tested this for the following workflows and it is working as expected:

1. localProxy connection over private urls
2. localProxy connection over public urls