Skip to content
This repository was archived by the owner on Sep 16, 2021. It is now read-only.
This repository was archived by the owner on Sep 16, 2021. It is now read-only.

Check local evaluation of secure constraints. #179

Open
Open
Check local evaluation of secure constraints.#179
Labels
question

Description

@gregw
gregw
opened on Feb 18, 2016

While debugging #164, it appears that http requests were able to terminate on the instance despite there being a confidential security constraint.

We need to verify if this really is possible? Perhaps only when the instance host is specified?
If so, we need to check the yaml generated constraints for confidential constraints. We should also consider ensuring that the normal jetty constraint processing is in place as a second line of defense.

Activity

  1. gregw
    added
    bug
    on Feb 18, 2016

  2. gregw commented on Feb 24, 2016

    @gregw
    gregw
    on Feb 24, 2016
    ContributorAuthor

    I think there was some confusion as the stage 3 guestbook has only a role constraint and not a data constraint. Testing with some data constraints indicates that all it working as it should.

  3. gregw
    closed this as completedon Feb 24, 2016

  4. ludoch commented on Feb 24, 2016

    @ludoch
    ludoch
    on Feb 24, 2016
    Contributor

    ha, you mean adding

    CONFIDENTIAL

    ?

    On Wed, Feb 24, 2016 at 6:55 AM, Greg Wilkins notifications@github.com
    wrote:

    Closed #179
    #179
    .

    —
    Reply to this email directly or view it on GitHub
    #179 (comment)
    .

  5. gregw commented on Feb 24, 2016

    @gregw
    gregw
    on Feb 24, 2016
    ContributorAuthor

    Yep,

    I tested with:

      <security-constraint>
    <web-resource-collection>
      <web-resource-name>data-constraint</web-resource-name>
      <url-pattern>/dump/ssl/*</url-pattern>
    </web-resource-collection>
    <user-data-constraint><transport-guarantee>CONFIDENTIAL</transport-guarantee></user-data-constraint>
  </security-constraint>
  <security-constraint>
    <web-resource-collection>
      <web-resource-name>data-constraint</web-resource-name>
      <url-pattern>/dump/relax/*</url-pattern>
    </web-resource-collection>
  </security-constraint>

    and all behaved as expected.

  6. ludoch commented on Feb 24, 2016

    @ludoch
    ludoch
    on Feb 24, 2016
    Contributor

    Yes! Thanks for the investigation...
    Now, for none default versions, you have to add the -dot- separator between
    the version and appname in the url, so it is more complicated for samples,
    but hey!

    On Wed, Feb 24, 2016 at 7:32 AM, Greg Wilkins notifications@github.com
    wrote:

    Yep,

    I tested with:

    data-constraint /dump/ssl/_ CONFIDENTIAL data-constraint /dump/relax/_

    and all behaved as expected.

    —
    Reply to this email directly or view it on GitHub
    #179 (comment)
    .

  7. lesv commented on Feb 24, 2016

    @lesv
    lesv
    on Feb 24, 2016

    To test, try http://1.project.appspot.com -- If security constraints are
    set properly, it won't work, if not, it might.

    On Wed, Feb 24, 2016 at 7:42 AM, Ludovic Champenois <
    notifications@github.com> wrote:

    Yes! Thanks for the investigation...
    Now, for none default versions, you have to add the -dot- separator between
    the version and appname in the url, so it is more complicated for samples,
    but hey!

    On Wed, Feb 24, 2016 at 7:32 AM, Greg Wilkins notifications@github.com
    wrote:

    Yep,

    I tested with:

    data-constraint /dump/ssl/*

    CONFIDENTIAL



    data-constraint
    /dump/relax/*

    and all behaved as expected.

    —
    Reply to this email directly or view it on GitHub
    <
    #179 (comment)

    .

    —
    Reply to this email directly or view it on GitHub
    #179 (comment)
    .

    • • *Les Vogel
    • • *Cloud Developer Relations
    • • *lesv@google.com
    • • *+1-4 <%2B1-650-338-7103>08-676-7023
  8. gregw
    reopened this on Feb 25, 2016

  9. gregw commented on Feb 25, 2016

    @gregw
    gregw
    on Feb 25, 2016
    ContributorAuthor

    Reopened just so we can discuss and make sure all is OK. My test webapp with the constraints above is current deploy as default and as 20160224t154511. I have tried the following requests:

    So most of those look good and none look dangerous. A few look a little hard to explain....

  10. gregw commented on Feb 25, 2016

    @gregw
    gregw
    on Feb 25, 2016
    ContributorAuthor

    Ah I was actually logged on for some of those, so the first correctly does redirect to auth.

    So the only real mystery is why http to instance.version gives a 404, yet http to instance.default works?

  11. gregw
    added
    question
    and removed
    bug
    on Feb 25, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    question

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions