HTTP redirect to HTTPS for web UI

HTTP redirect to HTTPS for web UI

[George Liu]

[-- Attachment #1: Type: text/plain, Size: 676 bytes --]

Hi All:
I'm working on http redirect to https task(
https://github.com/ibm-openbmc/dev/issues/895).
I took a cursory look at the design(
https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/24173) and did some
testing.

In bmcweb, I find it the current communication logic can only listen to one
communication protocol (http or https). If you listen to both protocols at
the same time, you need to change a lot of code and communication logic.
If we are going to implement this feature in bmcweb, it costs extra effort
and it's likely the implementation is no better than Nginx. so I prefer to
use Nginx.

Please everyone stay here to discuss and leave your comments.

Thanks!

[-- Attachment #2: Type: text/html, Size: 1348 bytes --]

Re: HTTP redirect to HTTPS for web UI

[Lei YU]

On Thu, Oct 31, 2019 at 9:48 PM George Liu <liuxiwei1013@gmail.com> wrote:
>
> Hi All:
> I'm working on http redirect to https task(https://github.com/ibm-openbmc/dev/issues/895).
> I took a cursory look at the design(https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/24173) and did some testing.
>
> In bmcweb, I find it the current communication logic can only listen to one communication protocol (http or https). If you listen to both protocols at the same time, you need to change a lot of code and communication logic.
> If we are going to implement this feature in bmcweb, it costs extra effort and it's likely the implementation is no better than Nginx. so I prefer to use Nginx.
>

From Ed's [mail in June][1], one approach is to use boost asio async_detect_ssl.

But I agree with George here that it costs extra and unnecessary
effort, because with nginx it is so easy to config the http->https
redirection, and it is easy to get all the https related configs
right, including HSTS.
In other words, we got such features for free (except for a few binary
size), why bother re-write it?

Considering the binary size, maybe it's worth the effort to check how
many bytes are increased compared between:
1. Current implement that bmcweb handles https only
2. Enable BMCWEB_INSECURE, opt-out all https related code in bmcweb,
adding a basic nginx and a configure file that does the https
redirect.

We could check the binary size to see if it's acceptable. Be noted
that implementing this feature in bmcweb increases the binary size as
well.


[1]: https://lists.ozlabs.org/pipermail/openbmc/2019-June/016557.html

Re: HTTP redirect to HTTPS for web UI

[Brad Bishop]

> On Oct 31, 2019, at 11:26 PM, Lei YU <mine260309@gmail.com> wrote:
> 
> On Thu, Oct 31, 2019 at 9:48 PM George Liu <liuxiwei1013@gmail.com> wrote:
>> 
>> Hi All:
>> I'm working on http redirect to https task(https://github.com/ibm-openbmc/dev/issues/895).
>> I took a cursory look at the design(https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/24173) and did some testing.
>> 
>> In bmcweb, I find it the current communication logic can only listen to one communication protocol (http or https). If you listen to both protocols at the same time, you need to change a lot of code and communication logic.
>> If we are going to implement this feature in bmcweb, it costs extra effort and it's likely the implementation is no better than Nginx. so I prefer to use Nginx.
>> 
> 
>> From Ed's [mail in June][1], one approach is to use boost asio async_detect_ssl.
> 
> But I agree with George here that it costs extra and unnecessary
> effort, because with nginx it is so easy to config the http->https
> redirection, and it is easy to get all the https related configs
> right, including HSTS.
> In other words, we got such features for free (except for a few binary
> size), why bother re-write it?
> 
> Considering the binary size, maybe it's worth the effort to check how
> many bytes are increased compared between:
> 1. Current implement that bmcweb handles https only
> 2. Enable BMCWEB_INSECURE, opt-out all https related code in bmcweb,
> adding a basic nginx and a configure file that does the https
> redirect.
> 
> We could check the binary size to see if it's acceptable. Be noted
> that implementing this feature in bmcweb increases the binary size as
> well.
> 
> 
> [1]: https://lists.ozlabs.org/pipermail/openbmc/2019-June/016557.html

FWIW I generally support solutions that re-use existing software and have large communities behind them already but I do remember Ed having some concerns about using bmcweb behind a proxy.

James any chance you recall what those concerns were?  I don’t think I was ever able to wrap my head around them.  Do you share Ed’s concerns?

thx - brad

Re: HTTP redirect to HTTPS for web UI

[James Feist]

On 11/4/19 4:36 PM, Brad Bishop wrote:
> 
> 
>> On Oct 31, 2019, at 11:26 PM, Lei YU <mine260309@gmail.com> wrote:
>>
>> On Thu, Oct 31, 2019 at 9:48 PM George Liu <liuxiwei1013@gmail.com> wrote:
>>>
>>> Hi All:
>>> I'm working on http redirect to https task(https://github.com/ibm-openbmc/dev/issues/895).
>>> I took a cursory look at the design(https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/24173) and did some testing.
>>>
>>> In bmcweb, I find it the current communication logic can only listen to one communication protocol (http or https). If you listen to both protocols at the same time, you need to change a lot of code and communication logic.
>>> If we are going to implement this feature in bmcweb, it costs extra effort and it's likely the implementation is no better than Nginx. so I prefer to use Nginx.
>>>
>>
>>>  From Ed's [mail in June][1], one approach is to use boost asio async_detect_ssl.
>>
>> But I agree with George here that it costs extra and unnecessary
>> effort, because with nginx it is so easy to config the http->https
>> redirection, and it is easy to get all the https related configs
>> right, including HSTS.
>> In other words, we got such features for free (except for a few binary
>> size), why bother re-write it?
>>
>> Considering the binary size, maybe it's worth the effort to check how
>> many bytes are increased compared between:
>> 1. Current implement that bmcweb handles https only
>> 2. Enable BMCWEB_INSECURE, opt-out all https related code in bmcweb,
>> adding a basic nginx and a configure file that does the https
>> redirect.
>>
>> We could check the binary size to see if it's acceptable. Be noted
>> that implementing this feature in bmcweb increases the binary size as
>> well.
>>
>>
>> [1]: https://lists.ozlabs.org/pipermail/openbmc/2019-June/016557.html
> 
> FWIW I generally support solutions that re-use existing software and have large communities behind them already but I do remember Ed having some concerns about using bmcweb behind a proxy.
> 
> James any chance you recall what those concerns were?  I don’t think I was ever able to wrap my head around them.  Do you share Ed’s concerns?

I think these were the main concerns: 
https://security.stackexchange.com/a/107106

Basically that since you're using HTTP, you leave yourself open for a 
man-in-the-middle attack. bmcweb does do the header trick mentioned in 
this post, so once you navigate to your bmc once, the browser remembers 
to always use https. I think that, along with potential binary size 
increases, were the biggest concerns. We also try to keep open the 
minimum number of ports in general as a best practice.

> 
> thx - brad
> 

Re: HTTP redirect to HTTPS for web UI

[Lei YU]

On Wed, Nov 6, 2019 at 1:20 AM James Feist <james.feist@linux.intel.com> wrote:
>
> On 11/4/19 4:36 PM, Brad Bishop wrote:
> >
> >
> >> On Oct 31, 2019, at 11:26 PM, Lei YU <mine260309@gmail.com> wrote:
> >>
> >> On Thu, Oct 31, 2019 at 9:48 PM George Liu <liuxiwei1013@gmail.com> wrote:
> >>>
> >>> Hi All:
> >>> I'm working on http redirect to https task(https://github.com/ibm-openbmc/dev/issues/895).
> >>> I took a cursory look at the design(https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/24173) and did some testing.
> >>>
> >>> In bmcweb, I find it the current communication logic can only listen to one communication protocol (http or https). If you listen to both protocols at the same time, you need to change a lot of code and communication logic.
> >>> If we are going to implement this feature in bmcweb, it costs extra effort and it's likely the implementation is no better than Nginx. so I prefer to use Nginx.
> >>>
> >>
> >>>  From Ed's [mail in June][1], one approach is to use boost asio async_detect_ssl.
> >>
> >> But I agree with George here that it costs extra and unnecessary
> >> effort, because with nginx it is so easy to config the http->https
> >> redirection, and it is easy to get all the https related configs
> >> right, including HSTS.
> >> In other words, we got such features for free (except for a few binary
> >> size), why bother re-write it?
> >>
> >> Considering the binary size, maybe it's worth the effort to check how
> >> many bytes are increased compared between:
> >> 1. Current implement that bmcweb handles https only
> >> 2. Enable BMCWEB_INSECURE, opt-out all https related code in bmcweb,
> >> adding a basic nginx and a configure file that does the https
> >> redirect.
> >>
> >> We could check the binary size to see if it's acceptable. Be noted
> >> that implementing this feature in bmcweb increases the binary size as
> >> well.
> >>
> >>
> >> [1]: https://lists.ozlabs.org/pipermail/openbmc/2019-June/016557.html
> >
> > FWIW I generally support solutions that re-use existing software and have large communities behind them already but I do remember Ed having some concerns about using bmcweb behind a proxy.
> >
> > James any chance you recall what those concerns were?  I don’t think I was ever able to wrap my head around them.  Do you share Ed’s concerns?
>
> I think these were the main concerns:
> https://security.stackexchange.com/a/107106
>
> Basically that since you're using HTTP, you leave yourself open for a
> man-in-the-middle attack. bmcweb does do the header trick mentioned in
> this post, so once you navigate to your bmc once, the browser remembers
> to always use https. I think that, along with potential binary size
> increases, were the biggest concerns. We also try to keep open the
> minimum number of ports in general as a best practice.
>

As the answer indicates "A way to mitigate this is to use an HSTS HTTP header"
It's easy to configure nginx to use HSTS header, so it's no big deal.

The potential binary size increase is a valid concern, it's worthing
comparing the binary size with and without nginx.

> >
> > thx - brad
> >

Re: HTTP redirect to HTTPS for web UI

[George Liu]

[-- Attachment #1: Type: text/plain, Size: 3756 bytes --]

Lei YU <mine260309@gmail.com> 于2019年11月6日周三 上午10:02写道：

> On Wed, Nov 6, 2019 at 1:20 AM James Feist <james.feist@linux.intel.com>
> wrote:
> >
> > On 11/4/19 4:36 PM, Brad Bishop wrote:
> > >
> > >
> > >> On Oct 31, 2019, at 11:26 PM, Lei YU <mine260309@gmail.com> wrote:
> > >>
> > >> On Thu, Oct 31, 2019 at 9:48 PM George Liu <liuxiwei1013@gmail.com>
> wrote:
> > >>>
> > >>> Hi All:
> > >>> I'm working on http redirect to https task(
> https://github.com/ibm-openbmc/dev/issues/895).
> > >>> I took a cursory look at the design(
> https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/24173) and did some
> testing.
> > >>>
> > >>> In bmcweb, I find it the current communication logic can only listen
> to one communication protocol (http or https). If you listen to both
> protocols at the same time, you need to change a lot of code and
> communication logic.
> > >>> If we are going to implement this feature in bmcweb, it costs extra
> effort and it's likely the implementation is no better than Nginx. so I
> prefer to use Nginx.
> > >>>
> > >>
> > >>>  From Ed's [mail in June][1], one approach is to use boost asio
> async_detect_ssl.
> > >>
> > >> But I agree with George here that it costs extra and unnecessary
> > >> effort, because with nginx it is so easy to config the http->https
> > >> redirection, and it is easy to get all the https related configs
> > >> right, including HSTS.
> > >> In other words, we got such features for free (except for a few binary
> > >> size), why bother re-write it?
> > >>
> > >> Considering the binary size, maybe it's worth the effort to check how
> > >> many bytes are increased compared between:
> > >> 1. Current implement that bmcweb handles https only
> > >> 2. Enable BMCWEB_INSECURE, opt-out all https related code in bmcweb,
> > >> adding a basic nginx and a configure file that does the https
> > >> redirect.
> > >>
> > >> We could check the binary size to see if it's acceptable. Be noted
> > >> that implementing this feature in bmcweb increases the binary size as
> > >> well.
> > >>
> > >>
> > >> [1]: https://lists.ozlabs.org/pipermail/openbmc/2019-June/016557.html
> > >
> > > FWIW I generally support solutions that re-use existing software and
> have large communities behind them already but I do remember Ed having some
> concerns about using bmcweb behind a proxy.
> > >
> > > James any chance you recall what those concerns were?  I don’t think I
> was ever able to wrap my head around them.  Do you share Ed’s concerns?
> >
> > I think these were the main concerns:
> > https://security.stackexchange.com/a/107106
> >
> > Basically that since you're using HTTP, you leave yourself open for a
> > man-in-the-middle attack. bmcweb does do the header trick mentioned in
> > this post, so once you navigate to your bmc once, the browser remembers
> > to always use https. I think that, along with potential binary size
> > increases, were the biggest concerns. We also try to keep open the
> > minimum number of ports in general as a best practice.
> >
>
> As the answer indicates "A way to mitigate this is to use an HSTS HTTP
> header"
> It's easy to configure nginx to use HSTS header, so it's no big deal.
>
> The potential binary size increase is a valid concern, it's worthing
> comparing the binary size with and without nginx.
>

Just now, I did a test.

I completely copied the Nginx configuration of meta-ibm and compared the
rofs binary size after compilation.
with Nginx: 18509824
without Nginx: 18022400
refer to:
https://github.com/openbmc/openbmc/tree/837851ae37a67b84f0f8c0fd310d33b5a731cc80/meta-ibm/recipes-httpd

>
> > >
> > > thx - brad
> > >
>

[-- Attachment #2: Type: text/html, Size: 6163 bytes --]

Re: HTTP redirect to HTTPS for web UI

[James Feist]

On 11/5/19 7:23 PM, George Liu wrote:
> 
> 
> Lei YU <mine260309@gmail.com <mailto:mine260309@gmail.com>> 于2019年11月 
> 6日周三 上午10:02写道：
> 
>     On Wed, Nov 6, 2019 at 1:20 AM James Feist
>     <james.feist@linux.intel.com <mailto:james.feist@linux.intel.com>>
>     wrote:
>      >
>      > On 11/4/19 4:36 PM, Brad Bishop wrote:
>      > >
>      > >
>      > >> On Oct 31, 2019, at 11:26 PM, Lei YU <mine260309@gmail.com
>     <mailto:mine260309@gmail.com>> wrote:
>      > >>
>      > >> On Thu, Oct 31, 2019 at 9:48 PM George Liu
>     <liuxiwei1013@gmail.com <mailto:liuxiwei1013@gmail.com>> wrote:
>      > >>>
>      > >>> Hi All:
>      > >>> I'm working on http redirect to https
>     task(https://github.com/ibm-openbmc/dev/issues/895).
>      > >>> I took a cursory look at the
>     design(https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/24173)
>     and did some testing.
>      > >>>
>      > >>> In bmcweb, I find it the current communication logic can only
>     listen to one communication protocol (http or https). If you listen
>     to both protocols at the same time, you need to change a lot of code
>     and communication logic.
>      > >>> If we are going to implement this feature in bmcweb, it costs
>     extra effort and it's likely the implementation is no better than
>     Nginx. so I prefer to use Nginx.
>      > >>>
>      > >>
>      > >>>  From Ed's [mail in June][1], one approach is to use boost
>     asio async_detect_ssl.
>      > >>
>      > >> But I agree with George here that it costs extra and unnecessary
>      > >> effort, because with nginx it is so easy to config the http->https
>      > >> redirection, and it is easy to get all the https related configs
>      > >> right, including HSTS.
>      > >> In other words, we got such features for free (except for a
>     few binary
>      > >> size), why bother re-write it?
>      > >>
>      > >> Considering the binary size, maybe it's worth the effort to
>     check how
>      > >> many bytes are increased compared between:
>      > >> 1. Current implement that bmcweb handles https only
>      > >> 2. Enable BMCWEB_INSECURE, opt-out all https related code in
>     bmcweb,
>      > >> adding a basic nginx and a configure file that does the https
>      > >> redirect.
>      > >>
>      > >> We could check the binary size to see if it's acceptable. Be noted
>      > >> that implementing this feature in bmcweb increases the binary
>     size as
>      > >> well.
>      > >>
>      > >>
>      > >> [1]:
>     https://lists.ozlabs.org/pipermail/openbmc/2019-June/016557.html
>      > >
>      > > FWIW I generally support solutions that re-use existing
>     software and have large communities behind them already but I do
>     remember Ed having some concerns about using bmcweb behind a proxy.
>      > >
>      > > James any chance you recall what those concerns were?  I don’t
>     think I was ever able to wrap my head around them.  Do you share
>     Ed’s concerns?
>      >
>      > I think these were the main concerns:
>      > https://security.stackexchange.com/a/107106
>      >
>      > Basically that since you're using HTTP, you leave yourself open for a
>      > man-in-the-middle attack. bmcweb does do the header trick
>     mentioned in
>      > this post, so once you navigate to your bmc once, the browser
>     remembers
>      > to always use https. I think that, along with potential binary size
>      > increases, were the biggest concerns. We also try to keep open the
>      > minimum number of ports in general as a best practice.
>      >
> 
>     As the answer indicates "A way to mitigate this is to use an HSTS
>     HTTP header"
>     It's easy to configure nginx to use HSTS header, so it's no big deal.

bmcweb already does this 
https://github.com/openbmc/bmcweb/blob/07a602993f1007b0b0b764bdb3f14f302a8d2e26/http/websocket.h#L92

https://github.com/openbmc/bmcweb/blob/07a602993f1007b0b0b764bdb3f14f302a8d2e26/include/security_headers_middleware.hpp#L32


> 
>     The potential binary size increase is a valid concern, it's worthing
>     comparing the binary size with and without nginx.
> 
> 
> Just now, I did a test.
> 
> I completely copied the Nginx configuration of meta-ibm and compared the 
> rofs binary size after compilation.
> with Nginx: 18509824
> without Nginx: 18022400
> 
> refer to: 
> https://github.com/openbmc/openbmc/tree/837851ae37a67b84f0f8c0fd310d33b5a731cc80/meta-ibm/recipes-httpd
> 
> 
>      > >
>      > > thx - brad
>      > >
> 

Re: HTTP redirect to HTTPS for web UI

[Brad Bishop]

> On Oct 31, 2019, at 9:45 AM, George Liu <liuxiwei1013@gmail.com> wrote:
> 
> Hi All:
> I'm working on http redirect to https task(https://github.com/ibm-openbmc/dev/issues/895).
> I took a cursory look at the design(https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/24173) and did some testing.
> 
> In bmcweb, I find it the current communication logic can only listen to one communication protocol (http or https). If you listen to both protocols at the same time, you need to change a lot of code and communication logic.
> If we are going to implement this feature in bmcweb, it costs extra effort and it's likely the implementation is no better than Nginx. so I prefer to use Nginx.
> 
> Please everyone stay here to discuss and leave your comments.
> 
> Thanks!

Hi George

I see you implemented this here:

https://gerrit.openbmc-project.xyz/c/openbmc/meta-openpower/+/28099

I’d like to propose this go in meta-phosphor and not meta-openpower.  Does anyone have thoughts on whether or not this should be enabled or disabled by default?

thx - brad

Re: HTTP redirect to HTTPS for web UI

[Lei YU]

On Mon, Jan 6, 2020 at 11:20 PM Brad Bishop <bradleyb@fuzziesquirrel.com> wrote:
>
>
>
> > On Oct 31, 2019, at 9:45 AM, George Liu <liuxiwei1013@gmail.com> wrote:
> >
> > Hi All:
> > I'm working on http redirect to https task(https://github.com/ibm-openbmc/dev/issues/895).
> > I took a cursory look at the design(https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/24173) and did some testing.
> >
> > In bmcweb, I find it the current communication logic can only listen to one communication protocol (http or https). If you listen to both protocols at the same time, you need to change a lot of code and communication logic.
> > If we are going to implement this feature in bmcweb, it costs extra effort and it's likely the implementation is no better than Nginx. so I prefer to use Nginx.
> >
> > Please everyone stay here to discuss and leave your comments.
> >
> > Thanks!
>
> Hi George
>
> I see you implemented this here:
>
> https://gerrit.openbmc-project.xyz/c/openbmc/meta-openpower/+/28099
>
> I’d like to propose this go in meta-phosphor and not meta-openpower.  Does anyone have thoughts on whether or not this should be enabled or disabled by default?

As I remember we had some discussion in the mailing list, and Intel
indicated that it's not a wanted feature.
But it does make sense to put the recipe into meta-phosphor, and one
could enable it in some company or machine layer.