[Questions]Can bmcweb support both ports 80 and 443

[Ed Tanous]

On 6/4/19 11:17 AM, Vernon Mauery wrote:
> On 31-May-2019 01:01 AM, Simon Zhu(朱英澍) wrote:
>> Hello,
>>
>>     Can bmcweb support both ports 80 and 443?
>>     And then we can use http://IP <http://ip/> or https://IP
>> <https://ip/> to visit bmcweb.
> 
> In general, there should be no need to use http anymore. https provides
> security and integrity. It seems like a bad idea to put users'
> information at risk by not using https.

bmcweb can support non-TLS http via the BMCWEB_INSECURE* configuration
options, although as the name implies, they are insecure, and therefore
shouldn't be enabled for anything relating to production, but is useful
in a debug context, or to compare the performance effects of encryption
on the end result.

If what you've described is something you're wanting to enable, there's
a few options that have been discussed in the past.

1. An http redirect to https.  While not the most secure option, if
implemented with the correct security headers and in a way that can be
disabled by the end user for high security environments, it does improve
the user experience when using a browser.  I'd be in full support of
this being done, if done properly.
2. A port 80 socket that allows all functions over non-encrypted
channels.  This really shouldn't be implemented, as it would involve
sending passwords in plaintext over an unentrypted socket.
Functionally, it would almost be better to have no password at all,
which might work for some people.  If this is something you really want
to pursue, we can talk more.
3. A hybrid socket using the asio async_detect_ssl thing here:
https://www.boost.org/doc/libs/1_66_0/libs/beast/example/common/detect_ssl.hpp

I've thought this would be an interesting way to implement #1, as it
could give us a compile time option to do #2 for debugging, without a
lot of code bloat by implementing both in parallel.  It's something I've
been meaning to look into for a long time, I've just had other things.

Overall, my opinion is that in production default settings, we should
never be exposing anything of value over an unencrypted socket.

-Ed