Uploaded image for project: 'Traffic Server'
  1. Traffic Server
  2. TS-3362

Do not staple negative OCSP response

Details

    • Improvement
    • Status: Closed
    • Major
    • Resolution: Won't Fix
    • None
    • None
    • SSL

    Description

      When get OCSP response, we check it before cache/staple it. If it's negative, I think we'd better discard it instead of sending back to user agent. This would not increase security risk: User agent would query CA for OCSP response if ATS does not staple it with certificate.

      Attachments

        1. TS-3362.diff
          5 kB
          Feifei Cai

        Issue Links

          Activity

            Fei, it looks like you are re-using existing metrics. Would it make sense to report these error conditions into new metrics instead of overloading the existing user_agent_unknown_cert and user_agent_revoked_cert? These metric names don't provide any hints that they may be related to OCSP.

            Also, you had a different version which reported debug messages to the "ssl_ocsp" tag instead of just "ssl". I found that useful for debugging just ocsp related issues.

            sc0ttbeardsley Scott Beardsley added a comment - Fei, it looks like you are re-using existing metrics. Would it make sense to report these error conditions into new metrics instead of overloading the existing user_agent_unknown_cert and user_agent_revoked_cert? These metric names don't provide any hints that they may be related to OCSP. Also, you had a different version which reported debug messages to the "ssl_ocsp" tag instead of just "ssl". I found that useful for debugging just ocsp related issues.
            ffcai Feifei Cai added a comment - - edited

            Oh, yes, you're right. The fetch and check of OCSP response is an independent thread, not in ssl handshake. I should report it in some new metrics, e.g. proxy.process.ssl.ocsp_revoked_certstatus, proxy.process.ssl.ocsp_unknown_certstatus...
            And, I'll extend ssl debug tag to ssl_ocsp. Will attach a new patch as soon.

            ffcai Feifei Cai added a comment - - edited Oh, yes, you're right. The fetch and check of OCSP response is an independent thread, not in ssl handshake. I should report it in some new metrics, e.g. proxy.process.ssl.ocsp_revoked_certstatus , proxy.process.ssl.ocsp_unknown_certstatus ... And, I'll extend ssl debug tag to ssl_ocsp . Will attach a new patch as soon.

            Minor comment on style - Would it be better to use a switch/case for the different statuses instead of a if/else if?

            sudheerv Sudheer Vinukonda added a comment - Minor comment on style - Would it be better to use a switch/case for the different statuses instead of a if/else if?
            jamespeach James Peach added a comment -

            Why should we not staple the negative response? If the user agent has to go and fetch it, that's an opportunity for an attacker to interrupt transaction (ie. an attacker could make the UA believe the OCSP server is unavailable). We should have a much better reason for making this change than what has been presented so far.

            jamespeach James Peach added a comment - Why should we not staple the negative response? If the user agent has to go and fetch it, that's an opportunity for an attacker to interrupt transaction (ie. an attacker could make the UA believe the OCSP server is unavailable). We should have a much better reason for making this change than what has been presented so far.
            sudheerv Sudheer Vinukonda added a comment - - edited

            Agree - If the concern is on serving a stale negative response, we could perhaps consider shorter refresh times (or even none?) for caching a negative response?

            sudheerv Sudheer Vinukonda added a comment - - edited Agree - If the concern is on serving a stale negative response, we could perhaps consider shorter refresh times (or even none?) for caching a negative response?

            Just a quick question on terminology: does "negative response" include both a fetch failure and a revoked status? It seems we might want to treat those differently.

            If we do serve revoked status we should complain (loudly) since this is a fatal error. Clients should send a bad_certificate_status_response alert but we shouldn't need to wait for that message to know about this condition.

            sc0ttbeardsley Scott Beardsley added a comment - Just a quick question on terminology: does "negative response" include both a fetch failure and a revoked status? It seems we might want to treat those differently. If we do serve revoked status we should complain (loudly) since this is a fatal error. Clients should send a bad_certificate_status_response alert but we shouldn't need to wait for that message to know about this condition.
            zwoop Leif Hedstrom added a comment -

            Do we still want to do this? If not, please close (remove fix version) as won't fix.

            zwoop Leif Hedstrom added a comment - Do we still want to do this? If not, please close (remove fix version) as won't fix.
            ffcai Feifei Cai added a comment -

            Thanks zwoop. I'll close this ticket.

            ffcai Feifei Cai added a comment - Thanks zwoop . I'll close this ticket.

            People

              Unassigned Unassigned
              ffcai Feifei Cai
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: