HTTP redirect to HTTPS for web UI

[George Liu]

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

> On Wed, Nov 6, 2019 at 1:20 AM James Feist <james.feist at 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 at gmail.com> wrote:
> > >>
> > >> On Thu, Oct 31, 2019 at 9:48 PM George Liu <liuxiwei1013 at 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
> > >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20191106/4be871f9/attachment.htm>