<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 11, 2020 at 2:34 PM Justin Sherrill <<a href="mailto:jsherril@redhat.com">jsherril@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div>
    <p>We had discussed base64 encoding the cert in the webserver on the
      way in and then letting cert guard decode it.  While that's not
      ideal I think it has some advantages over moving the full auth
      into the webserver.  What was your motivation for going with that
      approach over the base64 encoding approach? <br></p></div></blockquote><div>Thank you for this question! I ended up with a few different concerns about the base64 encode-and-forward idea. Architecturally the concern with it is that it's frowned upon to forward the client's TLS cert beyond the TLS termination point because that is what MITM software does. Also, there are some practical concerns: one, I don't think nginx can provide a similar runtime base64 encoding feature. Also I was concerned with header length truncation and what happens when the certificates get longer.</div><div><br></div><div>Overall having auth that is based on TLS certificates brought me to the conclusion that we need to auth where the TLS is terminated. What do you think?<br></div><div><br></div><div>More thoughts and questions are welcome. This is a good discussion.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p>
    </p>
    <div>On 3/11/20 2:11 PM, Brian Bouterse
      wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">
        <div>tl;dr: What we have today cannot work with rhsm
          certificates which Katello uses. To resolve, we need to have
          content guard checking moved to the webserver configs for
          apache and nginx and not done in pulp-content as it is today. 
          <a href="https://pulp.plan.io/issues/6323" target="_blank">https://pulp.plan.io/issues/6323</a></div>
        <div><br>
        </div>
        <div>We need to bring the auth to where TLS is terminated
          because we can't being the client certs to pulp-content due to
          invalid header characters. As is, pulp-certguard cannot work
          with Katello's cert types (rhsm certs) so that is driving my
          changes.</div>
        <div><br>
        </div>
        <div>If anyone has major concerns or other ideas please let me
          know. In the meantime I'm proceeding moving the authorization
          to the webserver and then updating pulp-certguard to work with
          that. This will make pulp-certguard's GA tied to pulpcore
          3.3.0. Feedback is welcome.<br>
        </div>
        <div><br>
        </div>
        <div>[0]: <a href="https://pulp.plan.io/issues/6323" target="_blank">https://pulp.plan.io/issues/6323</a><br>
          <br>
        </div>
        <div>Thanks,</div>
        <div>Brian<br>
        </div>
        <div><br>
        </div>
      </div>
      <br>
      <fieldset></fieldset>
      <pre>_______________________________________________
Pulp-dev mailing list
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a>
</pre>
    </blockquote>
  </div>

</blockquote></div></div>