<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:simhei,sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Lei YU <<a href="mailto:mine260309@gmail.com" target="_blank">mine260309@gmail.com</a>> 于2019年11月6日周三 上午10:02写道：<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Nov 6, 2019 at 1:20 AM James Feist <<a href="mailto:james.feist@linux.intel.com" target="_blank">james.feist@linux.intel.com</a>> wrote:<br>
><br>
> On 11/4/19 4:36 PM, Brad Bishop wrote:<br>
> ><br>
> ><br>
> >> On Oct 31, 2019, at 11:26 PM, Lei YU <<a href="mailto:mine260309@gmail.com" target="_blank">mine260309@gmail.com</a>> wrote:<br>
> >><br>
> >> On Thu, Oct 31, 2019 at 9:48 PM George Liu <<a href="mailto:liuxiwei1013@gmail.com" target="_blank">liuxiwei1013@gmail.com</a>> wrote:<br>
> >>><br>
> >>> Hi All:<br>
> >>> I'm working on http redirect to https task(<a href="https://github.com/ibm-openbmc/dev/issues/895" rel="noreferrer" target="_blank">https://github.com/ibm-openbmc/dev/issues/895</a>).<br>
> >>> I took a cursory look at the design(<a href="https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/24173" rel="noreferrer" target="_blank">https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/24173</a>) and did some testing.<br>
> >>><br>
> >>> 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.<br>
> >>> 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.<br>
> >>><br>
> >><br>
> >>>  From Ed's [mail in June][1], one approach is to use boost asio async_detect_ssl.<br>
> >><br>
> >> But I agree with George here that it costs extra and unnecessary<br>
> >> effort, because with nginx it is so easy to config the http->https<br>
> >> redirection, and it is easy to get all the https related configs<br>
> >> right, including HSTS.<br>
> >> In other words, we got such features for free (except for a few binary<br>
> >> size), why bother re-write it?<br>
> >><br>
> >> Considering the binary size, maybe it's worth the effort to check how<br>
> >> many bytes are increased compared between:<br>
> >> 1. Current implement that bmcweb handles https only<br>
> >> 2. Enable BMCWEB_INSECURE, opt-out all https related code in bmcweb,<br>
> >> adding a basic nginx and a configure file that does the https<br>
> >> redirect.<br>
> >><br>
> >> We could check the binary size to see if it's acceptable. Be noted<br>
> >> that implementing this feature in bmcweb increases the binary size as<br>
> >> well.<br>
> >><br>
> >><br>
> >> [1]: <a href="https://lists.ozlabs.org/pipermail/openbmc/2019-June/016557.html" rel="noreferrer" target="_blank">https://lists.ozlabs.org/pipermail/openbmc/2019-June/016557.html</a><br>
> ><br>
> > 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.<br>
> ><br>
> > 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?<br>
><br>
> I think these were the main concerns:<br>
> <a href="https://security.stackexchange.com/a/107106" rel="noreferrer" target="_blank">https://security.stackexchange.com/a/107106</a><br>
><br>
> Basically that since you're using HTTP, you leave yourself open for a<br>
> man-in-the-middle attack. bmcweb does do the header trick mentioned in<br>
> this post, so once you navigate to your bmc once, the browser remembers<br>
> to always use https. I think that, along with potential binary size<br>
> increases, were the biggest concerns. We also try to keep open the<br>
> minimum number of ports in general as a best practice.<br>
><br>
<br>
As the answer indicates "A way to mitigate this is to use an HSTS HTTP header"<br>
It's easy to configure nginx to use HSTS header, so it's no big deal.<br>
<br>
The potential binary size increase is a valid concern, it's worthing<br>
comparing the <span class="gmail_default" style="font-family:simhei,sans-serif"></span>binary size with and without nginx.<br></blockquote><div><br></div><div class="gmail_default" style="font-family:simhei,sans-serif"><span style="font-family:Arial,Helvetica,sans-serif">Just now, I did a test.</span></div><p>
I completely copied the <span class="gmail_default" style="font-family:simhei,sans-serif">N</span>ginx configuration of meta-ibm and compared the rofs binary size after compilation.<br>
with Nginx: 18509824<br>
without Nginx: 18022400<br></p><div class="gmail_default" style="font-family:simhei,sans-serif"><span style="font-family:Arial,Helvetica,sans-serif">refer to: </span><a href="https://github.com/openbmc/openbmc/tree/837851ae37a67b84f0f8c0fd310d33b5a731cc80/meta-ibm/recipes-httpd" title="https://github.com/openbmc/openbmc/tree/837851ae37a67b84f0f8c0fd310d33b5a731cc80/meta-ibm/recipes-httpd" style="font-family:Arial,Helvetica,sans-serif" target="_blank">https://github.com/openbmc/openbmc/tree/837851ae37a67b84f0f8c0fd310d33b5a731cc80/meta-ibm/recipes-httpd</a></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> ><br>
> > thx - brad<br>
> ><br>
</blockquote></div></div>