You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@trafficserver.apache.org by Jered Floyd <je...@convivian.com> on 2017/01/23 17:40:10 UTC
What dangers (if any) to enabling OCSP Stapling?
OCSP Stapling is off by default in ATS.
What risks, if any, are there to enabling it? Given that my issuer supports OCSP and many browsers support OCSP and OCSP Stapling, it seems like enabling it is the "safest" option. Is there a reason it is not on by default?
--Jered
Re: What dangers (if any) to enabling OCSP Stapling?
Posted by Jered Floyd <je...@convivian.com>.
Ah yes; on closer inspection I see that the problem site has stapled an OCSP trylater response. Ugh.
--Jered
----- On Jan 23, 2017, at 1:53 PM, Reindl Harald h.reindl@thelounge.net wrote:
> Am 23.01.2017 um 19:47 schrieb Jered Floyd:
>> This is exactly why I'm asking if Stapling should be enabled/default; to protect
>> against third-party infrastructure leading to downtime.
>>
>> Today I encountered a site where the OCSP Responder for their CA was providing
>> sec_error_ocsp_try_server_later and Firefox now defaults to not loading the
>> site! Were they OCSP Stapling, they may had still had a valid cached response.
>
> the opposite
>
> that is mostly caused by stapling while firefox as all major browsers
> would have just ignored OCSP when it is down without stapling but the
> stapling cached the try-later
>
> hence the two params in my httpd config and as long nobody confirms that
> behavior for ATS i would not enable stapling at all
>
>> ----- On Jan 23, 2017, at 1:12 PM, Reindl Harald h.reindl@thelounge.net wrote:
>>
>>> Am 23.01.2017 um 18:40 schrieb Jered Floyd:
>>>> OCSP Stapling is off by default in ATS.
>>>>
>>>> What risks, if any, are there to enabling it? Given that my issuer
>>>> supports OCSP and many browsers support OCSP and OCSP Stapling, it seems
>>>> like enabling it is the "safest" option. Is there a reason it is not on
>>>> by default?
>>>
>>> not sure how ATS is handling this, with httpd i had a lot of fun in
>>> timeframes where the godaddy responsers where unstable up to not be able
>>> to connect to internal admin backends until set the following values in
>>> the global configuration
>>>
>>> SSLStaplingReturnResponderErrors Off
> >> SSLStaplingFakeTryLater Off
Re: What dangers (if any) to enabling OCSP Stapling?
Posted by Reindl Harald <h....@thelounge.net>.
Am 23.01.2017 um 19:47 schrieb Jered Floyd:
> This is exactly why I'm asking if Stapling should be enabled/default; to protect against third-party infrastructure leading to downtime.
>
> Today I encountered a site where the OCSP Responder for their CA was providing sec_error_ocsp_try_server_later and Firefox now defaults to not loading the site! Were they OCSP Stapling, they may had still had a valid cached response.
the opposite
that is mostly caused by stapling while firefox as all major browsers
would have just ignored OCSP when it is down without stapling but the
stapling cached the try-later
hence the two params in my httpd config and as long nobody confirms that
behavior for ATS i would not enable stapling at all
> ----- On Jan 23, 2017, at 1:12 PM, Reindl Harald h.reindl@thelounge.net wrote:
>
>> Am 23.01.2017 um 18:40 schrieb Jered Floyd:
>>> OCSP Stapling is off by default in ATS.
>>>
>>> What risks, if any, are there to enabling it? Given that my issuer
>>> supports OCSP and many browsers support OCSP and OCSP Stapling, it seems
>>> like enabling it is the "safest" option. Is there a reason it is not on
>>> by default?
>>
>> not sure how ATS is handling this, with httpd i had a lot of fun in
>> timeframes where the godaddy responsers where unstable up to not be able
>> to connect to internal admin backends until set the following values in
>> the global configuration
>>
>> SSLStaplingReturnResponderErrors Off
>> SSLStaplingFakeTryLater Off
Re: What dangers (if any) to enabling OCSP Stapling?
Posted by Jered Floyd <je...@convivian.com>.
Harald,
This is exactly why I'm asking if Stapling should be enabled/default; to protect against third-party infrastructure leading to downtime.
Today I encountered a site where the OCSP Responder for their CA was providing sec_error_ocsp_try_server_later and Firefox now defaults to not loading the site! Were they OCSP Stapling, they may had still had a valid cached response.
--Jered
----- On Jan 23, 2017, at 1:12 PM, Reindl Harald h.reindl@thelounge.net wrote:
> Am 23.01.2017 um 18:40 schrieb Jered Floyd:
>> OCSP Stapling is off by default in ATS.
>>
>> What risks, if any, are there to enabling it? Given that my issuer
>> supports OCSP and many browsers support OCSP and OCSP Stapling, it seems
>> like enabling it is the "safest" option. Is there a reason it is not on
>> by default?
>
> not sure how ATS is handling this, with httpd i had a lot of fun in
> timeframes where the godaddy responsers where unstable up to not be able
> to connect to internal admin backends until set the following values in
> the global configuration
>
> SSLStaplingReturnResponderErrors Off
> SSLStaplingFakeTryLater Off
Re: What dangers (if any) to enabling OCSP Stapling?
Posted by Reindl Harald <h....@thelounge.net>.
Am 23.01.2017 um 18:40 schrieb Jered Floyd:
> OCSP Stapling is off by default in ATS.
>
> What risks, if any, are there to enabling it? Given that my issuer
> supports OCSP and many browsers support OCSP and OCSP Stapling, it seems
> like enabling it is the "safest" option. Is there a reason it is not on
> by default?
not sure how ATS is handling this, with httpd i had a lot of fun in
timeframes where the godaddy responsers where unstable up to not be able
to connect to internal admin backends until set the following values in
the global configuration
SSLStaplingReturnResponderErrors Off
SSLStaplingFakeTryLater Off